Version 2.42.5 Released

[EricL]

Version 2.42.5 is now available!

Direct Download Link.

Major Changes /Features:
Shot collision detection completely re-worked.  Numerous issues with return energy shots, small radius bots, shot ranges and so on addressed in this version.
New sim energy calculations displayed on tray and a new energy graph added (See Below).
The .stifftie sysvar has been (re)implemented.  There are now no *known* compatability issues with 2.37.6.


A detailed list of the changes from version 2.42.4 can be found here.

A few words about 2.42.5.
Shot collision should now be bulletproof (pun intended).  If a collisoin should occur, the code now correctly detects a collision, even for fast moving shots and small radius bots.  Fast moving shots should no longer be able to pass through bots in a single cycle to hit those behind, returning shots should now have the same effective range as those that initiated them and they should correctly begin their retrun journey from the point of impact.  Be aware that the graphic radius as drawn for bots can be shown as slightly larger then the reality so shots which are displayed as passing through the very edge of a bot may, correctly, not actually impact in the underlying physics.  

The new shot collision detection routine is more accurate and correct then the previous, but also more CPU intensive.  Additionally, the "lifespan" of returned energy and body shots was doubled (their speed is half that of the initiating shot) so they hang around twice as long, increasing the average number of shots in a sim at any given time.  The shot collision code is sensitive to the number of shots in the sim, so these two things may decrease the performance of sims with lots of shots (the tray now displays the total number of shots in the sim).  I have done the best I can at speeding it up (and this version includes several other performance improvements in other areas designed to offset this) but anyone who wants to take a look at the routine and suggest ways to improve it is welcome to do so (NewShotCollision() in the Shots Module).  It is very well documented, so people should not have too much difficulty folowing what I did.  One of my goals for the next version is to do some profiling and make further performance improvements.

Note that I also changed the way cycles/sec is calculated so that it is now averaged over the past 10 seconds instead of being a snapshot of just the past second (it therefor may read funny for the first 10 seconds of a sim, either new or just loaded).  This gives greater accuracy and resolution, particularly for larger slow running sims with cycles/sec in the low single digits or below 1.  Additionally, I handle timer events in a lot more places in the code then before.  This makes the UI more responsive and the timers more accurate so, again, especially for large, slow sims, the running time should better reflect reality.  But this also may have the effect of displaying a lower cycles/sec than before.  The sim may not be running any slower, it's just that cycles/sec is actually be calculated more accuratly.  Note that running time still runs slow relative to real time.  The whole way time and timer events are handled needs to be improved.

Lastly, the total energy in the sim each cycle is now displayed in tray along with an "Nrg Ratio".  The goal here is to give you some idea of how much energy is flowing into and out of the sim each cycle.  The Nrg displayed is the sum of all the energy and body (* 10) of all the bots in the sim at the end of the last cycle.  Energy tied up in shots is not included until it is absorbed by a bot.  Additionally, other forms of converted energy such as venom, posion and shell are also not included in the calculation.

The Nrg ratio is the ratio of the past cycle Nrg value over the average of the sim energy over the past 10 cycles.  If the ratio is >1, the net energy in the sim is increasing.  If the ratio is < 1, the net energy is decreasing.  Note that events such as veggie repopulations can bring an enormous amout of new energy into the sim in a single cycle, playing havoc with the "smoothness" of the ratio calculation, so be sure to wathc for this if you are using this to try to maintain a certain energy average.  Additionally, a new graph is now available which plots the total energy of each species over time.  This can be used over longer periods to examine net energy flows and smooth out the massive inflows from re-population events.  

As always, please bring bugs or other isuses to my attention.

Once again, and especially now that .stifftie is (re)implemented, I will also renew my call for people to test bots, especially multibots, from 2.36.7 and bring any behavioural differences between the versions to my attention.

Enjoy!

[Numsgil]

Nice work   Be sure to remind me to ask you to port over the shot code to C++ at some point in the future (though a straight port probably won't be possible, I'll have to look at your code at some point).

Light's Helios would be what I would consider a good bot to test for compatibility problems.  It pretty much uses all the tie functions there are.  I don't have time at the moment, but someone should run a sim with Helios and see if it still works correctly.  If so, I'd declare ties fixed

[Elite]

Woo, progress  

Yep, if Helios works then ties are officially fully backwards compatable  

2.4 is now stable enough for PY's Hexagonis - one or two stable hexagona are able to form, which is an improvement on the previous behavior of the Hexagona (is it Hexagona or Hexagonises?) going berserk
It isn't perfect but it's an improvement

Is it just me or does the new version seem slower? It seems to have taken a massive speed hit (maybe it's the new shot stuff), or maybe it's just me  

Helios still doesn't form 4-cell MBs, instead it forms weird 2-cell MBs that hold each other quite a way away from each other

There are still some minor issues with anti birth tie genes. My combat bots don't delete birth ties like they're supposed to.

[EricL]

The perf stuff is part real and part perceptural.  Read my first post above.

Regarding Helios, as I describe here, someone still needs to explain to me why it works in any version.  It violates my understanding of the way mutlibotness is supposed to work.  Unless I misunderstand it's code or how things are supposed to work regarding becoming a multibot and when things like .fixang are allowed to work (which comes from PY) it should never have worked as coded in the first place so one could say that it does not work today BY DESIGN.

The differences in Hexagonis behaviour are likely due to underlying physics differences in tie elasticity values.  I will play with it and try to tune things.

Any specifics you can provide on the birth ties issue would be appreciated.

[Elite]

The perf stuff is part real and part perceptural.  Read my first post above.

Regarding Helios, as I describe here, someone still needs to explain to me why it works in any version.  It violates my understanding of the way mutlibotness is supposed to work so one coudl say that it does not work today BY DESGIN.

The best person to do that would be Light. I haven't got a clue how Helios works

Any specifics you can provide on the birth ties issue would be appreciated.

Get Una 3.0 from the beastiary and run it in 2.37.6

Notice how it deletes its birth tie instantly after birth

Now run it in 2.42.5

Notice how it still has a birth tie after it is born

*********

 

I've just found the root of something that has been bugging me about 2.4 physics for some time

It turned out I had no friction enabled at all

No wonder they were sliding about like greased butter  

[Numsgil]

I agree with Elite that Light is the person to ask as far as Helios is concerned.  Blows my mind
 
 Definately should take a profiler and look at the program.  I do that from time to time, it's invaluable.

[EricL]

Get Una 3.0 from the beastiary and run it in 2.37.6

Notice how it deletes its birth tie instantly after birth

Now run it in 2.42.5...

As much as I appreciate the help, I'd like to very politely request that perhaps people might be able to help me out a little more by doing some debugging and helping to pinpoint problems instead of relying upon me to spend the hours to figure it out.  You don't need to have any coding knowledge to help debug things.  In fact, expereinced bot builders are better equiped to debug this kind of thing than I am.  Fire up a console in both versions, step through the bots cycle by cycle and test some mem locations.  Try to pinoint what 2.42.5 is doing or not doing at the sysvar/mem level relative to 2.37.6.

Sure, I could do that, but I already spend way to many hours on this stuff.  I'm asking for help.

[Elite]

OK, fixed it

It turned out that Una was turning away from it's parent on cycle 0 so that when it fired the tie to it's parent the tie missed. This also explained why so many bots were getting stuck to vegs.

I got my bot not to turn on the first cycle and the birth tie gene worked

You just need your bots to stay still and not to turn on the first cycle, so add the condition
*.robage 0 >
... to all turning genes

Problem solved      

[Elite]

Woohoo!!!

After giving my sims some friction, and modifying my bots so that their antibirthtie genes worked, my shot bots not work very, very well - incredibly close to how they were supposed to work in 2.37.6
(in fact, the only difference I can see to Una's at all is the dynamic sizes)

Very nice  

Well done Eric!
 

[PurpleYouko]

Why aren't your smileys working?
   

Mine seem OK

Hmm!! Now suddenly they are back. That was weird  

[EricL]

Woohoo!!!

After giving my sims some friction, and modifying my bots so that their antibirthtie genes worked, my shot bots not work very, very well - incredibly close to how they were supposed to work in 2.37.6
(in fact, the only difference I can see to Una's at all is the dynamic sizes)

Very nice  :D

Well done Eric!
 :clap:

Thanks Elite.  That's good to know and it's nice to hear that people find the work I'm doing useful.

For large sims with lots of shots, perf did take a step backwards in this version.  The execution order of the shot collision routine is O(S * B) where S is the number of shots and B the number of bots.  The added range of return shots increased the average number of shots in any given sim by perhaps 25% and the routine itself is quite a bit more CPU intensive, so this becomes quite noticable when either B or S or both are large.

I have some ideas to improve it.  Poof shots for example.  Right now, 20 shots are created every time a bot dies and even if the bot is at 0 energy at death, each of those shots is a -2 shot with a healthy range and 240 energy!!!!  Death adds  energy to the sim if any bot is close enough to absorb the shots.  This is magic energy created out of whole cloth independent of anything else.  The shots go off in random directions, but being next to a bot when it dies is a great way to get energy.  It's things like this that make managing the sim energy flow super frustrating.

I'd like to change it so that energy/body is conserved, that the energy in the poff shots sums to that left in the bot in it's energy/body when it died.  I'd like to create fewer shots if the energy isn't there to support them.  This would reduce the average number of shots in a sim and speed things up.

I think there are opportunities for doing a better job of ruling out possible collisons up front as well.

But the real payoff would be if someone has a computationally fast way to find the minumum distance between two points moving indenpendently at different velocities in a plane over a time period 0 < t < 1 without looping through and testing different points in time.   That is the meat of the collision routine and finding a faster solution would speed things up tremendously.

Edit:  Had a math error.  Death shot energy is actually 240/shot not 9600.

[Numsgil]

I have some ideas to improve it. Poof shots for example. Right now, 20 shots are created every time a bot dies and even if the bot is at 0 energy at death, each of those shots is a -2 shot with a healthy range and 240 energy!!!! Death adds energy to the sim if any bot is close enough to absorb the shots. This is magic energy created out of whole cloth independent of anything else. The shots go off in random directions, but being next to a bot when it dies is a great way to get energy. It's things like this that make managing the sim energy flow super frustrating.

 I thought poffs were strictly ornamental.
 
 

But the real payoff would be if someone has a computationally fast way to find the minumum distance between two points moving indenpendently at different velocities in a plane over a time period 0 < t < 1 without looping through and testing different points in time. That is the meat of the collision routine and finding a faster solution would speed things up tremendously.

 I have a huge book on collision detection code.  Sounds like you want closest point between two line segments defined parametrically.
 
 However, I think you can expand this more easily to a test between a swept sphere (capsules) and a line segment that returns the initial point of contact instead of the point where the contact is the closest.
 
 Allow me a day or so to read over my book (it won't take me a day to read it, it just might take me a day to get around to it ) and I'll come back with something.

[Numsgil]

Oh, and as to shot to bot collision complexity, I'm (slowly) implementing a hgrid for bots in the C++ version.  Collision complexity would then become roughly O(s), ie: linear instead of quadratic.

[Numsgil]

Here's what I have so far:
 
 a = botopos vector
 b = shotopos vector
 c = botvel vector
 d = shotvel vector
 
 collision occurs if:

Code: [Select]

t^2 (c - d) dot (c - d) + 2t (a - B) dot (c - d) + (a - B) dot (a - B) - (bot radius) ^ 2 <= 0
 That's a quadratic equation of t, so you just have to solve via quadratic formula to find two t's.  The one that's the closest positive value to zero is the time of impact.
 
 Then you just plug t back into the equations of motion of the shot and bot:
 
 ie:
 

Code: [Select]

botpos(t) = a + t©
 shotpos(t) = b + t(d)
I'll post the final solution later tonight in pseudocode if someone doesn't beat me to it.

[Numsgil]

Hehe, okay, this is taking less time than I thought
 
 

Code: [Select]

deltapos = botpos - shotpos
 deltavel = botvel - shotvel
 L2vel = squaredlength(deltavel)
 
 t0 = -(deltapos) dot deltavel + bot radius * sqrt(L2vel)
        -----------------------------------------------
                  L2vel
 
 t1 = -(deltapos) dot deltavel - bot radius * sqrt(L2vel)
        ------------------------------------------------
                      L2vel
 
 bool uset0 = true, uset1 = true
 time t <-- collision time
 
 if(t0 < 0 || t0 > 1)
     uset0 = false
 
 if(t1 < 0 || t1 > 1)
     uset1 = false
 
 if(uset0 = false and uset1 = false)
     the shot and bot don't collide
 
 if(uset0 = true and uset1 = true)
     t = min(t0, t1)
 
 else if(uset0 = true)
     t = t0
 
 else
     t = t1
 
 Now that we have t, we can find the pos of the bot and shot when they collided:
 
 posbot = oldbotpos + t * botvel
 
 posshot = oldshotpos + t * shotvel
 That's all from the top of my head, so someone feel free to double check the figures.  The basic algorithm is sound though (construct a quadratic and solve it)