9 réponses à ce sujet

[BCH]

I've written a simple script to get the name, name of current area, and name of current master (if any) of every henchman in my module.  This script appears to work fine except for getting the name of the area the henchman is in. 

When I first run the script, all henchmen are reported as being in the same area - an area NONE of them are in.

But then, if I move the henchmen to a different area, the script reports their area name correctly.

Any idea what I'm doing wrong?  The script is below.  I changed from using GetName(GetArea()) to GetName(GetAreaFromLocation(GetLocation())) just to see if there was a bug in GetArea(), but the results did not change.

void bchTellDMsHenchStatus(string sHenchTag, int nOrd = 0)
{
    object oUser = OBJECT_SELF;
    object oHench = GetObjectByTag(sHenchTag, nOrd);
    location lHenchLoc;
    string sOutput;

    if (nOrd > 0) sOutput = "DUPE #" + IntToString(nOrd + 1) + ": ";

    if (GetIsObjectValid(oHench))
    {

        sOutput += GetName(oHench) + " with ";
        sOutput += GetName(GetMaster(oHench)) + " in ";
        lHenchLoc = GetLocation(oHench);
        sOutput += GetName(GetAreaFromLocation(lHenchLoc));

        // AssignCommand(oHench, ActionJumpToLocation(GetLocation(oUser)) );
        SendMessageToAllDMs(sOutput);
    }
}

[Baaleos]

Despite the idea that every object must exist in one area or another.
It is actually the case that during transitions - the area object will be returned as OBJECT_INVALID;

If you do getArea on the PC object while they are transitioning = OBJECT_INVALID.
It is often the case that a JumpToLocation call on an NPC although it should be instant - often isnt.

Check your oArea - to see if it comes back as OBJECT_INVALID - and if so - repeat the function on a delay - to see if it resolves it.

eg

if(oArea == OBJECT_INVALID)
{
DelayCommand(1.00,ThisFunction());
return;
}

[GhostOfGod]

Not sure if it makes a difference trying to get the name of an area using "GetAreaFromLocation" as apposed to just using "GetArea". Maybe try something more like so and see if it works:


sOutput += GetName(oHench) + " with ";
sOutput += GetName(GetMaster(oHench)) + " in ";
oArea = GetArea(oHench);
sOutput += GetName(oArea);

Nevermind. I suppose I should read the whole post before I respond since you already tried it.

Modifié par GhostOfGod, 06 février 2013 - 07:15 .

[FunkySwerve]

I suspect Baaleos nailed this one. It's become standard practice for us to delay a lot of things if the pc is transitioning, with a pseudo that checks if (GetIsObjectValid(GetArea(oPC)) - if not, it cycles until it is.

Funky

[BCH]

Interesting, but I'm not sure we've covered it.

These aren't PCs, these are NPC henchmen. They spawn into specific areas when the module starts, so they aren't (as far as I know) in any sort of transition state.

So, when the module loads, most of them are in "Traveler's Tower" and two are in "Temple of Kernunos." But GetName(GetArea()) lists them as all being in "DM Office."

Then, after I move them all to "Hill Fort" the same code lists them as being in Hill Fort. But only after I manually move them.

I don't know if this is significant, but "DM  Office" is listed as being the second area in my module's list of areas.  That might make it Area ID 001 or something similar, right?

(All my areas do have unique tags and no default resrefs, BTW.)

---

I put in that one (commented-out) line to make sure I was actually getting the henchman objects, and it does seem to work fine:

// AssignCommand(oHench, ActionJumpToLocation(GetLocation(oUser)) );

Is there any similar brute-force way to see what object GetArea() is actually returning?

---

Any further thoughts?

Modifié par BCH, 07 février 2013 - 03:20 .

[FunkySwerve]

My next suspicion was in how you're getting the henchmen. GetObjectByTag is far and away the fastest way to get an object, but if you don't use unique tags as well as resrefs on all your creatures (and it's hard to see why you would, as the tag/res system isn't really built that way), then it's kind of a crap shoot as to which you'll get (it goes like so, according to the lexicon's entry:
Outside of the current area, the scan will begin starting with the last (most recent) area added to the module following this hierarchy:

OBJECT_TYPE_STORE (128)
OBJECT_TYPE_PLACEABLE (64)
OBJECT_TYPE_WAYPOINT (32)
OBJECT_TYPE_AREA_OF_EFFECT (16) (spell effects, like web)
OBJECT_TYPE_DOOR (8)
OBJECT_TYPE_TRIGGER (4)
OBJECT_TYPE_ITEM (2)
OBJECT_TYPE_CREATURE (1)

The way we get objects is a little different. For a long time we used waypoints in an area, naming them uniquely. You can use either GOBT or GetWaypointByTag to get them, then GetNearestObjectByTag to them to iterate the area, or GetArea() if it's the area you want. I would suggest trying another method of getting your henchies, to see if it returns expected result. If so, then GOBT isn't getting the critters you think it is.

Funky

[BCH]

This is one of the few instances where I can say that the tags involved are unique. Each hench has a unique tag, and there's only one of each henchman when the module starts up.

Edit:  the "dupe #" line in there is so far unused, I probably should have left that out...

I used this line:

AssignCommand(oHench, ActionJumpToLocation(GetLocation(oUser)) );

... as a test to jump each henchman directly to the DM running the script, just to make sure I was getting the right objects. Sure enough, the DM ends up surrounded by a cloud of henchmen, all accounted for, so I (am reasonably sure I) am getting the right henchmen objects.

But I'm not trying to be difficult, honest! :-) This is a real stumper...

Modifié par BCH, 07 février 2013 - 04:21 .

[FunkySwerve]

I'd have to see the mod. Something else is going on - maybe a CopyObject somewhere, maybe an area onenter or exit script firing causing unexpected behavior. Too many unknowns. If you like, you can pm me a download link, or I can pm you my email. I'm mildly curious as to what it could be.

Funky

[BCH]

Sad to say, given my history, the problem is very likely to be something small and stupid, so I'm hesitant to waste any more of your time at this point.

I have a session scheduled with my players tomorrow night (virtual tabletop game) so I will have ample opportunity to try out that script over and over again in different situations.

I will definitely keep your (much-appreciated) offer in mind, though, and I will post in this threat again if I find a solution or after another week or two of scratching at it.

[BCH]

Thanks again. Turns out this was indeed my stupidity. I was doing this test during the first minute or so the module was running, which is the only time the henchmen are not each unique in the module. So, it turns out the script was working, just not in a predictable manner.

(When my module starts, a copy of each henchman is retrieved from the database so that their inventory can be copied to the newly-spawned henchmen, making it persistent between resets. I was doing these tests while those from-the-database henchmen were still around, before they were automatically deleted.)