Explosive confusion

Okay, I wanted to quickly create a little example of a bomb mechanic that works similar to Bomberman.

I'm doing it using an array storing the obstacles that block the blast (value of 1)and a function that uses a nested loop which creates the blast in the four directions around it(using cos and sin) and only continues the line of explosion if there isn't an obstacle.

I thought of this implementation as rather elegant. <img src="smileys/smiley9.gif" border="0" align="middle">

Unfortunately it isn't quite working. In the example you click to create an explosion at that cell position. Now the blast that goes out north (270�) doesn't actually get blocked by obstacles when creating explosions on the left side of the screen. Or it gets blocked where there are no obstacles at all. On the right side it however works fine and all other blast directions also work according to plan (everywhere).

The values in the array also look fine judging from the debugger view.

This should be simple, but instead it's driving me mad. I've looked over it a million times and can't figure out why it's behaving so strangely.

<img src="smileys/smiley19.gif" border="0" align="middle">

Oh yeah, here is the capx: https://dl.dropboxusercontent.com/u/2306601/bomb_1c.capx

Maybe it just needs a fresh set of eyes.

after quite some testing, I found the problem. Seems to be some sort of computational error

use

Function.Param(0)+round(cos(loopindex("boomSides")*90))*loopindex("boomRange")

and

Function.Param(1)+round(sin(loopindex("boomSides")*90))*loopindex("boomRange")

when comparing the value in the array

after quite some testing, I found the problem. Seems to be some sort of computational error

use

Function.Param(0)+round(cos(loopindex("boomSides")*90))*loopindex("boomRange")

and

Function.Param(1)+round(sin(loopindex("boomSides")*90))*loopindex("boomRange")

when comparing the value in the array

Thank you very much for taking a look and nailing the error!

A computational error indeed, I don't actually think this should need the round expression at all. I mean we aren't even dealing with floats here, all the variables used in the event have simple integer values.

I found that you only need to apply the round for the X value in the condition, the second one isn't actually needed. I guess this makes some sense since the error only occurs on the left side, meaning at a certain range of X coordinates.

The X calculation for the 270? angle needs to be always 0 though, which even my calculator agrees on. Yet Construct somehow needs round to make it work?!?

So yeah, this leads me to believe this might be an actual bug in Construct 2. It could be an accuracy issue with the math expression cos or simply a general issue with that array condition and using math in it.

Sin, and cos will have some issues when it comes to rounding angles, plus the only time you might want to use it is when those rounding issues would pop up ie diagonals. Catch 22 I guess.

Also I'd highly suggest snapping your mouse xy with int(mouse.x/cell)*cell +cell/2 for tile games.

Sin, and cos will have some issues when it comes to rounding angles, plus the only time you might want to use it is when those rounding issues would pop up ie diagonals. Catch 22 I guess.

Right, but this is calculating the following three things for the north direction:

cos(3*90)*1

cos(3*90)*2

cos(3*90)*3

And all of these should equal 0. Yet I have to put round in front of it for some reason. Is this really something to be expected? I don't recall having had such an issue at any point in my ~5 years with C2 and Classic before that. And cos and sin were being used frequently.

Also I'd highly suggest snapping your mouse xy with int(mouse.x/cell)*cell +cell/2 for tile games.

That may be so, but I don't see the relevance here.

Probably the rounding issue is due to how the expression is converted to an integer. Which likely is the equivalent to int(expression).

newt

Couldn't you also just use round(mouse.x/cell)*cell

I was more like suggesting you use x, and y, offsets rather than sin, and cos.

In other words there is no extra benefit to using the trig, unless you wanted to do diagonals.

Rojo, yes, its just that the cell/2 gets you the hotspot offset.

Now that I'm wide awake and not on my phone I did some tests. I'm pretty sure you'd have to use round() in CC as well. And as far as being just integer values cos(270) is not exactly 0 in either C2 or CC.

If you set some text to cos(270) you'll get 0, but that's because C2 does some rounding to give you prettier numbers for display. If you set the text to str(cos(270)) you'll bypass the pretty rounding and get -1.8369701987210297e-16.

Now that I'm wide awake and not on my phone I did some tests. I'm pretty sure you'd have to use round() in CC as well. And as far as being just integer values cos(270) is not exactly 0 in either C2 or CC.

If you set some text to cos(270) you'll get 0, but that's because C2 does some rounding to give you prettier numbers for display. If you set the text to str(cos(270)) you'll bypass the pretty rounding and get -1.8369701987210297e-16.

In the meantime I did actually recreate the same example with CC and ran into the exact same issue, haha. So I guess I should just shut up and accept my defeat at math. And use round <img src="smileys/smiley36.gif" border="0" align="middle" />

It could be useful though if the array rounded instead of floored values to integers. Although that may lead to other math issues in other situations...

How bout just using overlap at offset, and getting rid of the array?

How bout just using overlap at offset, and getting rid of the array?

Your suggestion is valid, but my issue was not with finding a different approach, of which there are certainly many. I was just not getting why this exact approach didn't work the way I believed it should.

But yeah, for anyone looking to do something bomberman-like there is certainly no need for an array.