r90 breaking patrol movement

0 favourites
  • 7 posts
From the Asset Store
Run and Jump in 3 Dimensions! Take your platformer to the next level!
  • Hi everyone,

    I have been working on a platformer project for a few months now, and it has been stable up to the last release (which I updated to today).

    My problem is as follows: I have enemies with a patrol motion based on their touching two invisible boundary blocks (ie Upon overlap with the boundary blocks, the enemies will pause then move the other direction). This way I simply copy and paste the enemy and the boundary blocks wherever I need another instance of it. r90 has broken this, but only some enemies on a given level. What happens now are some of the enemies would simply blow past the boundary and just keep going, while others maintained their normal behaviour.

    Furthermore, I have animated sprites pinned onto the enemy blocks (On startup each enemy block spawns a sprite, which are pinned to whatever enemy block it overlaps). The aforementioned broken enemies would not have their sprites pinned and simply leave them behind.

    I am somewhat reluctant to upload my capx because it is huge, and I don't want to make it public prior to its completion.

    I test my game on Chrome, and am on Windows 7 64-bit. The error (which is, obviously, huge and surprising) occurred after updating to r90.

  • Reproduce in a new capx and post it, it will allow to make sure if it has something to do with your code or if it is indeed related to the new version.

  • 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 fast reply.

    PatrolBug.capx

    Hopefully that works (or rather, works in showing it not working). The first instance patrol behaviour works fine, but all subsequent copy/pasting of it does not.

  • Agreed with

    Changing the "is overlapping" event (that is tested each tick) into a trigger "on collision" that is only fired once on collision of the objects allows for the logic to be executed only once, as intended.

    Are you previewing under chrome ?

    If so, it's possible that you used to have so bad performance due to the use of the chrome software renderer and a bad compatibility with your hardware that made is such that there were fewer tests by second and so the code appeared to operate as intended.

    In the last versions of C2, Ash implemented a check to make sure that the game is ran to the best of your hardware's capabilities on Chrome.

    And so, with a greater number of tests each seconds, apparently "correct" code revealed in fact not to be the correct way to go.

  • Thank you both for your replies! Changing it to collision did fix the problem. Furthermore, I figured out the problem with the sprites not 'sticking' to the boxes; it is likely along the same vein of the reason you suggested, Kyatric. Prior to the update I had it simply set up that on the start of layout, if an animated sprite is overlapping the box on start of layout, it is pinned. After the update, this broke to pieces. Apparently I had to add a 'For each' condition as well to make sure that the condition is applied to each instance of the box.

    Again, thank you for your attention, and this 'bug' is resolved (I suppose it just uncovered faulty code). I was just a little stunned at how spectacularly everything broke all of a sudden =P

  • kirothius - I recommend following beta releases more closely if you don't want this to happen again - we occasionally have to make breaking changes and in this case I believe your problems stemmed from r86's change to the Sprite 'overlapping' condition. It was marked as a breaking change but I guess you weren't following beta releases or perhaps you didn't read all the changelogs linked to from r90? Anyways, glad this is resolved - closing.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)