You are here

ginc_group bugs?

7 posts / 0 new
Last post
kevL's
ginc_group bugs?

anyone want to have a look at 'ginc_group' to confirm or debate what I think are a couple of bugs?

1st, in DoMoveType()
- case MOVE_FORCE_WALK and MOVE_FORCE_RUN look like they're missing break; statements.

eg. MOVE_FORCE_WALK is going to load up
ActionWait()
ActionForceMoveToLocation()
ActionWait()
ActionForceMoveToLocation()
ActionMoveToLocation()

in oMember's action-queue.


2nd, GroupForceMoveToLocation()
- defines lNewDest/lDestination inconsistently in the switch block. The final command for each group-member is ActionForceMoveToLocation(lNewDest), but several of the cases leave lNewDest defined as it was on the previous iteration (or uninitialized on the first iteration), by defining lDestination instead -- but apparently not actually using lDestination for anything (other than to re-define itself on the next iteration).

Compare with GroupSpawnAtLocation(). It uses a very similar switch block, but defines its output-location/destination consistently.


--
aside, DoMoveType() was added [broken out of GroupMoveToFormationLocation()] later and does not have a prototype. Neither does GroupRemoveEffectOfType(), GroupApplyEffectToObject()

meanwhile, DeleteGroupString() has a prototype, but no definition ...

  • up
    50%
  • down
    50%
andysks

I could look at them later this week. The only thing I can say at the moment is that from personal experience (if I remember correctly that is) that GroupForceMoveToLocation works fine even if it looks weird on implementation :).

  • up
    50%
  • down
    50%
kevL's

hey Andy,
it's been a while since i looked at it, iirc nothing is going to staggeringly break -- but in some cases there might be added waits or type_walk instead of type_run, etc.

It should be pretty straightforward ...

  • up
    50%
  • down
    50%
andysks

Perhaps not the focus here, but I want to say something because we talk about ginc_group. Since I found the library and experimented with it, I can't let it go. I use it whenever I get the chance since it allows for easy written and reliable code. In my experience it is one of the most stable methods to do your thing in a module. I was surprised to see the thread name :). 

  • up
    50%
  • down
    50%
kevL's

well ... here's DoMoveType()

// move to the specified destination in the specified way.
void DoMoveType(object oMember, location lThisDest, int iMoveType=MOVE_WALK, float fStartNoise=0.0f, float fForceMoveTimeout=30.0f)
{
    switch (iMoveType)
    {
        case MOVE_WALK:
            AssignCommand(oMember, ActionWait(RandomFloat(fStartNoise)));
            AssignCommand(oMember, ActionMoveToLocation(lThisDest));
            break;

        case MOVE_RUN:
            AssignCommand(oMember, ActionWait(RandomFloat(fStartNoise)));
            AssignCommand(oMember, ActionMoveToLocation(lThisDest, TRUE));
            break;

        case MOVE_JUMP:
            AssignCommand(oMember, ActionJumpToLocation(lThisDest));
            break;

        case MOVE_JUMP_INSTANT:
            AssignCommand(oMember, ClearAllActions());
            AssignCommand(oMember, JumpToLocation(lThisDest));
            break;

        case MOVE_FORCE_WALK:
            AssignCommand(oMember, ActionWait(RandomFloat(fStartNoise)));
            AssignCommand(oMember, ActionForceMoveToLocation(lThisDest, FALSE, fForceMoveTimeout));

        case MOVE_FORCE_RUN:
            AssignCommand(oMember, ActionWait(RandomFloat(fStartNoise)));
            AssignCommand(oMember, ActionForceMoveToLocation(lThisDest, TRUE, fForceMoveTimeout));

        default:
            PrintString("ginc_group: invalid iMoveType case");
            AssignCommand(oMember, ActionMoveToLocation(lThisDest));
            break;
    }
}


note the (apparently) missing break; statements. ya know what happens when a break; statement isn't there? it falls through to the next case also, and the next until it hits a break; or runs out of scope.

So if MOVE_FORCE_WALK is passed in for 'iMoveType' these are the calls that line up:

    AssignCommand(oMember, ActionWait(RandomFloat(fStartNoise)));
    AssignCommand(oMember, ActionForceMoveToLocation(lThisDest, FALSE, fForceMoveTimeout));
    AssignCommand(oMember, ActionWait(RandomFloat(fStartNoise)));
    AssignCommand(oMember, ActionForceMoveToLocation(lThisDest, TRUE, fForceMoveTimeout));
    PrintString("ginc_group: invalid iMoveType case");
    AssignCommand(oMember, ActionMoveToLocation(lThisDest));


wtf

issue #2 that i pointed out is a bit more involved...

  • up
    50%
  • down
    50%
andysks

I wonder now... it appears they left the breaks out intentionally :D. Because they only miss on the two "brother" functions with forced move.

Another interesting note, is that game was released 2006. DoMoveType was added by ChazM at 6/27/2007.

Was it a test for MotB that got left uncommented? Was it a test for Mac? Or meant for an OC patch?

  • up
    50%
  • down
    50%
kevL's

DoMoveType() was broken out of GroupMoveToFormationLocation() so that it could be used on its own in 'ka_cutscene_setup' GroupMoveToPrefix() without duplicating code.
 

  • Because they only miss on the two "brother" functions with forced move.

and then print "ginc_group: invalid iMoveType case" to logfile ... lulz

anyway, they're fixed in my version of the script and that's good enough fo' me.

  • up
    50%
  • down
    50%