vbGore Free Online RPG Engine

I ran into some trouble with movement packets using Tcp.
I used to send a packet every time the client player requested to move, but this rendered inefficiently and created a whole crap load of problems once a tiny bit of lag was present.
After searching VBGore I thought making some sort of buffer to store movement packets before sending them would solve this problem, then I came up with this (code isn't real, it's just to show my point):



So basically the server receives a packet like "r,r,r,r,d,d,l,l,r,r,r,r," (r = right and so on with all directions).
Here I brake down the packet by ',' to get individual directions, and loop the array of directions checking which is which and actually moving the player.
Everything with this works fine, except everything happening IN the loop isn't being rendered, so it creates a kind of "skipping" effect which isn't very nice at all haha.
Is there a more efficient way of transferring packets via Tcp without this lag problem?[/code]

Fine I'll use Udp for movement then *sniff*.

The problem is your implementation. Its hard to say what is wrong with it without seeing it, but locally TCP should be near instant. UDP isn't going to help in the slightest bit unless the problem is a lot of dropped packets, which isn't going to be the case locally where nothing gets dropped. Without knowing what you're doing, UDP will just make things much worse for you.

you'll have to let the rendering take place after each iteration of the loop, so the player moves smoothly

I just noticed that counter variable - what the heck is the point of that? If you want to prevent spam, do it on a per-command basis. What you are doing is waiting limit loops before sending anything, and the waiting starts AFTER the first packet is queued. First off, TCP implements the Nagle Algorithm which combines packets together for you so you are just making a queue before the queue. Secondly, if you do want to queue the data, you might as well just do it on a timer not dependant on the send time. It'd be like sending every frame or so. But again, this is pretty useless.

Sorry, and thanks.

Forgot to mention this wasn't tested localy lol, so the problem was indeed lag. I now use Udp for movement only, works good .