Author: Adam Johnson <AdamJohnso@gmail.com>
Date: Sun Mar 25 21:08:57 2018 -0400
Add workaround for mouse handling bug in Win10 FCU
Windows 10 Fall Creators Update changed the behavior of SetCursorPos,
which no longer sends the expected WM_MOUSEMOVE message when
recentering the cursor. This adds a function to detect affected
versions of Windows and flags the necessity to manually send our own
message.
This workaround currently only detects the known affected version of
Win10, in the hope that it will be fixed and no further attention
will be required. If this regression is not fixed, additional Win10
versions can be added.
Author: Adam Johnson <AdamJohnso@gmail.com>
Date: Tue Feb 5 18:59:20 2013 -0500
Reintroduce a fun hack
Yeah, looks like PhysX 2.6.4 has a bug with spawning stuff inside of
regions. So, let's bring back the hack that spawns the avatar at -2000
feet. The link-in process will set the correct position on the controller
and fire the appropriate detectors.
Author: Adam Johnson <AdamJohnso@gmail.com>
Date: Fri Feb 8 00:15:56 2013 -0500
Fix crazy camera stack issues
Turns out, it was an artifact of us suspending the simulation during links
and partly because of Cyan's late adding of the avatar controller to the
sim. Now, we add the avatar as soon as the age data is loaded. This causes
the camera stack to be populated with whatever garbage PhysX decides on,
then xJourneyClothsGen2 is free to set the real stack after we get all the
SDL from the server.
Verified to fix Teledahn oddness and not display a regression in Kemo.
Author: Adam Johnson <AdamJohnso@gmail.com>
Date: Mon Feb 6 21:17:08 2012 -0500
Fix an obvious memory leak.
This thing was pissing me off, which made me piss off a lot of other people,
which pissed off even more people, so the entire planet got pissed off and
nuclear warfare began. So, let's not do stupid crap and piss me off, okay?
Author: Adam Johnson
Date: Fri Feb 10 12:45:14 2012 -0500
More panic link fixes
Now, we check the armature mod to see if we're REALLY linked in (the screen
is not black). That way, we can be sure all delayed transforms and false
hits (like how we initially spawn into the AhnySphere04 panic region) don't
panic link us.
PhysX requires all of its actors to have cooked mesh data. This cooked
data is unfortunately not compatible with other versions of PhysX outside
of the minor branch. The format is also largely unknown. Therefore, it is
relevant to allow CWE prps to include an engine agnostic physical format
to reduce our dependencies on proprietary libraries.
All PhysX blobs thankfully begin with the magic string NXS\x01, so we now
abuse that by adding our own format that begins with the magic string
HSP\x01. These blobs are cooked on the fly while already cooked blobs are
passed directly on to PhysX.
Original commit: 392c5f5cad
author = "Adam Johnson <AdamJohnso@gmail.com>
This also allows for future expansion of new hash techniques to be added, of course the more hash techniques added the more delay at login for the lowest on the totem pole.
I have tested this against the MOULa shard that uses SHA-0 and it works, there is a slight flash of the "Connecting dialog" as it re-tries sending the login but if the user saves the password, there is no flash and no delay.
and reenable as much USE_BINK_SDK stuff as empirically needed to get the Yeesha intro movie cave to disappear on its own, as before merging Cyan's Build 918.
Not the cleanest way, but I'm trying to minimize effort spent on this until we can get the proper solution, VP9 video support, from https://github.com/H-uru/Plasma/pull/458 .
In this case it now also works for non-owners of the age. Previously it only worked for owners because the ageInfoStruct does not contain the vault node ID, so it needed to be looked up somewhere, and that was in the AgesIOwnFolder.
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.
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.
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.
Adam Johnson
rarified
cjkelly1
CyanWorlds
Ian McIntosh
Christian Walther
Anne Marije v/d Meer