xpos, refxpos returning 0 on parts of large maps

[Trafalgar]

I started a 40000x30000 zerobot sim, and noticed that my shepherd bots near the right edge of the map were malfunctioning - they weren't flying to a zerobot to scan it when they were off to the side. It turned out that their xpos and refxpos were both returning 0.

I retested with a 32000x24000 map, and even a bot right on the right edge (with 31 thousand for its xpos) worked.

My guess is that coordinates above 32000 are probably being stored into xpos etc as 0.

[Numsgil]

Yeah, it's a problem of what to do when the robot's position is larger than the maximum allowable integer size.  The two solutions I have in mind are:

1.  Have the origin of (0,0) be the center of the field.  Then you could use the full range of -32000 to 32000.
2.  Have xpos and ypos return something like pos / some integer or something similar.

[Trafalgar]

Having xpos/ypos be inaccessible and refxpos/refypos be relative to the observing bot's position is starting to sound like it would be a good thing (provided angle and dist were modified to work accordingly, of course).

[MacadamiaNuts]

Yuck. Until it's fixed, you can do a check with:

*.refxpos *.refypos angle .setaim *.refxpos sgn mult *.refypos sgn mult store

or:

*.refxpos 0 >
*.refypos 0 >

If your bot has both the instant aim gene and the usual nine eyes aiming it can still fall back to the nine eyes. Not like it's a clean solution, tho. =P

Here's a nine eyes code within one store:

-40 *.eye9 sgn mult -30 *.eye8 sgn mult add -20 *.eye7 sgn mult add -10 *.eye6 sgn mult add 10 *.eye4 sgn mult add 20 *.eye3 sgn mult add 30 *.eye2 sgn mult add 40 *.eye1 sgn mult add .aimsx store

The fix, basically, should be substracting the bot's coordinates to the refx/refy coordinates before refx/refy are read. You may provide another pair of coordinates with a coarser grid, like, 10 field points per unit.

[EricL]

I would be happy to address this if there was consensus on what to do.

Personally, I support Trafalgar's solution of removing any notion of absolute position and having refxpos/refypos be relative.  

My reasons are several:

1) We are not going to depart from integer valued memory any time in the forseeable future.  Thus "fixing" this by somehow allowing posiitons >32000 is a nonstarter for me.

2) In principle, I am philosopcially uncomfortable with the notion of anthing non-local but that aside, allowing absolute knowledge of position is inconsistant.   If we allow knowledge of absolute position, why do we not for example, allow for infinite eyesight range?   I prefer a bot's knowlege of the world around them (and their senses) respect a sense of locality.  Helps with computation performance for one thing but also strikes me as more realistic and sane.

3) What does absolute positon even mean when the field is torridal?  What's more, I shortly plan to allow whole sides of the field to act as teleporters between mutliple instances, in essence allowing the 2D field to expand accross multiple instances or machines.  What does it mean then?  Yes, it allows for bots on the same field to rendeveuz or space out or agree on where to put the hive, etc. but I can imagine other ways to do those things using only local knowledge.  See #2 above.

4) Solutions which use the field center or courser granulatiry or additional mem locations for the higher order word of the position, etc.  just postpone the problem IMHO and don't address #2 and #3.

I haven't done anything up until now so as to avoid breaking bots, particular F1 league bots where the field is small enough not to present a problem but perhaps the time has come where consensus can be reached on a real solution...