Code center > Suggestions

in-cycle switching of control sysvars like .readtie and .focuseye

<< < (2/4) > >>

Numsgil:
I do think ties are a given.  Being able to communicate through multiple ties in a single cycle is good without being unbalanced.

gymsum:

--- 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?
--- End quote ---

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.

Peksa:
I agree with pretty much everything said here. For eyes, it could be a bit overpowered, but for ties it sounds good.

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

gymsum:

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

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page