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.
