- Fixed the status thread waiting many seconds before requesting the status for the first time.
- Fixed msi execution by removing the workaround for mapped network drives. That seems like a corner-case not worth worrying about anyway.
- Fixed total bytes being updated too late, causing interesting download progress.
(cherry picked from commit a893d74a209b44c683552358dedb6c85f9924bf8)
To register an update for install, there are three options:
- List any executable or msi file in the [External|Internal]Patcher manifest.
- As above, but in the *optional* DependencyPatcher manifest.
- Flag a file with the bit flag 0x10 in either of the above manifests.
This also fixes a bug that caused the status thread to deadlock in certain situations, causing the launcher to get stuck open.
(cherry picked from commit e0e918084395f93170abcea2853ad25ae3012385)
This should keep the avatar from getting stuck on some stupid stuff such
as on the pellet machine. A real fix would be to tweak the data, but we
cannot do that.
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.
Don't crash the launcher when the HTTP request for getting the server status message fails
This should fix the crash in UruLauncher.exe after starting UruExplorer.exe, reported by Treehugger at http://forums.openuru.org/viewtopic.php?p=8976#p8976 . It is the same issue as addressed in pull request #31 for the login dialog.
Untested because testing it is hard when the launcher patches itself out.