Again, this is wrong. For a general solution, the ONLY difference is streaming the variable changes vs. sending them in one large chunk. Lag would not have any actual effect on anything, as the server is not waiting for your confirmation that you received the previous message before sending a new one, but instead just sending them out as they occur. You may receive all of them 200ms late, but they will all still occur with the same delay relative to each other that the server sent them out with. The only case where there would be a visible issue with lag is when your ping has a very high variance.
Except the server is waiting for confirmation, as it is running on the TCP protocol. Streaming the instructions doesn't seem like a viable option because of the lag involved.
If you stream a video file, all you're doing is sending out chunks of the file which the client will playback when it needs to. It knows the exact order which those chunks are meant to be in thanks to the timestamp.
A delay in receiving instructions from the server could mean that the client receives instruction A and B at the same time, and executes them at the same time, even when instruction B was meant to be on a 5 second delay. Although there is confirmation that the packet was received (thanks to TCP) and the packets will be received in the right order, there is no way to know when the packets will be received.
Playing back a movie is all about timing, and what shouldn't happen is that playing it back twice will result in any change in the tempo of the movie. With the streaming method, it does change.
If the entire instructions were sent, the client could then play back the movie on its own and it would know the timing of the messages, which would be sent along. Granted, traffic would temporarily increase due to the extra information about timing, but shorthand (e.x. telling the client that this mob moves to the right 5 times in a row with a 2 second delay per movement vs. telling it when it moves as it moves) would make the difference and may well reduce some of the traffic.
At the very least such a movie would playback at the proper speed, without the possibility of network lag interfering with this.
Yes. This has absolutely nothing to do with your original question. How the hell will the server turn whatever logic you use to move your little pictures around into any shorthand?
Full or very nearly complete client-side processing would have to be there, or BYOND would have to use the /movie datum and suggestion so it can internally work out its own scheme for this.
Again, this is wrong. For a general solution, the ONLY difference is streaming the variable changes vs. sending them in one large chunk. Lag would not have any actual effect on anything, as the server is not waiting for your confirmation that you received the previous message before sending a new one, but instead just sending them out as they occur. You may receive all of them 200ms late, but they will all still occur with the same delay relative to each other that the server sent them out with. The only case where there would be a visible issue with lag is when your ping has a very high variance.
Yes. This has absolutely nothing to do with your original question. How the hell will the server turn whatever logic you use to move your little pictures around into any shorthand? You either need full client-side processing (in which case this request is pointless) or there's a net zero change in network traffic (in which case this request is pointless).