Author Topic: Distances, coordinates, units  (Read 2362 times)

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
Distances, coordinates, units
« on: May 12, 2008, 07:35:52 PM »
So, I'm measuring the distance between two bots with:

(This is inside an if block which has a boolean value on the boolean stack indicating whether code inside the if block should run or not)
Code: [Select]
*.refxpos *.refypos dist dupbool dup *998 != and 998 store dropbool
*.xpos *.refxpos sub dup mult *.ypos *.refypos sub dup mult add sqr dupbool dup *997 != and 997 store dropbool

The first line is dist(refxpos, refypos), and the second line is sqr(((xpos - refxpos)*dup) + ((ypos - refypos)*dup))

I have a bot which does repro 50, and then both it and the child move away from each other, until they pass 400 dist (according to dist, not the manual formula), at which point they both fixpos.

The bots are still close enough at that point to shoot each other, regardless of map size, indicating that the coordinates returned by dist are the actual (or near) coordinates. (The bots do not aim their movement or shots very well on the largest map size though)

(I'm going to write ~number in the rest of this post where I mean the number is sometimes that number, but is sometimes 1 higher or 1 lower than that number instead, to save time.)

(And for each bot, I'll say what I got for the dist method and the manual method with dist:manual)

On size 1-4 maps, I get either ~452:~452, or ~522:~522. Said another way, each single bot has either ~522 and ~522 for both methods, or ~452 and ~452 for both methods.

On size 5 maps, I get either ~452:~362, or ~522:~417.

Size 6 maps: ~452:~301, or ~522:~348

* = within 1 distance point anyhow.

So, we can conclude that:
1. Refxpos/refypos and xpos/ypos are returning values which are scaled down by the size of the map
2. dist() takes in scaled-down units, and returns actual distance units

So how do we do work on actual x or y coordinate differences? We have to get the actual distance, which we can do like so: dist(xpos+xdiff, ypos) or dist(xpos, ypos+ydiff).

Additionally, this is helpful: refvel* are in actual distance units rather than scaled-down units: My test bots are showing the same values at the same tick for these in both the smallest and largest map size.

There's just two problems I see so far:
1. At very large map sizes you end up with refxpos,refypos coordinates whose difference from your xpos,ypos is so tiny (say, 6 on the largest map) that the actual coordinates returned by dist (and angle) are unreliable.
2. Why are the actual distances being returned as sometimes ~452 and sometimes ~522 (which are ~70 units apart), and never something in between? (Note: I'm discounting the results from huge maps which return different actual distance values than ~452 and ~522, because their scaled-down units are so tiny that it makes the result inaccurate)
« Last Edit: May 12, 2008, 07:40:00 PM by Trafalgar »

Offline gymsum

  • Bot Destroyer
  • ***
  • Posts: 215
    • View Profile
Distances, coordinates, units
« Reply #1 on: May 12, 2008, 08:19:57 PM »
Its becuase the dist results and angles are scaled around a mod of a default of some sort I assume. Very odd that you should have any errors beyond environmental interference, producing these results; it could be that your bots arent focused on the same bot allt eh way through, or your bot cant see the bot froom 400 units away due to eye restriction.

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
Distances, coordinates, units
« Reply #2 on: May 12, 2008, 09:15:48 PM »
Quote from: gymsum
Its becuase the dist results and angles are scaled around a mod of a default of some sort I assume. Very odd that you should have any errors beyond environmental interference, producing these results; it could be that your bots arent focused on the same bot allt eh way through, or your bot cant see the bot froom 400 units away due to eye restriction.

Nope, it's not either of those. I spawned one bot with the simulation paused, and used the button for doing a single cycle to step through it one cycle at a time. There wasn't anything else near them in the sim.

And they definitely aren't moving out of sight range of each other, either.

(After they move to that distance, they fixpos and then do what I actually made them for - re-testing shot speed - one of them fires several hundred energy shots at the other, and they determine the fastest, the slowest, and the average shot speed (in actual distance per cycle)). At the moment there's just a bit of a problem: There's no sysvar for radius or refradius, and in order to calculate it I need some way to do cube roots. At the moment I'm having them just pretend the distance is 120 less than what's reported by dist, which would be correct if fix bot radii was on.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Distances, coordinates, units
« Reply #3 on: May 12, 2008, 09:57:24 PM »
I suspect the sometimes ~452 and sometimes ~522 issue has to do with Single to Long conversion in the simulator.  The distance routine does the math using Single arithmetic then converts to a Long to push it on the stack.  The way VB does this conversion may loose significant digits that impact the result in cases where the result has a lot of digits past the decimal.  I'll play around with it.  My first shot will be to take the integer portion of the Single before converting.  I'm not 100% sure how VB handles the conversion, but I think this should slide the decimal place enough to preserve the value accurately.

Trafalgar, posting a sim with your test bots would be very helpful.  Thanks.

Additionally, I should point out a flaw in current builds.  Distances are exact and proportional (meaning an X unit is the same distance as a Y unit) on fields of size 4 or smaller but X units are 4/3rd's longer than y units on fields size > 4.  Said another way, it will take a bot 4/3rd's as long to travel 1000 units in the X direction as it will the Y direction.   This is because the field aspect ratio is 4X3 but in fields > size 4, I use units 1/32000th the field width/height for both the X and Y axis.  What I should do is use units 1/32000th the field width for the X dimension and 1/24000th the field height for the Y dimension so that distances in the X direction are the same as in the y direction.   On fields > size 4, bots will encounter the right field edge at xpos=32000 and the field bottom at ypos = 24000.

I plan to make this change for the next release unless there are objections.

Quote from: Trafalgar
There's no sysvar for radius or refradius...
If would be trivial to add these.  I'm inclined to do both, not the least because conspec recognition IMHO is best based on phenotypical aspects, not geneotypical aspects.
Many beers....

Offline gymsum

  • Bot Destroyer
  • ***
  • Posts: 215
    • View Profile
Distances, coordinates, units
« Reply #4 on: May 13, 2008, 12:06:08 AM »
I could see a good purpose for reading bot radius on itself to identify if it can fit in a place or between two objects of fixed bots.

Offline Trafalgar

  • Bot Destroyer
  • ***
  • Posts: 122
    • View Profile
Distances, coordinates, units
« Reply #5 on: May 13, 2008, 10:53:32 AM »
Here's a saved sim on a size 5 map (attached to this post, it's only 75 KB or so), saved right at the beginning before any bots have done anything: http://shadowlord13.googlepages.com/aimtest.sim
P.S. Oddly, bots I add manually fly east/west away from each other, whereas ones spawned at sim start don't, they go some other direction instead. The bots there were all spawned at sim start by DarwinBots, not added by me.

The yellow AimTest bots will all split into two bots, move apart, and begin shooting at each other.

The parent bot will store:
dist(refxpos, refypos) in 998
the calculated (scaled-down) distance using the distance formula in 997
and 996 has 998's value minus 120

out3 will also be set to the value from 996.

The child bot only has one of those variables, I think.

If you're curious about the shot speed stuff:

After the first shot has hit, the child bot will also:
store the last shot's calculated speed in out4 (the calculated speed is based on what it reads from in3)
The total sum of all shot speeds for shots that hit in out5
The total number of shots that hit in out6
The lowest shot speed in out7
The highest shot speed in out8

The shooting and recording continues until the shooter runs out of energy and dies.

Offline gymsum

  • Bot Destroyer
  • ***
  • Posts: 215
    • View Profile
Distances, coordinates, units
« Reply #6 on: May 13, 2008, 10:40:29 PM »
could you post your code for the bot? It could be in your programming.