2 réponses à ce sujet

[MasterChanger]

Hi forumites, got some general questions and some optimization questions regarding scripts to affect encounters. The context for what I'm working on is being able to dynamically set whether encounters are active or inactive based on certain conditions (primarily day/night).

To begin with, I know it's possible to use SetEncounterActive( TRUE/FALSE ) to control whether an encounter will actually spawn when the trigger is entered. I've done this successfully through area-OnHB but I want to create a more generic script that can be applied to any area/encounter set.

One of the ideas I've played around with is having the area OnHB retrieve a waypoint I paint; the waypoint would have the same tag in all areas that this applies to. I would designate the tag of the encounter(s) as a variable on the WP, allowing the area to retrieve the appropriate encounters. This would be necessary because GetFirstObjectinArea does not allow an OBJECT_TYPE* filter for some reason, and I wouldn't want to iterate through all objects in the area just to retrieve the encounters. Any shortcuts here?

I also played around with the encounter events, primarily OnEnter and OnHeartBeat. I don't fully understand these, so input from anyone who has more info would be very welcome.

One of the things that I tested is when the encounter OnEnter is fired. From testing, it seems that if an encounter is entered while inactive, it will not spawn even if the OnEnter sets it to active (though it will the next time)--the potential spawn happens before the OnEnter. The opposite didn't seem to hold: when the encounter was entered while active and the OnEnter set it to inactive, the spawn did not happen.

I had a really hard time figuring out when the encounter OnHB was firing. It seemed to be firing only while actually standing within the trigger, but it also seemed that whether the encounter was active may have affected this. I'm not really methodical enough to figure this out.

I suspect that some of the spawning systems (MPWC, etc.) may address this, but I'm not looking at those at this time.

Modifié par MasterChanger, 12 août 2010 - 05:03 .

[_Knightmare_]

MasterChanger wrote...

To begin with, I know it's possible to use SetEncounterActive( TRUE/FALSE ) to control whether an encounter will actually spawn when the trigger is entered. I've done this successfully through area-OnHB but I want to create a more generic script that can be applied to any area/encounter set.

From a "module running more smoothly" point of view, you should avoid using Heartbeat scripts whenever possible. Reason is that they fire every 6 seconds while (most) other scripts are only fired when triggered to do so.

One of the ideas I've played around with is having the area OnHB retrieve a waypoint I paint; the waypoint would have the same tag in all areas that this applies to. I would designate the tag of the encounter(s) as a variable on the WP, allowing the area to retrieve the appropriate encounters. This would be necessary because GetFirstObjectinArea does not allow an OBJECT_TYPE* filter for some reason, and I wouldn't want to iterate through all objects in the area just to retrieve the encounters. Any shortcuts here?

Instead of cycling through all the object to find the WP you are looking for, instead us the function GetNearestObjectByTag() and enter the WPs tag for it. Use the PC as the base (as in the nearest object to the PC with the tag XXX). If there is only a single WP in the area with that tag (no matter if there are other WPs of the same tag in a different area), then it will find the one "local" to the area the PC is currently in. Set your encounter tags on there as you planned using string type variables. I suggest naming those variables something like "Day01", "Day02", "Night01", "Night02", etc.

I also played around with the encounter events, primarily OnEnter and OnHeartBeat. I don't fully understand these, so input from anyone who has more info would be very welcome.

I could give general info about those script events, but as you found out they seem to work a bit differently with encounter triggers. So generally - As mentioned above, Heartbeat scripts fire every 6 seconds, as long as the player is in the area (though an area's HB will fire no matter if the Player is in there or not). OnEnter will fire when ANY creature enters the trigger, so in this case you must check to make sure its a PC entering, if not exit the script:

object oPC = GetEnteringObject();
if(!GetIsPC(oPC)) return;

One of the things that I tested is when the encounter OnEnter is fired. From testing, it seems that if an encounter is entered while inactive, it will not spawn even if the OnEnter sets it to active (though it will the next time)--the potential spawn happens before the OnEnter. The opposite didn't seem to hold: when the encounter was entered while active and the OnEnter set it to inactive, the spawn did not happen.

The solution here (one way of many) would be to place a normal trigger around the encounter trigger so that the player must cross the normal trigger before walking over the encounter trigger. The normal trigger would be the one where you stick your OnEnter to activate the encounter trigger.

[MasterChanger]

I'm going to try to use some nested quotes here; I have no idea how ugly they'll come out on this forum.

_Knightmare_ wrote...

MasterChanger wrote...

To begin with, I know it's possible to use SetEncounterActive( TRUE/FALSE ) to control whether an encounter will actually spawn when the trigger is entered. I've done this successfully through area-OnHB but I want to create a more generic script that can be applied to any area/encounter set.

From a "module running more smoothly" point of view, you should avoid using Heartbeat scripts whenever possible. Reason is that they fire every 6 seconds while (most) other scripts are only fired when triggered to do so.

Yup, I'm aware of that, which is why I was asking for advice on other ways.

MasterChanger wrote...
One of the ideas I've played around with is having the area OnHB retrieve a waypoint I paint; the waypoint would have the same tag in all areas that this applies to. I would designate the tag of the encounter(s) as a variable on the WP, allowing the area to retrieve the appropriate encounters. This would be necessary because GetFirstObjectinArea does not allow an OBJECT_TYPE* filter for some reason, and I wouldn't want to iterate through all objects in the area just to retrieve the encounters. Any shortcuts here?

_Knightmare_ wrote...
Instead of cycling through all the object to find the WP you are looking for, instead us the function GetNearestObjectByTag() and enter the WPs tag for it. Use the PC as the base (as in the nearest object to the PC with the tag XXX). If there is only a single WP in the area with that tag (no matter if there are other WPs of the same tag in a different area), then it will find the one "local" to the area the PC is currently in. Set your encounter tags on there as you planned using string type variables. I suggest naming those variables something like "Day01", "Day02", "Night01", "Night02", etc.

As long as I'm using a WP at all, I could definitely use GetNearestObjectByTag() since I would know the WP's tag. The question was whether there was a way not to use this WP. No particular reason not to use it, I was just thinking that it was an extra step in the script that complicates things.

Using the player location is a base is an interesting idea as well. I suppose I really don't need to flip those switches if no PC is in the area. I wouldn't want to do it in an area OnEnter because I still want the changes to happen while PCs hang out in the area, but why do work on an on populated area?

_Knightmare_ wrote...
The solution here (one way of many) would be to place a normal trigger around the encounter trigger so that the player must cross the normal trigger before walking over the encounter trigger. The normal trigger would be the one where you stick your OnEnter to activate the encounter trigger.

That seems like the simplest solution so far! I could store the encounter tag as a variable on the outer trigger and only change each encounter as necessary. Seems very efficient. I could even make blueprints of these triggers if I'm going to use them a lot, called DayOnlySpawn or NightOnlySpawn or whatever.

More generically, I guess you could also just make a one-size-fits-all pre-spawn trigger that runs a script you store as a variable on the target encounter trigger, buying yourself those few seconds to flips some switches and push some buttons on the encounter before the player trips it.

Thanks _KM_!