Odd problem with destorying by PV count

This forum is currently in read-only mode.
From the Asset Store
An educational game for counting pictures. An easy to use template for developers to build larger games
  • I was attempting to comprehend RTS movement and came to the point where I was able to spawn graphical waypoints and have them destroy when the unit reaches them. That's when the problem appeared.

    http://dl.dropbox.com/u/4850857/RTS%20Movement.cap

    The cap itself, just so we're clear.

    The problem is as such.

    Each click, after activating the unit's movement, sets up a graphical waypoint with a PV set to a GV that goes up on each click.

    When the unit arrives at a waypoint, the sprite of the waypoint is set to destroy, by picking the one with the lowest PV.

    The issue rises when Contruct deems it right to destroy the number of waypoints forward equal to the PV of the current one, rather than the one.

    Not sure if I am clear enough, but the cap is easy enough to decipher.

    Any help or insight appreciated.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It seems that this condition:

    + Sprite: arrived at a waypoint[/code:3i8ucuqg]
    is always triggered twice, so it look like it's an issue with the RTS plugin.
  • That tells me very little.

    Am I to surmise it's a bug?

  • It looks to me like the 'arrived at waypoint' is triggering as the plugin calculates the path ahead of the object's movement position. But, further tests show that it does trigger twice near the correct spots, by spawning another sprite instead of destroying the markers. Anyway, if I quickly place a long series of waypoints ahead of the sprite, they disappear long before it's movement finishes, but it does complete the path correctly.

    I'd say that this is probably unintended behavior, and thus a bug. You may be able to work around it with a proximity check (the object is not guaranteed to overlap them,) and a queue of waypoints (to ensure that they are destroyed in order when paths overlap.) This would not be easy.

    Perhaps an acceptable alternative can be implemented, such as simply having each waypoint fade away after a certain amount of time, or leaving them all until the final destination is reached, then destroying all of them.

    EDIT - Removed flawed workaround, to prevent confusion. R0J0hound posted a good one below. Nice one, R0J0hound!

  • It's a bug with the RTS behavior. The "arrived at waypoint" is always being triggered twice for each waypoint. So with you events two 'Sprite2' objects are being destroyed when a waypoint is reached. A solution would to only destroy 'Sprite2' every other time "arrived at waypoint" is triggered.

    Here is your example with a workaround implemented:

    http://dl.dropbox.com/u/5426011/examples/waypointWorkaround.cap

  • Ok, just so I'm clear on what you did there:

    The expression checks if the GV equals 1. That much I got. What's that 0:1?

  • I'm using the conditional operator.

    It's in this format:

    condition ? ifTrue : ifFalse[/code:24ozcys7]
    It checks the condition, if it's true then the expression uses ifTrue value, and if it's false the ifFalse value is used.  So in my example if "global('triggercount')=1" is true 0 is used, and if it's false 1 is used.
  • Ok, got it, awesome.

    Thanks a bunch, you're great.

    (And a new useful expression learned)

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