Anticyclic Axes

[Z-Man]

Today was one of those days I tried to fix the non-normalized axes bug, but found a million bugs on the way before I even could start testing. One of them is that if the axes definition in the map goes the other way round (I keep forgetting whether the right way is clockwise or counterclockwise), the network code gets confused as well. Try it In a local game, everything is fine, you press "turn left" and your cycle turns right. In a network game, you press "turn left" and your cycle briefly turns right, but the next network update makes it turn left. You then ride along without a wall, because your client thinks you're going into the wrong direction.

Is this failure a bug worth fixing? Would anyone actually use this on a non-gimmicky server?

[Lucifer]

Hmm, if the map file supports going the other direction, then we should really support it. Other than that, seems like in a system that's defined by angle it should work symmetrically.

So, yes, it's a bug worth fixing even if nobody ever uses it. But if you restate your question to "is it a bug worth fixing now?", I don't have an answer.

[Z-Man]

It's fixed now, wasn't that hard after all. The map format supports other kinds of nastyness that still doesn't work over the network, for example having two neighboring or next-to-neighboring axes go into the same direction (so you'd have to press turn twice to see an effect, or you have one direction where pressing left or right has the same effect). A protocol change would be required for them.

Of course, the AI gets heavily confused with weird axis settings and can't cope with them at all. That's something I'm not willing to fix.

[Luke-Jr]

It's fixed now, wasn't that hard after all. The map format supports other kinds of nastyness that still doesn't work over the network, for example having two neighboring or next-to-neighboring axes go into the same direction (so you'd have to press turn twice to see an effect, or you have one direction where pressing left or right has the same effect). A protocol change would be required for them.

How about for all axis in the same direction, but with varying lengths?

Of course, the AI gets heavily confused with weird axis settings and can't cope with them at all. That's something I'm not willing to fix.

That's some AI...

[philippeqc]

It's fixed now, wasn't that hard after all.

Thanks

Hmm, if the map file supports going the other direction, then we should really support it. Other than that, seems like in a system that's defined by angle it should work symmetrically.

Not necessarly. You could have a system that associate "turn left" to +pi/4 and "turn right" to "-pi/8". You would need to turn twice as much on the right than on the left, and the resulting left directions would be affected by the amount of right turns. After a left turn, one could navigate on the North, South, East and West axes, OR on the North-East, North-West, South-West and South-East axes. And that is if you decide to be nice and have one being a multiple of the other, and that you decide that they are constant in space (at any location on the map, turning will result in the same effect) and time (at any time during the game, turning will result in the same effect).

The map format supports other kinds of nastyness that still doesn't work over the network, for example having two neighboring or next-to-neighboring axes go into the same direction (so you'd have to press turn twice to see an effect, or you have one direction where pressing left or right has the same effect). A protocol change would be required for them.

What would be the scope of this change?

Of course, the AI gets heavily confused with weird axis settings and can't cope with them at all. That's something I'm not willing to fix.

While it would be fun for a local player if the understood resonnable axes variations (3 axes arena), gimicky axes must tend to be more interesting when there is a human element involved. I'd say expose a good interface to the scripts, maybe someone will see it as a good opportunity to improve them without requiring full knowledge of the engine.

-ph

[Z-Man]

Luke: If you can write an AI that can cope with all future extensions of the game we throw at it automatically, you're invited to do so.

Same direction, different length is no problem if there is no packet loss, but the packet loss compensation code that springs into action when a command from the client stays missing can't possibly cope with it.

What would be the scope of this [protocol] change [to support all weird axis combinations]?

Also sending the number associated with the current driving direction, both for the client to server commands and the server to client syncs. There would be reserved bits to squeeze it in for the client commands, but the sync messages would need to get extended, I think. It's possible for later when the protocol is smart enough to leave out other information instead, like the driving direction vector that would become obsolete.

[joda.bot]

If the driving direction is removed the cycle could only move the map's axes right ? I'd prefer the cycle's direction to be unrestricted - atleast optional.

Is the server able to tell the client to switch to receiving mode, and perhaps even disable all predictions ? This might be good for teleports or moving a cycle without axes to select a start position before round start.