Welcome To Darwinbots > Newbie

Ties not working for some reason

<< < (3/3)

EricL:
Things get a little unpredictable when more than a single tie forms to/from a given bot in a given cycle.   In the case where you create a tie and one other bot ties to you in the same cycle, *.tiepres will either refer to the tie port you used to create your tie or hold a value equal to *.numties.  Which depends on the internal order of the bots in the internal bot array, which means which way it ends up is basically random for all intents and purposes from the bot's point of view.   In either case, the tie number for the tie you created will always be whatever number you choose (it can be addressed using whatever number you used).  

In the case where *.tiepres equals *.numties, then the tie the other bot created happened to be created last and *.numties is the tie port you can use to address the tie the other bot created.  If *.tiepres equals your tie port (or does not equal *.numties) then your tie was created last and *.numties - 1 is the tie port of the other bot's tie.

If you always use tie numbers greater than 10 say to address your own ties, then when *.numties is not what you expect, you can do

*.numties
*.tiepres *.numties !=
1 sub
clearbool
.deltie store

and be coverred excpet for the case where more than one bot tied to you in the same cycle.  If more than one other bot tied to you in that same cycle, things get more complicated.   Suffice it to say that the tie numbers of any ties you did not create will always lie in the range of 1 to *.numties.

I'm open to suggestions in this area.  Our tie system is lacking in many areas, not the least of which is feedback for bots to know what tie(s) went away in the last cycle.

In thinking about this, I could make a change so that ties you did not create always had contigious tie ports from yuour point of view starting at 1.  Thus, if there were N ties you know you created and still exist, then when *.numties was greater than N, you could do .deltie inc until *.numties equaled N.  If you always used high numberred tie ports for you own ties, you could safly do .deltie inc every cycle regardless of the value of *.tiepres or *.numties as an effective tie feeding defense.  I think I'll make this change in a forthcoming version barring better suggestions.

Bluchrome:
I agree the tie system is a little convoluted for my tastes here are my suggestions:

perhaps the tie system could be implemented with a tie ID stack where the system resets the stack to reflect all the current ties each cycle. Thus tie IDs can be popped until the stack is empty, and new ties are formed by pushing tie IDs unto the tie stack. For this to work obviously some new operands would need to be introduced to manipulate the tie stack. (tiepop, tiepush perhaps).Also backward compatibility would be maintained.

Since I havent viewed the source files im not aware of how feasible(programming wise) this would be for DB

Oh forgot. The stack could also implement a overflow push out policy where new ties push the bottom ties out thus breaking them or a overflow blocking policy where overflow blocks new ties.

Bluchrome:
One other question why is the degree system in DB equivalent to radians multiplied by ~200.

Numsgil:

--- Quote from: Bluchrome ---One other question why is the degree system in DB equivalent to radians multiplied by ~200.
--- End quote ---

I'm not sure of the original reasoning, but I'll bet it was to get a system that was approximately +- 1000.  1000 pops up in a lot of different places (size of memory array, body points, etc.)  Using degrees / 3 instead (so a range of +- 1080) was suggested once, but it's hard to adopt since it wouldn't be backwards compatible.

Navigation

[0] Message Index

[*] Previous page