This should be simple math here. what the heck?

When it's set to 225, the top event does not trigger, and the bottom one DOES - aka, a complete inversion of what it should do.

I tried it in many different ways, including using a completely different behavior - the "custom" one in pretty much the exact same equivelent way. The angle of motion is definitely traveling in the correct way, but it is NOT mirroring when it should and the conditions seem to be firing completely wrong.

I narrowed it down in the smallest way possible.

The middle event does not trigger here.

I am at a complete loss here.

Some quick help would be appreciated, assuming this truly is not a bug.

I am using the most recent version. I wasn't before, but updating did not fix it.

edit: ok I've chopped and changed with this answer, however my original comment about integer values still stands. Don't check against an integer value as angles are floating point. Additionally, check the capx, angle vs angle of motion. Hope it helps.

Ok, Try something like this :

("side" is a instance variable )

your question is not clear. if it is not the answer, give a little description

An angle will rarely be an integer value.

edit: it's not an integer value thing (still a valid point though), but check the capx

The word "integer" means whole number, right? Please correct me if I am wrong.

But if I am correct, then I am setting it to one in the bottom event, and then checking for that same exact same number immediately after.

In the top event, it shouldn't matter, since it's a range anyway, so a decimal number would still fall under it.

Ok, Try something like this :

("side" is a instance variable )

your question is not clear. if it is not the answer, give a little description

Firstly, why is the instance variable even necessary? It appears to affect nothing.

To clarify what I want to do, I want the bee to face left or right, however it also chases enemies, goes upward diagonally if there are no enemies, and therefore, can go in any possible angle. I want whether it is mirrored to be determined by the closed possibility, based roughly on which half of the circle radius the direction falls. With the way I tried to do it, it worked almost always, except when it was going up-left diagonally (not quite sure about possibilities for specific numbers other than 225) And I want it to be "angle of motion" for bullet behavior. As far as I can tell, the regular "angle" variable is tied to the image being rotated, and makes it go al upside down and stuff, and I really don't want that. Also, I just tried exactly what you showed me (with aforementioned bullet behavior variable instead of angle). And what it did was, only ever mirror if it faced exactly dead left. Nothing is making sense anymore.

And so you know, the bee already moves exactly the way I want. The trouble is ONLY the mirroring, and getting the conditions for such to recognize the angle correctly.

Sorry for the changes; check my updated post above. Will check your comments now.

edit: if you set angle to 225, it will probably be 225.00000031 or something internally. But yes a range check should work in this case.

edit 2: as always, without a capx this is largely guesswork as other events could be affecting the ones that you've shown

Sorry for the changes; check my updated post above. Will check your comments now.

edit: if you set angle to 225, it will probably be 225.00000031 or something internally. But yes a range check should work in this case.

edit 2: as always, without a capx this is largely guesswork as other events could be affecting the ones that you've shown

Even in your example, this is not mirroring it. At all. Even though I am blatantly checking for the same exact number it was just set to. And rotating it will not help me, as I have said I do not want to do that.

edit: made a mistake, gonna try again. sorry.

still doesn't. >.<

I took away the movement you gave it, ran it and pressed no keys, and it said this:

I do not understand this. It sets it to 225 at the beginning, but doesn't equal it?

Remember, I said in my game, the bullets WERE moving at the angle I wanted, despite not being recognized.

Can someone please enlighten me on how this is happening?

Can someone also please enlighten me on how an angle can equal -180? I thought it was always a number from 0-359?

this update illustrates the decimal issue

You misunderstood why I supplied the capx. I'm just showing the values aren't what you think. I'm not suggesting it is the answer to your mirroring issue. 'at all'.

Alright, this is just beyond rediculous. When using text to debug my own game, it was giving me negative numbers. 225 (left-up) became -135, while 315 (right-up) became -35. And checking for those numbers, and/or the ranges that included them, still didn't make the events work, either. And the bullets still moved in the correct directions despite this.

I really truly feel like this is a complete bug now.

this update illustrates the decimal issue

You misunderstood why I supplied the capx. I'm just showing the values aren't what you think. I'm not suggesting it is the answer to your mirroring issue. 'at all'.

You do know that file is completely unchanged, right?

Also, I did not actually wish to download an unstable beta just to open it. Thankfully I have 2 computers and the ability to uninstall stuff. But it wouldn't have been so bad if you had at least warned me, but more importantly, had a better overall tone with me.

Please. I just want legitimate help here. I am getting kinda annoyed, so sorry for my tone.

So somebody, please either tell me something specific and obvious that is just going over my head, or say "this is just weird" and draw attention to the idea that it might actually be a bug.

this update illustrates the decimal issue

You misunderstood why I supplied the capx. I'm just showing the values aren't what you think. I'm not suggesting it is the answer to your mirroring issue. 'at all'.

I just noticed the second file turned on "set angle" for the bullet behavior. How many times must I say that I do not wish to rotate things? This must be OFF. And it still tells me absolutely nothing about decimal numbers, the possibility of them, or answers any of my questions.

C2 is not the only thing you need help with.

Alright, this is just beyond rediculous. When using text to debug my own game, it was giving me negative numbers. 225 (left-up) became -135, while 315 (right-up) became -35. And checking for those numbers, and/or the ranges that included them, still didn't make the events work, either. And the bullets still moved in the correct directions despite this.

I really truly feel like this is a complete bug now.

So I don't know much about what you are doing, but this seems like you are getting wraparound on your angles.

315 = -35

225 = -135

remember angles just mean rotating around a circle and 20 degrees = 20+360=20+360*2 but it is also equal to 20+360*(-1)

you need to be very careful with angles so that you are looking at the correct quadrant. Checking for a specific angle range can be very dangerous and lead to funny situations like this

so perhaps for what you need to do, you'll need to add a check

if angle < 0, add 360

if angle >360, substract 360

that way you'll always be in the range 0-360. By the way, getting a 0-360 range for angles is not the same as using the remainder function (%).

also, if you only want to see in which quadrant you are, a simple solution:

cos(angle) is positive when the angle is to the right, negative on the left, 0 when 90° or -90°

sin(angle) is positive when the angle is to the bottom, negative on the top, 0 when 180° or 0°

Angles are cyclical so it's not reliable to use linear comparisons with them. 225 degrees = -135 degrees = -495 degrees etc. If you're making a comparison expecting 225 degrees, you will fail to match the other mathematically equivalent cases, in particular -135 degrees.

I'm aware Construct 2 in some places uses a 0 to 360 value, and in others it uses -180 to +180. But this is just a quirk of the way the equations work out and does not matter if you use angle-aware comparisons and calculations.

The Sprite object's angle conditions ("is between angles", "is clockwise from", "is within angle") are cycle-aware so you should always use them instead. For example any of these conditions would work (followed by the same condition inverted for the other case): "Is between -90 and 90 degrees", "Is within 90 degrees of 0", or "Is clockwise of -90 degrees". I note that you're using a behavior's angle of motion instead of a sprite object, so it's kind of awkward to use those conditions (you'd have to have a dummy sprite set to the bullet's angle and use the sprite's conditions...) so I've put on the todo list to port those conditions over to the System object so you can use them for anything.