Instant / correct movement in SL?

For a while I've been interested by the difference of movement in a game like Quake, Unreal Tournament or most 1st / 3rd person shooters and the movement in SL. In SL, whenever you press the Forward key to move forward it's more like you're asking your avatar to kindly move a bit in front while jumping is like your avatar gets basically thrown up. If you take a game like Quake, UT, etc. however and load a map (multiplayer even), the movement there is instant, fast and you feel like you tie yourself to the surface you're on lively and correctly and touch it in all ways. Jumping is also so "solid" and correct, and the way you jump over boxes, platforms, elevators, etc. in a game map can never be done in the current SL the same way when the avatar looks like it's pushed around while playing an animation when walking.

I'm wondering if not having a better movement in SL is a "can't" or "don't want to" thing however. I find it sad that this isn't possible in SL too and that the feeling of walking over a surface in a game is so real and good while in SL it feels so fake like you're floating. And don't get me wrong, I'm not saying "make SL like a shooting game" or anything, I'm just saying that the way a player moves around and jumps in a game is much better then the way it's done in SL. So I'm just curious if technically Second Life could be adapted to a quicker avatar movement mode.

The first thing that stands in the way of this is the fact that all physics and avatar commands are processed server-side. Basically, when you press the Forward key in SL to walk forward, your client sends a command to the server which then gets it and replies back to your client and then the avatar steps forward. I think this is a very bad and unrecommended method of operating avatar movement. Correctly, movement should be done client side and avatar updates should be sent to the simulator for other avatars to see, rather then taking a route to the server and back just to move your own avatar around.

To make the above possible however, avatar physics should also be processed client-side for each client and not on the simulator. The only things that the simulator physics should process are physical primitives which are left on their own on the ground and can be pushed around. Also, when an avatar sits on a prim its client should process the physics and not the simulator (so instant / correct movement can be done for riding vehicles too).

Fixing all this would make things both faster and more stable during lag as well as make instant movement possible which is most important (as currently you need to wait around 0.20 seconds after you press the forward button before the avatar starts to walk, which makes things very unrealistic even if people got used to it and don't notice it). Just imagine pressing a movement key in SL and the avatar stepping in that quarter second with no delay which could be sensed by the user. The main question of this topic is about this and if it could be made possible in SL in case LL wanted to make the effort to change it.

Other things alongside that which should be done are probably some better animations for walking (AOs can be found for that but what's default matters first), better collision and footstep sounds (I think 99% of the people here can agree that the current flush-flush you hear when walking over the ground is totally not right), and also a view bobbing factor so when the avatar walks fast the camera bobs up and down and probably swings sideways a bit too. I know this was all probably discussed before and Linden has to have thought of it but yet I want to know, do you think a movement like in games may be one day achieved in SL too? Do you think client-side physics and commands for avatars will be possible?

The biggest barrier to this isn't the fact that almost everything is done server-side so much as what your computer's capabilities are, especially in terms of bandwidth. I tend to be able to walk, run and jump without any problems, and I can even drive vehicles while staying in my own lane on SL's highways. The biggest barrier to having a smooth ground transportation experience in Second Life is network bandwidth, and draw distance.

Start by turning down your draw distance to 64m and your network bandwidth to the default 500. Enable the statistics bar with ctrl-! (that is, ctrl-shift-1). Turn your bandwidth up as far as you can without increasing your sim ping time. Now walk around: If your ping increases significantly when you move, bump your bandwidth settings down slightly until it doesn't anymore. Now, step the draw distance up one notch. You might have to adjust the network speed setting slightly to keep things in balance, depending on your connection. Longer draw distances increase the area for which your viewer has to check for and download objects (whether hidden behind other objects from you or not) by pi(1024)-pi(d^2) square meters per notch, where d represents your previous draw distance: increasing the draw distance length, therefor increases bandwidth requirements exponentially.

Increasing your network cache size to the maximum also tends to cut down on network usage, and thus network lag (since if your viewer comes across an object or texture already in it's cache, all it has to do is pull it from your hard drive and compare checksums instead of downloading it all over again assuming the object hasn't changed), especially if you are prone to frequenting a few areas and not travelling across continents regularly.

Hope this helps.

Yeah I know most things are done server-side which is exactly what I was hoping LL might change in the case of avatar movement. Also I did tweak my settings and have my network slider to 500kbps (my connection is a 10mbps up/down cable) but as fast as I can get the network to be the movement still won't be like local. The only thing that can really fix this is making avatar movement local... network will always have a noticeable ping and it will always be visible the avatar doesn't move directly and does it through the server no matter how fast the connection is.

Also keep in mind that removing the need for the avatar to move through the network may likely reduce a lot of lag overall too, as the part of the network that was used to send stuff so quickly to the server and back will be freed since you'd only be sending updates to your avatar's position to others instead of receiving them back too. We have to face it, avatar movement is completely incorrect like this and you hardly ever see any multiplayer 3D application (games or any other forms of virtual spaces alike) that use such a type of movement since no one ever wants such a thing because it's just wrong. I think we should try to press LL about this but I dunno.

Anyway I think there is another alternative to that; If movement must still remain server-side in case Linden really can't modify the client enough to make it local, maybe the client can at least simulate local movement while the real avatar movement would be done the same way. So when pressing the forward key, the client would show the avatar moving instantly even it that didn't yet get to the sim then find the most discrete ways to synchronize that with the way the avatar really moved like on the sim. At least one of these two ways would be helpful if possible I believe... I plan on making a jira entry about this (will likely get ignored like all others by LL but oh well) but I wanted to know what everyone thinks of this first.

Your connection is not 10mbps up/down, your connection is as fast as the slowest link between you and the SL grid. 500 might be too low, but there's an equally good chance it's too high.



I can't think of a first person shooter that doesn't make movement a serverside thing. The server has to work out the physics for it to be able to accurately describe everyone's actions.



You are less likely to be ignored if you follow the instructions on this website on how to better research the problem. I've filed a couple bugs in the JIRA before, and I've yet to have one that wasn't assigned. http://www.catb.org/~esr/faqs/smart-questions.html

That is true.. these are only the technical specs from my internet provider. The connection to LL is indeed much slower in reality, especially given the fact I'm connecting from a country in Europe all the way to a US server at least on certain sims (precisely the reason I set 500, otherwise even 1500 would have been too little for me). Sometimes even I'm surprised how it all even works as fast as it does...



Still, in most FPS games that you open and go in a multiplayer game on another server, movement is almost instant that the user hardly even notices there is a delay between pressing the movement keys and the character moving (if there even is a delay one could see in some games). So how do they do it, and why couldn't SL have the ability to do so too?



Thank you, that should probably help a bit with jira. Will certainly improve my bug reporting skills a little I got the impression LL are skipping many issues I report and not even looking at them, although on the other side it is understandable LL isn't that big to handle so many users and each person's idea or report.

A few reasons.

1) In most other games, you can host your own server. Look at your sim ping time: Odds are it's considerably higher than the ping time you have to servers in other games.

2) Precached content. With other games, you download everything in advance, already in optimized form, so really all your system has to do is sling frames. In Second Life, you have to download everything on the fly as it is encountered, much like a web browser, which frequently also increases ping. Another factor is until everything within view is rendered, what's making it to your video hardware is not optimized, so your system is having to do more work to keep up and display the partially rezzed objects. You can get pretty close to identical to the movement in other games if you're using Linux and you have an unholy amount of RAM (4+ GB and not much else running), in which case after a while, your entire SL cache will be in RAM in the filesystem cache, but this will only remain true while you're in a relatively unpopulated area (ie, can't have people beaming in constantly) and you don't move far enough in any direction you start hitting uncached objects.



I'm not sure that phenomenon is LL specific by any means... in many open source projects and businesses, it's fairly routine to close bugs as incomplete if there's just not enough information to work with; especially if it's going to take more than 30 seconds of poking around to make it work. Giving as much useful detail as possible tends to maximize the effectiveness of asking for help or reporting bugs.