Also, the text of the faded-out player list is re-rendered with alpha == 0 every time the mouse enters its area, do a little less needless work in that case.
Previous revision didn't work, many controls retained their shadows because they never got the new flags from the color scheme and put them into the dynamic text map. I haven't checked if any more of the many control classes are affected, but those that we need in the KI right now are covered.
The fix (adding adjustment of fRenderInfo.fDestPtr) made kRenderJustXForceLeft behave as intended (left-aligning the edge of the bitmap rather than the side bearing of the first character) but cuts off shadows in some places (e.g. at the left edges of "BUDDIES" and "NEIGHBORS" in the mini KI). To ensure enough space for the shadow, and considering that all content was developed and visually optimized with the bug in place, it seems better to preserve the buggy behavior and make kRenderJustXForceLeft work exactly like kRenderJustXLeft.
Intended to make KI text (player list and chat) better readable on light and patterned backgrounds. In this WIP, all text on GUI controls is rendered shadowed.
This fixes the irregular dark fringes around light text when not exactly pixel-aligned that are caused by independent interpolation of color and alpha. It also makes calculations simpler for things to come.
In addition to being a prerequisite for shadowed text, this also fixes an issue sometimes seen at the bottom of the mini KI player list where characters with a descender were missing.
Should work for Cyan too because plClient uses the same libraries.
I wonder what the purpose of the Release_Patcher configuration is and whether we should be using that one, which already has all this stuff (with slight differences).
- Remove plCyDebug and NetDiag which we don't have (from ef365800375c)
- Remove pfCCR which we no longer have (since 791583dea277)
- Add plUruLauncher and plClientPatcher (from ef365800375c)
- Add plFileEncrypt, plFileSecure, plPythonPack (from f3497c6d7f6d)
I also took the liberty of restoring the post-build copy step for plFileEncrypt and plFileSecure. If Cyan doesn't want that, we can probably put it in a separate project that is only part of AllClient-ou.sln but not AllClient.sln.
- plCCRMgr.h which is still needed by plAvatarMgr.cpp (plCCRError only - if there is more in this file at Cyan, that definition should be split out into a separate header)
- Stubs for pyCCRMgr{|Glue|Glue2}.cpp which are still part of the pfPython project as well as pfCCRConsoleCommands.cpp which is still part of the pfConsole project. This is under the assumption that these files still exist with nontrivial contents at Cyan - if not, they could just be removed from the projects. Requires adjustment by Cyan to build with PLASMA_CCR_RELEASE.
- Put more missing includes and calls under #ifdef PLASMA_CCR_RELEASE
Those who have the EAX SDK should indicate this on the command line by adding /DEAX_SDK_AVAILABLE to environment variable CL.
Trying to keep common project files and configurations between OU and Cyan for now, we'll see how that goes.
Too many changes to describe in detail, see commits on parent branch build918chunks.
Some of them break buildability outside of Cyan, to be fixed in subsequent commits.
Merge conflicts in some .sln and .vcproj files all resolved by taking the Cyan version.
MarkD: My thought was for the long term was to put most of the differences in the project and solution configurations, so there would be less differences in the sources. EAX is a good example - I put the #define for EAX_SDK_AVAILABLE in the projects that used it with the thinking that the fans would create new projects that would not have EAX_SDK_AVAILABLE and would create and use a different configuration in the AllClient solution. Cyan would use the "Release" config and the fans use something like "Release-ou" to build with. But maybe there are just too many differences.
MarkD: We felt that the fan de-BINKing did not go far enough.
CW: I suspect (haven't tested yet) that it's the cause of the bug that we see on MOULa but did not on Minkata where the rotating wall behind the missing Yeesha intro video stays indefinitely, with no obvious way out for the player, until it occurs to them to use the ESC key
MarkD: Ah. I think you are right. An oversight that can be easily corrected - maybe in the python code so that Ian can see the rotating wall for a few seconds and then auto continue on.
Copy of plJPEG with added preprocessor definition IJL_SDK_AVAILABLE.
CW: I'm guessing that's the workaround for the missing JPEG textures issue we found during the 918 update verification.
MarkD: Exactly.
Except for the addition of the plClipboard project, the partial CWE-ou state that was mistakenly taken into CWE in "Build 912" (a757a1fda0a3) was never actually used to build MOULa products.
Free the cursor, update
Updates to pull request #21 by Hoikas that fix the issue that quick mouse moves while walking/looking by mouse could get the cursor out of the window and break the continuous turning.
From H-uru PR #221 "Window fixes".
Fix remote code execution through Python.Cheat and Python.RunFile
An exploit fixed by boq. Original pull request: https://github.com/H-uru/Plasma/pull/218
This somewhat modifies the syntax used for running Python.Cheat; it's still easier to use it directly in Python, though.
Avatar physics update
A significant and much needed cleanup of the avatar physics code. It resolves numerous issue with and greatly simplifies the physx character controller implementation.
While there is still room for improvement, this is a good starting point.
Avatars now jump consistently, regardless of cpu speed. Fixes unexpected camera transitions with entering/exiting some subworlds. (Teledahn elevator) Fixes a jitter in animated subworlds. (Er'cana harvester) Dynamic controllers are correctly positioned on the ground. (Jalak) Much improved interaction with dynamic physicals.
Other physics related issues may or may not be addressed.
Port of H-uru #236 and #237. This adds stubs for the removed Bink files, to make things compile and run again, with just enough functionality to replicate the previous behavior when built without BINK_SDK_AVAILABLE, i.e. movies are treated as zero-length.
