GNOME Bugzilla – Bug 654072
Worm dies on invisible object
Last modified: 2014-08-19 00:50:20 UTC
Hello, While play with AI user I found below listed bug I am using Nibbles 2.30.0 with ubuntu 10.04 platform. - During the game my worm get killed automatically though I have not done any thing like touch the wall or accident with other worm - Infect when some other AI worm eat blue diamond then my work get killed that is really irritating because it is like forcefully computer not let you play game. If this is rule then I think all rules must be unique for all player. Thanks, Hardik Joshi
(In reply to comment #0) > - During the game my worm get killed automatically though I have not done any > thing like touch the wall or accident with other worm This bug is still around and is rather serious. I'm going to rename this bug to be a bit more descriptive. I have not found any clue as to how to reproduce this bug, but I've hit it several times: an invisible wall or worm causes you to die. The wall/worm/thing usually (or possibly always) remains in place after you die, so if you navigate to the same spot you will die again. > - Infect when some other AI worm eat blue diamond then my work get killed that > is really irritating because it is like forcefully computer not let you play > game. If this is rule then I think all rules must be unique for all player. Are you sure this is a bug? The blue diamond causes your worm to reverse, so if you're not very careful it's easy to accidentally die. If it is a bug, feel free to open a separate bug report for it, so that we can track exactly one bug in each report.
(In reply to comment #1) > I have not found any clue as to how to reproduce this bug It often happens on level 8, just beneath the top left teleporter (right where your worm spawns!). It's happened to me too often there for it to be coincidence, so maybe it has something to do with the spawn point. But I don't know how to reproduce it besides saying "play level 8 a lot."
Created attachment 281156 [details] red died; he was at the bottom-left corner moving towards the right Here my worm, w, dies on an invisible object. With a slightly hacked-up game I can see that the game thinks I have run into the yellow worm z, although I am a comfortable distance away. Seems like some bug has caused the yellow worm to be in more places on the map than he's shown to be. I think something must have gone wrong when he went off one side of the map to the other; odd because it normally works fine. z bb x y zz bb x y w zz bb x y zz bb x y zz bb x y zz bb x y zz bb x y zz bb x yyyyy zz bb x zz bb x zz bb x zz bb x zz bb x zz bb x zz bb x zz bb x zz bb x zz bb x zz bb zz bb zz AA bb zz AA bb zz bb z zz bb z z bb bb bb bb bb bb bb bb ccccccccccccccccccccccccccccccccccccccccccccccbccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccbcccccccccccccccccccccccccccccccccccccccccccccc bb bb bb bb bb bb bb zbb z zbb z zbb z zbb z zbb z zbb z zbb z zbb z zbb wwwz zbb wwwwwwwwwwwwww z zbb wzzzzzzzzzzzzz z zbb wz z zbb wz z zbb wz zzz zbb wzzzzzzzzzzzzz zz bb w zz bb w zz bb w zz bb wwwwwwwww zz bb xxxxxx w zz bb x y w zz bb x y w zz bb x y w zz bb x y w zz bb x y w
Created attachment 281157 [details] ascii diagram Aaaaand the text diagram is completely ruined due to Bugzilla's character wrapping. Here it is for real.
Created attachment 281158 [details] [review] Lil debug patch Too lazy to not leak these strings
Mario, Bryan, if you have some spare time, can you take a look at this? I'm not really getting anywhere... Great way to reproduce quickly is to start on level 8, the level with all the teleporters.
If you look at the ascii diagram, the best part is definitely the two lone pieces of the yellow worm in the upper-right corner, completely disconnected from anything else. Dunno how they got up there....
*** This bug has been marked as a duplicate of bug 619988 ***
Created attachment 281161 [details] scenario 2 - ascii I think it's a bug with managing the worm's tail after it goes off one side of the map. Here's another good one. I stupidly ran my worm, w (red), into a wall. Look what is going on with x (green). Looks like he went down through the gap in the center bottom, then when he came through the center top little bits of him got stuck behind, then there's a big trail of him along the wall that didn't disappear properly.
Created attachment 281162 [details] scenario 2 - screenshot
OK much better, a scenario we can really analyze because I decided to actually take a screencast: https://people.gnome.org/~mcatanzaro/nibbles-bug/ Looks like cyan enters the warp in the upper right, exits through the lower left, and leaves a trial of invisible carnage behind. Hm.... (Watch me fumble to start the game at the start! How hard it is to press the y key.)
Oh, dark blue left an invisible trail as well. This level is carnage :(
It happens when gnibbles_worm_get_tail_direction() returns -1 (which it should never do. a simple g_assert_not_reached() would have caught this years ago.)
Er, no, that is OK, at least sometimes. Looking for my next conclusion to jump to right now. I know I'm doing a really good job with this bug report because I'm up to 14 consecutive comments.
To reproduce without teleporters, go off the edge of the map and then IMMEDIATELY turn sideways to move alongside the opposite edge, before your worm moves a single space on the other side of the map in its original direction.
Created attachment 281249 [details] [review] Be more careful when moving head/tail pointers If we are at the edge of the board, we should not assume we intend to move our head/tail to the other edge of the board unless we are really moving in that direction. Hopefully fixes the invisible positions of death that get left behind sometimes when we go off the edge of the map. I THINK this works; at worst, it is harmless. Does not fix teleporters though :(
Created attachment 281257 [details] [review] Don't skip last space on board when moving left/up This would be a harmless, hard to notice visual glitch, if not that our test for whether the head can move to this position (different from this code, which controls the actual movement...) thinks this doesn't happen. So we can end of slicing off part of an enemy worm without getting killed.
Both patches (281257 and 281249) seem good to me.
Created attachment 281271 [details] [review] Fix corner-case handling of tail teleportation What we do here is really insane. After our tail moves into the teleporter, we erase it from the text board and remove its clutter actor, but then intentionally leave the tail pointer stationary, trusting to the gnibbles_worm_get_tail_direction function to position it properly on the next turn, then warping and moving the tail pointer an extra time on that turn. This kind of works because gnibbles_worm_get_tail_direction() operates on the clutter actors, which are stored in a linked list and do know their position. But it's also super fragile if we do anything interesting with the teleporters (e.g. teleport immediately on the next move, because we came at a teleporter from a particular direction). So instead of this don't-move-then-move-twice nonsense, assume that if we ever do not know which direction to move in it's because we're at a teleporter, and try to use it. Also, add a couple sensible assertions to make sure this assumption always holds. https://bugzilla.gnome.org/show_bug.cgi?id=733429
Created attachment 281272 [details] [review] Fix corner-case handling of tail teleportation Remove reference to wrong bug.
Created attachment 281273 [details] [review] Die when teleporting onto a worm Otherwise, we'll occupy the same space as another worm, which is weird at best, and maybe causes invisible death positions. Sucks for you if you teleport onto a worm. This commit is slightly messy as it leaves gnibbles_worm_test_move_head unreliable.
OK, I believe this patchset is complete... there is one remaining issue that sometimes occurs when worms respawn, but I'll use bug #733429 for that.
I think there is another bug remaining that sometimes occurs when moving into a teleporter, where gnibbles_worm_get_tail_direction() sometimes fails, but it's rare and I'm not sure why. We probably need to give up and store a second pointer to the tail+1st position.