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.
