Talk:PricklyPear

This name really remind me of oldwiki:PickyPEZ ;-) --Nat Pavasant 06:46, 5 April 2011 (UTC)

I like it too - reminds me of Pear :-P, but scarier. =) --Voidious 16:36, 5 April 2011 (UTC)

Well its probably not much to be scared of right now:-P It's cool that it's similar to a couple of different things, I like that:-)--CrazyBassoonist 20:09, 5 April 2011 (UTC)

Pink Panther Quote

In every way... ;-) --Skilgannon 06:42, 7 April 2011 (UTC)

Yep! I felt like that was particularly applicable to this bot..=)--CrazyBassoonist 11:52, 7 April 2011 (UTC)

WaveSuffering

I've got an extremely annoying bug going on with this robot... Occasionally it does not recognize when the other robot fires a shot, and consequently does not launch a wave for that bullet. I've tested it and it still happens when I take out the enemy gunheat simulation, which would otherwise be my first guess as to the cause of it. The truly annoying aspect of this bug is that it only happens about once or twice a game, so it's very hard to observe. This bug and a few other confusing problems are making me think of giving up on this robot.... But honestly, I don't feel like I have another 600 lines of code in me:-P. If anyone has ever experienced anything similar to this or thinks that they might know what's be causing it, please give me a shout....--CrazyBassoonist 20:55, 28 June 2011 (UTC)

One obvious possibility is the enemy hit a wall as he fired, have you checked for that? I assume you're tracking energy gained / lost due to bullet hits. Another really bizarre situation I hit once - and only on a specific JVM! - was my radar just slipping once in a while due to onScannedRobot inexplicably not happening. That kind of thing could cause all sorts of problems, including missed waves. Hang in there! =) --Voidious 20:59, 28 June 2011 (UTC)

That was one of my initial thoughts, but when I tried completely disabling the enemy gunheat and just assuming that every energy drop was a bullet, I still noticed the problem.... Sadly, this is just the strangest of several annoying bugs in this robot. I can only hope that the situation you described isn't happening, because I have no idea how I would deal with that:-P--CrazyBassoonist 21:08, 28 June 2011 (UTC)

Well, if he gained energy from hitting you on the same tick as he fired, his energy wouldn't drop, it would go up. Is that a possibility? --Voidious 21:10, 28 June 2011 (UTC)

No, sadly. PricklyPear does account for the energy change caused by enemy bullet hits--CrazyBassoonist 22:05, 28 June 2011 (UTC)

Perhaps skipped turns? Those happening could explain it perhaps. --Rednaxela 23:20, 28 June 2011 (UTC)

Do you miss a complete bullet, or does it differ only in power. When does this take place, at the begin, the middle or the end of a round. Thanks to BulletCatcher I found I missed bullets due to him hitting the brakes and firing at the same time. And recently I assume that when killing an opponent while it was able to fire, it indeed would have fired. It's better to evade a non-existing bullet than to be hit by a ghost-bullet. --GrubbmGait 00:14, 29 June 2011 (UTC)

@Rednaxela: I've never noticed any skipped turns in PricklyPear.

@GrubbmGait: It misses a complete bullet and it can happen at any time during a round. What did you mean about hitting the brakes and firing? I can't think of how that would cause missed bullets. --CrazyBassoonist 02:18, 29 June 2011 (UTC)

BulletCatcher accelerated and then came to a full stop, while firing at the same time. To my energydrop-correction it seemed that it hit a wall, (previous speed 2, expected speed 3, actual speed 0), so I did not notice the bullet. But frankly I don't expect you to have the same bug. It is a weird thing though. Best action I can think of is using that debugwindow and every tick output the energy and the corrections you make to account for hits etc. --GrubbmGait 08:14, 29 June 2011 (UTC)

DrussGT was running into this problem if the enemy fired in the same tick that they died... I now fire a wave on their death tick just in case... --Skilgannon 08:49, 29 June 2011 (UTC)

Well, I may have fixed this problem! I decided that it might be an with PricklyPears BulletHitBulletEvent behavior(it removes the wave for the enemies bullet involved), so I set it up to print out energy changes like GrubbmGait recommended and put it in a match with ncj.MoxieBot. It started missing waves like crazy, so I looked at the energy changes and found that MoxieBot was using bullets slightly smaller than the supposed minimum of .1. For example, at the beginning of the round MoxieBot went from 99.9 to 99.80000000000001. Anyway, I changed the code from energyChange>=0.1 to energyChange>0 and it fixed it. Now, I have noticed this problem before with larger bullets, but I'm hoping that was due to an error I had in the BulletHitBullet code (X's and Y's were switched) up until version 1.0.5 and I don't recall seeing this happen with any large bullets recently. I'm not sure if any other robots are susceptible to this, but I think the fact that MoxieBot is firing bullets with a power of less than .1 probably merits further investigation--CrazyBassoonist 17:05, 29 June 2011 (UTC)

Oh, that. I don't consider that particularly weird at all. Floating point numbers on computers are usually stored as binary floating point. This means that the number must be represented by <integer>*(2^<integer) (unlike decimal which is <integer>*(10^integer)). Just like, without using fractions, 1/3 is a number you can't represent in a finite number of decimal digits, 1/10 is a number you can't represent in a finite number of binary digits. As such, computers generally won't represent 0.1 or increments of 0.1 with perfect precision. :) --Rednaxela 12:11, 30 June 2011 (UTC)

I now work on same issue. And there are my results:

1. good way to debug is use -DRANDOMSEED property. It's requires time to find correct value, but then the bug become constant
2. sometimes enemy can fire, when his calculated gun heat is more than 0, but less, than gun cooling rate (0.1 by default)
3. if change condition gunHeat == 0 to gunHeat < gunCoolingRate, then bug disappear, but some time bullet speed or fire time calculated incorrectly. Last bug i didn't fix yet

--Jdev 06:11, 30 June 2011 (UTC)

My last bug appears, when enemy hit wall on decelerating and fire in same tick. So i used wrong wall damage (too large) in energy drop calculation and, as result, fire power became too low. It looks like gunHeat < gunCoolingRate solves problem with ghost bullets --Jdev 08:33, 30 June 2011 (UTC)