Code center > Suggestions

New tie structures

(1/5) > >>

Numsgil:

--- Quote ---That is going to screw up the .tielen1, .tielen2 etc. format.
--- End quote ---

I noticed that too.  Whatever system we come up with needs to be independant of the number of ties the system allows.  That is, scalable.

I would prefer a system with a minimal number of sysvars, and have some command to change which tie is being read from/written to at the moment.

Like:

set tie Y
read from tie
write to tie
switch to tie X
read from tie
write to tie
swtich back to tie Y
read from tie
write to tie

Like that.

Advantage is that mutations are more likely to keep tie actions consistant.  If you lost the switch to tie X command, then all your tie X commands are now being applied to tie Y.  And vice versa.

PurpleYouko:
Right.

It isn't quite that simple though. It would be great to do it that way but in order to do so we would have to work the tie comunications sequentially directly from the DNA parser before it goes to the main loop.

We seem to be moving more and more stuff into that part of the program lately.

Possibly we need to have a sub array of ties that is manipulated just line the memory cells are. That way each tie can be addressed internally (1-10) and externally (1-32000) on every cycle. Values for transferred data and target location can be set within the array as the DNA is parsed then the actual comunications take place in the main loop.

Yes that sounds OK I think.  :D

Still working on the exact details but it should be greatly streamlined over the present system

Numsgil:
So store the information that is being passed back and forth in the tie and then apply that to the bots during the update robots cycle?

That would work well I think.  Conflicting commands can be solved in the same manner I was planning on resolving conflicting stores, either chose one randomly or have smaller values take precedence, or some mixture of the two.

In a related note, I think we can get rid of all those trefvars if we can figure a way to allow the bot to say "what is at memory location X in the bot through the current tie?".  Perhaps a command instead of a sysvar.

PurpleYouko:
The trefvars are a little tricky. I was never entirely satisfied with them.
I am also not too keen on having to go through a 3 step system just to comunicate a single value through a tie.

456 .tienum store
-1 .tieloc store
-1000 .tieval store

seems like a complicated and long winded process to feed through a tie with a phase of 456.

something like a multi-part command which stores values directly into a tie array could work better.

take this as an example.

-1000 .tie#456#-1 store

this structure would store the value -1000 directly into the tieval location of a tie with a phase of 456 ready for delivery to the -1 location of the target robot in the execution cycle.

the .tie#xx#xx section of the command is no longer a sysvar but is actually a pointer to an array location within the new tie structure. The individual value can still be mutated but using such a system would more or less insure that tie communications become a relatively simple one step deal.

Numsgil:
But you're still specifying a tie phase implicitly.  I think the tie phase should be set somewhere else and then all the ties commands just use that number.  Somewhat like now, but changing the number will reset all the tie vars and commands, saving the commands you issued to a command stack somewhere.

And also, 32000 tie numbers just is too much.  Tiepres helps, but really you only need a couple, maybe 20 at most.  That makes using ties for mutations more likely.

something like: ".body readtie" to return *.body of the bot through your currently set tie.  (readtie is a command)

And 20 .fdbody writetie to send a write command.  That way you can read and write using as many different ties and bots and locations as you want.

Navigation

[0] Message Index

[#] Next page