Code center > Bugs and fixes

Got bots that behave differently in 2.37.6 and 2.42.4?

<< < (3/6) > >>

Sprotiel:

--- Quote from: Numsgil ---Figuring out the math for returning shots is somewhat difficult.
--- End quote ---
Not really: the only difficult part is to understand that it's a fairly simple kinematics problem, and that's physics not math.

The shot is fired with a velocity V_shot* relative to the bot, so its velocity in the standard referential is V_shot = V_bot + V_shot*. In the target's referential, the energy shot should be fired back with a velocity V_back' = -V_shot', with V_shot' = V_shot - V_target and V_back' = V_back - V_target. Therefore,
V_back = 2 V_target - V_shot

Assuming neither bot accelerates during the exchange of shots, back in the bot's referential, we have:
V_back* = 2 (V_target - V_bot) - V_shot*
which means that if the bot matches velocity with its target everything's just as if both bots were stationary.

Edit: clarification.

Numsgil:
Sprotiel,

It could be just me, but you've lost me in the derivation   As to the final equation, remember that shots don't get to "know" information about the bot that shot them the cycle they hit another bot.

The only information you have to play with is the velocity of the shot and the velocity of the hit bot.

Eric:
I actually had a question about this like two weeks ago.  Basically you can set up a quadratic equation and solve it with the quadratic equation to find the time of impact, and from that the location of impact via pos(t) = pos + vel(t)

This is the link I found.

Sprotiel:

--- Quote from: Numsgil ---It could be just me, but you've lost me in the derivation   As to the final equation, remember that shots don't get to "know" information about the bot that shot them the cycle they hit another bot.
--- End quote ---

I've clarified my post (I hope). The bottom line is just that the expression we should use is V_back = 2 V_target - V_shot

Numsgil:
When I get back home from vacation I'll plug it in and see what I get.

EricL:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page