Code center > Darwinbots3

Elemental Out/In Trace

<< < (2/4) > >>

EricL:
I don't garbage collect the robot array (but I do shrink it as high numberred bots die) so the bot array index is a unique ID for a bot we could use for this albeit one that is only good until the bot dies.  Bots are born and die too fast for us to try and define a real guid that fits in -32000 -> 32000 and rely on that for clean up of broken bot links so I'm thinking we just use the rob array index and in cases where a new bot has taken that slot, well, we just live with the fact that the bot may be accessing data from a bot other than what it thinks.   Putting a distance limit on this would reduce but not eliminate the possibility of this happening.  Think of it as a degree of uncertainity bots must live with when they try and get info on bots they can no longer see.

Things like "bot 45 attacked me 100 cycles ago" or "bot 45 is my offspring and he went thataway 2 cycles ago so ignore any bots in that direction until he's this far away from me" are exactly what I have in mind with this.  An aid to short term memory and vision that helps a bot keep track of nearby bots and lets them focus on those that are threats while ignoring or perhaps cooperating with those who arn't.

I don't like the analogy of comparing this to smell or similar.  It's not diretional, its not really a sense at all but rather more of a way to remember things and get info on things you've seen or touched recently.

Note I would probably want to put some sort of distance limit on this, perhaps twice the maximum vision range or similar.  I think it may be going too far to allow a bot to continue to intuit another's location long after it first saw it, when half way across the field.

Numsgil:
My issue with using the robot array index is that it could be used in nefarious ways to help with conspec recognition, robot age, telling if it's the beginning of the simulation, that sort of thing.  A random index ensures that the robots get a unique identification tag without gathering information that they shouldn't.

As for using it to collect refvar information, I'm concerned that it's in all ways superior to using actual eyes.  You wouldn't have to worry about tracking the target, keeping an eye on it, etc.  I don't see the downside.

EricL:

--- Quote from: Numsgil ---My issue with using the robot array index is that it could be used in nefarious ways to help with conspec recognition, robot age, telling if it's the beginning of the simulation, that sort of thing.
--- End quote ---
I don't see how.  A bot's position in the array has no relationship to those things.  The array is sparse with no locality.  I've changed how it works considerable over the years for perf reasons...


--- Quote from: Numsgil ---A random index ensures that the robots get a unique identification tag without gathering information that they shouldn't.
--- End quote ---
This is essentially what the array index is.


--- Quote from: Numsgil ---As for using it to collect refvar information, I'm concerned that it's in all ways superior to using actual eyes.  You wouldn't have to worry about tracking the target, keeping an eye on it, etc.  I don't see the downside.
--- End quote ---
You would still have to do something to load the refvars based on a rememberred ID, akin to looking at something with .eye5.  Initally, you would only be able to do this once per cycle I.e. "focus on" only one thing per cycle be that via .eye5 or via a rememberred bot ID.  If you were checking on that bot you saw 10 cycles ago, you would not be able to inspect the properties of the bot in .eye5 during the same cycle.   Yes, it lets you track bots you've once saw, but it does not tell you about bots you haven't seen yet.  You have to see a bot to get it's ID before you could use this.   It's not a substitute for vision.  And if refxpos and refypos are the big worry, we could exclude them.  Hell, I'd be happy to loose them as refvars entirely.  Ant bots could cooperate and communicae their position to each other by pushing their own xpos ypos to .out1 and .out2 for example, but this would be voluntary.

rsucoop:

--- Quote from: EricL ---I don't garbage collect the robot array (but I do shrink it as high numberred bots die) so the bot array index is a unique ID for a bot we could use for this albeit one that is only good until the bot dies.  Bots are born and die too fast for us to try and define a real guid that fits in -32000 -> 32000 and rely on that for clean up of broken bot links so I'm thinking we just use the rob array index and in cases where a new bot has taken that slot, well, we just live with the fact that the bot may be accessing data from a bot other than what it thinks.   Putting a distance limit on this would reduce but not eliminate the possibility of this happening.  Think of it as a degree of uncertainity bots must live with when they try and get info on bots they can no longer see.

Things like "bot 45 attacked me 100 cycles ago" or "bot 45 is my offspring and he went thataway 2 cycles ago so ignore any bots in that direction until he's this far away from me" are exactly what I have in mind with this.  An aid to short term memory and vision that helps a bot keep track of nearby bots and lets them focus on those that are threats while ignoring or perhaps cooperating with those who arn't.

I don't like the analogy of comparing this to smell or similar.  It's not diretional, its not really a sense at all but rather more of a way to remember things and get info on things you've seen or touched recently.

Note I would probably want to put some sort of distance limit on this, perhaps twice the maximum vision range or similar.  I think it may be going too far to allow a bot to continue to intuit another's location long after it first saw it, when half way across the field.
--- End quote ---

So this would be used to show changes in speed and trajectory? Or would it only readback one or the other? Also are there two noses or just one? Stero Smell Vision would allow a bot track two seperate paths at once to make sure that bot A did not go to bot B for help. I like the idea of distance limitations, but I think a strength eleminator would greatly change the field of usuable information. I.E. the original path the bot made would contain the information longer than say the outside edges that inherent this information. Doing that would really make smelling for bots dificult to do with certain search genes. Making the smell genes less of a primary viewer, but a clever auxiliary.

Numsgil:

--- Quote from: EricL ---The array is sparse with no locality.  I've changed how it works considerable over the years for perf reasons...
--- End quote ---

Ah, that changes things.  Then I have no objections.  I just didn't like the idea of bots 1-10 being the initial bots of a league match, and bot saying "oh, I'm bot #8, I must be one of the original."


--- Quote ---
--- Quote from: Numsgil ---As for using it to collect refvar information, I'm concerned that it's in all ways superior to using actual eyes.  You wouldn't have to worry about tracking the target, keeping an eye on it, etc.  I don't see the downside.
--- End quote ---
You would still have to do something to load the refvars based on a rememberred ID, akin to looking at something with .eye5.  Initally, you would only be able to do this once per cycle I.e. "focus on" only one thing per cycle be that via .eye5 or via a rememberred bot ID.  If you were checking on that bot you saw 10 cycles ago, you would not be able to inspect the properties of the bot in .eye5 during the same cycle.   Yes, it lets you track bots you've once saw, but it does not tell you about bots you haven't seen yet.  You have to see a bot to get it's ID before you could use this.   It's not a substitute for vision.  And if refxpos and refypos are the big worry, we could exclude them.  Hell, I'd be happy to loose them as refvars entirely.  Ant bots could cooperate and communicae their position to each other by pushing their own xpos ypos to .out1 and .out2 for example, but this would be voluntary.
 
--- End quote ---

My primary concern is with dog fighting.  Specifically evasion.  When you're dog fighting, you only care about the bot you're fighting.  Other bots are only distractions.  One of the nice things about the current system is that it's possible to sort of evasive maneuver your way out of a dog fight.  Especially if the enemy in question is relatively stupid.  Something like -100 .dx store can usually get you away from an animal minimalis type bot.  Info shots or venom that cause the other bot to turn away also work.

So all that said, if you removed all those spatial clues, I think I might be okay with it.  Maybe strictly limit the information you can determine to the in/out pairs and maybe memloc/memval.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version