A Land Far Away

Thinking on static spawns content for Amn, and the idea is to use some kind of per-PC tagging to avoid the pitfall of "monster crops pop up on server areas once every day, and the first PC(s) to plow through them harvests the xpeez". Question is, how should this be done in an intended way with ALFA systems? The initial plan is to use a time variable per PC for each spawning area. There would be something like 10 to 30 areas total, leading to max of 10 to 30 variables on a PC. (Could plausibly be a vector, too, each area having its own index). The time would be the last time the PC was here, to be compared to current time. (So, if the time you were here the least time is less than X, suppress spawns). Preferably this would be RL time, not the game time, as server system time should be more reliable.

Any advice?

Sounds complicated Regarding the variables... I am generally against putting lots of variables on PCs, which inflates the size and they must carry around wherever they go.

Perhaps an alternative, store them as campaign / module variables locally?

Just FYI, the spawns we have been discussing in other locations... they never arbitrarily spawn. The waypoints are built with a percentage chance to appear (50% is default, can be changed), and this percentage is rerolled IIRC every 3 RL hours. If a spawn is killed, it will have another chance to respawn after 1-3 RL hours, at the base percentage. So there's never a guarantee they'll be there, only the statistical probabilities... but these timers can of course be changed.

Yeah, I know the basics of spawnpoints and the probabilities. As we discussed, the philosophy behind these spawns would be that the party crossing to this spawns kind of area (which is dedicated to this kind of thing in the module) is to reproduce what would happen with a party around a pnp table telling their DM that "we go to this area here on the map and look for monsters to fight, because of reasons". The module area represents a small representative fraction of the terrain, the combat map that the DM would whip up for the random encounter. The module area is not one particular ~500m x 500m piece of the landscape. And it's not representing the same area between visits. The spawn is the random encounter, being rolled on a table, and things such as PC skills factor in whether they manage to find anything in the first place.

So this encounter area should be available to different parties closely following one another. (The area might even be instanced, but for reasons of gameplay and RP the chances of PC parties running into each other should be increased all the way, so rather no instances.) The area should not be available to the same party grinding encounter after encounter, though (again, more for reasons of gameplay than verisimilitude). To make this happen, I figured the easiest is to use time stamps on PCs. I suppose local variables could be used on the spawnpoint, in pairs of PC - time, if you think that's better? If so, what is the best ID tag for a PC?

acr_time_i provides an unambiguous reference for how much real time has passed for purposes such as this. You would want to do something like ACR_GetRealHoursSinceStart and subtract the old time from the new time to arrive at your desired comparison.

All PCs have a unique ID assigned to them when they're first made; this would be the best way to unambiguously refer to them. I don't recall offhand where the call to get it is, as I may be at work right now, but acr_pps_i seems like an obvious place to start looking, if you want to work on this today.

Few things, though (sorry to bulletpoint this. It sounds like it would be cool to have, but I want to make sure that all the likely breakages are known before you get started):
-- Make sure you only save a time when something actually spawns, or you'll be making it so nothing ever spawns on sufficiently-active players (and thus be immune to inherent risk from their travel), which will mostly mean that the risk/reward scheme you had planned for any fedex-type quests will drop off pretty quickly.
-- You'll need a means to control the exploit this will expose (go to area; see spawn; leave area and wait for despawn; return to monster-free area to bask in the ease and loot any loot boxes contained therein).
-- You'll need to be cautious that there are failsafes against multiple spawns (this will be harder to test without a live server, as either your timer or correct spawn configuration could make there appear to be correctly-configured spawns, and if it's the former a second group could enter the area and murder the first)
-- You'll want to use your local SQL database to measure these times, as you won't accomplish your goal with locals (the locals will be killed as part of a restart, so people who logged on first would still get all of the XP, but they would have to wait before returning that reset). Putting them on the DMFI tool would "work," but it would also follow that character everywhere in ALFA (which I'd like to avoid, to keep things cleaner for the other servers to work against), and putting them on locals would "work," but just not the first time (and it would, thus, be a mechanic that works better if the Amn team isn't updating... which seems a cruddy sort of concern to add to the pile).


I'm not sure if tech has the resources to work with this one at the moment, but the idea of offering a "cooldown unique to character" flag sounds like it would be a good tool to offer every server. Trick is that the stuff above (really those first three) seems like it would be a difficult thing to add in. I'm not sure that the spawn system is meant to handle being treated so. If you do get something working, it might be worth adding to the ACR, though.

Potential minor work around for some of the issues could be to increment the variable on the scripts that fire when a creature is killed. Check if killed by PC (or PC created effect) if so bang his variable, however you wish to save it, up by one.

Spawn wise, I figure, they fire as apart of Onareaenter or something similar? It seems trivial to check whatever variable you store there.

That way, you cover the exploit of PC's waiting out an area (although they can do that now with many spawns since the % chance of spawn is recalculated every few RL hours).

A cruddy and inelegant but obvious solution would be storing said vars on some no drop\trade\sell weightless item. Assuming they are persistent?

Spawns do indeed work from area events, however, not all of them will process during the OnEnter event, so there's no garauntee that GetEnteringObject() will be the creature triggering the spawn (as that will return the last object to trigger an OnEnter event-- and it would thus provide seemingly-nonsensical output if a badger tripped a trap on the other side of the server between the AT and the spawn processing). You could cycle through the PCs online (for(object oChumpsAndChumpettes = GetFirstPC(); GetIsObjectValid(oChumpsAndChumpettes); oChumpsAndChumpettes = GetNextPC()) { if(GetArea(oChumpsAndChumpettes) == OBJECT_SELF) { /* stuff here */ } } ) -- with a little handling to make sure that you don't cause problems by fiddling with the same PC multiple times (which is pretty well promised to happen in such a scheme).

We could feasibly provide a hook for creature OnDeath-- and that one would probably be popular generall. If we had such a scheme, we would probably want to get the waypoint which spawned the creature that just died and save the hour of the kill to a variable constructed from some unique identifier on the waypoint combined with the slaying character's unique character ID (performed similarly with all members of the party) which may then be referenced when a future spawn is triggered.


Items should not be used as persistent variables, for numerous reasons.

Well, I'm not sure at all when I can get to work at this, but the design I had in mind is:
- These "monster hunting areas" are separate crevices from rest of the server backbone, covering known dangerous areas so that each module area is representative of "combat map" for encounters - ICly always a different place between visits. (So this logic won't be used to spawns at/near roads and stuff) There will be no more than 10 or so areas on the server using this logic. And each area is dedicated to the encounter it has (composed of several spawnpoints, maybe).
- PCs enter these areas to hunt monsters; If monsters get the initiative (determined by skill checks), they flee and PCs find nothing. (So the party of all heavy-armor tanks will very likely walk around wondering why it's all so empty)
http://www.giantitp.com/comics/oots0024.html
Would be a nice touch to do an additional skill check that the scout notices hints of something having fled them when scouting check for initiative fails.
- Every time the area is entered, a "master encounter logic" should kick in to control spawnpoints. (A typical setup might be to use 4 spawnpoints of a goblin, with (independent) 60% probability for each to spawn, to get a number of goblins between 0 and 4, with average on 2. So on top of this, the encounter logic determines "are any goblins found", and if yes, kick in the spawnpoints as normal.
- The encounter area should reset itself relatively quickly after one round of "master encounter logic" for the next party. (Say, 30mins)
- The encounter area should not reset itself for this party to have another go until after a much longer time (Say, 5 hours)

To this effect, my plan has been this:
- Use ALFA spawns with 30min respawn timer.
- Hook the "master encounter logic" on the on_spawn_in script. This script checks for conditions, and if not met, will remove the spawn(s). These conditions are:

• Party scout beats the check of appropriate skills. (Say, party leader is the dedicated scout, need to tell players ooc to arrange it so.)
• None of the PCs in the party have had an encounter here in the last 5 hours.
• The party has more than one PC. (Yes, we always say to everybody they should never solo spawns, so here's coding that in.)

- The encounter logic will need to use variables that are stored per encounter, and ID PCs that have been here and when. For example, skillchecks are made per party per encounter, so one check is made and the result stored for every spawnpoint to use. Perhaps store this on a waypoint of a particular name in the area? Server resets should be rare enough that if it resets encounters for every PC, it doesn't matter.

The hard part seems to be that when the spawns activate and these spaw_in_scripts run, to have the script determine "Am I the first script of my kind running for this encounter? If yes, set parameters on the local variable storage, and then check if I should remove myself. If not, check from local varaible store if I should remove myself." The checking and writing parameters needs to be done in an atomic block for this to work, so that the "yes" part runs only once.

As long as there's a safety check that spawns won't pop up right on top of PCs (this should exist in the ALFA spawnpoint logic), that should cover it, as I'm think right now at least...

A troublesome issue might be the PCs coming in, and how they are set as a party. It's plausible the encounter logic script runs before all party members have ATd into the area. There's also the cases of the players partying up or not, which might be solved by telling the players how to organize to tell their automated encounter helper script what they're doing. (Give players an error report if the PCs present are eligible for an encounter cooldown-wise, but two party leaders are found (no dedicated scout))

It's getting long, but here's one more thing to consider:
If the encounter is set up of several spawnpoints, (the upto 4 goblins above), AND we still want to randomize the position within the area, we need some though. Else odds are each goblin is far away from each other, easy pickings one by one (since spawnpoints determine random positions within their range independently). A very nice solution would be to be able to hook it to the AI: The encounter logic makes every hostile in the area run towards the PCs and attack (same as "switch faction hostile" in the DMFI interface, only not stopping pursuit after awhile). Then the party attacking the 2 goblins they saw might be surprised by 3 ogres running in from outside their detection range! So use those sneaks and try to scope the area before engaging!
(Run script every 6 seconds: Cycle through all PCs: find which of them are in combat, and if anyone is, then cycle through all creatures: if this creature is hostile and not in combat, pick a random target from PCs that are in combat, and attack.)

Riotnrdd, are your encounters run from a single spawnpoint?

Well, the project is not quite insignificant. But one of these days...

Another option that sprouted to mind: Actually use the already existing rest/recovery system! A PC can trigger one encouter of the "go that area and hunt for monsters" type per rest cycle. That would either need a logical local variable on the PC, or a list of PC ID tags on the module somewhere, of those who have exhausted their hunting encounter this rest cycle. And code to reset the flag upon resting. The definite bonus of the per-PC, global across encounter areas, -approach is that a party can't run a chain through different encounter locations any more than they can grind one location.

Current logic on the rest is that you are rested if offline for long enough since last login, and you need to wait 24 IG hours (~3.5 real hours) to rest the first time after login. Isn't it?

I'd remove the requirement for a party to be present to spawn. IMO there's a lot of fun in creeping around in dangerous areas, whether or not you kill stuff.... but I guess that's yours to decide. If people want to solo, they should be able to. If individuals farm they should be identified and engaged.

All of my encounters are based on ALFA spawn system. What I do for areas is decide how many viable spawn points there are, and then decide how many I want to appear in that area on average, depending on local conditions, area size, etc. So I might drop 5 spawn points at 20% chance in a single area, which means on average, one will be active at any given time, but rarely the same place (reduction of exploitable patterns).

Riotnrrd wrote: So I might drop 5 spawn points at 20% chance in a single area, which means on average, one will be active at any given time, but rarely the same place (reduction of exploitable patterns).

And each of these points have a large range and small scatter? (One "being active" does usually mean one group (or one encounter on the table, which might be 1 bear, or 4 goblins), not one creature?) If I get this right, then there should be a small chance of getting two points active and placed on top of each other (or so close that they are within detection range)? This might lead to having to fight 1 bear assisted by 4 goblins - but you might also get goblins attacking some NPCS!?

Or do you place down 5 points at spots relatively far away from each other, and then each spot has 20% chance of having a spawn right there?

t-ice wrote:And each of these points have a large range and small scatter?

optimal range and spread can vary, there are defaults in the waypoints but the variables can be changed.

(One "being active" does usually mean one group (or one encounter on the table, which might be 1 bear, or 4 goblins), not one creature?)

Correct. active by group, though sometimes the group CAN be a single creature.

If I get this right, then there should be a small chance of getting two points active and placed on top of each other (or so close that they are within detection range)? This might lead to having to fight 1 bear assisted by 4 goblins - but you might also get goblins attacking some NPCS!?

They are typically spawned well out of sight range of each other, and well away from ATs. Part of the design decision for an area... I generally avoid multiple spawn points in close proximity. But yes, if you do this, and a neutral and a hostile both spawn together... they will FIGHT!

Or do you place down 5 points at spots relatively far away from each other, and then each spot has 20% chance of having a spawn right there?

Yes

Ah, well, that's actually not so difficult then.


So, in your area enter stuff, you have some space. In that chunk, you can loop through a couple things: namely, you can loop through PCs and count how many are in the area (if it's 1, the area was empty, and needs to be reset-- remember that nwn2server is single threaded, and you can use that to your advantage) and you can loop through waypoints in the area and enable/disable them before the ACR spawn system gets to them.

OBJECT_SELF is going to be the area-- so you can have data stored on a per-area basis (get the character's unique ID and append that to a prefix for your variables), which won't carry over resets and won't muddy up the character files, with the warnings (above) that this won't be a very good control around server resets/updates, because all locals will be cleared out as part of that process: but if that's good enough to make you happy with your server, I say huzzah.


// edit: if these areas don't have a custom OnEnter script, should totally make one. Obviously we don't want all of this extra code running in areas that won't behave differently. Just make sure that you're calling the ACR stuff, too.

// edit edit: and make sure that there are no returns before the ACR stuff runs; all code paths must reach it.

Sounds very interesting. Please share anything you develop.

Remember you can also use the NWN2 "encounter" or place triggers on the floor and go through an "on enter" type script for that. Just make a doughnut type shape around the entry way point.

Thanks for the pointers and help guys! (Esp. Zelk for the quite detailed expert advice) I'll let you know what develops. I don't have a ton of time, but I'm motivated to go at it now when I do get some.