Talk:PricklyPear

From Robowiki
Revision as of 09:14, 29 June 2011 by GrubbmGait (talk | contribs) (→‎WaveSuffering: rare case explanation)
Jump to navigation Jump to search

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)