Remove remaining actions in CCSequence

Forums Programming cocos2d support (graphics engine) Remove remaining actions in CCSequence

This topic contains 8 replies, has 4 voices, and was last updated by  jrhee 1 year, 5 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
Author Posts
Author Posts
November 11, 2012 at 12:58 am #245244

jrhee
Participant
@jrhee

Hello, is there a simple way to remove all remaining actions in a CCSequence, while ensuring the current action in the sequence completes?

Let’s say I have a sprite that’s already running through a CCSequence to get to point A. Midway through the action, I want it to change its path to go to point B. To do this, it needs to:

- first finish the current action in the sequence (i.e. finish traversing the current tile)

- clear all remaining movements in the sequence

- begin a new sequence of movements to go to point B

Thanks!

November 11, 2012 at 5:12 pm #391920

LittleBitStudio
@littlebitstudio

What about using a queue for waypoints.

Instead of building all the actions ahead of time, you could build just the actions for the movement to the next waypoint. Then when it completes, you build and execute the next waypoint. Then you could truncate your queue of waypoints at any point and add new points to change course.

beware, poorly written descriptions to follow:

MoveNext

* pop next waypoint from queue (no more, just stop)

* create move actions

* create CCCallFunc action to call MoveNext

* create CCSequence, add tag TAG_MOVE

* execute CCSequence

TruncatePoints

* empty queue

AddPoint

* add point to queue

* if !getActionByTag:TAG_MOVE then MoveNext (start the movement if not already)

hope it helps – Scott

November 11, 2012 at 7:26 pm #391921

jrhee
Participant
@jrhee

Hi Scott, that’s very similar to what I was originally doing, but I was running into problems with performance. Each movement is basically one step; at the end of each step, I was generating an action for the next step from a queue. Between each step though, generating the next animation/movement actions was causing a very slight hiccup, especially as the number of sprites increased. Preloading the actions into a sequence was the only way I could seem to avoid this.

November 13, 2012 at 1:40 pm #391922

jrhee
Participant
@jrhee

Hm, still struggling with this… I take what I said earlier about the hiccup between each step action being related to performance. It seems to occur between each step because the amount of movement is based on the ‘elapsed’ variable in CCActionInterval, which applies a MIN(1, elapsed) and at the end of each action. I looked more closely at CCSequence, and it seems to compensate for this by calculating the delta and applying on an extra update for the next action.

Has anyone run into similar issues while trying to implement a dynamic action queue? I should be ok not using the queue and just relying on CCSequence, but in that case I’d need the ability to stop all remaining actions in the sequence while letting the current one complete. Thanks!

November 13, 2012 at 2:21 pm #391923

razvan_b
Participant
@razvan_b

hi!

You can achieve this by doing this (pseudo)

id action = [ccsequence actions:[ccmove...], [cccallfunc actionwithtarget:self selector:@selector(check)], [ccmove...], [cccallfunc actionwithtarget:self selector:@selector(check)],….., nil];

[action setTag:0xdeadbeef];

[node runaction:action];

now in the method check you can have:

if(condition)

[node stopactionbytag:0xdeadbeef];//or pause or what ever, and you can resume at a later point.

i will explain further:

Between each action in the sequence you insert a check. In that check you verify if you need to interrupt the sequence and this way you are certain you do not interrupt it in the middle of an action of moving or scaling or whatever.

November 15, 2012 at 7:08 pm #391924

jrhee
Participant
@jrhee

Thanks Razvan! I’m trying something like that now, but even after putting in a check like you described, the CCSequence update that’s already in progress still seems to kick off the next action in the sequence. I think this is because the current and next actions are both triggered within the same CCSequence update.

Unless I’m misunderstanding, this code at the bottom of CCSequence’s update seems to cause the next action in the sequence to start/update at least once, even if the sequence has been stopped using a check method:

// New action. Start it.
if( found != last_ ) {
CCLOG(@"New action. Start it.");
[actions_[found] startWithTarget:target_];
[actions_[found] update: new_t];
last_ = found;
}

November 16, 2012 at 9:31 am #391925

razvan_b
Participant
@razvan_b

You might be right, i haven’t practically tested the described functionality. If that is the case then the only remaining option that i see is to make an array of actions and run them in sequence, checking the necessity of continuing with the next action with a method called after each one.

pseudo:

actions[0] = [ccsequence actions:[ccmove1..], [cccalfunc ...@selector(check)],nil];

actions[1] = [ccsequence actions:[ccmove2..], [cccalfunc ...@selector(check)],nil];

and in the check:

if(condition)

{

[node stopallactions];

if(index < max -1)

{

[node runaction:[action[index++]]];

}

}

November 17, 2012 at 12:51 am #391926

HiRez
Participant
@hirez

As a workaround, maybe insert CCDelayTime actions in between your real actions, with a very short delay, or some other kind of “dummy” actions, so when they get triggered with the previous action, you don’t observe anything?

November 17, 2012 at 3:55 am #391927

jrhee
Participant
@jrhee

I needed to use CCSequence here since it ensures seamless transitions between actions by adjusting t. Creating a custom queue or entering delays prevents that. For now, I wound up just adding an extra variable along with some extra checks in my startWithTarget & update methods to prevent the next action in the sequence from starting after completing the current one. Not pretty, but it gets the job done. Thanks all for the help!

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.