Preferences for Spawn System features?

[AcadiusLost]

As it turns out, I don't have posting rights to the NWN2/ACR forum (was the NWN2 Technical forum before, used to have access, but I guess now things got reshuffled in the "Forum Revamp".

So I'll pose these here:

#1: Spawn by Day: this is for the ability to make waypoint that will spawn it's child(ren) on day X, and depawn them again on day Y. It takes integers, Ronan had it coded to work on a tenday, meaning if you chose 1 and 3, the spawns would be present from the 1st-3rd, then 11th-13th, 21st-23rd. At least, I think that's what he was trying to do. For time being I've got it working on the 28-day Faerunian month, meaning spawn 1-3 will only be on days 1-3, of each month.

If you could only have one or the other, would you have a preference? Should it be a priority to change? With the tenday thing I may have to do some more complex coding to make it work reliably, the 28-day deal works currently.


#2: Spawn Attrition. If a spawn point randomly generates a group of 12 orcs, and players pick off three of them before escaping, the current spawn system will leave the spawn group as is for a while (as defined by a constant, configurable on a per-server basis)- however, at the end of that time, the point will despawn, along with it's "children". We have controls for number of times a spawn point can be cleared/killed off, but currently it would end up fully "recharging" every time, so long as at least one spawned "child" of the spawn point survived. Is this an acceptable behaviour? As we have it now, when the point despawns due to area inactivity, the replacement spawn is a fresh start, on all random variables including number and such. It seems to me going much beyond this is getting into the idea of creature population tracking, which is its own can of worms. Thoughts on this?

[indio]

99% of my time based spawning is to spawn in commoners in towns and taverns based on the hour of the day. So neither monthly nor tenday spawns help me. Hour-based spawns will. In NESS this was DO (Day Only) and NO (Night Only).

Spawn attrition does mean population tracking, and we can ill-afford anything like that imo. If a child lives and then the PCs leave that area, that spawn gets reset to full, every time.

[White Warlock]

Access provided to tech staff, moved thread to ACR forum

[Thangorn]

The key feature I'd like to see is one I worked on with NESS a bit..

* Encounter table type spawn generation.

One spawn point or group of area spawns able to randomly reproduce spawn groups of mixed composition, something like the following example -:

1. 2-12 orcs + 1 orc shaman + 1 leader
2. 2 weretigers
3. 2-20 goblins + 1-2 witchdoctors + 1 leader
4. 2-8 ghouls + 1-2 ghasts
...... etc.

your spawn attrition idea above is also very important to making this system work nicely.

I got close to be able to do it working with Sareena's old NESS spawn system but mixed groups never worked with the degree of accuracy I needed (ie. you could spawn a whole group of orc leaders or a mixed group of normal orcs and leaders, but not a group with just 1 leader as shown above)

night/day specific spawn group tables using this system would be preferable aswell. It'd also be important to figure out how long a character would need to be out of the area before a new "reroll" would be required on the spawn group table.

Similarly

* I'd like to see mutually exclusive spawning set up (another toughie) so you can have a bar or town spawn point which can spawn a bunch of NPCs and as part of the possible children are a bunch of unique one-off characters that if one of them randomly spawns in a group, then another one does not spawn in the same instance of the spawn group.

I'm sure theres other things I can think of, I'll post more when I am more awake.

[ç i p h é r]

#1: Spawn by Day: this is for the ability to make waypoint that will spawn it's child(ren) on day X, and depawn them again on day Y. It takes integers, Ronan had it coded to work on a tenday, meaning if you chose 1 and 3, the spawns would be present from the 1st-3rd, then 11th-13th, 21st-23rd. At least, I think that's what he was trying to do. For time being I've got it working on the 28-day Faerunian month, meaning spawn 1-3 will only be on days 1-3, of each month.

If you could only have one or the other, would you have a preference? Should it be a priority to change? With the tenday thing I may have to do some more complex coding to make it work reliably, the 28-day deal works currently.

I prefer your 28 day approach. It's more intuitive so requires less explanation.

#2: Spawn Attrition.

As we have it now, when the point despawns due to area inactivity, the replacement spawn is a fresh start, on all random variables including number and such. It seems to me going much beyond this is getting into the idea of creature population tracking, which is its own can of worms. Thoughts on this?

I don't have a problem deferring this until later, but I do think that population tracking is important for limiting spawn farmability and eventually for creating a truly dynamic spawning system (ie. orcs are wiped out, lizardmen move in - could be random, could be terrain dependent, could be race based - harmony/opposition - etc).

[AcadiusLost]

To address indio's comments:

Spawning by hour is in as well, and seems to be working, though the "circular case" may bear some more testing. So for a "day only" spawn, you'd set ACR_SPAWN_IN_HOUR to 6 or 7, and ACR_SPAWN_OUT_HOUR to 18 or 20. For "night only" spawns, the system should work in a circular fashion, so if you set ACR_SPAWN_IN_HOUR to 22, and ACR_SPAWN_OUT_HOUR to 5, it should give you that behaviour. The added plus is you don't have the behaviour of every single spawn changing a 6:00, instead you can tweak some to be early risers, some a bit later.

Thangorn:

The Spawn system as it is now, can do a pretty close approximation of your "mixed group" intentions: here's how it works:

ACR_SPAWN_RESREF_1 = "goblin_shaman"
ACR_SPAWN_RESREF_2 = "goblin_lieutenant"
ACR_SPAWN_RANDOM_RESREF_1 = "goblin_warrior"
ACR_SPAWN_RANDOM_RESREF_2 = "goblin_warrior"
ACR_SPAWN_RANDOM_RESREF_3 = "goblin_slinger"
ACR_SPAWN_NUM_MIN = 4
ACR_SPAWN_NUM_MAX = 6

This would spawn a group that will always include a shaman and a lieutenant, along with 4-6 others, with warriors outnumbering slingers 2:1.

Additionally, you can set the following:

ACR_SPAWN_RANDOM_RANGE = 100.0
ACR_SPAWN_RANDOM_RADIUS = 12.5

This would mean the group could appear centered on a point up to 100.0 from the waypoint, randomly determined. When they spawn in, the group will be "scattered" by up to 12.5 in every direction, allowing you to make a closely-grouped camp or a natural scatter of ambient wildlife.


with regards to the spawn attrition: right now the default despawn time is about 4 minutes, meaning if a party wears down a spawned group, backs off to heal and rebuff, etc- they will find the same opponents remaining so long as the area doesn't remain inactive for 4 continuous minutes - if it does, then the spawn will reset, potentially changing position and numbers. It's something we'll probably have to see in beta to get a good sense for- we can start by extending the 4-minute window, and see if there are any performance hits.

[ç i p h é r]

with regards to the spawn attrition: right now the default despawn time is about 4 minutes, meaning if a party wears down a spawned group, backs off to heal and rebuff, etc- they will find the same opponents remaining so long as the area doesn't remain inactive for 4 continuous minutes - if it does, then the spawn will reset, potentially changing position and numbers. It's something we'll probably have to see in beta to get a good sense for- we can start by extending the 4-minute window, and see if there are any performance hits.

Ah. I've always thought that if a party gets to rest and heal/rebuff, then so should the critters/NPCs they left behind. A "rest" is technically the passing of at least a day.

[indio]

Thanks Acadius.

I have to say I'm very impressed and grateful. Cereborn used to operate in a similar way while developing our version of NESS. Regular updates, opportunities for feedback, always progressing. Good show.

[Thangorn]

The Spawn system as it is now, can do a pretty close approximation of your "mixed group" intentions

That all seems really easy to implement. I should be able to test it all out as soon as I get this beta1 build sewn up in the next couple weeks.

So how about different, randomly selected mixed groups referenced from the one spawn point? or one-off unique random spawns referenced from within a group?

thanks AL

[indio]

AL, any chance of getting hold of a test system? I simply want to be able to spawn commoners in during the day and despawn them at night so I can begin our beta. Also, it might help you if someone else is able to check things out during development.

[AcadiusLost]

Sorry, had a busy friday and was gone all saturday for a tournament- just trying to get the bugs worked out of the hourly spawning, then I'll put the test system up - right now it's improperly reading spawn in and spawn out times if they are >15, so your standard day and night spawns tend to not work like they're supposed to, yet.

I'm hopeful to have it on the tech ftp in a matter of hours, though.

[indio]

Excellent. Can you PM me the details for the tech FTP, or simply a copy of the files, or are they available only to tech staff, or what do I need to do to get access? No clue.

I ask this because the links Ronan posted in the ABR release thread above no longer work, presumably because he was hosting his own ftp.

[Ronan]

The spawn in/out "days" are supposed to be days of the tenday, in the original spawn system spec. The "months" are then months of the year the spawn should be active in (I don't expect these to be used, unless we have some sort of seasonal system with persistant time, but it was trivial to add).

Given how time passes IG, I thought spawning in and out based on days of the tenday and hours of the day would be used the most. Most people in Faerun work every day out of a ride (and so would probably spawn in the same spots) but some don't.

However, the code as it is is bugged, since GetCalendarDay() returns the day of the month (oops).

The specs of the system, ie the results of the previous threads discussing spawn features, are listed here, though there are likely some inconsistances between the manual and the code:
http://www.alandfaraway.org/docs/Technical/ACR2Spawn

By the way, I did find the latest version of the spawn system I had done and uploaded it to the repository, with a test mod and notes on how it differs from the last version. Most of the changes aren't "critical", except for one: You must have the spawn point initialization done in DelayCommands() like this other version does, and I'd recommend keeping the error reporting which detects possible dropped DelayCommands() (though I've never actually witnessed this happening, even when I tested with an absurd number of spawn points). Otherwise a TMI will kill the initialization, iirc after only a few hundred spawn points.

Indio, I believe the FTP was Bool's.

[AcadiusLost]

Since I've made extensive changes based on the 6/6/06 committed code, I'll look at potentially rolling fixes/changes from your more recent code back in with a later update most likely. The version I've got inhand (will be committed tonight) works for most all of the parameters, plus a few more (randomized positions) besides. I'll have to edit the wiki to bring it in line with what I've got ready as well, should have that done by tomorrow sometime I expect.

With regards to the Spawn By Day, I had it changed to be day of the month and working before I realized where you were trying to go with it- I believe I posted the question above, and folks generally liked the more intuitive day of the month implementation better, though there is no fundamental reason we couldn't return to the former one if it's preferred. With the "day of the tenday" approach, how were you planning to handle the fact that the months have 28 days, meaning day "1" of month 2, is actually still part of the third tenday? Just use ACR_GetGameDaysSinceStart? I see the utility in being able to make NPCs who spawn for a significant number of the days, punctuated by periods of nonspawning, but for practical purposes, after month one players and DMs are likely going to have a hard time working out when tenday spawns should be active and when they shouldn't be.

The second change I noticed in the comments on your updated code was the persistence of spawned children, even across area despawning due to inactivity timeout- I'd considered the problem and discussed it in brief, but the thought was that if the PCs have been gone long enough to let the area despawn, the spawns may well have had a chance to get reinforcements, move on, etc. Adds some unpredictability to the system- but also opens the door for certain sorts of OOC exploits. I'm not set on either implementation- generally the shorter the despawn timer is, the more persistence of the children makes sense. So we may let performance be our guide in this- or even make it another option on the waypoint, if the systems can cooexist.

[Ronan]

I'd figured you'd made a lot of changes, but didn't think it would hurt to post the code. Oh, I did forget to mention you should probably test with the spawn groups I uploaded too, since I'm not sure if those were posted anywhere but in the forums before. Their code works, but of course its possible additional changes to the spawn system could break them.

I wanted day of the tenday over day of the month because I thought that is what builders would use more often. But I don't think its possible in NWN2 (I haven't kept up with recent NWN2 patches though) without some more coding of our own. Something like ACR_GetDayOfTenday() in acr_time.nss might be nice, for player emote-ball-like tools to tell the player what day it is. Actually, I'll add that. I like the idea of players being able to tell more immediate time (ie, hour, day) more precisely than longer time periods (tenday, month, year) in our weird bizzaro-world-time.

How long a spawn point stays active depends on the variables set (which can be extremely random). The purpose of saving despawned (but not deactivated) spawn points was to make it look like (to the player) spawns which should persist actually persist. For example, a goblin camp should stay active for a IG day or so regardless of whether or not the spawn system must despawn the area for performance reasons. Overall the idea was to make the spawn system seem more natural and unpredictable, with possibilities of things like a player encounting a goblin camp just before they pack up and leave. The downside is of course more overhead, the system basically tracks the activity of every spawn point in the module, albiet rather sporatically. IIRC when I tested it, the overhead was still nothing like NESS's.

I made a big error in the original code when I distinguished spawn point activity from whether or not it was spawned. Then I realized I couldn't despawn a point and have it still active unless I'd stored its state Its a logical bug which probably annoys me more than it would an actual user, unless we end up having to despawn areas relatively quickly for performance reasons.

If you do want to merge the new spawn tracking code, I can try and point out which functions changed.