2.42.3b Now Available

[EricL]

Dang.  I think it needs to be an executable, lile a zip file, for an http URL to work and you need permissions to get to the FTP share via FTP...  And the Attach file option seems to have gone missing in this topic...  Let me see if I can figure out why the zip is getting corrupted...

Okay, I just uploaded a zipped version again and this time it appears to unzip okay....

[Elite]

It works! Thanks Eric  

And the collision detection is working brilliantly. Great job  

[EricL]

It works! Thanks Eric  

And the collision detection is working brilliantly. Great job  

Thanks.  I now have more empathy for women in the delivery room...

Viruses are still on my list to dig into for the next version and I need to look into .tielen1-4 and .tieang1-4, but please let me know if you find any other things that need attention.

[PurpleYouko]

Eric

Please bear in mind that when I designed the tielen1-4 and tiang1-4 controls, we only had a maximum of 4 ties available.

The number of these commands needs to be the same as the number of avaliable ties in whichever version you release.

Additionally there was always one problem that I had with these things.
When ties are made, the internal tie array fills up from the bottom so the first tie made can be addressed by tielen1 and so on. The problem I encountered is what happens when you have four ties then tie number 2 gets deleted for some reason?
There isn't any way to really know which slot you are filling up when you make a new one. We might need to address that issue in some way but I am not quite sure how.

This only really becomes an issue when designing complex MB structures but as long as we want DB to be a mixture of design (for some) and evolution (for others) then we need to think this through quite a bit and maybe even come up with a completely new system.

The requirements are

• We need to be able to directly address a given tie with the absolute minimum of commands (no settie or tienum stuff)
• we need to be able to adjust or set multiple ties in a single cycle. Not possible with the current tienum system unless we change it in such a way as to make the DNA sequential rather than pseudo simultaineous.

Any thoughts on the issues?

[Elite]

I believe Nums has detailed a new system here - New Tie Paradigm

Setting ties is done by commands rather than sysvars so multiple ties can be manipulated each cycle, and ties can be set by tie phase or by tie port

***

As for what could be done in 2.4, I've got an idea:
*.tiepres1-4
(or however many ties that there can be at one time)

Only problem is it doesn't allow the manipulation of multiple ties per cycle, but it's a start.

[Numsgil]

My new tie paradigm does address this issue, providing .recentphase and .recentport.
 
 Feel free to read and comment, I've extracted it largely from the post where we talked about it PY.

[EricL]

I assume widespread use of 2.5 is not that far in the future, say a few months at most.  Given that, I currently think it's beyond the scope of the VB fork to radically change DNA execution fundementals, in particular to make any fundemental changes to the two-step process of 1) execute all the DNA to load up the mem array and then and only then 2) do what the mem array says to do.   Said another way,  one could imagine creating new in-cycle execution artifacts which would allow for separate, per gene execution, shooting multiple types of shots in different genes per cycle, changing the value of tienum to address different ties in-cycle, etc.  I don't want to make changes of this magnitude in 2.4 if 2.5 is only months away.  If 2.5 slips out, then we can re-visit changes of this magnitude, but that is my assumption for now.

So, that means any operational parallelism in 2.4 will require specific sysvars.  IMHO, this leaves several options for 2.4 regarding addressing multiple ties in a single cycle:

1) Do nothing.  This is why I asked eariler whether anyone actually used .tielen1-4, etc. in 2.37.6  If no-one does, no big deal.  I won't make them work and I won't have to deal with the issues you (PY) point out so well.

2) Make them work but don't deal with the issues with ties getting deleted, more than 4 ties, etc.  This might be sufficient for designers moving from 2.36.7, but strikes me as hackish and incomplete.

3) Make them work, but limit them to 4 ties (you can have more, but you can't address them in parallel) but deal with tie deletions.  I could do this by making some implicit rules that the first tie to fill a slot will be bound to the tie sysvars for that slot unitl it is deleted and maintaining a per-bot mapping from tie to tie sysvar and changing that as ties get added and deleted.  If there are more than 4 ties and one gets deleted, maybe the least recent tie not mapped to a sysvar takes the slot or not...    Or perhaps I could add a .settievar that would allow the bot to explicitly map ties (via tienum) to parallel tie sysvars for parallel addressing....

4) Add more sysvars for more than 4 ties (I think you can have 10 ties in 2.4).  This would be 16 additional sysvars (.tielen5-10, .tieang5-10) plus still would need to be explicit about deleting/addition behaviour as in 3) above.

In my mind, 3) is the default plan but I'll noddle it for a a few days before I start.   I am of course, very open to better suggestions...

[Numsgil]

2.5 is very close.  I'm really terrible at estimating time required to finish but I see the Beta beeing done in another 2 months at the longest, 1 month at the shortest.
 
 Most of what's left is hole filling and GUI building.