xpos, ypos, angle and dist

[EricL]

I think most everyone knows that xpos and ypos don't work for larger fields with dimensions >32000 (they get capped in current versions at 32000).  Similarly for refxpos, refypos, trefxpos and trefypos.

What people may not know is that angle and dist are also similarly broken.

There are valid arguments both for and against making global information such as exact position available to bots.  Personally, I am more inclined to provide only local, bot-relative information and let bots operate exclusivly from what they can "see" around them, but I hesitate to take action which would break backward compatability without some discussion and consensus.

There are two possible choices I see.  The first is to do away with xpos and ypos completly and make the related refvars and trefvars as well as the semantics of angle and dist bot-relative.  They would return or take relative coordinates.

The refvars would return the position of the viewed or tied bot relative to the viewing or tying bot.
'angle' and 'dist' would similary take relative positions instead of absolute positions as they do today.  This has the effect of bascially making dist equivalent to pyth.

The second chocie is to retain xpos and ypos and the refvars and institute a grid system, where the field is made up of 32000 X 32000 grids.  xpos and ypos would be mod 32000, thus indicating a bot's absolute position on a particular grid.  Angle and dist would work as today, but using the absolute coordinates of the particular grid the bot was on and would work as long as the position the bot was using to dertermine an angle or distance was on the same grid.  The result of a dist or angle would be nonsensical when the position was from another grid, say when using the xpos ypos or refvars of a bot across a grid boundary.  Adding the sysvars .gridx and .gridy (along with refgridx, refgridy, trefgridx, trefgridy) would help a bot to know when this was the case.  Unfortunatly I don't see a clean way to avoid bots having to deal with grid boundaries without moving to a bot-relative scheme and thus breaking backward compatability.

As above, I prefer the first option even though it breaks backward compatability.  It's local rather than global, removes the need for bots to deal with grid boundaries and handles any field size.  Bots will be able to do things such as

.refxpos, .refypos angle .setaim store

and have it work on any size field.

The downside is backward compatability and the fact that ant bots and such will need to find some other means of global positioning coordination.

Comments appreceiated.

[MacadamiaNuts]

Maybe, divide xpos ypos by a factor relative to field size, so in a field of 320000 x 320000 pixels they would return the coordinates divided by 10.

That would be unaccurate only at very close range for very big sims I think. Relative coordinates could be added too, and newer bots would use those instead to avoid the coarser "spatial awareness" at big fields.

LF deactivates the xpos/ypos aiming beyond dist 32000; running in a bigger sim is fun as after a while you see clearly how they remain more time at the poorer aiming areas.

[Numsgil]

Maybe, divide xpos ypos by a factor relative to field size, so in a field of 320000 x 320000 pixels they would return the coordinates divided by 10.

This is my preffered method for "fixing" refpos, too.

For a new system, though, I would use local coordinates, but use polar instead of cartesian coordinates.  That way bots don't have to convert to find the distance and angle of another bot.  And really, bots only care about the polar coordinates of another bot anyway.  Do something like refdist and refangle, which return the distance and angle to another bot.  Then you could drop dist and angle operators after a few iterations (which I'm not a fan of because they make evolved DNA impossible to decipher).

[EricL]

Maybe, divide xpos ypos by a factor relative to field size, so in a field of 320000 x 320000 pixels they would return the coordinates divided by 10.

Okay.  Something about every bot having a built in GPS still bothers me, but I've got it coded up this way for 2.43w.

[Testlund]

Yeah, no GPS system for the bots! I don't want my bots in one corner to know what's going on in the other corner. I don't understand the math behind all this but I guess by using grids it would cause some inconsistent behavior, like two bots close enough to touch each other might not react to each other properly just because they happend to be on different sides of the grid line, if that's how it would work. Personally I don't care about backward incompatibility as long as it improves DB.

[MacadamiaNuts]

Well, actually xpos and ypos don't tell them what's going on on the other corner, only where is the other corner.

*.totalmyspecies and *.totalbots do.

[EricL]

I can rationalize xpos and ypos as a poor man's substitue for long distance vision (one that is computationally a hell of a lot faster than implementing actual long range vision).  Bot eyes don't see very far, but position info at least lets them know where they are relative to the size of the field, as if they could see mountains int eh distance for oreientation.  Ant bots deciding where their hive is or using postioning info to coordinate can be rationalized (sort of) in this way.  Omnieye targeting on the other hand...