Darwinbots Forum
Code center => Bugs and fixes => Topic started by: EricL on May 15, 2006, 12:09:20 PM
-
After fixing serious bugs such as crashes, my number one priority for continued work on the 2.4 code fork is closing the gap on issues with bots which work in 2.37.6 but which do not work in 2.42.4 or which behave radically different in that version.
To that end, I am soliciting examples of such behavioural differences. If you have a gene or bot which works in 2.37.6 but does not work in 2.42.4 or which demonstrates significant differences in behaviour between the two versions, please reply with details to this topic.
Please be as specific as possible. I'm happy to go get bots from the beastiary and run them in the two versions myself and read the DNA and reverse engineer what it should be doing and what it is actually doing, etc. but that takes time, time I could be using writing code or fixing bugs and I'm only one guy. So, the extent to which you can help me out by pointing me to the specific differences or ideally to the actual DNA area or sysvars which behave differently, that would be much apprecated. Uploaded sims which illustrate this are of course, much apprecaited.
Also, 2.42.4 fixed a bunch of things, so please use that version and not previous versions of 2.4 for your testing.
Known issues with 2.42.4:
.stifftie is not yet implemented.
.fixlen and .fixang work, but multibots which rely upon specific tie physics for crawling or using tie length for acceleration, etc. probably behave differently. Please report such differences.
I have not personally tested .tielen1-4 and .tieang1.4 so they may or may not work in 2.42.4. Specific help here requested.
Viruses have been reported to work in 2.42.4, but I have not tested them.
I am still investigating issues with retruned energy shot ranges and small bot evaporation.
Thanks for your help!
-
Play the attached sim in 2.42.4
Animal minimalis just dies out
This sim illustrates some of the bizzare shot bugs
-
Play the attached sim in 2.42.4
Animal minimalis just dies out
This sim illustrates some of the bizzare shot bugs
First, thanks for the sim. I've taken a look and found several things.
The first is a bug. MaxVelocity is not saved to or loaded from sim files. The setting will be whatever it was from the previous sim run. This is a real bug. I had been doing some testing eariler with virgin installs where you install 2.11 and then lay 2.42.4 on top of it. In such cases, MaxVelocity gets set to 0 adn since it's not in the saved sim file, stays 0. With a 0 Max Velocity, the engine correctly prevents bots from moving and thus they die out fast.
Once I changed the Max Velocity slider to something reasonable, the bots started moving and feeding and promptly dying. This is not a bug. The waste threshold setting in the sim as posted is set to 100 and Animal minimalis has no gene to rid itself of waste. As soon as waste crosses this threshold, random values start getting written into the bots memory and quickly they do something stupid which kills them.
I could not run the sim for very long even after I increased the waste threshold because (and this is another real bug) sim files seem to store absolute path names instead of relative path names. The bots were feeding and killing off the veggies and as soon as they killed the veggies off to a certain level and the engine needed to load some more veggies, it looked for the veggie bot file in the path indicated by the sim which does not match my install.
I will fix the Max velocity issue and the sime file path issue in 2.42.5.
If there are "bizarre shot bugs" illustrated by this sim, I'm too dumb to see them. I suspect that what people may think are problems with shots, etc. may in reality be do to death by altzheimers due to waste buildup. Certainly one would expect bots with no waste elimination gene to die rather quickly in a sim where the waste threshold is set to 100.
Elite, I would be interested in knowing whether you still think there are issues in this sim with shots once you set the waste threshold to negative 1.
-
As a postscript, it's not clear (to me at least) why altzheimers is as fatal as it is. This is something I will look at I.e. to understand exactly how bots die from altzheimers.
-
Ah yes, you are correct. I set my waste threshold lower and the bots survived quite nicely
EDIT: Oops, I meant higher
-
Ok, here's the shooting bug
A single fixed bot in the centre of the screen fires at a veg. It's shots hit the veg but the energy shots that the veg returns don't reach the shooter bot.
-
There was a routine that I modified back in 2.36 that set returned shots to have the same speed, duration and energy (not *.nrg type enrgy) as the incoming shot.
Prior to that they were all fixed values.
Sounds like it has gone out of whack in 2.4.
-
Figuring out the math for returning shots is somewhat difficult.
You want it to have the maximum liklihood of finding the eating bot. You would expect a bot moving at constant speed firing at a veg moving the same speed to feed successfully. This took alot of work, but here's what I ended up with. It would be good to check and see if this is how the VB version is handling it:
Returning shot's velocity = colliding bot's velocity - shooting shot's velocity / 2
-
Returning shot's velocity = colliding bot's velocity - shooting shot's velocity / 2
This is the essence of the problem. When shooting at a stationary bot, the returning shot's velocity will be half of the velocity of the incoming shot. Since range is the number of cycles the shot lasts, this means that the return shot travels only half as far in it's lifetime.
I have remedied this by doubling the "range" of returned energy shots. Per the formula above, their return velocity from stationary targets will be half that of the incoming shot, but they will last twice as many cycles.
-
Note that there is an additional issue of much smaller magnitude (nerdly vector math pun intended). Whereas regular shots begin their journey right at the edge of the firing bot's radius, the starting position of a returned shot is presently specified as the position of the incoming shot at the end of the cycle where the impact of the shot on the bot was detected. But of course, this is not the actual point of impact - it happened sometime during that cycle. The actual point of impact is somewhere back along the shot's trajectory. The faster the incoming shot is traveling, the further it will have penetrated inside the target bot during that cycle. Thus, at present, returning energy shots start from somewhere inside the bot, not at the edge of the bot. How far inside is a function of how fast the incoming shot was traveling.
The good news is that I think the shot collision routine takes into consideration shots which pass all the way through a bot in a cycle, either through the edge on a glancing shot or right through the meat of small bot (though it appears it may not take into consideration the target bot's own velocity when determining shot collisions, only the taget bots position at the end of the cycle). So, for glancing shots, return shots may actually start from outside a tagetted bot or for small bots, even behind them!!!!
-
Figuring out the math for returning shots is somewhat difficult.
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.
-
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. (http://www.siggraph.org/education/materials/HyperGraph/raytrace/rtinter1.htm)
-
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.
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
-
When I get back home from vacation I'll plug it in and see what I get.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Maybe just adding a button to stop drawing them would be best. Then players could hide them for some increased speed.
It turns out that doing the actual drawing of stuff in DB is not all that CPU intensive relative to the rest of the code. Oh sure, if you have a small sim, then the drawing part is a reasonable fraction of the total computation and turning off the graphics results in a noticable increase in cycles/sec. But for large sims, it's in the noise. The time it takes to draw stuff is linear to the number of things being drawn with a small constant overhead for each thing (e.g. each tie, bot, shot). But the vast majority of stuff in the sim needs to be calculated whether graphics are on or not and some of those things are worse than O(N) ((I.e. nonlinear - doubling the number of bots needs more than double the number of CPU cycles because the number of possible interactions - who sees who, ties, shots, etc. increases faster than 2X). Shot collision for example is proportional to both the number of shots and the number of bots in the sim, though there are a lot of perf shortcuts now that make it a lot better then O(N^2). So, the computation time it takes for the sim as a whole increases non-linerally with the size of the sim and the physics calculations, etc. become a larger and larger percentage of the total CPU time as the sim size increases.
So, not drawing shots saves very little. You still have to keep track of them, do all the math to figure out collisions, release energy, etc.
Bottom line, drawing stuff is easy. Figuring out what to draw, now that's hard...
-
Helios (http://www.darwinbots.com/Forum/index.php?showtopic=104), Light's legendary MB, doesn't work in 2.4
It just doesn't form 4-cell MBs like it's supposed to
-
Dollars to donuts it has to do with the more dynamic sizing in 2.4. That's where I'd concentrate my debugging efforts.
-
Not sure if it's been fixed yet, but I figured out what was causing the mysterious poison shots to be returned on occasion by bots/walls without any poison. It's caused by shots again near the end of their lives, apparently with nrg being just below zero, these would cease existing next cycle but I guess they're not caught in time. Anyways the oddball poison shots returned don't have any real nrg or poison, so don't compose a major threat.
Added right before the poison shot generation area:
If nrg <= 0 Then GoTo exitsub
Did the trick and stoped them from forming
Also found another minor bug in shots, allowing walls to receive stray shots, giving them nrg and waste. Probably at least part of the reason they keep occasionally dieing on me.
Added some code to check that a bot isn't a wall in the -2 shot case handling section to correct for it.
Something else is also going though, I had a mutant TheOne figure out a way to kill them in a single shot. Sneaky bots, I'm going to try and trouble shoot where the problem is.
-
Helios (http://www.darwinbots.com/Forum/index.php?showtopic=104), Light's legendary MB, doesn't work in 2.4
It just doesn't form 4-cell MBs like it's supposed to
Well, first off, .stifftie is not implemented in 2.42.4. But that is only part of it.
The main issue is that unless I am mistaken, Helios should not work in any version and the fact that does in 2.37.6 is a bug. It attempts to use .fixlen, .fixang and .stifftie well before it is a multibot, like at .robage 2 and 3. My understanding (as PY says very adamantly here (http://www.darwinbots.com/Forum/index.php?showtopic=1323)) is that these sysvars should not work unless a bot is a multibot and that bots arn't multbots until a tie has hardned and the only way a tie can harden is for it to exist for 20 cycles so that is what the 2.42.4 code enforces.
So, the reason it is not forming 4 bot multibots ( I think) is that it expects to stiffen the tie to its first offspring and fix it's length to move the offspring away to make room to reproduce again at a specific age , but of course this does not work (by design) so the other offspring can't be born on the cycle it wants them to because it's first baby is still in the way adn this messes it up.
-
Not sure if it's been fixed yet...,
Added right before the poison shot generation area:
If nrg <= 0 Then GoTo exitsub
I had actually caught this and fixed is in a similar fashion.
Also found another minor bug in shots, allowing walls to receive stray shots, giving them nrg and waste.
Nice find. I'll take care of this in 2.42.5.