Plans for Trigger based Spawn System

For those who didn’t see it yet I released a trigger based spawn system of my own on vault yesterday.

I would like to discuss further development of this system here. And I would like to hear your opinions and suggestions.

While this isn’t WIP and the scripting package is fully functional, when working on this recently I realized some of the flaws and limitations.

I think that the main flaw is that it is quite tiring to set it all up. It is not as easy as just draw encounter, right click Add Spawn Point and select npcs in properties. Builder must be aware of monster resrefs, all the variables the system offers and how to set up spawn (way)points.

Right now each spawn trigger must or rather should have unique tag. This is because the spawn points are based on tag of the trigger and spawn script takes spawn (way)points in other areas into consideration. This could actually be used as feature but if this wasn’t a case it could make things easier. Right now builder is recommended to use tag in following format “enc_areanameshortcut_something” where something is 1,2,3 or start, mid, end anything that makes it easier to navigate in toolset area selection. If the scripting would only considered spawn (way)points in same area as spawn trigger it, builder could exclude the area shortcut and simply give triggers tags “enc_goblins1” “enc_skeletons3” “enc_generic1” and most importantly, could save such encounters into palette and use it in new area without changing its tag. It is not that big benefit and only saves a few seconds, but maybe it could be worth it.

BTW this remind me that the spawn triggers works without placing spawn (way)points. In case the spawn waypoint doesn’t exist, npcs will appear right in front of player. This also matches vanilla encounter behavior and while I hate lazy spawns like this (from player’s perspective) there is no reason not to preserve this functionality.

Continuing on the improvements, I can’t think of any other change in the scripting that could make it easier or rather faster to use. However, what scripting cannot do could be handled via multiple blueprints. Right now this is coming with single spawn trigger blueprint with basically no variables set.
Maybe it would be better to pre-set all variables even if with zero or default values. Additionally it could benefit users if there were more blueprints all pre-set in some way so user could speed up the setting process by selecting the spawn trigger template closes to his desires.
For this, I would like to ask for help, preparing such blueprints.


Maybe it would be better to pre-set all variables even if with zero or default values

This would certainly make it easier to use. How NESS does it is pretty good too having all the settings in the tag of the trigger.

As for limitations. There is quite big issue with calling DestroyObject on the NPCs spawned from spawn trigger. This system was developed for a PW that wasn’t using any area cleaners or despawning so there was no risk having one of the npcs destroyed. Destroyed npcs will not fire OnDeath script which is extremely important to make spawn trigger assume OnExhausted event (all npcs that were spawned killed) and began countdown to the re-activating spawn trigger.

Right now if the npcs spawned from spawn trigger are deleted outside of the spawn system, the spawn will render inactive untill next reset.

This will be adressed in future, however there is no solution that would let me to find out the OnExhausted event happened immediately after npcs were destroyed outside of the spawn scripts.

There are two ways how to handle this - pseudo heartbeat, perhaps each 30 seconds that will check spawned npcs status. Or more efficient but less precise, check the npc status when player enters the spawn trigger. Right now, nothing happens, in next version it could at least start the re-activation countdown so the spawn trigger would not break infinitely, just had longer reactivating delay than supposed.

Either way, if you use this you should avoid destroying npcs from this spawn and use Despawn feature instead.

If the Despawn feature doesn’t suit you then you should make exceptions into your area cleaning/npc despawning system based on this:

spawn trigger internal code:

thus, check if npc has local int GET_IS_FROM_ENCOUNTER, then either ignore the npc or if it must be cleaned/despawned then you should do this:

//code from function Despawn() in enc_include:
object oEncounter = GetLocalObject(OBJECT_SELF,“ENCOUNTER_FROM”);
int nAlive = GetLocalInt(oEncounter,“NUM_SPAWNED_CREATURES_ALIVE”)-1;
if(nAlive < 1)//OnExhausted!

hmm, I don’t think that will work well for more than 1 group,

I would recommend to combine NESS with this instead I guess, there where you need spawn (multiple) npc(s) of single type use NESS and my humble spawn trigger for cases where you want some randomness

However I really like the conditional system of the NESS. This scripting package had conditions on its own but the way it was handled was really meh and in the end I never used it and I was just relying on (pseudo)randomness. For example, you can influence the randomness of the spawn trigger by:
specifying same monster multiple times in group:
NPC_GROUP_1 “goblin,goblinking” has 50% chance for spawning goblinking
NPC_GROUP_1 “goblin,goblin,goblin,goblinking” will have less than 25% chance for spawning goblinking (I think it is less than 25% because iirc it rolls chance for each npc in group from first to last - will need to look into this and maybe recode it so all npcs will have same chance to spawn if it is true)
similarly you can have 3 same groups just to make sure the 4th (different) group will have lower chance of being chosen.

Anyway, I am thinking of borrowing the way how NESS handles conditions such as spawn day only/night only/PC level. My idea is to put the string output that follows NESS documentation into variable IF_GROUP_X . But this will not be easy task and I must get more familiar with NESS first.

1 Like

I really like where you’re headed with this system and will be keeping my eye on it. Most of the time I’d rather not have encounters scale with the power of the party.