Spawn System (ALFA / ACR)

[ç i p h é r]

Good news indeed.

Ronan's initial work suggested that we see the system slow down on it's local int access the more variables we start piling onto these poor waypoints.

I *think* his test cases were in the hundreds or thousands of local variables on an object. The concern was primarily for persistence where you could expect a lot of variables stored on an object (item). I don't think we'll approach anywhere near those numbers for system-specific objects/variables, but it certainly doesn't hurt to be as efficient as possible.

Currently, spawns appear in a tight group, right on top of their waypoint- I'll need to write some location randomizing functions with parameter constraints if we want to simulate the kind of unpredictability we came to expect from NESS. I believe I read in the NWN2 forums, that createobject no longer nudges a creature to the neaest walkable area- currently I believe it's just failing if the recommended location is unwalkable. This could be a problem in exteriors, when we don't know what "Z" coordinate the ground would be for a given X and Y coordinate.

Looks like he had some planned variables for randomization along two axes (vertical & horizontal). Perhaps he put hooks in the code for these too.

No other comments. Thanks AL.

p.s. I'm sure you already plan to, but as you fix, update, and extend the system, please update the spec in the Wiki as well so it remains accurate.

[AcadiusLost]

I *think* his test cases were in the hundreds or thousands of local variables on an object. The concern was primarily for persistence where you could expect a lot of variables stored on an object (item). I don't think we'll approach anywhere near those numbers for system-specific objects/variables, but it certainly doesn't hurt to be as efficient as possible.

He's actually composing many of the variables on the spawn waypoint together during the initialization process, so that when it comes to time to spawn, only a handful need to actually be read, so he seems to have taking great pains to reduce them- that could have been just forward-thinking rather than a move of necessity, in either case we'll see how it goes. Some of that manipulation is over my head, so expect any functions I write from scratch to be the klodgy ones.

p.s. I'm sure you already plan to, but as you fix, update, and extend the system, please update the spec in the Wiki as well so it remains accurate.

Will, do, once it's ready to go out for testing- don't want to change a bunch of things on there only to receive improved code from Ronan and have to change things back, heh. Some of it just needs to be reworded for clarity I suspect.

[ç i p h é r]

If you'd like me to review functions you write from scratch, just let me know. Peer reviews are SOP in process-focused development environments, so it's certainly not something you should ever feel funny about.

[AcadiusLost]

Only minor progress tonight: Got a time-of day spawn waiting for the right time to spawn, though it didn't despawn on schedule. First try at a "spawn on day 3, despawn on day 5" waypoint seemed to spawn on day 1, so definitely a closer look needed there.

The spawn system will currently properly stop running spawn refresh pseudoheartbeats when no PCs or DMs are in an area, but I'm not sure if it's queued up for actual despawning or not- haven't seen any despawn yet.

Had some success with mixing fixed with random spawns in the same waypoint as well- so you could make sure the "boss" always makes the spawn list, and vary up the number and distribution of his followers randomly.

Anyone know what the visual range for PCs is in NWN2? I've stuck 25.0 in for time being for the ACR_SPAWN_IN_SIGHT handling, but the real deal would be preferable, naturally.

Getting closer to having something testable for people, but I'd like to work out what's going on with the despawning and respawning first.

[Rotku]

Great work, AL! Great to see someone stepping up and continuing with this!

[ç i p h é r]

Anyone know what the visual range for PCs is in NWN2? I've stuck 25.0 in for time being for the ACR_SPAWN_IN_SIGHT handling, but the real deal would be preferable, naturally.

It depends on what's defined in ranges.2da. I've linked the article in the wiki, which explains the fields if you need to know.

Looking at what's in the repository (2das directory), currently player visual perception range is 50m (Spot) and player auditory perception range is 20m (Listen). I believe all units of distance are in meters, though I'm not 100% certain. They're the same as the game defaults.

[AcadiusLost]

Just an update on current headway:

I've successfully added position randomization by including the following two local float variables:

ACR_SPAWN_RANDOM_RANGE (determines the maximum random distance from the spawn waypoint, at which the spawn will focus on- all children will spawn at this point unless RADIUS is set, see below. Diretion is random, so this describes a circle of potential targers, with radius = Range. Default = 0.0)

ACR_SPAWN_RANDOM_RADIUS (determines the maximum distance from the spawn target for each child, with distance and direction determined randomly and individually for each spawn child- think like "scatter pattern". Spawn target center will be the waypoint location unless RANDOM_RANGE is set, above. Default = 2.0)

Both these seem to work excellently, now that I've fixed (yet again) the RandomFloat function. I like the 2.0 default on RANDOM_RADIUS just to give multiple spawns a bit of room, so they're not on top of each other, though 0.0 would spare CPU cycles slightly. Had to remember my trigonometry along the way to get these working, but it was easier than I feared.

I also discovered that the ACR_SPAWN_IN_DAY and ACR_SPAWN_OUT_DAY variables were only assigned to work in the context of a tenday, while our months have 28 days- this may have been intentional behaviour, but it limited our ability to schedule spawns. As such, I rejiggered things to allow 1-28 as a range here (had to allocate 5 bits each instead of the original 4 to accomodate). I can switch this back if there is a good reason to go by the tenday- I suppose maybe if people want their merchants to get "weekends" off? I really don't know how the tendays work against the 28-day months, but it's looking like we don't have space in the nTimes INT to reflect both tendays and days of month. In any case, making this switch got me through working out how Ronan mapped all the times and info into bitwise sections of a single integer, so they've illuminated me considerably on some of the finer points.

I also found some problems with one of the underlying conditional functions, which was causing our problems with hour/day/month spawns misfiring- that fixed, they seem to be working fine- they wait until the proper time to fire, and realize they should be despawning when they are supposed to. Haven't played much with the "circular" case for these (spawn in at 20:00, spawn out at 06:00), but at first glance it seems to be working.

Spawn Area heartbeats are being disabled whenever all PCs leave an area, and are correctly waiting for the delay defined in acf_spawn_i before trying to despawn all waypoints in the "inactive" area to free up memory.

Right now, the major sticking points are Despawning- the system knows when to despawn, but can't properly access the LocalObjectArray holding the pointers to the spawn children. The Array Length is returning as 0 whenever it tries to iterate through, removing the spawn children.

Also at issue: I don't see any implementation coded for spawn durations, though I could be overlooking it somewhere, needs more testing.

Finally, I need to write the death reporting function to keep a spawn waypoint informed of when it should consider respawning- doesn't look like that part of the system was ever finished.

[AcadiusLost]

Brief update, not much time spent on this tonight, but I did conquer the failed despawn bug: the problem was not with the object pointer arrays, but with the array index- it wasn't being incremented properly during the spawning phase, which was keeping the scripts from being able to parse through when it came time to start despawning the spawn children.

This experience in mind, I'll need to rewrite the DeathReport function.

also, it does seem that despawning, as currently implemented, is irrevocable, such that an 8:00 - 17:00 spawn might not come back on day 2- I'll look into that, may be something I've overlooked.

[AcadiusLost]

Allright, I've got spawns repopulating at reentry of an area despawned due to activity correctly, was just a matter of getting the despawning function to adjust the right bits so the area pseudoheartbeat knows what happened, once it starts back up again.

I also did some rewriting for the ACR_ReportSpawnDeath(), such that it should deactivate a spawn point when all the children have been killed (or start the "recharge delay" if appropriate).

We're fast approaching a point at which we'll have a few design decisions to make, I'll start a thread soliciting advice on them in the NWN2-ACR forum.

[AcadiusLost]

Cleared away a few more pesky bugs, confirmed that the SpawnInScripts are being called as we'd want them to be, and did some work on making my test mod into something more easily testable by others.

I've made it into 4 areas, linked by my Seamless ATs. I haven't enabled prespawning of the areas yet, but it would be pretty straightforward.

Added 4 "example" waypoints to the pallete, a Day-only spawn, a Night-only spawn, a random-spawn, and a static spawn. Will add a few more before I roll up a test mod for the tech ftp.

Lingering "quirks" of the system:
-delayed respawns do not seem to be coming back like they're supposed to. (instant respawns work fine, come back at the next spawn system heartbeat).
-values above 16 are not functioning for spawn by hour, or by day
-values above 8 are not functioning for spawn by month

Seems like we have 2 separate problems there, but neither is major. Should have them locked down in the next day or two.

[ç i p h é r]

Great. And be sure to commit your example waypoints to the repository as well (blueprints/waypoints) so we can bundle them in with relevant releases. No work shall be lost! (Well ok, unless it's shite )

Thanks AL.

[AcadiusLost]

Both bugs conquered. All the time-limited parameters are behaving, and respawn delays work regardless of whether any PCs are in the area at the time the timer runs out. Implementation is such that the spawn will reappear at the next spawn pseudoheartbeat after elapsing of the timer- meaning an "instant respawn" will still not be until the next heartbeat, but I expect that's acceptable.

I'll clean up some of the excessive debugging report spam, then commit the code this evening, also try to get the wiki edited to reflect the system in it's current state, and work on getting the test mod up on the tech FTP along with a few more sample spawn waypoint examples.

[Ronan]

Yikes, sorry about all that... Worst part is I'd corrected a lot of those problems, but hadn't committed the code. Then it took me forever to find the proper version, since I've got about 30 ALFA2-related mods over 10 NWN installs scattered throughout 1 PC and 2 laptops.

Please PM me if you get stuck on something or want me to work on something specific. I don't often check these forums, and probably won't be in chat or IG, but PMs pop out at me.

Just be sure and get those spawn group examples in the ABR... I'm proud of those, since even Twiggee say she could understand them

[AcadiusLost]

Ungh, I'd written my own spawn example waypoints, hope they'll suffice for now.


So, I've set up an ACR test mod, and am uploading it to the Tech FTP. It is unfortunately 24 meg RAR'd, as it includes four 32x32 areas so that the Seamless ATs can be tested alongside the spawn system.

RAR'ed with the mod is a small hak, called alfascripts_v0_1.hak: this contains some of the ACR code. The module itself has plenty of user-configurable acf_ scripts for events, though it's only a fraction of what we'll have in the real ALFA ABR. Note that the hak does not include any of our new 2da files or anything- this is just for testing and early mod development. Cipher plans to roll out a public release of this code once it's had a brief testing phase.

I've updated the wiki ACR2 Spawn System Manual to reflect the code in it's current state (in the acr test mod), so that will be a guide to playing around with it, and for builders who want to start designing spawn waypoints of their own ahead of time in their Beta areas.

That information is here: http://www.alandfaraway.org/docs/Technical/ACR2Spawn

Note that for respawns to work properly, spawned creatures need the acf_spawndeath.nss file in their OnDeath event (or an equivalent), in the module I've added c_chicken_acr and c_badger_acr which have this, but testers should feel free to add this to any spawned blueprints in the test mod. We will likely have a more official version of it by our public release.

Also note that spawn waypoints made by the DM client Creator won't function, as they need to be initialized OnModuleLoad currently. So- tweak in the toolset, test in the mod.

I've left some SendMessageToAllDMs reports in, to allow better bug reporting. Check the wiki for things that need testing, and guidance on how to use the many configurable prameters available.

[Ronan]

Ungh, I'd written my own spawn example waypoints, hope they'll suffice for now.

While I had a few spawn WPs, they were outdated. I ment spawn groups:
http://alfa-bmf.svn.sourceforge.net/vie ... xample.nss
http://alfa-bmf.svn.sourceforge.net/vie ... omplex.nss
Those were examples intended for people to learn on. It would be nice if people would submit some into the ABR, too.

Note that for respawns to work properly, spawned creatures need the acf_spawndeath.nss file in their OnDeath event (or an equivalent), in the module I've added c_chicken_acr and c_badger_acr which have this, but testers should feel free to add this to any spawned blueprints in the test mod. We will likely have a more official version of it by our public release.

Good point, I just added the spawn death hook in the NPC death event script.

You'll probably want to check to see if the object passed to ACR_OnNPCDeath() was actually spawned (ie, has a parent). Since its a "public" function, there is no telling with what error it could be called.[/url]