Sticky input

[yurch]

I mentioned this once in the "feedback thread" in passing, but I think it's important/serious enough to warrent a thread.

I must stress that I don't know how the mechanics of the game work, but the easiest way for me to describe this is with mechanics, so bear with me here.

It appears the client input is sent to the server by change in input. This means there are two potential messages a client can send the server: Key has been pressed, and key has been released. Because of the imperfect ways of the internet, however, sometimes messages don't get through. Due to it's one-time nature, I think "key has been released" is not getting through on occasion, leaving the key marked as 'pressed' for long durations. The result is input that seems to stick in less than optimal situations for a connection. Pressing the same direction over and over in an attempt to get the 'key released' message to go through seems to stop the nonstop turning/throttle and adds some validity to the above hypothesis.

I believe that this is the cause of situations where some players complain that they are 'spinning out' in tanks/hovercraft from mere taps of the keyboard, both from stationary and while moving.

I think that an additional (sanity?) check is needed for the keystate. I can get this several times a minute if I'm unlucky, and it can make simply orienting the chassis in a direction an infuriating process.

[ClaytoniousRex]

Your analysis of how it works is basically correct. This is of course only problematic when you're suffering from packet loss but since all of our servers for this public test are clustered in one place, there are plenty of players suffering from packet loss (the usual fix would be to pick a better server to play on).

I think you're right that this is what a lot of people run into when they say they're "spinning out". I'll talk with Stan (Zen Master of all of this control/user input code) and see what we can do about it.

Incidentally, what kind of packet loss do you have? Is it usually 0%? (I mean as reported by ping, for example).

[yurch]

Yeah, usually 0%, at the moment. My connection can vary a lot though, one week I had 400+ ping to virtually every server, next week it's fine. Famite is the worst for me, usually.

I used my dropteam.log to check for the server IP's... is it normal for this thing to be 180+ meg!?

[yurch]

Any word on this? I just had another spell of what seems like rather excessive loss on the famite server. I'm punching the brake after every turn.

Some players are also complaining that they can't always get typed messages to send. Is that related to this?

[yurch]

I really, really hate to bring back up such an old issue, but has any leeway been made with this? I've had several potential inductees give up entirely on the game because of this problem.

I hate to say it, but it really is quite unacceptable to have to type the same message several times or fight with the controls to do simple movement.

These are never problems in other games. Packet loss may cause uneven visual movement, which is reason enough to find another server, but the client should really be resending lost input the moment it's detected.

[kapps]

I agree that this is a problem that needs to be addressed. The steering just doesn't seem very fluid even with a fairly low ping. The game almost becomes unplayable when the ping goes up and the controls stop responding. How do other FPS games get around this?

[weasello]

Other games get around it by doing everything on the client end, thus creating what most people call "lag."

That is to say, a tank appears to be in your crosshairs and suddenly jumps out of the way.

By restricting vehicle movement to server-allowed only, and by using their prediction code, it essentially removes this problem altogether - except in the most unusual cases, all vehicles actually will be exactly where they appear to be.

I think the only way around it is to significantly change the way the server<>client protocol works (not likely, and will introduce more problems)...

If the server can't see you un-pressing the turn button, then none of the other players can either; this system is really the "most fair" method in terms of accurately depicting the battlefield.

I do hope they can come up with some novel way of dealing with the shortcomings

[yurch]

Well, no, other games use keystates too. It's a matter of the client comparing the state of things and resending in a case of discrepancy. It's the same for the typed messages... it should just get resent if lost, and not by the player, but his client.

No need to be changing architectures around.

[weasello]

I've found in many action-genre games, information isn't double checked - send a message, send a confirmation, send a confirmation receipt - it's a three message process that can triple the effective "ping" of a server.

But... Maybe they can double check key un-presses only? *shrugs*

[yurch]

It is obvious to a player when the keystate or a message isn't going through - you don't see the message or the vehicle keeps going. I wouldn't expect actual traffic to be that much higher, many of the resend-criteria can be determined from the above situations by the client, and the input has to be resent anyway.

[poesel]

It shouldn't be that hard to add to the 'send on change' a 'send on timer' of the keystates. The keystates are only a few bytes and if the timer is ~1sec then you only add a little to the network load.

A missing keystroke would then be corrected in an average of 500msec which seems acceptable.

This is of course without knowledge of any of the inner workings of the program.

[ClaytoniousRex]

I'm testing the fix right now. So far, it looks solid. Will advise when it's ready to test.