Darwinbots Forum
Bots and Simulations => DNA - General => Topic started by: Elite on January 28, 2006, 05:32:14 AM
-
This is the *official* thread of hivebot's .out/.in communication systems, the Keepers' information gathering and (x, y) location stuff.
All bots should 'report in' at the hive to see a Keeper/Queen periodically so information will get to all the bots via .in/.out eventually. That's partially the reason for the hive concept - somewhere lots of bots can congregate to swap info.
We need quite advanced communication methods for the bots to be able to relay coordinates and 'explainations' to each other.
I was thinking:
The bots could use a 'tree' method. How you interpret the next .in depends on the previous .in - anyone get that? So .in1 could tell the bots wether the message is about pray, threats, hive location etc. and they could interpret .in2-5 based on that.
... just an idea
Even if you don't understand a word I'm saying :D feel free to play around with ideas relating to those sections of the code here.
I bet lots of you that say you can't program bots very well have some good ideas anyway (If you think of something good, then we'll program it for you)
-
I suggest that the 'normal' hibernating bots all tie together, so that a wake-up call can be distributed quickly through the hive via a chain reaction.
A suggestion:
Keepercode:
cond[I]
I see something is wrong and
I see one of the hybernating bots[/I]
start
50 .shoot store
1 .shootval store
stop
etc.Normal bot code:cond
[I]I'm in hybernating mode[/I]
*50 1 =
start
*.robage 40 store
1 .tienum store (assuming that's the tie phase)
50 .tieloc store
1 .tieval store
stop
cond
*40 10 add *.robage =
start
1 .deltie store
[I]goto battle mode[/I]
stop
What'ya think?
-
Hey, brilliant idea :D
A bot going to hibernate could just tie on to the 'Hibernator blob' and fix. Then they can be woken up nearly instantaniously and can respond rapidly to a call to feed.
Also, If any one hibernating bot were attacked they could wake up the rest of the species.
And the bots could share nrg and even put one or two veggies in the 'Hibernator blob' to keep the hibernating bots from loosing too much nrg during hibernation and reduce the need for complex SG hibernation coding that avoids conditions.
Great! Thanks a lot for that!
Once we've got the hive location code sorted I'll try to code it.
Keep those ideas coming :D This is exactly what I got you all involved for.
Any progress with Pray Species Henk?
-
Not yet, to busy with annoying my brother and his girlfirend and beating 'em at Age of Empires. I'll get to it soon :)
-
Since comminicating with a series of in's and out's will take a lot of time (I estimate 3+ cycles per conversation?) it might be better to assign each command a bot might need to deal with to a particular in/out slot and value. Since this will mean multiple commands will be assigned to the same communication frequency, there should be a heirarchy of command importance. That is, the higher number command will overwrite the lower number command, but the lower level command will not overwrite the higher command. In addition to this, we want every drone that recieves the order to relay it to other drones. This can be done by copying the recieved value into it's own .out.
So, for example, a drone sees a conspec with 10 stored in in/out1. Suppose this is the hibernation command. It then copies that value into its own out1 and starts a 'countdown' until it goes to hibernate. It stops eating food, but it wanders around until that countdown expires so that other drones can see the command displayed.
When the keeper sees a drone that has not recieved a necessary message (which it can tell, based on the value it displays), it will approach and fire an info shot forcing the drone to look at the keeper. The drone then put's the keeper's command on display so that other drones who happen to see it will do the same.
Since this system requires a heirarchal command system, one of the following should happen:
1. The commands continue to escalate until hibernation, during which time they are set to zero.
2. There is a command to change from using frequency 1 to frequency 2 or 5 or etc. These cycle around infrequently enough that there arent any 'loops' in communication.
3. Drones periodically return to the hive to have their frequency changed. The hive gives the wraith instructions on when to return again. This isnt good because it is slow.
I suppose there are other ways to make this work, but I haven't thought of them.
-
It's actually a bunch quicker to tie to a friend then send a series of values into specific memory locations then break the tie when you have finished.
The other bot can then act on the information that you gave it.
I use a similar method in my Antbot 5 (http://www.darwinbots.com/Forum/index.php?showtopic=1087) where the queen is able to program her offspring as well as hijacking workers from other queens of the same species
-
It's actually a bunch quicker to tie to a friend then send a series of values into specific memory locations then break the tie when you have finished.
The other bot can then act on the information that you gave it.
It takes 1 cycle for a bot to recieve a message and then copy it into it's own in/out. It will then be visible to the next bot who sees him, who then uses 1 cycle to copy it. The vector bot I posted uses a system like this.
Even though the tie can send a higher volume of information faster, in/out can be used to spread simple information at very high speed.
-
It takes 1 cycle for a bot to recieve a message and then copy it into it's own in/out. It will then be visible to the next bot who sees him, who then uses 1 cycle to copy it. The vector bot I posted uses a system like this.
Even though the tie can send a higher volume of information faster, in/out can be used to spread simple information at very high speed.
That vector bot ate Una for breakfast
-
Maybe a re-run of the leagues with all the new contestants is in order (*cough* PY *cough*).
-
That vector bot ate Una for breakfast
Making it able to kill una was much harder than making it able to beat The One or the SG version of swarm. Had a rock/paper/scissors thing going for a while. Although Una 1 still rapes it >.>
-
Maybe a re-run of the leagues with all the new contestants is in order (*cough* PY *cough*).
Not quite sure which version to actually run them in.
We seem to have a general movement toward 2.4 so it may be worthwhile to start the leagues over in that system and go from there.
Do the leagues actually work in 2.4 now?
-
I think Eric's working on it (or is going to).
-
Besides which I only run the F1 and F2 league.
We have others to run the short-bots and Multi-bots
-
Well bummer. The bot barely survives alone in 2.4
-
We could always expand the league systems to run in both 2.3 and 2.4 as seperate systems.
I have to admit though that I would really like to see Darwinbots going in only one direction. (possibly two as I would like to see the VB version kept alive parallel with the C++ version)
This means that at some time we are all going to have to get together and decide which version to 'officially" endorse.
With the work that Eric has been putting into 2.4 lately it may well be that we will go that way. If we can just get the systems to be a little more compatible then it would be great.
Failing that we might just have to start over and design stuff to run in 2.4
-
I think 2.4 is definately becoming a little more ANSI. What about your bot doesn't work well in 2.4 abyaly?
-
I think 2.4 is definately becoming a little more ANSI. What about your bot doesn't work well in 2.4 abyaly?
Well, it can no longer break birth ties. And it's a mystery to me why so many bots die off while eating.
-
We should spend some effort to try and see why it's not working.
-
I'll second that. If there is some aspect of 2.4 that is causing these problems then it needs to be located and fixed.
-
FYI, I plan to just keep pounding away on 2.4, knocking off the problems preventing 2.37.6 bots from running correctly. I'm just going to keep at it until one of three things happens: 1) I get there, 2.4 is 100% ANSI relative to 2.37.6 and everybody is happy that there are no significant compatability differences between the versions 2) 2.5 comes along AND everyone looses interest in the VB version(s) or 3) I burn out.
Leagues are on my list for 2.4, but not top of the list I suggest we not set the predecdent that there are two different leagues for the two different versions just yet, at leat not for reasons having to do with ANSI incompatabilities. Rather I suggest we keep the "official" leagues on 2.37.6 until the functional differences between the versions that impact combat bots are essentially nil. At that point, we can decide to run a special 2.4 league for bots that take atvantage of entirely new capabilities in 2.4+ if we want, but I don't think we should have two leagues simply because of "ANSI" incompatabilities.
I really appreciate that everybody keeps trying to use 2.4. It really helps me make progress. I know there is still a ways to go.
-
Making it able to kill una was much harder than making it able to beat The One or the SG version of swarm. Had a rock/paper/scissors thing going for a while. Although Una 1 still rapes it
That's because the first Una cheats by info shooting 32000 into .up
Una 3.0 doesn't cheat like that. The 3.0 version has a new enemy evaluation system and some major design flaws that I found were corrected. Una 3.0 was also my attempt at making a 'cleaner' bot that may work better in 2.4
BTW, I hope the movement commands have been limited in 2.4
It is also possible to use such an 'instant-kill-cheat' shot with the .strpoison, .strvenom, .mkslime and .mkshell commands
There should probably be a rule against using it in the leagues
-
Judging from personal experience, I would say that number 3 is quite likely.
-
Man I am really envious on your ability to programm bots ^^.
Well another topic can you store in more than memory location pery cyle using ties?
I thought you could only address one location.
Hmm I wish my wire/satellite concept and my use tied bot as additional eye concept would work although I am sure if these would be good for a hivebot.
Ok concerning the in,out tie stuff, I am not sure whats the problem but if you just want to make something readable you might consider to use one digit of an out to specify the "topic" and the rest for a value.(use modulo)
Or if you have enoguh outs you use one to sepcify the topics(again using modulo to assign digits to other outs topic)
If you want to tell someone something you might consider to producing "data capsules" meaning you will produce bots which only lives to be a messenger for a certain message (using ties for data transfer).
Depending on what kind of version you use these capsules could be produced beforehand. Basically you use a virus to make an empty bot, insert a virus(gene) that inhibits all he needs to know for basic functioning then you reproduce him with shoots storing in 300 repro so you have a storage of them, if you need to send a meesage you just give them they calues they shall transmit and of they go, or you bind them to your bot and whenever he sees a bot of his own kind he uses deltie to set one data capsule free and continues his fly.
Another possibility would be if each hive bot would have a certain "sector" assigned to him so you know where to find him. Or you might consider using a replacement tactic, you send one bot out to find a none hibernating bot, if he finds one he sucks it dry killing it off and then walks back to go into hibernation, such he replaces the bot he killed.
-
That two digit communication code is a good idea. So a complex message can be sent through in/out1 alone.
Also, if the queen bot timestamps each message with it's own age in another frequency to be sent alongside the message, it solves the problem of bots knowing which command is more up to date.
Also, if you're using viruses, you could make a gene that reprograms a veggie to be a messenger bot. That way it can just cruise around displaying the message and check back with the queen occasionally for more up to date information without needing to stop to eat. As it does that it can scout the area and record it inside its memory and report that back to the queen through tie info transfer.
-
Oh! Since elite doesnt want a stationary hivebot, as it moves it can leave behind 'pointer' bots. Each pointer bot will stare in the direction the queen went. The next pointer bot will be dropped within sight range of the previous one, and they can form something like a tail displaying the current location of the queen.
-
That's a really cool idea.
-
Thats similar to what I tried with wirelayer:
http://www.darwinbots.com/Forum/index.php?showtopic=1275 (http://www.darwinbots.com/Forum/index.php?showtopic=1275)
Its for 2.4 and still has some bugs in it(which also causes the wirelayeer to not always move in a straight line.
I planned to create a movable wire and a two way version but as I am lazy like ever I did not programm anything yet.