Glitchy behaviours just by objects being into a subfolder!!

Problem Description

Platform behaviour gets glitchy and imprecise on some situations......only if the object is organized into a subfolder!

Attach a Capx

CAPX

Description of Capx

The example presents a simple platform game situation, with a moving platform (solid object with sine behaviour), a solid block on top of it (solid + platform behaviours with default controls disabled), and a player character with platform behaviour.

Steps to Reproduce Bug

• Create a sprite with sine (linked to vertical movement) and solid behaviours.
• Create a sprite with platform (optionally disable default control so it stands still) and solid behaviours to act as a solid block and place it on top of the moving platform.
• Create a platform behaviour sprite.
• Create an object subfolder and move the player object to it.

Observed Result

With the player standing on the solid block, it lags behind the vertical movement of the platform and the block, and the "Is on floor" condition (Displayed via text at runtime on the example) acts erratically only being true at the extremes of the vertical movement when it is slower (As you can imagine, this can lead to all kind of issues on a complex project...).

At first I tought it was just a limitation with Construct and stacking stuff on moving platforms, but the thing is........It works perfectly IF YOU JUST TAKE THE PLAYER OBJECT OUT OF THE SUBFOLDER! (You can do just that on the example capx...take the player object back from "New folder" to the Object types main folder).

Expected Result

Well, at least that folder organized objects behave the exact same way as unorganized ones...This could be a pretty serious bug...who knows what else may not work properly just because being into a sub folder?

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)

Operating System and Service Pack

Windows 7 Sp1

Construct 2 Version ID

r244 64-bit (A friend of mine still uses r237 and reproduced the bug)

Wow, it actually does change the behaviour just by moving the player object to a subfolder. I've had this exact problem for ages and it was all because of a subfolder. Hope this will be fixed. Thank you for sharing

I can reproduce, Ashley could you please look into this?

This is really concerning and could affect a lot of projects.

Tested, can also reproduce. This would explain a number of weird bugs I ran into with Sombrero.

I can reproduce this as well. Could it be related to the fact that C2 editor works faster when you have your object in the subfolder?

I can reproduce this as well. Could it be related to the fact that C2 editor works faster when you have your object in the subfolder?

I don't know why that would change runtime behaviors.

I reproduced it too.

A few days ago I've made a post about something similar (glitchy), but in my case, the player stays always on floor.

I've explained why I think this is happening in that post.

You could take a look at it:

That's an amazing bug-find! I can reproduce it - and I fear for the repercussions for the c2runtime.....

I can confirm too.. that is pretty weird.

Ashley this is a bit of a big issue.

Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

Yikes. That is no good. Load order shouldn't affect behaviors like that.

Ashley, have you had a chance to look at this yet?

I had this problem as well with the positioning of an object from a container. I could reproduce the bug filed here as well.

> Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

>

Yikes. That is no good. Load order shouldn't affect behaviors like that.

Ashley, have you had a chance to look at this yet?

The behaviors need to be updated in some arbitrary order. Construct 2 tries to hide some of this from users, but since it can't automatically figure out what your intended behavior is, you will inevitably have to deal with it at some point. At least like this, you have some level of control over it.

This is why I prefer to use events whenever I can, since I have complete control over the order those run in. Behaviors could have this same level of control too, IF they provided the option of disabling their javascript tick functions and using an action to trigger them instead.

>

> > Changing the folder it's in seems to change the tick order of the behaviors. This is probably related to how Construct 2 assigns IDs to objects on export. If I put Sprite in 'Folder1', Sprite2 in 'Folder2', and Player in 'Folder3', IsOnFloor is constantly true. If I swap Sprite and Player, then the described buggy behavior occurs.

> >

>

> Yikes. That is no good. Load order shouldn't affect behaviors like that.

>

> Ashley, have you had a chance to look at this yet?

>

The behaviors need to be updated in some arbitrary order. Construct 2 tries to hide some of this from users, but since it can't automatically figure out what your intended behavior is, you will inevitably have to deal with it at some point. At least like this, you have some level of control over it.

This is why I prefer to use events whenever I can, since I have complete control over the order those run in. Behaviors could have this same level of control too, IF they provided the option of disabling their javascript tick functions and using an action to trigger them instead.

I didn't mean "behaviors" in the sense of C2 Behaviors. I meant functionality (through events) shouldn't be affected by what folder something is in. Poor word choice on my part.