Bots and Simulations > Bot Tavern

Ambitious MB project

<< < (8/11) > >>

Houshalter:

--- Quote ---X inc inc will increment location X, then increment zero. you have to implicitly say X inc X inc or X dup inc inc.
--- End quote ---
Really? this might explain many errors in bots i've made in the past.


--- Quote ---make that second *.numties simply .numties and it should be sweet.
--- End quote ---
oops.  


--- Quote ---*.lasttienum seems to refer to the first, not last, tie, so should probably be left seperate from .tiepres, which refers to the most recent tie. Other than that, the code seems pretty good. You may want to look into taking advantage of OCULUS, I'll be using it here and there anyway...
--- End quote ---
I'll rename it. I started with the concept that you had to reproduce then shoot a tie at your offspring but maybe you can just harden your birth tie. Also i completely left out tie angles and hardness and the like. If it becomes a problem and it probably will, i'll have to come back to it. can't you just store a negative number in one of the tie angle sysvars to make your bots free rotating.?


--- Quote ---I was thinking that using 31999 rnd ++ .tie store to make a virtually unique tie ID could be helpful for organizing ties. Do you think this would be a good idea to implement?
--- End quote ---
Im not that familiar with the bitwise commands yet. But whats the point of having unique tie ids. You might be able to eliminate unique bot ids, and have every bot be identified by its ties, but that just makes it even more unessacarly complicated. If you plan on creating a new cell type, like a brain (that would be really, really cool), where the cells are connected to as many neighboring cells as possible, it could be usefull. You could set aside a memory range for every tie and when it made it and access it like an array. I suppose the advantage to a brain would be you could take advangtage of a lot of bots collective memory and processing power and combine it into one. it would be taxing on the bot though. Maybe you could make it run intirely on incs and decs to save nrg.

bacillus:
The tie ID is not that complicated really. It creates a random number between 0 and 31999, then increments it as 0 would not form a tie. The point of doing so is that a bot can remember which tie formed when, and allows the child to form the tie on birth without having to read parent info, which seems kind of suspect (the only other option is static tie ID, which disables tie switching completely). The parent can't bond on the birth cycle, and you'll be surprised how often they fail to bond after the birth cycle, becuase they move out of alignment or one of them turns or another bot gets in the way, etc...


--- Quote ---Maybe you could make it run intirely on incs and decs to save nrg.
--- End quote ---
The trouble with this is that until loops are implemented in DB3 (and that's not looking remotely close to being likely), inc/dec commands allow only a fixed variation. Increasing 50 to 100, for example, could be better done with *.X 50 add .X store than X inc X inc X inc etc. (fixed) or X inc over 50 cycles (way too slow).

Houshalter:

--- Quote ---The parent can't bond on the birth cycle, and you'll be surprised how often they fail to bond after the birth cycle, becuase they move out of alignment or one of them turns or another bot gets in the way, etc...
--- End quote ---

I know. Im trying to avoid systems that are set in stone and require precise timing and coordination. If a parent fails to tie to the child the first time it sees it then it will just try again the next time it sees it and if some random factor makes the child drift away and breaks its birth tie then it will just not do anything and die or get attached to by another tentacle on another bot.


--- Quote ---The trouble with this is that until loops are implemented in DB3 (and that's not looking remotely close to being likely), inc/dec commands allow only a fixed variation. Increasing 50 to 100, for example, could be better done with *.X 50 add .X store than X inc X inc X inc etc. (fixed) or X inc over 50 cycles (way too slow).
--- End quote ---
10 incs/decs is equal in cost to 1 store. Im not sure how a brain would work though. I suppose you could have it simulate a neural network, randomly tieing to other bots and changing their wieghts and stuff. Maybe you could put boolean logic in there to and allow the bots to use an array of memory as, well memmory. Im not sure how you would get it to learn though.

abyaly:

--- Quote from: bacillus ---
--- Code: ---cond
*.out1 *.numties !=
start
*.out1 *.numties store
stop
--- End code ---

make that second *.numties simply .numties and it should be sweet.
--- End quote ---
.numties is intended as a read location. If you store info there it will just be reset next cycle. Why are you doing this?

bacillus:
An inadvertent reversal of commands perhaps?

I think that it would actually be a great idea to implement a backup gene like your tie former...

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version