Tieports

[Endy]

Another topic got me started thinking about these again, and ways they could be better :)  I was wondering if perhaps tielenX/tieangX could also readback the current length of that particular tie. That way the bots could know which tieport was activated and various basic information about it.

Something like:

Code: [Select]

cond
*.tielen1 0 !=
start
300 .tielen1 store
stop
would be really useful.

[Numsgil]

I don't see why not.

I've done something similar with setaim and some other sysvars.

Keep in mind at some point the tie interfaces are going to change.  It will probably become something along the lines of:

1 settie

*.tielen

instead of

*.tielen1

Anyway, you can read more about all that here.

[Endy]

Sounds good, thanks.

Just how do other programming systems or real cells work to make parallel processing units? Is there anything we could use from these in Db? Right now MB's are difficult to program at best , especially when you have to juggle multiple ties.

[Numsgil]

Real organisms have every gene basically 'executed' simoltaneously, but they are limited somewhat to locality.  Certain protiens in certain physical parts of the cell.  I don't think I've managed to find any other simulator that has to address this sort of issue the way DB does.

For MBs, we really need two things in my mind:

1.  A DNA structure that encourages modularity.  That is, one gene controlling a tree of genes 'underneath' it.  I discussed this sort of thing in a recent post.

2.   Better communication between individual cells.  Real developmental biology is poorly understood I think, but generally cells are tought to differentiate based on hormone levels.  The stem cell produces two distinct hormones axially apart from each other, then divides in the same direction.  The daughter cells know what to become based on the hormone level.

[Endy]

I checked on the tieports and they appear to hold their values even after the affected tie is gone, ie. 300 .tielen1 store at age 0, will affect any tie that becomes tielen1.(which means some of my bots were doing a massive amount of unnecessary storing)

Thanks for the above.

Number one isn't too hard nowadays, but number two is a bit difficult with just shots or ties. We really need some sort of particle information system (hormones basically) that isn't so processor costly.

Speaking of differentiation I made a snap tie share feeder, that actually improved in terms of overall population, when it had a non-feeding phenotype. It was very odd since I originally expected the community to do worse, and instead it did better. (these are insanely good at nrg gathering, and so should be used with caution)

[PurpleYouko]

I don't see why not.

I've done something similar with setaim and some other sysvars.

Keep in mind at some point the tie interfaces are going to change.  It will probably become something along the lines of:

1 settie

*.tielen

instead of

*.tielen1

Anyway, you can read more about all that here.

This kind of syntax would make the entire concept of the tieport commands pointless.

The reason behind their introduction was so that multiple ties could be adjusted on a single cycle.

If we have a "settie" sysvar then that value will go into a memory location and that will mean that only one value of "settie" will be available for each cycle.

For example. One of my bots uses tieang1 and tieang3 in the same gene in order to perform a rowing action to move. The only way "settie" can do this is if it isn't actually a sysvar at all. It would have to be applied prior to passing the memory locations into the main loop. That, of course, means that all the tieang and tielen sysvars would also need to be parsed in this way too.

This approach is just setting us up for a big-assed mess if you ask me.

A better idea would be to expand the tieang and Tielen memory locations into arrays then parse them all via the main loop. But keep the controls the way they are now rather than try to use a "settie" command which is really a step backward anyway.

[PurpleYouko]

As for reading back tie lengths and angles? That should be easy enough to do.

[Numsgil]

This kind of syntax would make the entire concept of the tieport commands pointless.

The reason behind their introduction was so that multiple ties could be adjusted on a single cycle.

We discussed this already, remember?  I even linked to the thread.

Basically we agreed that you should be able to address tie ports using positive values and specific tie locations (like 1st tie, etc.) using negative values.

If we have a "settie" sysvar then that value will go into a memory location and that will mean that only one value of "settie" will be available for each cycle.

settie would be a command.  It would change the value of the tie sysvars to reflect the current tie being pointed to, and save any sysvar commands from the previous tie.

Again, we discussed this and it's all in that thread I provided.  I even recently asked people to look it over again to see if they're still onboard with it all.

The idea basically is to let the same controls control any tie, and just change where those commands are pointing to.  I'm trying to maximize the liklihood of mutations learning to use the tie commands.  This sort of system allows a sort of 'recruitment' of existing code into new purposes.

[PurpleYouko]

Yes you are right we did discuss it.

Thanks for reminding me. I had obviously forgotten the finer details of that discussion.

Settie as an immediate command would work in the way that we discussed in the other thread. By putting the negative address on top of the stack.

It still seems rather unweildy to have to use 2 genes to get the job done though.

[Numsgil]

It depends on exactly what you're trying to do.

In my mind, complex multibots need to have full access to any of the memory locations in any bot tied to it, and the ability to manipulate tie lengths and angles for any or multiple ties in any given cycle.

I'm trying to imagine something that constructs a neural net.  It would read in controls from one cell and transport them to another cell.  non-'brain' cells would need to carry out these actions.

This is simply too unwieldly without a simple set of controls.  If the controls aren't location specific, that is, the same controls can be used to control tie 8 or tie 1, I think we're more likely to see mutations learn to use them.

Make the broad side of the barn a bit bigger, so to speak.

The last point we agreed upon is, in my mind, the best.  If settie is set to 0, then the other tie commands take two values, allowing you to explicitly specify which tie you're addressing with each command.