Skip to content

New Encounter-related Scripting Functions

I've always thought the nwscript support for encounters had room for development.

The first thing I wish I had for one of my encounter scripts is a way to determine the parent encounter that spawned a particular monster. That'll let me flexibly read vars off the parent enc and customize creature behavior without making multiple copies of the creature blueprint. There are workarounds I have; I can read vars off of areas, and avoid mixing behaviors in an area. Or, I sometimes make sure spawn points are contained in their encounter and use the encounter's OnEnter hook to "claim" monsters by way of checking a regex on their name.

All that's a pain; support for a function like so would solve a few headaches and limitations for me:

object GetSpawnParentEncounter( object oCreature ); - This function returns the encounter object that spawned the calling creature, if any. Otherwise, returns OBJECT_INVALID.

Someone may have a use for a complimentary set of functions, perhaps object GetFirst/GetNextSpawnedChildCreature( object oEncounter ) from a provided parent encounter as well. I suggest it for symmetry. I haven't thought about it a ton, but I suppose I could use it to despawn child creatures when a quest condition is achieved, for example. There are other ways to do that, but this would add some power, and others may have application ideas.

Secondly, I suggest functions to manage the entries on the Creature List tab. For example:

int GetEncounterCreatureListEntryCount( object oEncounter, int nMinCR = 0, int nMaxCR = -1);
struct tCreatureListEntry GetEncounterCreatureListEntry( object oEncounter, int Nth, int nMinCR = 0, int nMaxCR = -1);


The idea here is to be able to see how many creatures in CR range min:max are referenced by the encounter design, and then to be able select one manually/randomly for a script doing some manual overrides of the encounter spawn behavior. Alternatively, I've suggested a new built in Spawn Option - Continuous Individual - (see link below to the toolset thread). Others may wish to be able to re-write (Add/Remove) entries from this table. That would let me build encounter tables in 2da format to be globally assembled in game on module load or on area enter or such. That's beyond my needs but larger teams might find the idea attractive. The CR filters are optional; I can always build that myself if those parameters are not implemented. Alternatively, a function that picks a random creature resref off the list for me within a given CR range could replace both functions above.

Thirdly, I suggest functions to manage the encounter spawn point placement. For example:

int GetEncounterSpawnPointCount( object oEncounter );
location GetEncounterSpawnPoint( object oEncounter, int nSpawnPoint = 1 );


This would let me nuke workarounds in existing code where I look for nearby waypoints by tag to use them to substitute for encounter spawn points. Alternatively, a routine that picks an attractive Spawn Point (ie furthest from PCs) so I can use it to manually spawn a placeable or creature would be useful instead.

Finally, I'll suggest exposing the event + code that generates a spawn for an encounter. Some of the above suggestions can feed into that, but perhaps a different set of functions already exists and just needs to be exposed.

---
Also, there's some suggestions for new encounter-design toolset features over here: https://forums.beamdog.com/discussion/68067/toolset-encounter-design-features#latest . If any of those suggestions get attention, I'll suggest including relevant script support for new features, as well.

Also related - DM Client suggestions: https://forums.beamdog.com/discussion/68066/dm-client-suggestions-encounter-waypoint-management-features#latest

---

Anyone have other wishlist items for encounter design?

-Dave
squattingmonkKhuzadrepadunahan

Comments

  • KhuzadrepaKhuzadrepa Member Posts: 3
    edited January 2020
    @shadguy I commented on your other thread, but these are also great ideas! No other wishlist items right now from a scripting perspective, except maybe see if the OnEnter should fire prior to the spawning that I mentioned over there.
Sign In or Register to comment.