plRegistryKeyList::Read assumed that plUoid object IDs are always
sequential. This is not the case since f664e8b resulted in all keys
getting an ID. The problem manifested itself here because there were
temporary materials that were being created and thrown away, causing
object ID gaps.
This fixes some of the "multiple definition of symbol" warnings we get
from the linker. I checked this against the OU AllDlls solution and
deleted the version not present in it.
Due to a complicated set of circumstances, this was the problem that
caused console key input eating on Gehn. Always remember kids, ifdef
include hackery is teh ebils.
So, yeah, this blows away MaxSceneViewer. We're never going to get around
to fixing that. In exchange for this massive code explosion, you get a
free MaxFileData stub type thing. It keeps all the data just so we don't
blow up Cyan's plugins. This fixes the "Missing Dll" messages people keep
whining about.
Shhh! I'm sneaking this "feature" in for Gehn 18. The idea is that we
should no longer require MOULa installs for the installer to work. So,
after we've extracted the files but before we quit the installer, we fire
up `UruLauncher.exe -Repair -ServerIni=repair.ini -PatchOnly`. This will
download all the standard MOULa stuff, exit, and the install finishes.
Whew!
It appears that the hsTArray memory management really sucks for smart
pointers like plKey. The crash mentioned at
http://forum.guildofwriters.org/viewtopic.php?f=117&t=6291 went away
immediately after switching plKeyCollector to an std::set.
This was overlooked when the consolidation was done in 3027e0605c.
With this fix, the number of frames to be loaded is entirely defined
in a single place. This also prepares the code for a future commit
to remove the necessity of the compile-time definition entirely.
So this is interesting. If you disable Planar Reflections and visit an age with a DCM, you will crash after a few minutes. This is because plDynamicCamMap is sending the wrong plRefMsg to the plLayer. This does nothing (aside from waste time), so we keep sending the ref again and again and again and again until we get some weird heap corruption and KABLOOOOOOOOOOOEY!
So, it appears that once our dialog is created, the DialogBox windowproc
is nuked. So, to hack around this, any errors that occur while it is open
are cached and reported out after we close everything down. It sucks, but
it works. I blame Microsoft.
This is the crowning feature: the whole point of this exercise. You can
now update redists from the client launcher itself. To activate this
functionality, you will need to flag the file 0x10 in the manifest. I
recommend listing your redists in the patcher manifests.
This adds a license-stopgap "feature" ... You can now update only the game
data by using the -Repair argument on the launcher. You'll need to specify
a stripped down MOULa server.ini with the GateKeeperSrv keys/host.
This argument works just like it does in Guild Wars. It checks all the
files (using Cyan's evil "Internal" and "External" manifests) for changes.
Expect this to take a decent amount of time.
Two of the big nasties, according to profiling, are the TnL enum and
creation of Direct3D objects. It turned out we were doing these things
several times (3 and 4 respectively) during the init process. So, now we
have an hsGDirect3D namespace and some smart pointers to manage them!
Remove detection for cards that are don't support at LEAST DirectX 8.
There's no way they would even be able to get past Direct3DCreate9, so we
shouldn't need to worry about them... I hope.
If you have less than 11MB VRAM or need to use the ref implementation,
then you are using a dinosaur and have no business even attempting to play
this game.
We already link against it, so that's just a waste of time. Also, cleanup
some unneeded ddraw includes. Remember that in Direct3D9, all devices can
render in windowed mode.
Branan Purvine-Riley