SOLVED! I have a pelicular bug in my game, needing help

I give up, I am writing here.

I am making a BoulderDash clone and using array to detect things.

By some reason on the COLUMN 1 (with base zero, so basically second column ONLY that column, if you go down a few tiles, and then go up, you go up one tile and then get stuck there, and can only go left, basically through the solid and then out of the map itself...

The funny thing is that it is only happening on column 1, in both test levels.

I have disabled the other objects movements and the problem is still there so it is not there the problem lies.

I have printed screenshot of the events and looked through the X and Y everywhere and it seem to be ok.

If you press Space bar while in game you get numbers overlaid the tiles to show actual array data. This is taxing so only reachable by key trigger.

Frustrating, indeed.

Could also have to do with the level creation too, I am loading the levels from tmx strings. But the array looks fine from there, so I am not sure.

EDIT:

I deleted the capx, but now I am re-adding it, for Ashley if needed.

Maybe this is too odd to solve?

I put breakpoint at line 31 (array value = EMPTYSPACE for the up direction) and normally it would just break once for every up movement. But at the stuck position it is stuck there, breaking the "runtime" debug.

This made me put break points for 31, 32, 34 and it cycles through these in the debug time. It is as if the array value is not matching any of these, even though it should match EMPTYSPACE (0).

So I added Browser Log - MapArray.At(GridX, GridY-1) at line 30, and there I discovered that the returned value is 1, which is SOLIDWALL, when it should be zero (EMPTYSPACE)

I verified with the actual array and there the value is zero. Why does this return one? I have a feeling it is grabbing the value of column zero (which is all SOLIDWALL). But why only for this column and not the other columns?

Closer but still puzzled.

No I haven't updated the capx with the log entry but I might if this is confusing.

Could you please create a version that uses no third-party plugins? I might be able to take a look.

Oh right. Will consider it. But it is just one plugin: JSONTMXImporter. You could remove it afterwards if you dislike it.

But if there's more people willing to help but not interested to put in plugin, let me know.

To Fimbul and eventual others:

Ok here's a version without plugins (hopefully, let me know otherwise)

The level is very basic, but the problem is there, which is the main objective.

File deleted.

Nope, it still requires JSON-TMX importer.

My suggestion would be to add some logging. Use Browser.Log to dump out your moves and even the map so you can see the data change. The problem will probably pop right out once you can see the data easily.

Fimbul

Now? (How odd, I did remove it. silliness...)

File deleted.

blackhornet, I did so, with the debug overlay, and also adding Browser log (which I wrote about here in later post).. I have concluded that it grabs the value from column zero, but I do not understand why it does that. :/

I will not give up this. I will continue trying to figure out why it does that!

Got it! The problem is, by using Move at angle, you are not guaranteed nice integer Player position values. If you dump the player coordinate, you see they are not always even multiples of 32. As a quick fix, do:

Every tick -> Set Player position to round(Player.X), round(Player.Y)

Oooh, thank you, that one I would not have caught myself! I will look at my capx and implement your fix and see if it helps.

EDIT: It helped!!! Thank you so much, blackhornet

And while at it, I might add that rounding to all the moveable objects.

Got it.

The problem was a rounding error when setting the player's X position when moving UP in the first column.

It was being set to 63.99999999999 instead of 64.

This is likely due to using the "move at angle" action not being precise enough.

The bug is fixed by replacing those actions with "Set Position" actions and manually adding/subtracting from X/Y coordinates.

It would also be fixed if you replaced your int() logic with round() logic, but that would be more akin to masking the bug than to actually fixing it.

A better solution would be to not rely on the player's X/Y position on the canvas to determine it's X/Y position on the grid. Set the player's X/Y position on the canvas based on it's X/Y position on the grid, not the other way around.

To see the bug in action, open your broken capx and:

• select the player object in the debugger
• Watch it's X position, it should be TILESIZE (in this case, 64)
• Move down. It's X position should still be the same (64)
• Move up. It's X position should be slightly lower than TILESIZE (63.999999999)
• Your expression evaluates GridX to int((63.999999999/64)-1) -> int(0.99999-1) ->int(-0.00001) -> 0
• You expected it to evaluate to 1, so your code breaks.

That was a tough one! Ashley, we have a rounding error here, possible bug?

And thank you, Fimbul (and for your more in depth solution/explanation too so it will help other people too if needed.)

I am so thankful of the help of this excellent forum.

"proper" bug or not, I am happy that this got solved with your help, at least found the actual error. I almost considered making a *very ugly* solution of only for column 1 up, but no need for that now.

I forgot to upload the fixed version. Here you go.

Also helena, don't just "round" the values, please, otherwise this bug might come back to haunt you.

My "fixed" version is a better workaround than rounding, but it's even better to implement the proper fix like I described (by using gridX and gridY as basis for player.x and player.y).