Code center > Suggestions

New tie structures

<< < (2/5) > >>

PurpleYouko:

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

I disagree on this point. 20 just makes it way too easy to randomly find the right one. And for any other purpose than feeding through ties, it isn't going to make much difference if you have 20 options or 20,000 options.

I prefer to be able to address the tie phase directly from the command rather than have a single command that resets all of the subsequent tie functions....
unless...
You mean to use the change address commands in a sequential fashion so that you can address a certain tie for a while then change to another and do some actions on it then go to a third one and so on..
How would that work with a simultaineous or parrallel processed genome though?

The other point is that for things like setting tie lengths and angles, we can use the internal array which will only have 10 values. That method doesn't use phases at all but just directly addresses your own tie. For this to work, each tie needs to keep its assigned value and not be shuffled when a tie is lost so it might require some minor reworking.

this would work very much like the (apparently) ill fated .tieang1,2,3,4. commands.

628 tieang#1 store would set the robot/tie angle of internal array tie number 1 to an angle of 628 (directly away from the tie)

300 tielen#9 store would set the length of internal array tie number 9 to a length of 300

There are two alternative ways to address ties in this system and the old system would still work also so backward compatability would be good. The only thing lost would be the specific 8 sysvars that directly address the tie angles and lengths. Not a great loss since few (if any) robots have been made with these yet

Numsgil:

--- Quote ---You mean to use the change address commands in a sequential fashion so that you can address a certain tie for a while then change to another and do some actions on it then go to a third one and so on..
How would that work with a simultaineous or parrallel processed genome though?
--- End quote ---

That's exactly what I mean.

Something like this:

cond
start
1 settie
.nrg readtie
stop

cond
1000 <
start
1000 -1 writetie
stop

cond
start
2 settie
.body readtie
stop

cond
1000 <
start
1000 -1 writetie
stop

Then we just have the ties store what the bots are trying to do with them, and apply it after all bots have had a chance to run their DNA.

My main concern is how likely a bot is to actually get the necessary commands to feed through a tie.  Just randomly mutating for a while it should be possible to form a tie (already does) and then all you need in this system is to have 1000 -1 writetie (which is still somewhat unlikely, but much more probable).

We could have tie number default to 1 if no settie command is set.


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

I disagree on this point. 20 just makes it way too easy to randomly find the right one.

--- End quote ---

Currently tiepres lets you find the tie of any feeding tie bot.  The bot can compensate by firing a new tie every cycle.

So if we just prevent a tie from registering for a cycle if you didn't fire it, we get the same effect, without the need of complicated numbers that the bots aren't likely to develop.

this could eat food:

cond
start
.tie inc
-1000 -1 writetie
stop

which is much more probable to evolve.  (only 5 commands, not interdependant)

PurpleYouko:
Are you making a differentiation between internal tie array values (1-10 ties) and programmable tie phase (1 to whatever)?

For instance I don't think a robot should be able to feed through a tie just using its internal tie address as this is often going to be different than the robot at the other end of the tie is using to address the same tie.

for example, If bot one has 3 current ties numbered 1,2 and 3 (internally), then he shoots a 4th tie at a target bot (number 4 internally). The target bot has no ties so the tie that hits it becomes number 1 on his internal array. Both robots can now control some aspects of this tie using their internal structure but both use a different ID to do so.

However if the tie was fired with a phase of 25 then that is the value that will be returned by *.tiepres and is the value that will be used by both bots to feed or leach.

As far as the syntax goes then I don't really see the advantage of having an active tie then accesing it for a while with other commands.

your suggestion

--- Code: ---.tie inc
-1000 -1 writetie
--- End code ---
As you say, this has 5 sections and relies on a value to be present in .tie. Presumably firing a tie by storing a number into this will also set the value for later use and will not be erased until it is overwritten.

Yes it works pretty well.

Now look at this idea. (slight modification to bring the two ideas a little closer)

--- Code: ----1000 writetie#1#-1
--- End code ---
This has 2 sections with the second section being made up of 3 parts that cannot be split further. There will always be a number after each hash and they will be 100% mutatable
To take this a step further, .tie could be tied into the first hashed number so that this number is set whenever a tie command is issued. It now becomes very easy to mutate a command that will write to a tie. It only requires a single command preceded by a number.
Also each instance of this is independent of other "settie" commands.

Not sure about auto setting the value though. I just thought of some reasons why that wouldn't be so good. just let it default to 1 and -1 and you have easy tie feeding through tie phase 1 that could very easily evolve.

Numsgil:
I was imagining that the number you use to fire a tie is more a relic than anything.  As long as tie feeders still get that one cycle free feed before the prey can respond, just letting bots address ties through their position in the internal array seems simpler, more robust, and easier to mutate.

It's like that infomertial.  "Just set it, and forget it".  If you never change the tie you're focusing on, all tie commands use the first tie in the array.  So all a bot has to do is store positive numbers to .tie to form a tie (the numbers don't matter anymore, or maybe they determine tie type) and then use a number -1 writetie command.

Backwards compatibility can be preserved with some kind of DNA converter.  It depends alot on the actual implementation.  But this is definately an instance I'm willing to "break" old bots for the sake of new features.

My only point I haven't made yet is on syntax.

writetie#number1#number2 looks frightful, and doesn't inherantly do anything that the stack can't handle.

"number2 number1 writetie" works just as well, and sticks with the current coding structure.

And that's all I have to say about that.  We should probably start a new thread in suggestions forum and let people vote on a particular implementation.

PurpleYouko:

--- Quote ---writetie#number1#number2 looks frightful, and doesn't inherantly do anything that the stack can't handle.
--- End quote ---

Yes it does look a bit scary. I am not married to the idea anyway. It was just something that I threw together.
It does do one thing that the stack can't. It would fix the usable numbers in place into a single very short command structure rather than relying on external settings.

OK so a default of one in .tie would work just fine and would probably be very good as far as letting bots access what is most likely their only tie.

However I am definitely against discarding the old tie structure entirely since it is able to do a few subtle things that will be impossible using a new internal array address system exclusively.

Currently it is possible to use a gene such as


--- Code: ---cond
start
5 .tie store
-1 .tieloc store
100 .tieval store
--- End code ---

Doesn't look like much at first glance but what if this is a Multi-bot with several ties that mostly have different numbers but has two in specific strategic positions that share the same phase?
Then this particular gene will send energy to both of these ties in the same cycle from a single command.

There are many instances where this kind of behaviour is extremely useful. For instance, most bots can feed from multiple ties at once because they all share the same phase address.

In complex MBs this is just about the single most useful feature that I have found with the way ties are now.

Admitedly some of these things can be replaced by sharing but then that is designed to only work with mature MBs and not with quick hitter tie feeders.

And what about deleting ties? getting rid of 10 seperate ties with internal array addresses would take 10 seperate operations.

1 .deltie store
2 .deltie store
etc.
etc.

With the existing system, 10 ties that all have a phase of 15 can all be deleted at once by a single command.

15 .deltie store

Doing away with the old system in favor of a new one would in many ways make MBs harder to use and to evolve rather than easier.
I think we should be able to work out something pretty awesome from the ideas that we have been throwing around, but it can't entirely replace all the old stuff. It should compliment it and give alternative paths to the same end but never totally replace it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page