Put Xaudio on the first layout and make it global.

Nice, if true. I wonder if they'll let people without an office actually develop for the thing though... I'm guessing not, considering their comments in the past about not being interested in working with garage developers.

What if you put one set of resize handles around all of the objects selected?

I think the right and left arrows would be better, and having moving the hot spot around should be ctrl + arrows. Coming from an animation background, ergonomically it's preferable to not have to hold another key when repeatedly checking if an animation is smooth with the arrow keys. I think swapping between frames would also be used more often than hot spot placement with arrows as well, especially once the image editor gets more features.

Apologies for the messy .capx, but this is the first time I've managed to reproduce this reliably (.capx link sent via PM). The problem seems to be localized in two events - 122 and 137.

Event 122 should select the instances of enemybase where enemybase.hittimer is less or equal 0. This appears to not always be the case.

Run the .cap, hold the left mouse button in the direction you want to move. When you're close to the enemybase black oval, it'll move towards the hero. At that point - and only when the enemybase is moving towards the hero (otherwise the bug won't show) and the detector sprite overlaps it, click in the direction of the enemybase to attack it. Doing do will result in the enemybase.hittimer value getting stuck above 0, and the enemybase isn't hit backwards properly.

Next, enable condition 3, "enemybase.hittimer is less or equal 0" in event 137. Run it again, and it works properly.

It shouldn't make a difference if that condition is enabled or not, as that condition has already been checked in event 122.

Don't use system compare, it doesn't do any picking.

Only make one thread per topic. Multiple threads across the forums are unnecessary.

Construct classic has a 'pick by comparison' condition which does that, which hasn't been implemented in C2 yet. You can also set a variable to the distance, and check the variable instead.

Sorry I confused you. I was getting a bit tricky with the examples where I switched the order of the conditions - basically forget that, because it seems to have only confused you.

I'll make it simple:

===============

space is not pressed

- global variable = 1

- global variable = 2

===============

or-

===============

space is not pressed

global variable = 1

space is not pressed

global variable = 2

===============

Example 1 is better.

Please stick to english in the forums, or provide a translation to your posts. Thanks!

Think of it this way - each condition requires construct takes some processing time to determine if it's true or not. Some conditions are more resource intensive than others, like collision detection. There's no point to your second example because it just wastes cpu time checking if space is not pressed twice.

Event one:

If sprite1 is overlapping sprite2

Global variable = 1

Event two:

If sprite1 is overlapping sprite2

Global variable = 2

That would result in two collision checks when only one is needed.

Event one:

If sprite1 is overlapping sprite2

Sub event one:

• Global variable = 1

Sub event two:

• Global variable = 2

The way above would only check for collisions once. If no sprite1's are overlapping sprite2's, then sub events one and two are not checked at all. This way the runtime doesn't have to waste time checking the same conditions over and over again.

Another option for efficiency in this case is reversing the order of the conditions, because checking a global variable is far, far faster than collision detection.

Event one:

Global variable = 1

Sub event one:

• If sprite1 is overlapping sprite2

Event two:

Global variable = 2

Sub event one:

• If sprite1 is overlapping sprite2

This way the collision check is only run once as well even though there are two conditions for it. Another benefit is now the collision check is only run when it's needed, not every frame. In this case however, it's not even necessary to have sub events, as this example is functionally the same:

Event one:

Global variable = 1

If sprite1 is overlapping sprite2

Event two:

Global variable = 2

If sprite1 is overlapping sprite2

If the global variable = 3, then neither of the collision checks are run, because since the first condition was not true, it skips the rest of the conditions and actions in the event.