Spawn systems, NPC behaviors, and loot drops

[ç i p h é r]

Yes, that summary is correct. I'll separate the existing specification threads to accommodate the push for independence. We need to flesh things out a bit more than we have though.

EDIT: BTW, we still need the ability to spawn in NWN objects that NESS provides. This includes creatures, items, and placeables. So if the system already handles the spawning of all but the encounters that have been conceptualized here, perhaps we really need to look at modifying NESS rather than a ground up rewrite.

All things considered, we should focus on the systems we need to build or rewrite first as we can always ignore the redundant parts of NESS if time proves to be short, starting with the encounter system. That will probably dictate much of what we need to do around it. Anyone have a different opinion?

[Ronan]

My opinion of NESS is rather poor. I'm guessing it was made before local variables could be edited in the toolset, since its based off the tags of waypoints. The result is that it must look at every waypoint in an area to find NESS waypoints. Then it has to parse the tag, where the spawn data is located. From what I can tell, NESS and NESS flags are one of the biggest headaches for builders. This tag parsing combined with behavioral and loot systems make it much more complicated than it should be, IMO. And the fact that the behavioral systems aren't tied into the AI means they don't shut off when an NPC is possessed or when its AI is turned off (extreme annoyance for DMs). It spawns things with its heartbeat script, which isn't very fast. We could spawn things OnAreaExit, predicting the AT destination and preparing spawns before the PC's transition finishes. Walking into a cave, lagging from work NESS is doing, then suddenly finding yourself surrounded by 20 orcs is not fun. Finally, it doesn't adhear to our coding conventions or standards.

We could replace the system with one which uses easy-to-read intuitive local variables on the waypoints, using a specific tag for each waypoint (so the native function object GetNearestObjectByTag() could be used). We could turn NESS flags from their current syntax into local variables as easy to configure as,

Code: Select all

ACR_SPAWN_RESREF
ACR_SPAWN_GROUP
ACR_SPAWN_TIME_IN
ACR_SPAWN_TIME_OUT
ACR_SPAWN_MIN_NUMBER
ACR_SPAWN_MAX_NUMBER
ACR_SPAWN_RESERVE_NUMBER
ACR_SPAWN_NEAR_PC
ACR_SPAWN_MIN_DELAY
ACR_SPAWN_MAX_DELAY
ACR_SPAWN_CHANCE

And of course, we could provide a base waypoint template to builders. The code does not actually have to be complete for builders to start using it. Leaving WP names free for descriptive purposes is nice as well. Add our debug system to the headaches caused when things don't seem to spawn when they are supposed to, and I think a new spawn system is one of the better improvements we could add for NWN2.

[Fionn]

ACR_SPAWN_DAY_IN
ACR_SPAWN_DAY_OUT

Also, if there's a way to have a global variable for ACR_SPAWN_FACTION_STRENGTH so we can easily up the number of [Orc] or [Animals] on a server.

[indio]

Agreed with Ronan on the variable approach to spawning.

Thee Quest System in the current basemod operaates similarly, to a degree. You place the NPC (or in our case, a waypoint or whatever), right click on them and define a number of variables, and that's all she wrote.

[ç i p h é r]

Can't argue with that. A rewrite it is then.

Some additional thoughts:

For spawn points that have player based restrictions (ie must be in the vicinity to spawn), moving the spawning off HBs and onto area transitions is logical. But we'll still need to make sure these spawn points keep spawning as long as players linger in the area without waiting for another transition. So, transitions might serve as events which activate idle spawn points in the destination area but the spawn point itself will have to schedule its next spawn cycle and shut itself down when players are gone. Similarly, if a spawn cycle comes and goes but players are not in the vicinity, we'll have to decide whether the spawn point should spawn at the next contact with a player or just wait for the next scheduled cycle.

For spawn points that have no spawning restrictions, they'll have to get into the scheduler from the onset and spawn according to their time cycles. If we're talking about dynamic spawning and raiding parties forming as a result of unfettered spawn growth, these spawn points can't be player restricted. I think we'll still need *some* reliance on area heartbeats to accomplish these things, at least for spawn point activation. Unless we keep track of the spawns with counters or something....