Dealing With Lots Of Guard Posts

[Sirbomber]

I'm working on a map with 50+ AI Guard Posts that I want idled until a player's units approaches it (see E/P4 for an example).  So...

How does (unit).isDiscovered work (if at all)?
Will I need to create unit variables for all 50 Guard Posts, or is there a better way to do this?

I'm sure I'll need to know more as I work on this more, but that's all for now.

[Hidiot]

Unless you can make it the other way around, as in if the unit discovered the GP and not the other way around, then you can dynamically assign a limited amount of unit handles for the GPs. Of course, you could still end up having all handles in use unless you idle the GPs again after no player has been around them and re-assign the handles.

This best works if each handled unit has a standard code for it, or several larger groups, otherwise it will not work very well.

[Eddy-B]

It's been a while since i've coded renegades, but if you want each GP to respond when it gets "discovered" then you WILL need 50 variables.

Now, the vars are not the problem, you can virtually create limitless variables (i'd use an array in this case). The problem is: you have only a limited amount of triggers available (ScStub's). What you could do is create events using my event system (InRectEvent) to determine if an enemy has entered a certain area.

I forgot how IsDiscovered works (if it does at all, since there is no fog-of-war in OP2).

[Hidiot]

Will not dynamically attributing a variable for each GP each time the GP needs its state changed work?

On seconds thoughts, it would have to be done in a kind of rect check, but one might want to make the check more of a circle-like check, not a rectangular one that you can commonly do. Which couldprobably be done by verifying a circle of individual tiles. But, it would imply much more work and more variable.
So I guess it's not such a viable solution after all.

[Sirbomber]

Oh yes, I forgot about IUnit entirely.  I'll just check for player units entering the GP's area and turning the GPs on as needed.  Of course, I'll have to set up rects and triggers and yuckiness.  Guess there's no easy solution, unless I attract Hooman's attention (though that would more involve confirming there is no easy solution, rather than providing one).

You'd like to think that isDiscovered would check if there were any enemy units in the unit's line of sight (or the unit in question was in something else's line of sight), but sadly it doesn't appear work that way.

[Hooman]

Guess there's no easy solution, unless I attract Hooman's attention (though that would more involve confirming there is no easy solution, rather than providing one).

Haha!


Anyways, Unit.isDiscovered() is only for Wreckage units. It will return false for anything else.


I would have just setup a rect trigger or maybe a few if you didn't want a single perfectly rectangular region. You can always set all the regions to have the same callback if you want them to function the same. If anything enters that rect, then use an Enum to iterate over all the guard posts and tell them to turn on. That way you only need about 2 local variables, and 1 trigger.

Or did you want the GPs to have independent activation regions? Do you want the GPs to turn off when no units are around?
 

[Sirbomber]

No, I want the GPs to turn on individually (in most cases; sometimes there are a few grouped together).

They will not turn off after being discovered and left alone for awhile.

[Eddy-B]

Anyways, Unit.isDiscovered() is only for Wreckage units. It will return false for anything else.

Sounds about right to me..  as i said: it's been too damn long for me!
 

[Hooman]

Ok, so create a bunch of rect triggers, each of which turns on some GP(s). There are two ways I can se this working. One is to just create a bunch of different callbacks that would turn on the GPs in some region, and set each rect trigger callback accordingly.

The other would be to reuse the same callback for each rect trigger, but then to figure out which trigger fired yourself. That's one of the weaknesses of the trigger system. The callback isn't passed any information about which trigger caused it to be called. If you kept around a global array of triggers, and trigger rects, then this would allow you to iterate over all the GPs in that region and turn them on if the trigger has fired.


The second way is probably more complicated from a source code perspective, and less efficient from a runtime perspective, but more easily extensible. It would be possible to get the second way to work without hardcoding a bunch of things. Plus, you could also setup the triggers in an automated way. Such as using an enum to find all GPs for that player, and for each one found (that is turned off), it can generate a rect trigger around that region, and mark which unit that region turns on.


The system might work something like this (untested code):

Code: [Select]

struct GpActivateStruct
{
 Â Trigger activateTrigger;
 Â Unit gp;
};

struct ScriptGlobal
{
 Â GpActivateStruct gpActivate[32];  // ** Set appropriate array size **
 Â int numActivateGp;
};
ScriptGlobal scriptGlobal;

int InitProc()
{
 Â Unit unit;
 Â LOCATION loc;
 Â PlayerBuildingEnum buildingEnum(aiPlayer, mapGuardPost);
 Â int i = 0;

 Â while (buildingEnum.GetNext(unit))
 Â {
 Â   // ** Might want to add a debug check here to ensure the end of the array isn't passed, and possibly warn the level designer **
 Â   //if (i >= numof(scriptGlobal.gpActivate)) ...
 Â   // Should probably check the GP is disabled here (using an extension library)
 Â   scriptGlobal.gpActivate[i].gp = unit;
 Â   loc = unit.Location();
 Â   scriptGlobal.gpActivate[i].activateTrigger = CreateRectTrigger(true, true, playerNum, loc.x-10, loc.y-10, 20, 20, "EnableGP");  // ** Set approptiate Rect size. This sets the rect to be 10 tiles in any direction from the GP **
 Â   i++;
 Â }
 Â scriptGlobal.numActivateGp = i;
}

SCRIPT_API void EnableGP()
{
 Â int i;

 Â // Find out which GPs need to be activated
 Â for (i = 0; i < scriptGlobal.numActivateGp; i++)
 Â {
 Â   if (scriptGlobal.gpActivate[i].activateTrigger.HasFired(playerNum))
 Â   {
 Â     scriptGlobal.gpActivate[i].gp.DoUnIdle();
 Â     // Delete the trigger and unit, so we can free ScStubs, and don't accidentally call DoUnidle on a different unit if the GP is destroyed and another unit is built that uses the same unit index
 Â     scriptGlobal.gpActivate[i].activateTrigger.Destroy();  // Free ScStub
 Â     // If not last item in list, swap current item with last item
 Â     if (i != scriptGlobal.numActivateGp)
 Â     {
 Â       scriptGlobal.gpActivate[i] = scriptGlobal.gpActivate[scriptGlobal.numActivateGp-1];
 Â       i--;  // Need to recheck current slot, since it contains a new value now
 Â     }
 Â     scriptGlobal.numActivateGp--;  // Dump the last item on the list
 Â   }
 Â }
}

You of course need to define aiPlayer, and playerNum yourself. You might also need to write the numof macro, which was written in Hooville (BaseData.h) like this:

Code: [Select]

#define numof(array) (sizeof(array)/sizeof(array[0]))