Glitchy behaviours just by objects being into a subfolder!!

Report Construct 2 bugs here.

Post » Thu May 04, 2017 10:32 am

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.
B
54
S
19
G
13
Posts: 97
Reputation: 10,146

Post » Fri May 05, 2017 2:37 pm

Johncw87 wrote: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?
B
76
S
43
G
24
Posts: 525
Reputation: 20,555

Post » Sat May 06, 2017 1:59 pm

I had this problem as well with the positioning of an object from a container. I could reproduce the bug filed here as well.
Black Bobby The Hole Greenlit with 303 votes.
B
36
S
8
G
1
Posts: 163
Reputation: 3,029

Post » Sun May 07, 2017 6:30 pm

digitalsoapbox wrote:
Johncw87 wrote: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.
B
54
S
19
G
13
Posts: 97
Reputation: 10,146

Post » Sun May 07, 2017 9:50 pm

Johncw87 wrote:
digitalsoapbox wrote:
Johncw87 wrote: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.
B
76
S
43
G
24
Posts: 525
Reputation: 20,555

Post » Mon May 08, 2017 12:31 am

digitalsoapbox wrote:*quote snip*

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.


The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.
B
54
S
19
G
13
Posts: 97
Reputation: 10,146

Post » Tue May 09, 2017 1:38 am

Johncw87 wrote:The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.


At the very least, it would be nice for this kind of stuff being consistent so we can work around it. This is pretty serious and I hope it gets fixed on Construct 2 -Construct 3 or not- since it can potentially break a lot of stuff, and kinda penalizes you for trying to be organizated.

(I have no idea how Construct 2 works internally, but maybe it could be made so the folders are an editor only abstraction thing and doesn't get reflected on the final code in any way).
B
26
S
7
G
1
Posts: 74
Reputation: 2,092

Post » Tue May 09, 2017 2:18 am

yeah, being able to specify in the events where behaviors tick would make the most sense. It's ridiculous that their order changes like this.
B
43
S
19
G
65
Posts: 1,098
Reputation: 37,933

Post » Fri May 12, 2017 8:53 pm

Johncw87 wrote:
digitalsoapbox wrote:*quote snip*

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.


The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.


C2 doesn't export objects in folders, it's all in xml files, where they're stored in the order they've been created, regardless of the "folder" they're tracked in through the IDE.
B
76
S
43
G
24
Posts: 525
Reputation: 20,555

Post » Sat May 13, 2017 1:09 am

digitalsoapbox wrote:
Johncw87 wrote:
digitalsoapbox wrote:*quote snip*

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.


The events are only being indirectly affected. The functionality change isn't related to the events at all. You get different results because the behaviors (both platforms and the sine) evaluate in a different order. This causes the positions of the objects to be different than they otherwise would when the event sheet is evaluated, which then changes the result of the conditions. You can see this when the player 'lags' behind the other sprites. The platform behavior attempted to solve this problem by doing its move logic in 'posttick' while other behaviors use 'tick', but all this really did was move the problem, which is made clear when you have a platform object stand on another platform object.

There are ways that this could be changed so that you don't have to think about the tick order of behaviors, but I wouldn't expect to see them in Construct 2, what with Construct 3 being the primary development focus now.


C2 doesn't export objects in folders, it's all in xml files, where they're stored in the order they've been created, regardless of the "folder" they're tracked in through the IDE.


Dude, I know that. I regularly edit the xml myself when I want to change something in a way that the editor won't allow (like moving a member variable between an object and a family).

To clarify on what Construct 2 does on export, it goes through the xml tree and assigns ID values to the object definitions. Presumably, it assigns them sequentially in the order that it finds them, and this order can be changed by moving objects into subfolders (<object-folder> elements in the xml). These ID numbers are how construct 2 refers to object definitions at runtime, and they can affect the order that behaviors are ticked.

This is also why you can't create objects by name, as the names you assign in the editor don't exist anymore at runtime.
B
54
S
19
G
13
Posts: 97
Reputation: 10,146

PreviousNext

Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest