It works, but there are issues. I was mistaken, bot/shot collision detection DOES NOT take into consideration shots which pass completely through the target bot during the cycle. The faster the shot (and the smaller the bot) the higher the probability that the shot will not actually be located inside the bot at the end of any specific cycle but will have rather passed completly through it during the cycle, particularly when the shot is off-center. In such cases, no collision will be detected. Since Sprotiel's formula speeds up return energy shots relative to what is in the code at present, this dramatically increases the probability that bots will not receive the returned energy shots even when they hit them. Perhaps this is why you slowed down retruned shots in the first place Nums, I.e. so that they would have a decent chance not only of getting impacted but of having this impact detected.
As someone who has not studied the history of shots, I find the whole concept of returned energy shots a little strange. What exactly are we simulating here? Energy chunks of bots being shot off? Why then do they fire back towards the firing bot as opposed to scatterring in a more realistic, semi-random real-world explosion fashion? This strikes me as neither a simulation of a real-world phenomenon nor a cyber-effecient artifact. Since bot's can't see shots, whether the bot gets the retruned shot is purely probabilistic today and thus encourages conservative bot-target ranging behaviour (whether evolved or designed) which attempts to increase this probability by reducing relative changes in velocity while shot feeding. If we wanted to insure bots got the energy when their shot hit a target, it would be trivial (and computationally faster) just to give the firing bot the energy at the point when their shot hit the target bot instead of dealing with returned shots at all, so I assume that the probabalistic nature of returned shots is desired for some reason. I expect that the plan was someday to make shots visable, thus requiring shot feeder sophisication not only in aiming shots but in manuvering to capture released energy. But until that day, things are kind of half pregnant in my opinion. But I digress...
The issue with shot/bot collision detection needs to be fixed. Num's ray/circle intersection algorithm looks like a good start but what we really need is a ray/cylinder interesction algorithm since the target bot may also be in motion. Even that is not exact since it does not take into consideration motion during the cycle (I.e. the shot ray may intersect the bot cylinder, but the bot may not have been at that location in the cylinder when the shot was there or vice versa). I'll be working on this for 2.42.5, but if you have a good algorithm for this, please let me know.
The issue with where the return shot starts from, whether from the edge of the targetted bot or the position where the shot that caused it is at the end of thet cycle is important, but not critical in my opinion. As the code stands, on average, returned shots will start their return journey from inside the targetted bot at a depth of 1/2 of the distance the original shot travels in a single cycle (modulo the collision detection problem). This is significant, but given the probablistic nature of retruned shots, not as critical as the collision detection thing.
