6 réponses à ce sujet

[dickel]

Just wondering if this would be an easy option to go in terms of lessening the amount of onHeartbeat scripts that are firing on Npc's in an area i've already been to but not one i'm currently in.
So basically have each area's on enter and on exit scripts to disable and enable the scripthidden of each npc in the area. That way with the option (disable a.i while hidden -enabled) , the amount of resources spent running on heartbeat scripts on npc's is hopefully lessened?
Am I correct in assuming this and would this be the recommended way to go?

[MasterChanger]

I wouldn't say that this is the best way. Creature OnHB's have a quick-exit condition when no PCs are in an area. Their AI level gets set to VERY_LOW when the last PC exits (I've never been sure exactly where this happens, but I know it does). The default1 OnHB script checks for this AI level and immediately exits if it is true. Note that this applies to creature OnHB's, but no area OnHB's.

If you're still worried about having a lot of NPCs hanging around for no reason, you can use NESS, which is a system that makes it easy to spawn in all kinds of objects (not just creatures) and clean them up when you're done with them.

[dickel]

Sweet as Masterchanger, that's good to know.
I'll look into NESS and see how I go. Appreciate the quick reply.

[Dann-J]

MasterChanger wrote...
I wouldn't say that this is the best way. Creature OnHB's have a quick-exit condition when no PCs are in an area. Their AI level gets set to VERY_LOW when the last PC exits (I've never been sure exactly where this happens, but I know it does). The default1 OnHB script checks for this AI level and immediately exits if it is true. Note that this applies to creature OnHB's, but no area OnHB's.

Is this also true of iPoints? I have a heartbeat script attached to some iPoints that checks what time of day it is, and spawns in various encounter creatures accordingly (then removes them at other times). However I've found that the hearbeat script only spawns the encounters if the player is in that area at the time.

Do iPoints behave more like creatures than placeables? Would I be better off putting the HB script on placeables, or even on dummy triggers? Or do you have to be a certain distance from a non-creature in order for its HB to start firing at all?

Modifié par DannJ, 05 avril 2011 - 03:04 .

[MasterChanger]

I don't know much about iPoints, but they pretty much seem to be placeables with no visual appearance. They should have the same behavior as any placeable.

There's no default OnHB for placeables, but there are specific ones for ipspeakers and stuff. You just have to follow those to see if they have any quick-exit checks. As far as triggers, those OnHBs work like Area of Effect OnHBs: they only fire when a creature is inside the area (I'm almost positive.)

For your particular purposes, DannJ, you would have a few options when it comes to spawning those creatures: Trigger OnEnters, Area OnHBs, NESS (which uses area OnHBs). If you want to run things when Our Heroes are within a certain location, triggers might be your best bet.

[Dann-J]

The problem with trigger OnEnters is that some spawn areas can be accessed from various directions, requiring multiple triggers for each encounter. I'd have to check all the triggers for the same event and deactivate the others to prevent them firing more than once (then reactivate them all again later). I can also see my spawn areas from cliff-tops, and I'd like to be able to see things wandering or swimming below, rather than have them spring suddenly from nowhere.

I may have to have an Area OnEnter script that double-checks that the spawn HBs have worked, and if not then spawn the relevant creatures if the time of day is right. Using the Area OnHB script has the downside of having to search the area for all objects that contain the local variables that control what get spawned at what time of day. I don't think I'd like all that happening every six seconds (whether in the area or not). At least the Area OnEnter only fires once each time you enter the area, with the individual placeables apparently not firing their HBs at all if you are in another area entirely.

[MasterChanger]

DannJ wrote...

The problem with trigger OnEnters is that some spawn areas can be accessed from various directions, requiring multiple triggers for each encounter. I'd have to check all the triggers for the same event and deactivate the others to prevent them firing more than once (then reactivate them all again later). I can also see my spawn areas from cliff-tops, and I'd like to be able to see things wandering or swimming below, rather than have them spring suddenly from nowhere.

When I added encounters to several hundred areas for a PW, I got very used to painting creative trigger shapes. In most cases, you can paint a huge trigger with a lot of vertices so that it includes all approaches you want to cover; just how big the enclosed area is doesn't really matter.

However, if I were to start adding encounters to a large project today, I would strongly consider using NESS instead of triggers. I didn't last time around primarily out of concern for the performance hit from using the Area HBs (and because I sometimes wanted to write area HBs of my own to do other work). The general consensus, though, is that using Area HBs responsibly (quick-exit conditions for no PCs, mainly) results in a relatively minor performance hit, and that this is what NESS does.