Odd problem with destorying by PV count

For questions about using Classic.

Post » Fri Jun 18, 2010 4:28 pm

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.
B
2
G
2
Posts: 13
Reputation: 676

Post » Fri Jun 18, 2010 7:51 pm

It seems that this condition:
[code:3i8ucuqg]+ Sprite: arrived at a waypoint[/code:3i8ucuqg]
is always triggered twice, so it look like it's an issue with the RTS plugin.
B
79
S
24
G
54
Posts: 4,741
Reputation: 40,745

Post » Sat Jun 19, 2010 7:18 pm

That tells me very little.

Am I to surmise it's a bug?
B
2
G
2
Posts: 13
Reputation: 676

Post » Sun Jun 20, 2010 1:08 am

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! :)
B
3
S
2
G
2
Posts: 187
Reputation: 1,449

Post » Sun Jun 20, 2010 2:11 am

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:
[url:2ufzcgd7]http://dl.dropbox.com/u/5426011/examples/waypointWorkaround.cap[/url:2ufzcgd7]
B
79
S
24
G
54
Posts: 4,741
Reputation: 40,745

Post » Sun Jun 20, 2010 6:31 am

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?
B
2
G
2
Posts: 13
Reputation: 676

Post » Sun Jun 20, 2010 7:10 am

I'm using the conditional operator.
It's in this format:
[code:24ozcys7]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.
B
79
S
24
G
54
Posts: 4,741
Reputation: 40,745

Post » Sun Jun 20, 2010 6:13 pm

Ok, got it, awesome.

Thanks a bunch, you're great.

(And a new useful expression learned)
B
2
G
2
Posts: 13
Reputation: 676


Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 0 guests