TSShapeConstructor::addTrigger() bug [w/ fix]

#1 There is something odd going on with trigger editing in the Shape Editor. There's no reason why you can't have triggers #2 and #4. I'm looking into what is going wrong.

In the meantime, you could manually edit the TSShapeConstructor::onLoad method to add the triggers you need.

#2 I tried. None of this work:

%this.addTrigger("root", "0", "2");
%this.addTrigger("root", "0", "4");

%this.addTrigger("root", "0", "2");
%this.addTrigger("root", "1", "4");

The result is always trigger "1" on frame 0 and trigger "2" on frame 3.

#3 Debugging through TSShape::addTrigger(), the problem is obvious (the solution... not so much).

There's a quite the logical problem when adding triggers. Triggers are stored in a shared vector, and each shape contains the index and number of triggers they use. It's ok so far.

However, the point of insertion for new triggers is based solely on the sequence's first trigger (which is 0 for sequences without any triggers, which is my case). This means that the triggers for "run" (which is sequence #2) are added to the start of the vector, pushing the triggers used by "root" (sequence #0) further. Right after addTrigger() tries to fix the firstTrigger of all other sequences from the current one onwards. Since "root" comes before "run", it never gets its firstTrigger fixed, and thus uses the newly added "run" triggers.

I think either the calculation of trigIndex or the fixup code needs to change in order to cope with this, otherwise the only workaround is to carefully re-arrange the addTrigger() ordering until it works.

#4 Okay, I think I found the solution. Seems addTrigger() in its current state is setup to only properly add triggers to animations that already had triggers to begin with. It's adding triggers to triggerless sequences that bugs things out.

I changed the fixup code to check all sequences other than the current one and increment their firstTrigger if it is greater-or-equal to the current trigIndex. This seems to solve the problem.

Replace this:

// fixup firstTrigger index for other sequences
for (S32 i = seqIndex + 1; i < sequences.size(); i++)
{
   if (sequences[i].numTriggers > 0)
      sequences[i].firstTrigger++;
}

With this:

// fixup firstTrigger index for other sequences
for (S32 i = 0; i < sequences.size(); i++)
{
   if (i != seqIndex && sequences[i].numTriggers && sequences[i].firstTrigger >= trigIndex)
      sequences[i].firstTrigger++;
}

#5 Nice one, Manoel! Another solution would be to fixup seq.firstTrigger, so that triggers in the shared vector have the same order as the sequences that reference them. eg.

// Fixup seq.firstTrigger if this sequence does not have any triggers yet
if (seq.numTriggers == 0)
{
   seq.firstTrigger = 0;
   for (S32 i = 0; i < seqIndex; i++)
      seq.firstTrigger += sequences[i].numTriggers;
}

// Find where to insert the trigger (sorted by keyframe)
S32 trigIndex;

I think there is still an unrelated issue with editing triggers in the Shape Editor. I'm looking into that now and will post a fix here if possible.

#6 Your solution looks a tad better. I believe it would deal better with triggers being added to different sequences in a random order.

And I noticed some oddities when editing, with some triggers refusing to be deleted once in a while and generating strange output in the .cs file (a mix of addTrigger() and removeTrigger() calls).

#7 Logged as THREED-713