Author Topic: in-cycle switching of control sysvars like .readtie and .focuseye  (Read 6619 times)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Today, refvars and trefvars are populated only once per cycle,  at the beginning of the cycle based upon whatever the value of .focuseye or .readtie was at the end of the last cycle.  Changing .focuseye or .readtie mid cycle has no effect - only the last value stored matters and then only for the next cycle.  This makes it impossible to switch between eyes or ties during a cycle.  Same thing with .tienum and controlling ties.

I've been playing around and I think I can make the refvars and trefvars populate mid cycle whenever .focuseye or .readtie is modified.  This would make things like the following possible:


-4 .focuseye store
*.memval *.dnalen != and
140 .aimleft store
-1 .shoot store

-3 .focuseye store
*.memval *.dnalen != and
105 .aimleft store
-1 .shoot store

-2 .focuseye store
*.memval *.dnalen != and
70 .aimleft store
-1 .shoot store

.
.
.

What do people think of this?
« Last Edit: May 03, 2008, 01:04:27 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #1 on: May 03, 2008, 02:30:22 PM »
If you can get it to work, huzzah!

But there are issues here.  Basically you'd need to store all the refvars and trefvars for every potential bot the first one can see or is tied to, otherwise you have the potential for the order that a bot's DNA is executed to effect the results you get, which is bad.

Also, this would effectively change the senses from 1 eye with 8 proximity sensors to 9 full eyes.  That's a huge jump in senses.  Old bots just don't stand a chance with something like that.  Maybe we could change the dynamics a bit and limit it to, say, 3 or 5 full eyes?

Offline bacillus

  • Bot Overlord
  • ****
  • Posts: 907
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #2 on: May 03, 2008, 06:44:27 PM »
My OCULUS code would really benefit from that. But I think Numsgil's right, that would just give bot too much power:

-4 .focuseye store
'Code for eye 1
-3 .focuseye store
'Code for eye 2
'etc...
This would essentially turn the eyes into one huge eye that can still be used as nine eyes, without the drawback of widening the focus eye.
"They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown."
- Carl Sagan

Offline Moonfisher

  • Bot Overlord
  • ****
  • Posts: 592
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #3 on: May 03, 2008, 07:29:21 PM »
It seems a litle overpowered in some way but it also creates the possibility to reconize when you are outgunne or surounded and such...
Also it would be cool if you could read the .tin values of different ties in one cycle, having a focustie or something... (Not nesesarily being able to change tienum, just the tie you read from)
Could be interesting... but would make compex eyes very powerfull compared to "normal" eyes...

Offline The_Duck

  • Bot Neophyte
  • *
  • Posts: 29
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #4 on: May 03, 2008, 08:23:52 PM »
How about just doing it for ties? The current eyes design is based around a single focus eye, but I see no reason why all ties shouldn't be equivalent.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #5 on: May 03, 2008, 10:03:03 PM »
I do think ties are a given.  Being able to communicate through multiple ties in a single cycle is good without being unbalanced.

Offline gymsum

  • Bot Destroyer
  • ***
  • Posts: 215
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #6 on: May 04, 2008, 01:05:46 AM »
Quote from: EricL
Today, refvars and trefvars are populated only once per cycle,  at the beginning of the cycle based upon whatever the value of .focuseye or .readtie was at the end of the last cycle.  Changing .focuseye or .readtie mid cycle has no effect - only the last value stored matters and then only for the next cycle.  This makes it impossible to switch between eyes or ties during a cycle.  Same thing with .tienum and controlling ties.

I've been playing around and I think I can make the refvars and trefvars populate mid cycle whenever .focuseye or .readtie is modified.  This would make things like the following possible:


-4 .focuseye store
*.memval *.dnalen != and
140 .aimleft store
-1 .shoot store

-3 .focuseye store
*.memval *.dnalen != and
105 .aimleft store
-1 .shoot store

-2 .focuseye store
*.memval *.dnalen != and
70 .aimleft store
-1 .shoot store

.
.
.

What do people think of this?

I have been toying arround with multibot eyes, one idea I had was to have two bots focus on the same bot through touts, and have a tird bot tied to either bot scan for more. So far I've managed a translator and tout/ins, the focus is almost completed. I've been wondering tho, how was sight supposed to be handled? Was it to be realisitic? Or simulated? Because realisiticly, you would have several bots looking at one group or bots, and those bots would tell others to activate based on tie counters and such.

Offline Peksa

  • Bot Destroyer
  • ***
  • Posts: 118
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #7 on: May 05, 2008, 06:07:02 PM »
I agree with pretty much everything said here. For eyes, it could be a bit overpowered, but for ties it sounds good.

Offline goffrie

  • Bot Builder
  • **
  • Posts: 65
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #8 on: May 06, 2008, 07:59:36 PM »
I'd add a (configurable) energy cost for multiple .focuseye changes in one cycle, so as not to terribly unbalance things.

It would be a nice addition, though

Offline gymsum

  • Bot Destroyer
  • ***
  • Posts: 215
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #9 on: May 06, 2008, 09:24:45 PM »
Quote from: goffrie
I'd add a (configurable) energy cost for multiple .focuseye changes in one cycle, so as not to terribly unbalance things.

It would be a nice addition, though

I agree but not sure it should be in energy, but in change times. I say limit the number of times a focuseye change can be made to 9 times, so theres no repetetive cycleing of the same 9 eyes 20 times in one cycle. I've also been wandering about the processing powers of a bot, ideally its limited by the programer, but what is the computation speed of a bot with one eye active? It seems that this by increasing memory for eyes it would sacrfice in some logical and computational speed and activation, so by setting several eyes to activate in a single cycle takes away from the bots ability to decide things and interpret information. I think overall its a good idea, but should be limited to multibots since they posses the  means for more information to be processed, unless theres some genetic codes to increase computational speeds and logic production.

Offline gymsum

  • Bot Destroyer
  • ***
  • Posts: 215
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #10 on: May 07, 2008, 11:34:04 PM »
Eric, if you added a multiple eye ref switch, could you go ahead and add a multiple memloc and tmemloc for multi bots? It would be nice if we could build bots that thought and did stuff at the same time.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #11 on: May 07, 2008, 11:50:51 PM »
Switching tmemlocs during a cycle is something I would approve of, but memloc switching is not.  There need to be limits on what you can do when you meet a perfect stranger.

Offline gymsum

  • Bot Destroyer
  • ***
  • Posts: 215
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #12 on: May 08, 2008, 12:14:13 AM »
I could see that being a decent balance, single bots couldn't identify certain things based on limitations, while multibots could multitask, by reading and sending to two different ties in a single cycle, thus improving memloc features, three bots could do three memory related things in under 4 cycles.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #13 on: May 08, 2008, 12:25:31 AM »
Quote from: gymsum
Eric, if you added a multiple eye ref switch, could you go ahead and add a multiple memloc and tmemloc for multi bots? It would be nice if we could build bots that thought and did stuff at the same time.
Yes, I could do that and yes, I totally agree that it would be nice to have more take place in cycle.

The main reason I think this all would be good - the whole thing I.e. switching the focus eye in cycle, switching the readtie, numtie and yes, tmemloc/tmemval in-cycle - is that I think it opens up or at least greatly increases the opportunity for more complex evolved and/or programmed behaviours.

Personally, I'm not a big fan of one trick pony bots and that IMHO is what a lot of DB has been about or at least used to be about over the years.  The bot that got to the top of the leagues wasn't the one with the best or most complex navigation or stalking or hiding behaviour, it was the one that exploited a design flaw that let you force your prey to make 32000 units of venom or took advantage of an unprotected sysvar in the current top opponent or fooled another's conspec recognition system and so on.  Bots that had lots of sophisitcated code got whacked by far simpiler bots using one clever trick.

Now, clever tricks are all well and good and have their place, but personally, I would like to see bots compete, be they hand coded or evolved, on a higher level, more sophisticated playing ground where more complex, sophisticated behaviour conveys advantage not disadvantage.  I want the bot that that can keep one eye on a shape wall and another on a prey and use the shape as cover and do so reliably without worrying about losing the shape between cycles because it has to switch eyes to see the prey.  I want the cat-o-nine tails multibot that can pivot ten tied bot appendages into position to shoot at a prey all at once.  I want swimming bots and multibots coordinating many cells at once and so on.

Now that the skelaton of Seasnake is there, most of what I plan to do there going forward is complex behaviour stuff.  e.g. curl around a prey so that more cells can fire upon it all at once or curl up when attacked to present less target area and avoid hitting your own cells as you fire back.  That kind of thing.  Head to head, toe to toe, no tricks involved.

DB is a bascially a time sliced, quantum system.  Cycles are quanta.  Bots could do some of these things today over the course of multiple cycles, but that would mean that bots with sophisticated behaviours pay a price in that time slows down for them I.e. they take multiple cycles to complete what is logically a single action.  This penilizes sophisitcated behaviour and favors one trick ponies.  Don't get me wrong, there will always be a place for the small, fast, simple bot that finds and exploits a weakness just as there are biological viruses that exploit us multi-trillion cells organisms.   But I'm understandably biased towards multicellularity.
« Last Edit: May 08, 2008, 12:26:09 AM by EricL »
Many beers....

Offline Peksa

  • Bot Destroyer
  • ***
  • Posts: 118
    • View Profile
in-cycle switching of control sysvars like .readtie and .focuseye
« Reply #14 on: May 08, 2008, 06:15:40 PM »
Hmm.. When you put it that way, I say go for it. And if you go for it, go all the way. No artificial limitations for how many times you can change eyes. All nine eyes should implemented. No other artificial limitations on DNA. You could maybe add an optional cost for switching eyes, but I don't really see the point.

I still think that most of the old bots are going to be overrun after this, but that's not necassarily a bad thing. It show's that things move forward (or at least somewhere ).

Ps. If this can be done, it could be done for every sysvar. That might be too much though, even if it would do wonders for evolved DNA.

Example:
Code: [Select]
cond
*.eyef 50 >
start
10 .up store
stop

A bunch of unrelated DNA here.

cond
*.up 10 >=
start
-1 .shoot store
stop