Code center > Bugs and fixes

Got bots that behave differently in 2.37.6 and 2.42.4?

<< < (4/6) > >>

Numsgil:
Shots started before my time, but as far as I understand, it's a relic of the C Robots heritage.  Shots are the "cannon" that are common in such simulations, with the returning shots the way that the bots can use it to feed.

One nice property of returning an energy shot is that it takes some time to travel, creating a kind of time differential between firing the shot, causing damage, and recieving nrg.

For the ray - cylinder collision, I imagine you want to test two simoltaneous equations.

Bot:
pos(t) = pos + t(vel)  t in [0,1]

Shot:
pos(t) = pos + t(vel) t in [0,1]

You'd then have to check if there's an intersection at a time when the t's are the same.  I can check my collision detection reference manual when I get home wednesday and give you a definative answer.

Sprotiel:
I'd say that the major argument for shots is that they are quite hard to catch, which puts the bots under selection pressure.

Correctly checking for collisions between shots and bots isn't very hard. It's exactly the same problem as the ray/circle intersection :
The bot's position during the turn is given by r_b (t) = r_b + t v_b.
The shot's position is r_s (t) = r_s (t) + t v_s
and the vector expressing its position relative to the bot is r(t) = r + t v = r_s (t) - r_b (t)
All there is to check is whether there's a t in [0,1] for which |r(t)| < R, R being the bot's radius.
So we have to study the function |r(t)|^2 = r^2 + 2t(r.v) + t^2 v^2. It reaches its minimum at t0 = -(r.v)/v^2, where |r(t0)|^2 = r^2 - (r.v)^2/v^2.

Therefore, there's a collision iff |r(0)|^2 < R^2 or |r(1)|^2 < R^2 or ( 0 < t0 < 1 and |r(t0)|^2 < R^2 ).

I don't know what's the best algorithm to translate the above into code, but it shouldn't be too hard. The most important thing is to have a quick check to reject the majority of the cases, which will probably rely on the fact that if |r| - |v| > R, we're sure there's no collision.

Endy:
Shots are just sort of part of DB. They could be redone to have guaranteed effect but that would impose it's own problems. Poison and Venom would be a nightmare in that version. If it could be done easily enough a more chemical version of shots would be nice; but I'd imagine the processing power for that would be even worse than for shots.

Maybe just adding a button to stop drawing them would be best. Then players could hide them for some increased speed.

EricL:
Here is a summary of what I have done for 2.42.5 regarding shots.

First, I have written a new shot collision routine based upon Sprotiel's algorithm (thanks Sprotiel!).  Though the new code that actually does the collision detection is a little more involved and thus more computationally intensive than the old, I have added some performance improvements to the routine above and beyond what was there before.  Bascially, I don't bother to do the math for bots which are not near enough to the shot to have possibly closed the distance in the past cycle.  So, the new code as a whole is now as fast or perhaps even faster than before.

I had to add some additional code to detect cases where a fast moving shot completly penetrates a bot with a high number in the robot array and then enters a second bot with a lower number all during the same cycle so as to be sure to detect and report the collision with the first bot the shot hit and not the second.  Otherwise, you can get cases of starvation where the firing bot is shooting through a small bot and hitting one on the other side, but the returned energy shot is being absorbed by the bot in the middle.  That is, the code has to be aware that the shot ray could interesct two (or more) circles!

The final solution works very well.  The code now has (I hope) a fairly bullet proof (pun intended) bot/shot collision routine which takes into account both shot and target bot velocity (and thus position) during the cycle - a marked improvement over what was there before.  It can handle shots of varying speed (within reason) so if we wanted to for example, expose a sysvar to allow for bots to shoot at different speeds, or base shot speed on .shootval or similar, the code is now set up for that.  (To be clear, such capabilities will NOT be in 2.42.5).

As fas as the speed of returning energy shots, I have been playing around with this and while Sprotiel's V_back = 2 V_target - V_shot formula works well for ideal environments without brownian motion or gravity when the firing bot maintains constant velcoity during the cycles it takes for the shot it fired to impact and the associated energy shot to retrun, the increased shot speed actually decreases the probability that the firing bot will receive the returned energy shot in cases where these conditions are violated.  In short, the slower the returned shot travels and the longer it lasts (I.e. the longer it's "range" in cycles) the greater the probability that the firing bot (or some other bot) will stumble into it.  When returned energy shots travel fast, they often miss and go zooming by the bot that fired the causal shot because the bot isn't exactly where the math/physics say he should be due to brownian motion or his own acceleration.  Slower shots hang around the area for a longer number of cycles, resulting in more consumptions.

So, I have left the returned energy shot speed as it was:

Returning shot's velocity = colliding bot's velocity - shooting shot's velocity / 2

But have doubled the "range" - the number of cycles they last.  The result is that in situations where the targetted bot's veloctiy is zero, such as a fixed veggy, the returned energy shot has the same range in terms of distance on the field as the shot that initiated it, giving a satisfying visiaul experience, but it goes half as fast (lasting twice as many cycles).   In cases where the targetted bot has velocity, well, generally it's being chased and the energy shots maintain a good deal of the targetted bot's velocity, but fall behind at a speed of 1/2 the ***relative*** speed of the incoming shot.   Again, I think this is visually satisfying and exhibits good results in a variety of environments and circumstances.  Feedback and comments are of course very welcome.

Additionally, since I had to figure out exactly when (in terms of a fraction of a cycle) the shot hit the bot anyway as part of the collision detection routine, I now begin returning energy shots at the initial point of impact and not some arbitrary distance inside (or through and beyond) the bot.  This should give returning energy shots *exactly* the same range in terms of distance on the field as the shot which caused them.  

One last thing is that I found and fixed an order of operation bug with shots that are on their last cycle of age.   In short, collision detection was not happening on the last cycle of a shot's life, even though the shot was being displayed.  This resulted in cases where a shot from a distance could be seen hitting the target bot but no energy shot was being returned.  I've remedied this.  Note that the energy of the returned shot still falls off dramatically when the triggerring shot is near the end of it's range.  So even though an energy shot will now be returned due to a hit from a shot on its last cycle of existance, the nrg in that returned shot will be much less than if the feeding bot had fired point blank.

EricL:
I'd like to reiterate my call for people to bring version differences or other issues with 2.42.4 to my attention.

On a separate note, I have been testing the changes to shot collision detection mentioned above and working on overall performance in general.  I feel very confident that 2.42.5 completly nails the issues with shots observed in previous versions.

Navigation

[0] Message Index

[#] Next page

[*] Previous page