4 réponses à ce sujet

[tmp7704]

Search is being its usual self so if there's already thread dealing with this, apologies.

I'm trying to use the PRCSCR mechanics to add an item to warden's cache in Denerim. The script is set to trigger for area den02al_den_market which typically means the Denerim market. It executes, but here's where the trouble starts.

I want the item to be spawned in the den260_warden_cache area, not on the market proper. I tried the following:

location lSpawn = Location( GetObjectByTag("den260ar_warden_cache"), Vector( -0.747734, 20.8677, 0.0280043 ), -55.0714 );
CreateObject( OBJECT_TYPE_PLACEABLE, PRC_STORAGE_R, lSpawn );

this doesn't seem to work -- the item is spawned in a rather inconvenient spot of Denerim market instead (in area where the player is, i.e. den200ar_market )

To make things funnier, if the script is launched again (on re-entering the market) it detects properly the storage item was spawned. But if the player zones into the den260_warden_cache area the item is no longer detected -- i can manually trigger the script and spawn the item where it was supposed to be in the first place. Which to my understanding shouldn't be happening because these two areas form single zone and remain in memory together.

I was thinking of maybe using the "any area" workaround for PRCSCR and then checking the area tag for den260_warden_cache ... but another gotcha, because the warden_cache is technically in single area list with the den200ar_market, PRC doesn't trigger when zoning into the warden_cache.

Kind of stumped at this point, any suggestions how to resolve that would be very welcome.

Modifié par tmp7704, 20 mai 2010 - 04:46 .

[Craig Graff]

You need to filter for the tag of the area. Unfortunately Location seems to default to the current area if it doesn't find a valid area object. Do something similar to the following:

if (GetTag(GetArea(GetMainControlled())) == "den260ar_warden_cache")
{
 // your spawn code
}

Modifié par Craig Graff, 20 mai 2010 - 07:29 .

[tmp7704]

Craig Graff wrote...

You need to filter for the tag of the area. Unfortunately Location seems to default to the current area if it doesn't find a valid area object. Do something similar to the following:

if (GetTag(GetArea(GetMainControlled())) == "den260ar_warden_cache")
{
// your spawn code
}

Unfortunately because of the way warden cache is positioned, the script practically never seems to trigger in situation when the PC actually *is* there (short of maybe loading a save with player being there) -- even if i set the PRC location to "any" the script is only launched when entering den200ar_market because both these places belong to the same area list. If i set the location to den02al_den_market then it also executes pretty much only when entering the den200ar_market but not when entering the cache itself. I'm guessing it's because when the market loads, it also triggers loading other parts of this area list including the cache, even though the PC isn't "physically" there?

However that makes me thinking, why does the game seem to have trouble locating that area object in the first place? (as well as locating the item spawned in another part of the currently loaded area list) I was under impression that everything which shares the same area list is supposed to be visible by the game at the same time, at least builder wiki makes such a claim...

[tmp7704]

Small follow up. i've added sanity check to the code:

        object oCache = GetObjectByTag( "den260ar_warden_cache" );
        if( !IsObjectValid( oCache ) ) { return; }

this check is passed, implying that the game can find the cache area just fine while on the market. However, trying to spawn the item still places it in the market area despite the call uses

        location lSpawn = Location( oCache, Vector( -0.747734, 20.8677, 0.0280043 ), -55.0714 );
        CreateObject( OBJECT_TYPE_PLACEABLE, PRC_STORAGE_R, lSpawn );

and with the oCache being valid object the fallback to current area shouldn't be happening..?

[tmp7704]

Well, in the end i "solved" it through brute-force method of modifying the script associated with the den260ar area so the additional item is spawned where it's supposed to... but that's hardly a solution at all given it's going to conflict with anyone else doing the same thing to put their own things in there. But oh well.