[sldev] movement within the client

[Lawson English]

Callum Lerwick wrote:
> On Sat, 2007-12-29 at 18:34 -0700, Lawson English wrote:
>
>   
>> Thanks for the info. Rather than workarounds, I'd rather that we asked 
>> for new features though. This isn't supposed to be a competition to see 
>> who can hack the server the best: its supposed to be a collaborative 
>> effort to see this thing thrive, or such is my attitude.
>>     
>
> Yes, the way movement is handled now is pretty crackrocky. Under laggy
> conditions, and especially under low framerates, which basically means
> always in popular areas, it becomes impossible to move without
> overshooting all over the place, rudely plowing through people and
> falling off platforms.
>
> There's basically three things I want to see:
>
> 1) No overshooting
> 2) Proportional control (such as with a joystick)
> 3) A "move to here" option
>
> I can't say I know what I'm doing as far as low level protocol design
> for this, but my guess is this all could be accomplished with a "I want
> to be at X,Y,Z" client-to-sim message. The sim would still be
> authoritative about avatar position, it should be viewed as a request,
> the sim could ignore or modify the actual result as it sees fit, such as
> collisions, bounding avatar velocity, etc. Which is pretty much what it
> is doing already.
>
> This would prevent overshooting, since the message is an absolute, not
> relative. This would allow proportional control, the client would just
> be sending a series of short X,Y,Z updates.
>
> SL actually already has a "move here" feature, but it only works on
> terrain, so unless you're in a sandbox it is pretty much useless.
>
> (And of course we can and should always ask the question, "How does
> Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?",
> they've been doing this for years... AFAIK a major difference is they
> all perform collisions/physics simultaneously on the client and server,
> and resolve any de-synchronization by holding the server authoritative.)
>   
AN interesting point. The problem is, as long as SL uses Havok, I don't 
see how you'd handle it client-side unless you could add a client 
physics engine that worked just like Havok. And the folks that made 
Havok would proably be a tad less than pleased if SL added a requirement 
for people to use a 3rd party engine that competed with them. They might 
suddenly yank LL's Havok license.


Or maybe not, though the server code is soooo far from being ready for 
release (from what I've heard) that worrying about making the client 
physics more efficient probably isnt' even a blip on the LL horizon.


Lawson