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.
fix plVault LogMsg calls + remove useless wide char usage
fix usage of plAvatarMgr::FindAvatar() and plLinkEffectsTriggerMsg::SetLinkKey() with temporary variables
plNetServerSessionInfo.h need std::string
fix plProgressMgr.h: NumLoadingFrames() have an useless class context information
fix plSocket usage of non-standard NULL
This reduces the amount of redundant #includes in the plMessage headers.
Still need to check over the actual source files and do some work to
remove pnUtils (ugh) from one message.
plMouseDevice::HideCursor can crash if it is called before the cursor is
created. This happens if the client pops up a disconnected dialog before
initialization is complete. I've seen it happen!
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.
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!
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!