From a performance perspective, it makes sense to me to minimize the amount of heartbeat activity when a PC is not in an area. Hence I'm doing things like only spawning NPCs upon PC entry into an area and only running custom waypoint activity when a PC is in the same area. I think I might also do a script-hidden on the NPC populace when the PC leaves the area, rather than despawning then respawning later upon return. (I think that will preserve conversation state as well as inventory and variables.) Are there other things I should be doing? Would turning off flickering lights provide any benefit? What about sounds?
Thanks.
Containment of heartbeat activity
Débuté par
rjshae
, mai 16 2012 01:13
#1
Posté 16 mai 2012 - 01:13
#2
Posté 16 mai 2012 - 01:30
Heartbeats are not really so bad in themselves - it is the excessive use of loops that contain a lot of processes - primarily in addition to the large amount that run outside of user defined scripting
graphics like render shadow rather than lighting are also one of the main drags on performance
I am pretty sure that sounds are not concurrently maintained if the area is not loaded - and as far as the size of waves - even a 20 second looping non-positional (global) sounds do not exceed 200Kb; a mere pittance in comparison to the above.
graphics like render shadow rather than lighting are also one of the main drags on performance
I am pretty sure that sounds are not concurrently maintained if the area is not loaded - and as far as the size of waves - even a 20 second looping non-positional (global) sounds do not exceed 200Kb; a mere pittance in comparison to the above.
#3
Posté 16 mai 2012 - 04:59
use xp_profiler and focus on what things it suggests, the issue is the AI almost entirely, second is the area design, pathfinding, shadows, textures ( especially when they first load onto the video card ). ( set up NWNX just so you can use it even if you are entirely in single player. )
Heartbeats should be avoided initially, often you end up with them being the first solution, instead of using the correct features of the engine and resorting to them only when needed. Eventually if you do a hundred things you don't want to have a hundred heartbeats. After you learn the engine, at least to a degree enough to know what events are there, then carefully using them when appropriate ( posting what you do to ensure it's not causing havoc and listening when people suggest other ways to solve the same problem ).
One thing to be careful of is fake heartbeats, add in some way of ensuring you don't get duplicated fake heartbeats, that only one can be in effect at any given time. ( i generate a random number and pass it to each repetition, and if it matches the random integer stored on the object it can continue, else it just ends. )
Heartbeats should be avoided initially, often you end up with them being the first solution, instead of using the correct features of the engine and resorting to them only when needed. Eventually if you do a hundred things you don't want to have a hundred heartbeats. After you learn the engine, at least to a degree enough to know what events are there, then carefully using them when appropriate ( posting what you do to ensure it's not causing havoc and listening when people suggest other ways to solve the same problem ).
One thing to be careful of is fake heartbeats, add in some way of ensuring you don't get duplicated fake heartbeats, that only one can be in effect at any given time. ( i generate a random number and pass it to each repetition, and if it matches the random integer stored on the object it can continue, else it just ends. )
#4
Posté 16 mai 2012 - 05:21
I often have a check at the very beginning of a custom heartbeat script to abort if there is no player in the area, if the script is controlling some sort of eye (or ear) candy. There's not much point having creatures do or say things that are purely cosmetic if there's no-one in the area to see or hear them.
The default creature HBs check whether there is a player in the area, and reduce their processing load accordingly. Creature HBs only seem to fire every 60 seconds with no player in the area (an order or magnitude less often than usual), and AI is also scaled right back.
I doubt that things like placed lights or sounds actually do anything when a player isn't in the area. Certainly placed effects stop working when you leave - if you enter an area with a placed effect close by you sometimes catch it starting up again.
The default creature HBs check whether there is a player in the area, and reduce their processing load accordingly. Creature HBs only seem to fire every 60 seconds with no player in the area (an order or magnitude less often than usual), and AI is also scaled right back.
I doubt that things like placed lights or sounds actually do anything when a player isn't in the area. Certainly placed effects stop working when you leave - if you enter an area with a placed effect close by you sometimes catch it starting up again.
#5
Posté 16 mai 2012 - 07:17
Thanks. I tried the script hidden approach last night and it worked well enough, so I'll probably leave that in (at least for isolated areas). I haven't tried the xp_profiler (at least I don't think I have) so I'll give that a shot as well. Sounds like the sounds/lights/effects don't need to be touched. I'm pretty much relying on the built-in scripting for the most part, although throwing in some waypoint special scripts to make the behavior less robotic.





Retour en haut







