Bots and Simulations > The Gene depository

Demo of new .eyeNwidth sysvars

<< < (2/4) > >>

Zinc Avenger:
Apart from needing to explicitly have a reference to an eye to turn on eyes, I can't see it breaking existing bots. These are just additional features that if not used, which default to the original standards. I could be wrong here of course

And of course, older bots are all of a sudden going to become very, very vulnerable to having their eyes messed with. Can even something fearsome like the top tie feeder beat a bunch of T. Preservans which has been modified to shoot, say, -4 into .eyef?  

EricL:
ZA is absolutely correct.  It is totally and completely 100% backward compatable.  None of the new eye features mess up exsiting bots.  Values of 0 in the new sysvars do exactly what everyone has been used to for a very very long time.  I worked hard to make sure this was the case even though it complicates things some (e.g. when you use .eyeNdir or .eyeNwidth, the values are offsets from the defaults, not the actual direction or width).

The point about having an eye statement for the eyes to work is a performance thing in the code that has been there since before I came on the scene.  The code doesn't populate the eyes if the bot does not have an eyeN sysvar in it's DNA.  This works fine for most hand coded bots, but not for evolved bots since they can evolve indirect addressing of the .eyeN locations.

Thus, it's not in the code yet, but I will likely disable this little perf thing in 2.43 so that the .eyeN sysvars get populated even for bots that have no .eyeN sysvars.  Hate to take the perf hit, but it's probably not large - most bots in most sims except plants use their eyes.  We will get it back and more when I implement stupid built-in plants.

EricL:

--- Quote from: Zinc Avenger ---And of course, older bots are all of a sudden going to become very, very vulnerable to having their eyes messed with. Can even something fearsome like the top tie feeder beat a bunch of T. Preservans which has been modified to shoot, say, -4 into .eyef?  
--- End quote ---
The marco point is well taken but in the name of nit picking clarity, I think you mean shoot -4 into .focuseye, not .eyef.  

Presumedly, the top feeder does not (yet) use any of the new eye features and thus never bothers to check the value of .eyef, which for bots that never change their focus eye, will always be the same as the vaule of .eye5.  Shooting a -4 into .eyef will therefor not have any effect on bots that never read from that sysvar.

Sooting -4 into .focuseye on the otherhad can really screw up a bot since presumedly it has no DNA to change .focuseye back, it's refvars will from then on represent what is in .eye1, not .eye5.

Again however, the marco point is very well taken.  There are many sysvars which if mucked with by another bot or by waste build up can really screw up a bot.  And now there are 20 (well, 19) more.

Zinc Avenger:
Yup that's what I meant. And I wonder why none of my hand-written bots never work!

Oh, and when it comes to evolution having a hard time with all these new sysvars... I've learned never to discount the possibility of evolution doing the most insanely complicated and unlikely things with a bunch of bitwise operators, timers, and seemingly-irrelevant numbers.

Light:
using

1221 .eye5width store

and then

cond
*.eye5 0 >
start
  *.refxpos *.refypos angle .setaim store
stop

gives a bot that will turn towards whatever is nearest to him, negates the need for other eyes  

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version