Possible bug but perhaps I'm missing something

Post reply
0 favourites
  • 7 posts
From the Asset Store
Write The Missing Letter For Kids - Educational Game
$14 USD
Game with complete Source-Code (Construct 3 / .c3p) + HTML5 Exported.
R Games's avatar
R Games

  • Hello!

    Just wanted to make sure before posting a bug that I'm just being a fool and it's not actually a bug.

    The example is very simple. Two sprites with pinned "wheels", both with bound to layout and 8 direction. If I move the sprites to the edge of the window one set of wheels doesn't behave properly when the sprite reaches the edge.

    https://drive.google.com/open?id=1gBzXmUDmay7q5vp3eHqrXrpc1Q6IEZh_

    Thanks

  • Define "doesn't behave" properly.

    As far as I could see, I noticed no difference between the wheels of the top sprite and bottom sprite.

    Your wheels are pinned to the sprite, meaning that when you move your sprite, the wheels are then moved, with some delay (due to the nature of pin).

    If you can explain clearly what you are expecting and what you are experiencing, it will be easier to investigate your issue.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Hi Kyatric. Thanks for the response.

    What I experience from the capx I shared is:

    • All is ok when moving without reaching the edge of the layout.
    • when reaching the edge, and without lifting the key, the wheels of the bottom sprite move relative to the sprite they are pinned to (which shouldn't happen since they are position pinned to this bottom sprite).
    • when releasing the key, the wheels of the bottom sprite return to the original position relative to the sprite that are pinned to.

    I've also tried to replicate this behavior in C3 building it from scratch, but it didn't show. Now, when I imported the C2 example to C3 it behaves again as I described above (???).

    I'm using the last build of C2, r262.

  • (which shouldn't happen since they are position pinned to this bottom sprite)

    That is one of the side effect of pinned instances.

    As I said, there is a delay between the "main" object moving (that is moved thanks to the 8Direction behavior) and the moment the pinned instances are moved.

    So basically, sprite 3 is moved "outside" of the layout, the pinned instances are moved along, and sprite 3 is repositioned by the "BoundToLayout" behavior.

    Nevertheless, the wheel instances already have been moved, giving this strange impression.

    It is a kind of bug, but it's also due to the way Construct works and the order in which operations happen.

    You may fill a bug report for it to get a confirmation from Ashley I guess.

    For Construct 3, were you running the C3 or C2 runtime in your version built from scratch ?

    If it is C3 runtime, it would make sense since it's been a complete rewrite and possibly Ash did "correct" (or make it more solid) the pinned behavior.

  • The runtime has to run behaviors in some order. There's no fundamental way around this. The order you are getting is either:

    1) move 8direction

    2) bound to layout

    This means it bounds it to the layout after moving 8direction, which works as you want it to. Otherwise it's

    1) bound to layout (before it's moved)

    2) move 8direction (which could then move it outside the layout)

    This means the object can temporarily be left outside the layout, because 8direction moved it after it checked the bounds.

    The workaround is to change the order the behaviors run in, which you can do by rearranging the list.

  • The runtime has to run behaviors in some order. There's no fundamental way around this. The order you are getting is either:

    1) move 8direction

    2) bound to layout

    This means it bounds it to the layout after moving 8direction, which works as you want it to. Otherwise it's

    1) bound to layout (before it's moved)

    2) move 8direction (which could then move it outside the layout)

    This means the object can temporarily be left outside the layout, because 8direction moved it after it checked the bounds.

    The workaround is to change the order the behaviors run in, which you can do by rearranging the list.

    Ahhhh!!! Many many thanks. I was losing my mind. I knew that I was missing something. Didn´t occurred to me to check the order of behaviours.

    Thanks you very much Kyatric and Ashley

  • UPDATE

    I'm sorry, but I got ahead of myself in posting. I checked and is not the order of behaviours. The sprite that shows the "bug" has the right order of behaviours (1. 8-Direction 2. BoundToLayout).

    So I began to test one more time:

    Redid the example one more time. This time the "bug" does not happen. Order of behaviours doesn't matter.

    https://drive.google.com/open?id=1I_sHeTvYs-Ru0r_d8m9RCdYp-_pvJg2R

    Next, I cloned the second "car" sprite (since that was how I made the original capx), added the events for this new object and this time the bug appears in the new instance.

    Now I check what happens if I add a fourth car by not cloning. This car4 also does show the bug.

    https://drive.google.com/open?id=1MDNk_YMDroGb_GG5a1p6Mi9t1gZYCRmF

    All cars have 1. 8-direction 2. BoundToLayout. I've also tried changing the order of behaviours but it doesn't change anything.

    What do you think?

    PS:

    For Construct 3, were you running the C3 or C2 runtime in your version built from scratch ?

    It was the C2 runtime

Post reply
  • 7 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)