Tie-Only Custom Variables

[rsucoop]

As the demand for more custom variables grows, and multi-bot necessity for tie values to be read and transfered; I propose the following. Create 50 variables that only exsist inside a tie, that way a multibot could push more than one value through the tie at once, store in the tie's memory. A bot could then read from any of the values stored in the tie at once, and would not directly affect the memory in the tied bot. Communications would be streamlined alot, suddenly a multi-bot could issue an order, and every cell would know it within 1 cycle per attached bot. One problem I do see, is that multiple ties means 50 * numties of infomration that must be created, so a multibot would suddenly have a very large brain to work with. Maybe not 50 locations, but more than a dozen locatios to be effective for DB simulation.

[Numsgil]

When I was working on the problem of ties for DB3, trying to get a bot to read and write to any memory location of a bot attached to it, I arrived at something that's very similar.  There's two tricks here:

1.  You're using 50 memory locations.  Just up it to 1000, and suddenly you can use another connected bot like an extension of yourself.  Like a dummy puppet to do with as you please.

2.  While you do need to use a buffer in the tie (so that the order that bots execute their DNA doesn't matter), you don't need to actually store a copy of the other bot's memory in the tie.  All you're interested in is what the bot's memory looked like at the beginning of the cycle, and any changes you've made to it during this cycle.

Taking the two together, I came up with a system where bots interface with memory through a "filter".  Doesn't matter if it's the bot's personal memory or an attached bot.  This filter ordinarily reads the bot's "base" memory, what it's memory looked like at the beginning of the cycle.  But if a bot stores a value to a memory location, it's stored in the filter instead of the "base" memory.

After all the bots have had a chance to execute, the filters are "applied" to the base memory.  Each bot's DNA goes first, and then any connected bots' filters are applied (probably averaging any conflicting stores).  Pretty sure I have a working version for it right now in the DNA module I wrote.  The funny part is that, even if the other bot is lame, deaf, and dumb, and alzheimic, you can still use the funny way the filters work as a large array of temporary memory to manipulate.

Something like this could be implemented in the current version.  It would mean alot of code rewrites.  Would be a major overhaul (one of the reasons I started DB3 fresh instead of directly porting the current version), but if Eric's willing I think it could be done.

[rsucoop]

When I was working on the problem of ties for DB3, trying to get a bot to read and write to any memory location of a bot attached to it, I arrived at something that's very similar.  There's two tricks here:

1.  You're using 50 memory locations.  Just up it to 1000, and suddenly you can use another connected bot like an extension of yourself.  Like a dummy puppet to do with as you please.

2.  While you do need to use a buffer in the tie (so that the order that bots execute their DNA doesn't matter), you don't need to actually store a copy of the other bot's memory in the tie.  All you're interested in is what the bot's memory looked like at the beginning of the cycle, and any changes you've made to it during this cycle.

Taking the two together, I came up with a system where bots interface with memory through a "filter".  Doesn't matter if it's the bot's personal memory or an attached bot.  This filter ordinarily reads the bot's "base" memory, what it's memory looked like at the beginning of the cycle.  But if a bot stores a value to a memory location, it's stored in the filter instead of the "base" memory.

After all the bots have had a chance to execute, the filters are "applied" to the base memory.  Each bot's DNA goes first, and then any connected bots' filters are applied (probably averaging any conflicting stores).  Pretty sure I have a working version for it right now in the DNA module I wrote.  The funny part is that, even if the other bot is lame, deaf, and dumb, and alzheimic, you can still use the funny way the filters work as a large array of temporary memory to manipulate.

Something like this could be implemented in the current version.  It would mean alot of code rewrites.  Would be a major overhaul (one of the reasons I started DB3 fresh instead of directly porting the current version), but if Eric's willing I think it could be done.

1000 would be amzaing, that would mean a multibot would be capable of actually learning a behavior it watched.

[rsucoop]

By adding the filter, would that disable the single memtransfer directly to the other bots memory? Such as a read command.

[Numsgil]

Presently the mem transfer is held in a buffer anyway, because if you're robot 10 in the array, and you change robot 20's memory before robot 20 gets to run their own DNA, you have an unfair advantage.  This would just formalize that idea and increase the scope.

[rsucoop]

Presently the mem transfer is held in a buffer anyway, because if you're robot 10 in the array, and you change robot 20's memory before robot 20 gets to run their own DNA, you have an unfair advantage.  This would just formalize that idea and increase the scope.

PErhaps then we should use special ties to directly effect the memory of a bot at the event cycle in the other bot, regardleess of Bot B's gene cycle. This would prove easier for manipulating a veggie.

[Numsgil]

Not sure I understand what you're saying.

[rsucoop]

Not sure I understand what you're saying.

OK, so a bot is tied to another, an enemy. Before it feeds it checks, to make the nemy not delete the tie, it needs to be able to push some value into the bots memory before its genes activate. That's what I mean, a tie information transfer that happens regardless of the genes in the objective bot.