These checks introduced a hidden race condition. If the initial avatar
physical update comes in after the initial avatar update (always happens
on DirtSand, never happens on MOUL), then the physical update could be
rejected if the avatar is sitting on the ground or on a sitting modifier
(this adds stages, which count as a task). This results in seeing an
avatar sitting at the link in point. Whoops!
I can think of no cases where these checks are actually useful. It's also
difficult to determine if we are linking in due to the fact that we're in
the grey area between loading the entire age and fading the screen. All
flags indicate we're in the age. This is just the best way to fix it(TM)
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.
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.
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.
Darryl Pogue
Vincent Munsch
Florian Meißner
