Code center > Suggestions

Tieports

<< < (2/2)

PurpleYouko:

--- Quote ---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.
--- End quote ---
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:

--- Quote ---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.
--- End quote ---

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.


--- Quote ---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.
--- End quote ---

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.

Navigation

[0] Message Index

[*] Previous page