Are you using the latest stable release?

Something like you are describing was fixed in a recent beta release. The problem was related to making image point changes immediately after loading a new image, that's why it seemed like it happened at random.

You can give the beta release a spin and see if you still encounter the same problem doing what you do normally.

If you don't usually use beta releases make sure to have backups of your project, just to be sure!

There is no built in way to do this, there isn't any browser API either, so anything you do will likely be imperfect.

If I were to cobble something together I would probably look into a combo between the on movement trigger and a timer.

Whenever the trigger takes place start a timer, if the trigger happens again before the timer completes, reset the timer and assume the mouse is moving. If the timer manages to complete before on movement is triggered again, the you can assume the mouse is not moving.

You would need to try out different lengths of time to see what works for you.

Rnamon

I am not 100% sure on this, but I don't think C3 functions support the kind of meta programming your are describing.

My suggestion would be to have functions that ADD and SUBSTRACT (possibly more operations) that receive two parameters, the attribute of your character they are modifying and the value.

You would then make as many function calls as you have hats. Each hat would also need to have an instance variable indicating what attribute they modify and another saying by how much.

The body of each function can then modify the corresponding attribute of your character and use the value accordingly.

This would make it easy to later add more functions and different hats with different properties.

supergameweb.com

If you take the event you showed before, and replace rgba with rgba255 it should work. Just tried it out myself.

Oh right! I also went to the docs to check, but I misread :P

But I still don't understand the purpose of rgba() and rgbEx() with the values from 0-100. Not a single program I've ever used in my entire life did use 0-100 for setting RGB-colors. Except Construct. I guess it's easier to set something to 30% red, but that's such a specific thing I don't think I've ever needed that. Anyway, I'm glad there's still the variants that just take 0-255 values.

I wasn't going to go into detail, because it seemed a bit off topic, but since you are mentioning it...

The 0-255 range is a relic of the past which just refuses to die and it looks like it won't be dyeing any time soon.

The 0% to 100% range makes a lot more sense conceptually, 0% is no color and 100% is all the color, every position in the middle is valid. This allows the notation to represent essentially an infinite amount of colors, where with 0 to 255 you have a workable, but in comparison very limited amount of values, because there are no fractional values.

Using a single byte to represent a color channel was introduced at a time where using a 64 bit floating point value to do the same was impossible.

I guess the main reason it is still used, is for backwards compatibility. There are some really old file formats floating around and they are still supported, so that means that new programs still need to understand that color information can be stored in individual bytes.

You can also never underestimate the power of familiarity, there are a lot of people that will just not question that 255 is the maximum value a color channel can have. And so the range continues to be used. I am pretty sure that all popular image editing software uses the 0% - 100% range under the hood, but presents the legacy format in the UI.

In Construct there really is no reason to support the 0 - 255 range, other than backwards compatibility and user familiarity with the format. It literally offers no benefits.

I see, I misunderstood what you were trying to do.

To use the RGB values as they appear in the animations editor you should use the rgbEx255 expression or the rgba255 expression, these accept values in the 0-255 range.

rgba and rgbEx accept values in the 0-1 range.

If you are not interested in the alpha channel use the Ex variants, those only accept red, green and blue values.

Have you checked the luminosity slider at the bottom of the main color picker?

If it's all the way to the left no matter what color you pick it will be black.

I think you are thinking about this the wrong way, because collisions won't take place in the middle of the loop, they either happen before or after, so you won't be able to stop the loop mid way.

I think you want to do a few things:

1. When a collision happens, stop all the tweens. This should stop all movement that is taking place.
2. Check there is a collision before even starting the loop, if there is don't even start.

It's very hard to figure out what is happening from looking at a screen shot, but I have a feeling that your continue variable doesn't have the value you want it to have, so every time the loop starts, new tweens are created.

Just trying to help from glancing at the screen shot of your events, so don't take everything I write too seriously :)

Just realised what you are trying to do, I don't think that will ever work.

If I understand correctly continue will be set to false when a tween finishes, but the for loop will always end before any of those tweens are completed.

Perhaps it would be better for you to explain what you are trying to do before anyone can help.

It's hard to tell what is going on from the screenshot, what is setting the continue variable to false?