Code center > Bug reports

trefnrg returning 0

<< < (2/2)

goffrie:

--- Quote from: gymsum ---The easiest way to read all ties constantly, unless you want the bot to focus, is to use the following gene:

cond
*.......
start
*.timer mod *.numties *.tiepres add .readtie store
stop

It takes the timer (an infitely expanding number and wraps it around the number of ties a bot has), that means every cycle a new tie is read.
--- End quote ---

Eek. '*.timer mod' doesn't quite do anything (I think you meant '*.timer *.numties mod'), and you're assuming that all the ties are in order - but you could have ties numbered 3, 792, and 29674, and your snippet would check 29674, 29675 and 29676.

Peksa:

--- Quote from: Trafalgar ---I want it to always read the last tie to tie to it, basically, since if it IS another bot tying to it, it needs to be able to see if it's friendly and if not, delete the tie before the other bot can do anything nasty (like setting shootval to 31999).
--- End quote ---

Doesn't *.tiepres .readtie store do that?

Trafalgar:

--- Quote from: Peksa ---Doesn't *.tiepres .readtie store do that?
--- End quote ---

Does setting .readtie instantly update the trefvars? If not, then not quite.

Probably I should set readtie to 1 before anything ties to the bot, since if there is no tie 1 that should be what tiepres will become when another bot ties to us.

goffrie:

--- Quote from: Trafalgar ---
--- Quote from: Peksa ---Doesn't *.tiepres .readtie store do that?
--- End quote ---

Does setting .readtie instantly update the trefvars? If not, then not quite.  

Probably I should set readtie to 1 before anything ties to the bot, since if there is no tie 1 that should be what tiepres will become when another bot ties to us.

--- End quote ---
Actually, .tiepres will become what the other bot put into .tie, IIRC.

Correct me if I'm wrong

EricL:

--- Quote from: goffrie ---Actually, .tiepres will become what the other bot put into .tie, IIRC.

Correct me if I'm wrong
--- End quote ---
Your wrong in current versions.  It used to be this way, back in the long long ago, but there was some argument made, perhaps by me, that the target bot should not have insight into the tying bot's tie naming conventions.   So, *.tiepres for the target bot is essentially *.numties.  When that tie gets deleted, it reverts to the previous tie port.  I'm not really happy with this, since if a bot creates it's first tie by doing 2 .tie store and then gets tied to, *.tiepres will still be 2, but at least bots can use higher numbers for the ties they create and distinguish them from those created by others.  Besides, using the tying bot's tie port has similar collision problems.

I've been thinking a nice addition might be a pushties command that pushes all the tie ports onto the stack.

W.r.t. updating trefvars, the trefvars reflect the properties of the bot at the other end of a tie the cycle following when .readtie is set to that tie port.  I.e. the trefvars will be updated the cycle following *.tiepres .readtie store.   This cycle delay is exactly the subject of the recent suggestion I posted regarding in-cycle updating of control sysvars.  Were I to impliment that, the trefvars would be updated immiediatly in-cycle when .readtie changes, allowing subsequent DNA to operate on the trefvars that cycle.

Navigation

[0] Message Index

[*] Previous page