Author Topic: Venom impact on .fixed  (Read 9116 times)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Venom impact on .fixed
« on: March 16, 2006, 05:43:41 PM »
.fixed and .fixpos are treated differently than other sysvars today with respect to venom.  For example, if you use venom to overwrite another bots' .myeye, that bot will be confused about how many .eye statements are in their DNA for a period of time dependent upon how much venom was used.  The period of influence is obtainable via .paralyzed and once .paralyzed gets to 0, the effect of the venom wears off and the venomized bot returns to normal.  That is, referencing *.myeye will agian return the correct value.  This happens without the effected bot having to have any anti-venom specific code in its DNA.

It doesn't work this way for .fixed / .fixpos as far as I can tell.  Becuase of the asymetry in .fixpos and .fixed (one is kind of control only, one is kind of read only) when a bot gets fixed due to venom, they will be fixed forever more even after the venom wears off unless their DNA contains explicit instructions to do something about it.

Is this the correct behaviour?
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Venom impact on .fixed
« Reply #1 on: March 16, 2006, 06:04:49 PM »
It's not a bug if that's what you're asking.  It's debatable if there's a better behavior

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Venom impact on .fixed
« Reply #2 on: March 16, 2006, 06:21:02 PM »
Understand its by design.  My question is why it is the way it is.  Is there some reason it was purposfully designed this way?
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Venom impact on .fixed
« Reply #3 on: March 16, 2006, 06:26:28 PM »
It wasn't necessarily specifically designed that way.

Originally PY added fixpos and fixed to let bots control their fixed-ness.

Then he added Venom.

The way the two interact forms the way it is now.

Most things are like that.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Venom impact on .fixed
« Reply #4 on: March 16, 2006, 06:33:00 PM »
yea, I kind of figurred that, thus my question.

I like symetry.  I'm not saying change it, but when one thing doesn't work the way all the other things do...

Probably should have posted in the Suggestions forum.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Venom impact on .fixed
« Reply #5 on: March 16, 2006, 07:55:00 PM »
The problem is that it's a toggle instead of a command.  memloc, pval, etc. are all other toggles.  Toggles don't have to be reset every cycle by design, which makes them particularly vulnerable to venom and poison.

Offline Elite

  • Bot Overlord
  • ****
  • Posts: 532
    • View Profile
Venom impact on .fixed
« Reply #6 on: March 17, 2006, 12:34:17 PM »
You should have an unfixing gene in your bots as standard

Code: [Select]
cond
start
.fixpos *.fixed mult dec
stop

This gene costs no energy at all and can even go in conditionless bots

If your combat bot gets fixed, then it's your fault for not putting an unfix gene in  :P

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Venom impact on .fixed
« Reply #7 on: March 17, 2006, 01:44:43 PM »
Got it.  My question was less about coding for anti-venom and more about generating discussion on the  philosphy of the DB design in this area I.e. more about the question of what should be handled by the engine as part of the world's physics and what should be handled by the bot.  Let me try to explain.  I think of venom as three main things 1) the ability for a bot to semi-persistantly (I.e. longer than a single cycle) overwrite a mem location in another bot 2) the fact that the DB engine maintains state about this for how long it lasts and 3) the fact that the engine, not the bot, is generally resposible for putting things right when it wears off (else, why maintain the state?).

Now, 1) makes perfect sense to me because without the ability for bot A to potentially impact bot B's memory for longer than a single cycle, the world would be smaller, the scope of possible bot variation would be less.  But a question I pose is why should the engine be resposible for making it wear off?  Should venom wearing off be world chemistry or bot genetics?

2) is a design decision IMHO.  We could decide that the engine should maintain absolutely no state what so ever about venom I.e. that it is entirely the responsibility of the bot to check for venom effects and code for anti-venom via DNA self-checking approaches for all types of venom.  This raises the bar for coding for anti-venom, puts more stuff into the DNA, simplifies the engine but I don't think it has an impact on diversity I.e. it does not reduce the size of the space of all possible organisms or adaptations.  Personally, I think I favor this approach.  I like simplifying the engine and putting more into the DNA as long as it maintains maximum diversity potential.  Besides, there are problems with the engine maintaining state about venomized bots.  What if a bot shoots multiple kinds of venom?  What it a bot gets venomized by multiple bots with different venoms?  Should the engine maintain separate venom countdown state about each and every memory location for every bot I.e. have a separate .paralyzed sysvar and maintain separate countdown timers for all the different possible ways to get venomized?  Today this is kind of broken in my opinion as there is only a single paracount for each bot.

3)  Okay, so, we can decide (as the DB powers that be have in fact done) that venom wearing off is in fact chemstry, not genetics, that it is an artifact of the world physics and that it should be the responsibility of the engine to maintain state and track this.  Okay, I'm fine with this, but then lets be consistant.  If venom wearing off is the resposibility of the the engine, then all venom should wear off without the bot having to do anything.  A bot might and should be able to make it wear off faster by adding anti-venom code to it's DNA, but IMHO this should not be a necessary condition for any and all venom wearing off eventually.   If we are going to have the engine maintain venom state and make venom wear off, then it should do so regardless of what kind of venom it was.  Personal opinion.

Now, I fully realize that there is a lot of code history and that the engine, design and sysvars/mem have evolved over time (pun intended).  There will always be inconsistances like this in any version.  I just wanted to generate some discussion as to whether in future versions, we want to address this in some way.  The two possibilties I see are

a. Getting rid of all venom state in the engine and making it entirely the responsibility of the bot to code for anti-venom.  Bots can use venom to write to another bots memory, most thigns work liek they do today I.e. the size of the victum's shell and the size of the venom shot dictate whether or not it gets through, etc. but how long it lasts if it does get through is completely the resposibility of the venomized bot.  If the bot has no anti-venom DNA, the venom lasts forever.

b. Enhancing the engine to handle multiple types of venom and enhancing the state maintained by the engine so that it remembers the value of toggles before they were venomized and puts them back when the specific venom that impacted that memory location wears off.

Hey, if a newbie isn't good for stirring things up a little, what the hell good are they for anyway? :)
-E
« Last Edit: March 17, 2006, 01:58:47 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Venom impact on .fixed
« Reply #8 on: March 17, 2006, 02:06:58 PM »
I like this sort of discussion.  I had many similar ones when I first joined, which resulted in several reworkings for the better.

I'm not sure I understand what you mean by "bot genetics" being responsible for venom wearing off.

At present, venom attaches itself to a memory location and rewrites it with a certain value for X many cycles, then it stop overwriting it.

What are you suggesting an alternative would be exactly?  I agree with all the issues you've pointed out with the present situation, but I misunderstand the solution you pose.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Venom impact on .fixed
« Reply #9 on: March 17, 2006, 02:42:11 PM »
It's not completly thought through.  For example, it may end up being just too difficult for bots to code for policing their own memory, selection might favor having a super thick shell, etc. but here's he idea:

The engine would retain all the present code for deciding if venom makes it to a bot, .mkshell would work the way it does today in impacting venom shots, etc.  But if the venom shot was successful, instead of the new value being 'asscoiated' with the specific memory location in the victum and used as that value by the engine if the bot is still paralyzed, the new value would actually overwrite the location in the bots' memory.  The engine would no longer need to remember the previous "real" value becuase it would no longer be the engine's responsibility to put the "real" value back.  The engine would no longer maintain a count for how long venom lasts.  The .paralyzed sysvar would go away.  Venom would last forever unless the bot heals' itself by detecting the change and rewriting the venomized location back to an appropriate value (or another bot of the same species helps perhaps - can you say 'anti-venom venom'?).  How does a bot know what the 'real' value is?  That would be entirely the resposibility of the bot.  The engine would NOT remember this.  It's stateless here.  The bot would have to code for that in it's own DNA.  Think of the way it works for .Fixed today, but for all memory locations.  Venom wearing off becomes totally the resposibility of the bot, not the engine.  Don't want to wory about policing your own memory?  Grow a really thick shell!

The .shootval for a -3 shot would be used not for determining how long the venom lasts but instead perhaps imapcting the distance of the venom shot or the probability of it getting through the victum's shell (like it does for -6 shots I think).   The more venom you used, the farther it goes, the higher the probability of it getting through the shell, the more it costs you.  .mkvenom works the same way it does today.

-E
« Last Edit: March 17, 2006, 02:50:57 PM by EricL »
Many beers....

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Venom impact on .fixed
« Reply #10 on: March 17, 2006, 03:05:45 PM »
FYI, one reason I like the idea of venom replacing the actual location in the actual memory array is that the bot's memory is then the same for both the venomized bot and other bots around it who may look at it's memory.  The engien doesn't have to "fake it out."

For example, when playing around with venom, I think I saw that even after bot A used venom to change bot B's *.myeye, *.refeye for bot A still returned the old value.  Might be a bug, but I think what a bot sees when it looks at itslef and what other bots see should be the same.
-E
« Last Edit: March 17, 2006, 03:06:13 PM by EricL »
Many beers....

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
Venom impact on .fixed
« Reply #11 on: March 17, 2006, 03:32:59 PM »
I see one major problem with leaving the bots to police their own memory.

It would remove the entire effectiveness of venom. You might as well delete venom entirely since it is already possible to rewrite any memory location to any value using information shots. In that system, the value is overwritten then the engine forgets all about it and the affected bot is free to detect it and fix it if it is able to.

The concept of venom is that a bot can fix another bot's memory location for a number of cycles equal to the power of the venom shot. This venom fixing is specifically designed to continue to overwrite the memory location, no matter how many times the victim tries to fix it. Effectively the envenomed bot is utterly helpless against the venom, as are real organisms effected by a neuro-toxin.

Your point about the toggle for fixed is a good one though. Maybe the engine should remember the old state and return it when the venom wears off.

Multiple venom shots. Right now, one venom is the cure for other venoms. The latest venom shot to hit will overwrite the effects of the previous one. Think of it as a chemical reaction of the toxins. the timer remains and is added to but only the latest shot will have an effect

If you can figure out how, you might be able to use this to cure yourself of venom by  having another bot (like a conspec) fire a harmless venom shot at any envenomed conspec it finds, overwriting the damaged memory location.

How is it that I always think of these sneaky things while answering posts  :blink:
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
Venom impact on .fixed
« Reply #12 on: March 17, 2006, 03:35:42 PM »
Quote
For example, when playing around with venom, I think I saw that even after bot A used venom to change bot B's *.myeye, *.refeye for bot A still returned the old value. Might be a bug, but I think what a bot sees when it looks at itslef and what other bots see should be the same.

No it shouldn't. if the venom makes it read *.myeye wrong then that is simply because it's senses are screwed up. It has double vision or something.
Just because I think I have 13 fingers and 7 toes doesn't mean that you will count them that way. It just means that I am suffering from deusions.
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Venom impact on .fixed
« Reply #13 on: March 17, 2006, 03:47:25 PM »
Ah.  The subtlty that one design point for venom was that the venomized bot is prevented from changing the impacted location back until it wears off escaped me.  Also, I have not looked at info shots yet.  Had I done so, I would have perhaps saved us all some typing.  Please hang on a moment while I remove foot from mouth.

So, yup, my propsal is akin to getting rid of venom completly.  Let's not.  To prevent bots from changing the impacted location until the venom wears off, which sounds like a fine feature of the world to me, the engine [you]must[/you][/I] maintain the state.  I humbly withdraw my proposal.

Perhaps I'll look through the code at all the toggles and propose something on expiring all types of venom... but not today...   :banghead:

-E
« Last Edit: March 17, 2006, 04:02:23 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Venom impact on .fixed
« Reply #14 on: March 17, 2006, 06:20:34 PM »
I do like the idea of different flavors of venom not cancelling each other out.

There are two things associated with this:

1.  Bots that make venom should have to make a specific flavor of venom, which can't be turned into other venom later.

ie:

If you target .myeye with venom, and start making it, you shouldn't be able to later target .shoot and use the old venom that targets .myeye.

2.  Bots with multiple venom should have multiple venom effects.

This way I imagine a bot could make and use several varieties of venom that do all sorts of things, sort of a deadly coctail of various effects.  Fir ethe conspec confusion the first cycle, then use paralysis the next cycle, etc.