[sldev] Victory Conditions

[Tateru Nino]

Paul Cook wrote:
> My own thoughts as to "Victory Conditions" on the two most hated bugs
>
> SVC-85: The friends list bug
>
[etc]
> That's all for that issue, I think. Now,...
>
> SVC-472 - Region Crossings
>
> This is a much more vague and unspecific issue. I break it down into 
> these problems.
>
> 1. Attachments messing up on region crossing..
>
> This frequently and annoyiingly happens. The avatar's attachments 
> often simply vanish, or move to odd locations like the waist. Hud 
> devices especially, simply vvanish.
>
Nicholaz Beresford found the causes of this and fixed them.
> 2.  Unseating
> A problem which most often affects cases where multiple avatars are 
> sitting on the same object. They seem to randomly get unseated.. This 
> makes passenger vehicles a nightmare to use. In my experience, 
> additional avatars beyond the first are sometimes getting unseated.
>
>
> 3. Sinking into surfaces
>
> This is most often seen  when crossing regions on foot, less so when 
> flying. The avatar seems to move without colliding with things on the 
> other side of the crossing for a few seconds. In addition, the 
> avatar's trajectory seems to get altered. Theoretically, walking 
> across a straight bridge between sims should be alright, but in 
> actuality, the avatar starts moving diagonally downwards, instead of 
> contonueing straight forwards as they were when the crossing started. 
> I think this part could be solved by simply keeping the 
> avatar/object's trajectory intact, so that if they cross a sim walking 
> in a straight line, they'll be at the same altitude on the other side.
>
> Another problem with this area, is the lack of collision with stuff. 
> When falling through things at sim borders, this is often not just a 
> clientside effect, but the avatar will actually end up under or inside 
> objects when the crossing completes.
Actually, I think both of these are motion prediction issues. When 
crossing a sim border, the agent is assumed to continue at last course 
and speed until the simulator handover is complete, at which point the 
viewer is sent updated position information. The avatar can appear to be 
moving through the terrain and objects if their movement vector 
outweighs the simulator handoff time (there's quite a bit of stuffing 
around to hand the agent from one sim to another along with attachments 
and script states intact. This also includes the network latency between 
the departure sim and the viewer and between the arrival sim and the 
viewer).

I am guessing that item 2 (unseating) is actually triggered by the 
viewer under circumstances where position updates are sent to the viewer 
in an order that makes it seem as if the seat and the agent are too far 
away from each-other. That's more of a deduction than anything I've had 
the opportunity to confirm.

> 4. Constant motion
>
> Also a notable problem, quite related to the previous, the avatar 
> keeps moving when crossing a sim, while the next siim loads them. When 
> things are going good, this helps t prevent breaking the flow of 
> motion, and is nice. But when sim crossings are going slowly, he user 
> often ends up walking or flying in a straight line for several 
> seconds, or even minutes. No new data seems to be downloaded during 
> this time, and so it's quite possible, and likely, that the useer will 
> walk outside of theiir own draw distance, and just be moving around in 
> endless sea and sky until the crossing finishes.
>
> To remedy that, I'm thinking some sort of timeout for that continued 
> motion. After which, the avatar should just stop, and stay still 
> until  the crossing finishes.
I think perhaps yes. If you're doing more than a few seconds of motion 
prediction without updates it is probably time to halt and await further 
updates.
> 5. slowness.
>
> Ultimately, the worst problem. Simply the time it takes for a region 
> crossing to complete. This is affected by attachments and scripts in 
> the user, as we know. But it does also seem to depend a lot on the 
> performance of the sim. Aside from upgrading the hardware of every 
> sim, the only solution I can think of for this, is preemptively 
> loading the avatar for neighboring sims, before a crossing begins. To 
> minimise the excess load this would cause, there should be some 
> intelligence in doing so. Like preloading based on the avatar's 
> proximity, and direction of motion. If an av is 30m away from a sim 
> border, and moving towards it steadily, it's not unreasonable to 
> expect them to attempt a crossing, and would be a good situation for 
> preloading.
>
> Where multiple avatars are sitting on one object, they should be 
> treated as a single entity for deciding preloading, and all preloaded 
> at the same time when necessary.
>
> Hopefully, doing that will greatly speed up sim crossings.
[see above]
I think there are probably more delays in ... well 'baggage handling' 
than in the raw avatars and agents themselves. Attachments and script 
states come to mind immediately.

-- 
Tateru Nino
http://www.massively.com/