Tie question (2.4A)

[EricL]

If I sucessfully shoot a tie during the execution of my DNA on cycle n, should *.numties and the *.tref sysvars be updated and able to figure into cond statements during the n+1 cycle?

I'm seeing behaviour in 2.4A where I shoot a tie, it suceeds, but *.numties, etc. don't get updated in time to be used in the following cycle.  They update for the n+2 cycle.  This makes my tie shooting gene which is conditional on numties fire twice.  

Looking through the code, I see that FireTies() is called pretty late in the cycle, after readtie(), which updates the tref sysvars and Update_Ties(), which updartes .numties.  So, at the end of a cycle, new ties may have been sucessfully created during that cycle, but that information is not yet reflected in the bot's memory arrays.  

Then, on the next cycle, ExecRobs() (which executes the robot DNA and evaluates the gene cond statements) is called pretty early, before readtie and Update_Ties get a chance to update the bot's memory with the tie results of the previous cycle.  This means that it takes 2 cycles before .numties, etc. read correctly.

Bug?

-E

[Numsgil]

The order of operations for what robots update when is very particular.  If it's out of orer that are a whole slew of possible problems that could develop.

So while it would be nice to have the tie available immediatly, moving the order around so that happens could seriously break something else.  Or not.  But the potential for problems exist.

[EricL]

Understood, but did this change in 2.4 or has it always been this way?  I.e. have people been coding their bots knowing that ties take a few cycles to form, knowing they can't rely on .numties, etc. the cycle after they fire a tie or is this delayed reaction a new thing?

[Numsgil]

Check to see if it does the same thing in 2.37.  I don't think I even touched ties in 2.4, but I could be wrong.

[EricL]

What, you mean do some actual work?  But asking random questions of the cloud is just so much easier...

2.37.6 exhibits the same behaviour I.e. fire a tie in cycle n and numties and all the tref sysvars arn't available to the bot until the n+2 cycle.

I won't try to do anything about this in 2.4.

[PurpleYouko]

numties gets its value in line 115 of the "ties" module. Right after the ties are parsed to see if they point to anything.

This is one of the first things that happens in the main cycle, second only to calling "Tieportscom". A robot should be able to see a value in *.numties on the cycle N+1 and in fact I'm almost certan that they do..

Values in *.readtie are going to take a little longer though because tat will have to wait until the robots on both ends of the tie have been parsed individually.

There has always been a slight issue with the order in which ties are parsed. They are obviously sorted out by robot number so that older bots with lower numbers are parsed first. This has some effect on information transfer along ties and is the reason that the second entire loop "Tieportscom" was added and all direct tie comunications were moved to there. It still isn't perfect though.

Imagine two enemy tie feeders both start to feed on each other in the same cycle.
They are both equal in size and strength but one is older than the other. The older one gets to feed first so by the time the other one gets to feed, he is at a disadvantage due to the loss of his energy.

Ties are a nightmare full of this kind of thing.  :(

[EricL]

Maybe I'm on drugs.  But...

Your right, numties gets updated at that line in the ties module, but in the 2.4 source, that looks to happen way late in the cycle.  

In UpdateSim() it goes

  ExecRobs
  updateshots
  UpdateBots

It's not until UpdateBots() that numties gets updated, long after the robot DNA has executed in ExecRobs.  UpdateBots() calls Update_Ties() which is where nutmies gets updated as you indicate.

I've stepped through the code in 2.4 and I'm pretty sure that numties doesn't get updated until the n+2 cycle in 2.4.

It may not actually work the same in 2.37.6.  All I did to check was look at .numties the console in 2.37.6, which I now realize isn't indicitive on when it really gets updated, but in 2.4, I'm pretty sure (he says with a worried newbie look on his face).

[PurpleYouko]

Wouldn't know about 2.4. I have never had any input on the code for that release. 2.37.6 is my baby.  :D

[Numsgil]

What, you mean do some actual work?  But asking random questions of the cloud is just so much easier...

A subtle jab eh?  I do lots of work on DB, it just happens to be on things no one has access to yet :P

[EricL]

A subtle jab eh?

No no no, a jab at myself, not you.  You made it obvious that I could have verified it myself in the time it took me to ask the question.  In hindsight I should have got off my lazy butt and done so rather than taking the easy way out and simply asking.

[EricL]

Okay, I've stepped through the code in 2.37.6.  The names of the routines have changed, updatepos() became UpdateBots() and the mainline sim loop moved out of cycle() in console.frm to the new master.bas, but the order of execution and the behaviour is the same in both versions.  In short, the results of the n cycles' tie shots don't get updated until after the DNA executes in the n+1 cycle.  Numties does NOT update in time for it to be used by the DNA in the n+1 cycle in either version.

[Numsgil]

I think I rearranged things in 2.4 to fix some bug or other I found with the order of operations.

[EricL]

Things got rearranged/renamed, but the order of operations as far as this specific issue goes remained the same.  This isn't something you introduced in 2.4 Nums, it was this way before.

Bottom line for me is that I'm not going to attempt to fix/change this in 2.4.  The last thing I want to do is open that can of worms.  Mucking about with order of operations I'm more likely to break things than fix them.

It's a separate issue as to whether this behaviour should be addressed in the C++ version.  I leave that question to larger brains than myself.