| 01-16-2009, 07:04 PM | #1 |
The question is pretty simple: I want to steer a car with no latency [DESYNCS ALLOWED], how do I do it? My bot allows the game to continue after an apparent desync, and I can modify it to support rudimentary 'broadcast_data' and 'received_data' functions in a map. This allows me to perform desyncing actions, then resync using the communication functions. The problem is, I'm having trouble getting usable controls. Currently I'm trying to use the camera's change in position to detect arrow key inputs. There are complications, though: - I need to keep the camera centered on a moving unit while doing this. - If you use the pan functions, the arrow keys need to be repressed. - SetCameraBounds doesn't cancel the arrow keys but seems to require a frame to be rendered before taking effect. So right now I can detect key presses some of the time, and the camera is really jumpy because it needs to wait for frames before moving back to the unit. I originally tried using insert/delete [rotate left and right], which worked easily enough, but the rotation of the camera is so large you get disoriented. |
| 01-16-2009, 07:15 PM | #2 |
Would just like to point out that the arrow key events appear to work on a periodic timer. Reason I think so is that I did a test for the latency the same way that modern games test latency on HD tvs, and found that latency to slowly decrease and then suddenly jump up to around half a second, before going down and jumping again. |
| 01-16-2009, 07:21 PM | #3 | |
Quote:
That's probably because the host only sends a TICK every 250ms, which would give the behavior you're describing. |
| 01-17-2009, 01:34 AM | #4 |
Yes, arrow keys have very bad response times. Perhaps use abilities with WASD to turn the vehicle? Or maybe never-clipped trackables along the outside of the map and estimate the current mouse position (I'm not entirely sure this is possible.) You could pan using either method, I beielive. |
| 01-17-2009, 01:49 AM | #5 |
My personal experience is that the arrow-key delay is the same as any delay when you tell your unit to do something I.E regardless if youre on lan or on bnet, if you order a unit to use an ability there will be a delay. On Bnet, I selected a normal unit, and did a right-click move. then, at the exact same time, I pressed an arrow to move another unit w/ a movement system i coded (w/ geometry, not a move order) and both units registered at the EXACT same time while this isn't some hard evidence, my personal experience is arrow key delay is exactly the same pressing a hotkey on a unit to use an ability. try it |
| 01-17-2009, 04:04 AM | #6 | |
Quote:
Except I was testing in single-player. |
| 01-17-2009, 10:24 AM | #7 |
Order latency in SP is far better than arrows, and also on B.net (although not actually got objective proof of that one, just from subjective experience). |
| 01-17-2009, 02:43 PM | #8 |
This is all beside the point. I'm looking for input that has no latency on battle.net, it was already obvious I couldn't use the arrow key events. |
| 01-17-2009, 04:59 PM | #9 |
No input has no latency, all inputs tick with 250ms, unless you use some external program to reduce that. |
| 01-18-2009, 07:20 PM | #10 | |
Quote:
The current camera position has no latency, and I said that in the original post. ... |
| 01-18-2009, 09:54 PM | #11 | |
Quote:
Maybe cause it's done locally? |
| 01-18-2009, 10:47 PM | #12 | |
Quote:
That's right. I'm looking for a good way to use local actions as 0-latency input. [The fact that this will cause desyncs is not important.] |
| 01-18-2009, 10:48 PM | #13 |
If you could withdraw the current camera position without a desync it's entirely possible. However, broadcasting it would still suffer the same delay - not to mention panning a moving camera is extremely disorienting for the player. |
| 01-18-2009, 11:08 PM | #14 | |
Quote:
Right, but broadcasting your position means controls respond instantly, and that's what's important in a racing game. It doesn't matter that player 2 sees player 1's car teleport a bit here and there, because it's better than player 2 failing to turn in time every time. Keep in mind the camera is following the car, so the 'control' pans are hidden in the normal pans. The problem is I need to NOT pan the camera every other frame and THAT looks bad. |
