Author Topic: Problems with 2.44f  (Read 4565 times)

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Problems with 2.44f
« on: September 09, 2007, 08:00:56 AM »
1.  Veggies don't seem to respawn.

2.  I was having weird issues with custom costs not "sticking" on the costs form.

3.  Internet population stats add the species to the species list, even when they're not on your computer.  When you restart, you get a "what the heck file is this?" message.

4.  Something is seriously wrong with shots.  The returned energy shots' vectors are screwed up.  Two dogfighting bots will leave a trail of white shots.  That's a clear indicator that something with the vectors is screwy.  This might be a long standing issue that I'm just now noticing.  I'm fairly certain that 2.37 was working correctly in this regard, though I can't test it for some reason (2.37 isn't running, I probably need to set up a seperate install location for it.)

5. Doesn't seem to be forward compatible with 2.43.  Try running 2.43 and you get some odd "type mismatch' error.  I think it has to do with the internet settings file, but I don't know for sure.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Problems with 2.44f
« Reply #1 on: September 09, 2007, 04:29:22 PM »
Quote from: Numsgil
1.  Veggies don't seem to respawn.
Whoops.  I ANDed where I should have ORed in the veggy repop routine.  I had to add code to exclude non-native veggies (I.e. teleported in from another sim) for repopulation since the DNA file may not be handy.   Wasn't checkign nativeness right, which in fact would impact non-internet sims without teleporters. Someday we shoudl perhaps include the DNA file in the dbo and auto-add ...   Fixed in 2.43g

Quote from: Numsgil
2.  I was having weird issues with custom costs not "sticking" on the costs form.
I'm using the species structure to store runtime stuff now like the population totals for the species.  This means I have to copy runtime info into the tmpopts structure when the options dialog is opened.  Beleive it or not, each value in simopts is copied to tmpopts explicity.   Long history predating my arrival.  in the last buddy, I tried to clean this up to copy the whole structure, but its complicated.  There are some really strange repaint issues with the Options dialog.  DispSettings gets called when the form repaints after the Costs dialog gets closed, which was putting the simOpts values back into the TmpOpts struct everytime the dialog painted, which was erasing changes made in the costs dialog.  I should probably do this right and dig into the whole way options dialog stuff gets loaded and what window messages occur when, but I'm too lazy.   I've handled the issues with the costs and repainting by backing out my whole struct copy and copying the values I need explicitly jus tlike it has always been done.  Ugly, but works.   Fixed in 2.43g.

Quote from: Numsgil
3.  Internet population stats add the species to the species list, even when they're not on your computer.  When you restart, you get a "what the heck file is this?" message.
As above, I need a species struct for every species in the sim whether it is native or not.   Right now I'm showing all the species everywhere and then catching it when you try to do something on a species (like insert one) for which a local DNA file does not exist.  I've cleaned this up a little now for sim restart - you only get one "what the heck" common dialog per species now independent of how many you wanted to insert when you restart the sim.  Additionally I silently try the Robots directory as well as whatever the path on the origianl bot that caused the species entry to be created says is in an attempt to find a DNA file for bots that may be non-native  to yoru machine but for which a local file exists on yoru machine (just in a different main install point) but we still have this higher level issue of dbos not containing the DNA file so you will still get this when you restart from settings (but not from a saved sim) for bots for which you don't have a DNA file.
   To be clear, it's not the internet stats per se but rather when a bot of a new species gets teleported into the sim that it gets added to the species list.  The internet stats graph will show the totals for bots  that never make it to your local sim - say they get introduced into another connected sim then die off before being teleported to yours.  You will see a chart entry for them, but not an entry in the species list.   Only when a bot of a novel species actually makes it to your sim do I add a new species instance.   You can save sims with such bots and they will run fine but if you save settings (including restarting from the last settings) well, without the DNA file, what can I do?

Quote from: Numsgil
4.  Something is seriously wrong with shots.  The returned energy shots' vectors are screwed up.  Two dogfighting bots will leave a trail of white shots.  That's a clear indicator that something with the vectors is screwy.  This might be a long standing issue that I'm just now noticing.  I'm fairly certain that 2.37 was working correctly in this regard, though I can't test it for some reason (2.37 isn't running, I probably need to set up a seperate install location for it.)
Indeed, this is a long standing issue.  The return shot velocity is half the velocity of the shot that caused it (relative to the impacted bot).  This means that if two dogfighting bots are shooting at each other while moving quickly sideways, as many velocity matchign genes do, the return shots trail behind them, impacting neither.  There was a long discussion on this whole topic maybe 10 months ago.  Happy to make whatever changes people want to see here.  (Also a reason I think shots should be visible)

Quote from: Numsgil
5. Doesn't seem to be forward compatible with 2.43.  Try running 2.43 and you get some odd "type mismatch' error.  I think it has to do with the internet settings file, but I don't know for sure.
Yea, I screwed up the internet settings a little.  It's a text file, not a binary file, so the type mismatch was due to older versions trying to read in a integer saved as a string only the dummy string I was using wasn't a number....  Fixed in 2.43g in a backward compatable manner. l
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Problems with 2.44f
« Reply #2 on: September 09, 2007, 08:20:35 PM »
Quote from: EricL
Quote from: Numsgil
...well, without the DNA file, what can I do?

I see two options.  You could either "extract" the DNA from an imported dbo and save it in some sort of directory somewhere, or go through the code and find everywhere where an imported species needs to be in the species list and work in some new logic for an "imported species" list.

Also, while you were poking around in loading routines, did you change the way bots are loaded so that the DNA file is only read in once?  This was a long standing (and rather silly) issue with large sims being started fresh.  It would take 5 or 6 seconds reading a DNA file 1000 times.

Quote
Quote from: Numsgil
4.  Something is seriously wrong with shots.  The returned energy shots' vectors are screwed up.  Two dogfighting bots will leave a trail of white shots.  That's a clear indicator that something with the vectors is screwy.  This might be a long standing issue that I'm just now noticing.  I'm fairly certain that 2.37 was working correctly in this regard, though I can't test it for some reason (2.37 isn't running, I probably need to set up a seperate install location for it.)
Indeed, this is a long standing issue.  The return shot velocity is half the velocity of the shot that caused it (relative to the impacted bot).  This means that if two dogfighting bots are shooting at each other while moving quickly sideways, as many velocity matchign genes do, the return shots trail behind them, impacting neither.  There was a long discussion on this whole topic maybe 10 months ago.  Happy to make whatever changes people want to see here.  (Also a reason I think shots should be visible)

There was a time when this was working right.  I've managed to get 2.37 running (ugh) and it was definately working right then.  The code was this:
Code: [Select]
vx = (Shots(t).vx - rob(n).vx) / -2 + rob(n).vx
vy = (Shots(t).vy - rob(n).vy) / -2 + rob(n).vy

If that's still the code, the other idea I have is that it might have to do with when the robots' velocities are updated relative to when shot impacts are done.  The two might be out of sync.  You might try using the robot's old velocity, for instance.

It should be immediately apparent if it's working right or not.  Just load up two animal minimalis based bots and watch them duke it out.
« Last Edit: September 09, 2007, 08:21:05 PM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Problems with 2.44f
« Reply #3 on: September 09, 2007, 11:16:58 PM »
Quote from: Numsgil
I see two options.  You could either "extract" the DNA from an imported dbo and save it in some sort of directory somewhere, or go through the code and find everywhere where an imported species needs to be in the species list and work in some new logic for an "imported species" list.
The problem with the first is mutations and our definition of species.  Extracting the DNA from the dbo only works if there have been no mutations (and no viruses).   The second is essentially what I have done.

 
Quote from: Numsgil
Also, while you were poking around in loading routines, did you change the way bots are loaded so that the DNA file is only read in once?  This was a long standing (and rather silly) issue with large sims being started fresh.  It would take 5 or 6 seconds reading a DNA file 1000 times.
It still reads in separatly for each bot.  Not sure this is high priority since it only impacts the start up of a brand new simulation with large numbers of bots but I'll take a look and if I see an easy fix, I'll take care of it.

Quote from: Numsgil
There was a time when this was working right.  I've managed to get 2.37 running (ugh) and it was definately working right then.  The code was this:
Code: [Select]
vx = (Shots(t).vx - rob(n).vx) / -2 + rob(n).vx
vy = (Shots(t).vy - rob(n).vy) / -2 + rob(n).vy
It's done with vectors now, but that the current code is equivalent to the above.

Quote from: Numsgil
If that's still the code, the other idea I have is that it might have to do with when the robots' velocities are updated relative to when shot impacts are done.  The two might be out of sync.  You might try using the robot's old velocity, for instance.

Right idea.  I think what is happening is that my new (I.e. last year) shot collision routine has showed up some flaws in the whole return shot paradym.   Last year, I rewrote the shot collision routine for performance and other reasons.  As a side effect, it got a lot more accurate.  It now figures out exactly when in the cycle the collision occurs and exactly where and I use this information in computing the return trajectory, starting point and timing of the returned shot.   I.e. shots impact on the impacted bot's edge (not somewhere inside as before) and return shots start on their return journey exactly when and where the impact occurs.  That is, a return shot will already have traveled some distance on it's way back by the end of the cycle in which the impact that casued it occurred.  This was essentially free to do as a necessary side effect of figuring out if a collision occurred is learning when and where it occurred.  Before, the point of impact was calculated as the position where the shot would be at the end of the cycle instead of assumign imapcts occurr at bot edges.  Similarly, the time at which return shots began their return trajectory was always on cycle boundaries.   Additionally, the point of origin of any returned shot was taken to be the impacted bot's center.   These artifacts had the effect of delaying the effective time the return shot was generated by up to a full cycle, giving it a boost in the direction the impacted bot was traveling (since it was shot from the center and not the edge).  These things combined to "carry" return shots along with the impacted bot for up to several cycles (depending upon when in the cycle the shot impacted and the impacted bot radius).

If our paradym is that a returned nrg shot is a piece of the bot shot off from the edge, then I like my code better even though it reduces the collision probability in certain cases, like bot movement lateral to the direction of shooting.  If we are to do anything, I'd prefer speeding up return shots to changing the above aspects of where and when return shots orginate...
Many beers....

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Problems with 2.44f
« Reply #4 on: September 09, 2007, 11:43:19 PM »
I've been playing with return shots.  2.43h will have some tweaks which shoudl improve things.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Problems with 2.44f
« Reply #5 on: September 10, 2007, 06:16:48 AM »
I remember when you were playing with all that now that you mention it.  I don't think, though, that this is the problem.  Pretend that two bots aren't accelerating but are moving laterally together dogfighting.  From either bots frame of reference, it should be exactly the same as if they were standing still and dogfighting.  Yet this doesn't seem to be what I see.

I've even seen problems with a bot attacking a veggie coming at it, so it has to move backwards.  The returning energy shots seem to trail behind the veggie.  It looks to me like returned shots have a constant speed that isn't being effected by the speed of their parent.  If I had to guess, I'd say that a shot's scalar speed is being capped somewhere.  I'm having a heck of a time determining if this is really the problem or not just looking at the program.  I might need to peek into the code...

Oh, and you're new version (G) seems to have problems with tie length.  I've seen some birth ties that were definitely longer than the maximum tie length.
« Last Edit: September 10, 2007, 06:15:50 AM by Numsgil »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Problems with 2.44f
« Reply #6 on: September 10, 2007, 10:44:24 AM »
Quote from: Numsgil
It looks to me like returned shots have a constant speed that isn't being effected by the speed of their parent.  If I had to guess, I'd say that a shot's scalar speed is being capped somewhere.
Aha!!!!! Found it.  You are correct.  Was overwriting the vector later in the routine.    Fixed in 2.43h.

Quote from: Numsgil
Oh, and you're new version (G) seems to have problems with tie length.  I've seen some birth ties that were definitely longer than the maximum tie length.
Fixed in 2.43h.  My recent modification to nrg sharing wasn't updating numties for bots with only one tie they did not create.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Problems with 2.44f
« Reply #7 on: September 10, 2007, 03:06:53 PM »
yay

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Problems with 2.44f
« Reply #8 on: September 14, 2007, 02:48:52 AM »
Things are going great.  This isn't a bug, but the internet populations graph has a whole slew of dead competitors (bots with 0 population) that really only clutter things up.  I think it's safe to say that if you don't see your species listed, it must be dead.  At the very least, a button to hide dead competitors would be nice.

Second, instead of using population as the ranking mechanism, maybe you should use invested energy.  How much nrg + body * 10 + venom, shell, slime, etc. a bot has.  Or available energy, which would just be nrg + body * 10.

Third, right now alga minimalis is the only successful plant species, but I'm a little worried about some uber plant being introduced that's really just a combat bot with the veggy box checked, or even an alga minimalis with some sort of insane virus.  A bot with access to free nrg is just going to mop everything up.  In the future, hopefully mechanisms will be in place to allow for competitive veggies and bots to be shared, but right now I think either not transferring veggies, or unchecking the veggy box on any imported veggies might be a good idea.

You could reason that the different sims exist under different suns, and the chlorophyll like pigment alien veggies use just aren't efficient at capturing the native sun's light frequency range.

Last, for some reason Enitor Comesum has existed almost two full days on my computer hooked up to the internet.  This is absolutely shocking.  There's nothing about enitor comesum that should make it in the least bit competitive, other than that it's very draconian at dealing with mutations (translate the name from latin to see what I mean )  I mean, it'll lose to Animal Minimalis hands down in a league match.  It can barely sustain itself with enough individuals on any of the smaller arena sizes.

It's not that Predator doesn't come into the sim.  It's that as soon as it does it explodes and dies.  And enitor comesum doesn't seem to be fairing all that well outside of my sim.

I'm skeptical that this is a legit situation.  I could see a strong bot holding down its home territory against encroaching invaders, but that doesn't seem to be the case here.  I could also see an exotic bot surviving in an extreme settings sim where others couldn't.  But these settings are about as standard vanilla as it gets.  The only non standard changes I've made are to give veggies 3 nrg based on kilobody, a rather long veggy repop timer with low veggy respawn, and a field size of 3.

I just booted the sim, loaded some throwaway bots (Animal Minimalis and Enitor Comesum (if anything, Animal Minimalis should have won the local contest)), and left it alone for two days.  I figured some predator species would invade like before.  Doesn't seem to be the case.

I'm not sure what  the problem is, or even if there's a problem, but it just all seems rather unlikely to me.  Either there's a new imbalance somewhere (maybe nrg shots are returning way too much energy), something's up with transferring bots from sim to sim that messes them up, or I'm witnessing honest to goodness biomagic on my computer.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Problems with 2.44f
« Reply #9 on: September 14, 2007, 01:18:04 PM »
Quote from: Numsgil
Things are going great.  This isn't a bug, but the internet populations graph has a whole slew of dead competitors (bots with 0 population) that really only clutter things up.  I think it's safe to say that if you don't see your species listed, it must be dead.  At the very least, a button to hide dead competitors would be nice.
Thanks.  I'm having a lot of fun with internet mode.  Way cool.

I kind of like seeing which bots have been introduced into the connected internet sim, but I hear you.  I'll see if I can do a button or time them out after a few hours...

Quote from: Numsgil
Second, instead of using population as the ranking mechanism, maybe you should use invested energy.  How much nrg + body * 10 + venom, shell, slime, etc. a bot has.  Or available energy, which would just be nrg + body * 10.
Good idea.  I think over time I'll do internet versions of some of the other graphs.  The total nrg/species  graph is essentially what you are asking for I think.  I'm also workign on a sims graph that will show you the population of each connected sim....

Quote from: Numsgil
Third, right now alga minimalis is the only successful plant species, but I'm a little worried about some uber plant being introduced that's really just a combat bot with the veggy box checked, or even an alga minimalis with some sort of insane virus.  A bot with access to free nrg is just going to mop everything up.  In the future, hopefully mechanisms will be in place to allow for competitive veggies and bots to be shared, but right now I think either not transferring veggies, or unchecking the veggy box on any imported veggies might be a good idea.
Yea, this touches on the larger question of what restrictions we want to place on internet mode sims, a conversation I want to foster in the other topic I started in the Internet sharing forum. Should we standardize environments? Mutation rates? etc.  I'm thinking we will have many different internet modes, each with different standards and restrictions, with at leat one (the current one) being a total free for all.  I plan to make this whole thing - the choosing of which internet mode to join - be data driven from the server, so we can add new internet sims with new restrictions (multibots only, etc.) without revving the exe.  The program will populate the menu dropdown from the server as well as perhaps download a specific sim with specific non-changable environmental restrictions and run it....

As far as your specific question of super veggy bots in this specific internet mode, it's not the super advantage you might think at first.  There is an easy defense to prevent such bots from having an advantage in your specific sim: simply give veggies 0 nrg per cycle and rely upon repopulation to provide veggies and nrg input for the non-veggy bots in your sim.   Non-native veggies won't repopulate.  This takes away any advantage a veggy bot might have outside it's native sim.   The veggy repro limits then make being a veggy a further disadvantage (given the goal is max population numbers) as non-native veggies will still be restricted from reproducing in a sim if the veggy population is a the limit.  As we change the veggy paradym going forward, I expect there will be additional disadvantages to being a veggy, such as restricting or illiminating voluntary movement, which should make trying this cheat even less attractive.  

Quote from: Numsgil
Last, for some reason Enitor Comesum has existed almost two full days on my computer hooked up to the internet.  This is absolutely shocking.  There's nothing about enitor comesum that should make it in the least bit competitive, other than that it's very draconian at dealing with mutations (translate the name from latin to see what I mean )  I mean, it'll lose to Animal Minimalis hands down in a league match.  It can barely sustain itself with enough individuals on any of the smaller arena sizes.

It's not that Predator doesn't come into the sim.  It's that as soon as it does it explodes and dies.  And enitor comesum doesn't seem to be fairing all that well outside of my sim.

I'm skeptical that this is a legit situation.  I could see a strong bot holding down its home territory against encroaching invaders, but that doesn't seem to be the case here.  I could also see an exotic bot surviving in an extreme settings sim where others couldn't.  But these settings are about as standard vanilla as it gets.  The only non standard changes I've made are to give veggies 3 nrg based on kilobody, a rather long veggy repop timer with low veggy respawn, and a field size of 3.

I just booted the sim, loaded some throwaway bots (Animal Minimalis and Enitor Comesum (if anything, Animal Minimalis should have won the local contest)), and left it alone for two days.  I figured some predator species would invade like before.  Doesn't seem to be the case.

I'm not sure what  the problem is, or even if there's a problem, but it just all seems rather unlikely to me.  Either there's a new imbalance somewhere (maybe nrg shots are returning way too much energy), something's up with transferring bots from sim to sim that messes them up, or I'm witnessing honest to goodness biomagic on my computer.

So, Preditor7 is very mutated (over 400 and counting).  He's had couple million cycles and has changed remarkably since I introduced him.  For one thing, he seems to operate at much lower nrg levels, preferring to reproduce quickly.  I think specieis recognition went away early on and competition between conspecs has drivien this.   My therory is that evolution favors faster generations all else being equal.  He who reproduces faster, wins.  In any event, when Preditor7 teleports in to a fast running, relatiovely sparse sim with high nrg bots, it is at a disadvantage, especially if there are costs.  He doesn't have the stored nrg to last long.   That they evaporate when they get there may merely be because they are so weak to begin with and can't find food or defend themselves for long in yoru sim, even against dumber bots.  On the other hand, my sims are dense and have low or zero costs, so when a dumb bot teleports in, it faces a lot of attackers.  When Enitor's teleport in, they last awhile but loose but get overwhelmed by larger numbers in the long run.   I may be wrong, but we may have already acheivied the kind of defensable stability we were disucssing on the other thread.

Last night, I introduced Preditor8, which is basically the same as Preditor7, but with mutations turned off and a higher reproduction nrg threshold.  He reproduces much more slowly, but operates with a igh nrg and body level, so he has the stored nrg to last and fight when he gets teleported.  I see that as of this morning there are no more Enitor's left in the megasim and that Preditor8's are getting teleported back from your sim.  I assume they made it there with enough nrg to wipe out the Enitors and take over, where Preditor7 could not.  

This is so cool!
Many beers....

Offline Elite

  • Bot Overlord
  • ****
  • Posts: 532
    • View Profile
Problems with 2.44f
« Reply #10 on: September 14, 2007, 01:24:12 PM »
Is it just me, or is .sharenrg not working properly? It seems to stop transfering energy after a few moments of use.

EDIT: Ah, okay then. Thanks.
« Last Edit: September 14, 2007, 02:16:17 PM by Elite »

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Problems with 2.44f
« Reply #11 on: September 14, 2007, 01:29:18 PM »
Quote from: Elite
Is it just me, or is .sharenrg not working properly? It seems to stop transfering energy after a few moments of use.
I made soem changes to nrg sharing in recent builds.  See #25 here.
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Problems with 2.44f
« Reply #12 on: September 14, 2007, 10:41:37 PM »
My program exploded last night, so that's why all the enitors died out.  It's been close to 2 weeks since I restarted, so I'm going to restart and hope that it wasn't something weird with the program

I have noticed that if you try to play with the program when the internet upload/download is going on, you can screw up your sim pretty bad.  It's like the internet connection gives up but still keeps the sim paused.