Author Topic: Sim thermodynamics  (Read 4043 times)

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Sim thermodynamics
« on: April 05, 2006, 12:53:24 PM »
I've run into a couple of other strange altzheimer's related behaviours recently (like high energy, high body bots suddenly dying becuase their nrg or body was set to negative ) and a crash in a different area having to do with a huge negative value in .body.  All are the result of altzheimer's writing wacky values into a set of key locations when waste gets high.

I do not think it is the right thing for Altzheimers to be able to permanently change bot memory locations which are really state information "about the bot" (like .nrg, .body, .mass, .waste) maintained and set by the engine as opposed to information set and maintained by the bot, as means of for contoling it's behaviour or interacting with its environment - .dn, .aimsx, etc.   Allowing the former lets altzheimers  go beyond it's purpose IMHO, to go beyond making the bot act "funny" due to internal waste build up and instead adversely impact what I will call the "laws" of the sim - for example, the law of conservation of mass/energy.

Ignoring the crashes for a moment, do we really want a build up in waste to cause a bot with 32000 body and 32000 ernegy to die suddenly in one cycle and take all that energy out of the sim in one cycle?   Do we really want altzheimers to suddenly and magically give low energy bots massive energy or suddenly make a scrawy bot instantly massive?   Where did that energy come from?  Where did it go?  Altzheimers has the ability to magically invent it and destroy it.

I put forward the premise that energy/mass in a sim should be conserved.  Energy should only enter the sim via sunshine on veggies at the rate specifed and only leave via utilization - movement, shots, DNA execution, whatever.  The more I think about it, the more I dislike the notion that energy can be magically added or removed by Altzheimers.

I suggest that memory locations which constitute engine-maintained state about a bot should be off limits to Altzheimers.  

Comments?

-E
« Last Edit: April 05, 2006, 12:55:44 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Sim thermodynamics
« Reply #1 on: April 05, 2006, 02:36:56 PM »
I think you misunderstand what alzhiemers is doing.  When it writes over .nrg with something like -3, it doesn't make the bot actually have -3 nrg any more than writing 32000 to .nrg manually will give a bot 32000 nrg.  Rather, alzheimers interferes with the only way bots have to sense the world and themselves, and so makes bots think they have -3 nrg, or whatever.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Sim thermodynamics
« Reply #2 on: April 05, 2006, 03:05:38 PM »
Sorry, I'm tired.  Your half right.  I understand that the engine thinks its maintaining state outside the mem array, and that altz... only impacts the mem array directly, but energy loss is happening indirectly because of it.  The end effect is the same.   There are lots of routines that are being indirectly impacted from altzheimers writing huge negative values into the mem array values.  For example:

Private Sub feedbody(t As Integer)
  If rob(t).mem(fdbody) > 100 Then rob(t).mem(fdbody) = 100
  rob(t).nrg = rob(t).nrg + rob(t).mem(fdbody)
  rob(t).body = rob(t).body - rob(t).mem(fdbody) / 10
  If rob(t).nrg > 32000 Then rob(t).nrg = 32000
  rob(t).radius = FindRadius(rob(t).body)
  rob(t).mem(fdbody) = 0
End Sub

Now imagine what happens to .nrg when Altzheimers writes -32000 to mem(fdbody).  .nrg goes way negative, .body gets pushed way high and maybe overflows mem(body) down the road if the bot isn't killed off due to .nrg < 0...

or

Private Sub storebody(t As Integer)
  If rob(t).mem(313) > 100 Then rob(t).mem(313) = 100
  rob(t).nrg = rob(t).nrg - rob(t).mem(313)
  rob(t).body = rob(t).body + rob(t).mem(313) / 10
  If rob(t).body > 32000 Then rob(t).body = 32000
  rob(t).radius = FindRadius(rob(t).body)
  rob(t).mem(313) = 0
End Sub

when Altzheimers writes -32000 to mem(313) which is .strbody.

The net result is that oddles of energy or body get vaporized or added, big fat bots dissappear or small ones grow insteantly and somtimes a hi magnitude single gets assigned to an Int and things crash.  

Should I be adding code to check for special limits in all these routines?  Should we perhaps change Altzheimers to write deltas to current values instead of anything from -32000 to 32000?  Am I just sleep deprived?
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Sim thermodynamics
« Reply #3 on: April 05, 2006, 06:06:17 PM »
Theoretically values like that that could cause huge nrg changes are limited.

fdbody for instance can only feed or store 100 body at a time, regardless of what is stored in the memory.  Also, fdbody won't feed more body or store more body than physically exists.  That is, again theoretically, total nrg values can't just disappear or reappear from nowhere, even when the bot dies (this is far more true of course in corpse mode).

What would be a good idea is physically checking all the possible sysvars for sysvars that aren't limited like that.  There might be some holes.  Try to find them and I'll help you cap them.

Alzheimers shouldn't have limits, but what it effects should.  If you limit alzheimers for certain locations, it still means that mutations might end up writing 32000 to fdbody.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Sim thermodynamics
« Reply #4 on: April 05, 2006, 11:43:13 PM »
Quote
fdbody for instance can only feed or store 100 body at a time, regardless of what is stored in the memory...
Certainly for positive values, but I think there are at least a few places in the code where it just doesn't handle large magnitude negative sysvar values correctly be they from mutations or altzheimers.  I've watched high nrg high body bots suddenly just dissappear and not from shock or prediation...

I think I now have what I need to proceed.  I won't change Atlzheimers.  It will continue to write anything from -32000 to 32000 anywhere in the array when waste exceeds the threshold.  I will add the code to address the cases where large negative sysvar values (no matter where they came from) are causing problems by attempting to enforce the sysvar "rules" as best I can.  Where negitve values are written into sysvars like fdbody, I will keep the sign but clip the magnitude.  (Hey, I just found some text in the movement section of the wiki that actually says this!  Doh.  Takes me a while to catch on I guess.) So, any negative value < -100 written into .fdbody from anywhere including Atlzheimers will have the equivalent impact as -100.  This is what is missing.  It will prevent the overflows at least (though I suspect there re a lot of little holes liek this) and should curtail the magic energy creation/destruction.

So, basically, this all comes down to a bunch of bugs that need fixing in the area of insuring that large magnitude negative sysvar values cause the expected behaviour.  As you suggest, I will try to walk through all the sysvars looking for such cases...

-E
« Last Edit: April 06, 2006, 12:00:18 AM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Sim thermodynamics
« Reply #5 on: April 06, 2006, 12:45:24 AM »
Yeah, it's alot of busy work.  Annoying how the minor details like that can get in the way.

Offline Griz

  • Bot Overlord
  • ****
  • Posts: 608
    • View Profile
Sim thermodynamics
« Reply #6 on: April 06, 2006, 09:17:08 AM »
Quote from: Numsgil
Yeah, it's alot of busy work.  Annoying how the minor details like that can get in the way.
which means they aren't 'minor' after all.
it's about seeing the big picture ...
while also paying attention to the details.
both are required.
不知
~griz~
[/color]
   "The selection of Random Numbers is too important to be left to Chance"
The Mooj  a friend to all humanity
[/color]

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
Sim thermodynamics
« Reply #7 on: April 07, 2006, 09:50:03 AM »
Well they are minor as long as nobody notices them.  

As soon as the problem is isolated then it becomes the biggest thing we have ever seen.

At least we can fix it then though.

It is quite possible that there are still a number of places in the code where negatave values aren't handled correctly. Back in the old days, tie feeding was such a "loophole" in the code. It wasn't until I designed "H Devincio Venator" that we realized it was even possible. Back then we could transfer positive values through ties with a maximum cap of 1000 points but nobody ever tried setting it negative. There was no limit whatsoever so HDV was able to drain an entire robot in one cycle.  

It was kind of fun watching him decimate the world of shot feeders.  
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D

Offline Endy

  • Bot Overlord
  • ****
  • Posts: 852
    • View Profile
Sim thermodynamics
« Reply #8 on: April 11, 2006, 05:09:38 AM »
What about the random waste death? Not sure the exact equation, but it'll happen after alot of pwaste is accumulated.

Offline PurpleYouko

  • Bot God
  • *****
  • Posts: 2556
    • View Profile
Sim thermodynamics
« Reply #9 on: April 11, 2006, 09:31:38 AM »
Pwaste still only kicks in Altzheimers. It just does it on every cycle instead of now and then.
At least that was the way I originally programmed it. Might have been changed for all I know.
There are 10 kinds of people in the world
Those who understand binary.
and those who don't

:D PY :D

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Sim thermodynamics
« Reply #10 on: April 11, 2006, 10:05:57 AM »
If Waste and PWaste are above the waste threshold, there is a small but real chance that a bot will instantly die.  Something like 1 in 700 per overflow per cycle.