Spawnpoints & Encounter logic. Local variables & PC tags.

For toolset tutorials as well as question and answers.
t-ice
Dungeon Master
Posts: 2106
Joined: Fri Apr 17, 2009 6:24 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by t-ice »

Weighing my options in light of Zelk's advice above... Arrived at this thought:

Instead of a per-encounter cooldown, I could use a per-PC "fatigue" counter, which will be reset by the resting system. The big difference is that the cooldown would be global (=server-wide) across these hunting encouters. So it would pertain to chaining through encounters the same as hitting one repeatedly. (Because apparently running gauntlet over a server to exterminate spawns is a thing.)

Regardless of how that's done, some things I keep rattling my brain about:

If I use a on_enter script to determine whether to activate the spawnpoints for this party, and those spawnpoints are set to respawn after, say 20mins, then I need to de-activate the spawnpoints from respawning after they've been fired once, and until an appropriate party walking into the area re-activates them. Otherwise the first party could RP for 20mins in the area, and in spawns another encounter.

I also need to figure a way to prevent using a split party to circumvent the cooldown. If I use the area exit script, can I use the same "only 1 PC in area" condition to check that this PC was the last one to leave, and now the area is empty?
Zelknolf
Chosen of Forumamus, God of Forums
Posts: 6139
Joined: Tue Jul 05, 2005 7:04 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by Zelknolf »

You might want to hold off if you want a global response to killing stuff; we do have concepts for global / cross-server farming controls in the design phase now, and you might end up making something redundant-- or make something that 'stacks' with a coming ACR system to make your server the hateful/miserly ones.


Also, that does seem like it would present a struggle in verisimilitude. "There are no gnolls in this area because I just killed the gnolls here yesterday" is easy to RP against, even if someone else found gnolls later ("Oh, maybe they weren't gone; maybe they were just scared of me. They just watched me brutally murder their families... y'know... a day ago. And the fight was laughably one-sided."); "There are no giants in this area because I just killed two goblin clans 50 miles away" seems like it would be a struggle. It could probably be chalked up to chance the first few times, but it's hard to act like patterns don't exist when they do. Though if this only applies to special offshoot "kill stuff here" areas, there at least wouldn't be any exploits (e.g. "kill goblins as a means to safely travel through more dangerous areas").
t-ice
Dungeon Master
Posts: 2106
Joined: Fri Apr 17, 2009 6:24 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by t-ice »

Zelknolf wrote:"There are no giants in this area because I just killed two goblin clans 50 miles away" seems like it would be a struggle.
Not really. The encounter represents the party telling the DM they "hunt this general area for monsters". This is an activity that is obviously time and energy consuming. So the behind-the-scenes hunting, which the party ICly attempts when then party ATs into the encounter area, returns to the party the message, eg: "Hytit Hardor is too tired to follow the party on this hunt." (You know, because he killed two goblins clans 50 miles away today already.)

Then the party ATs to the area without monsters, and if Hytit is the only one who got too many "fatigue" points, the rest of the party can RP saying goodbye to him. The all-fresh-PCs-party can then AT back to the world map, and back to the encounter area again, to successfully attempt the hunt. And the party is given the message: "You hunt for monsters in this area, Ranger Smith scouts for the party." The module area is supposed to represent a different piece of terrain in that general area every time it is entered, after all. (The combat map the DM places before the party going random encounter hunting)

But you are correct in that the intent here is overlapping with any global xp dimret system. And could lead to bad things. The obvious downside is that it shuts down content before a player who wants to play. But any cooldown always does that, and grinding one encounter over and over is about as bad as riding a cycle-through-all-hunting-encounter round across the server...
Zelknolf
Chosen of Forumamus, God of Forums
Posts: 6139
Joined: Tue Jul 05, 2005 7:04 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by Zelknolf »

Fair enough-- I suppose proceed with the frame that we could potentially be looking at a "You're too tired to learn anything from fighting more stuff, and are too bleary-eyed to do an effective job of searching for valuables" down the road, and the goal of that proposal is to craft incentives and rewards such that either no one will want to farm or no one will care if people do (while purely producing the latter would be superior, pragmatism says that accomplishing the latter will do the former to at least some players).
t-ice
Dungeon Master
Posts: 2106
Joined: Fri Apr 17, 2009 6:24 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by t-ice »

Okay, hopefully I will have some time to try to code this thing over the weekend. The only way to prevent cheating the system I can think of is to reserve the grounds for one party at a time. Unfortunately that means no PC parties running into each other, but oh well. Currently the plan, in meta-code, is:

-Data is stored as locals on area, includes a list of when was each PC here last, and a list of PCs in the party that currently is using this area.
-Scouting check skill DC to find quarry in this area is stored as a local variable on the area in the toolset.
OnAreaEnter script is the main logic:

Code: Select all

[*]Check is the area is empty.
- If the area is not empty, check if the incoming PC is on the current party list. 
   - If not, port PC to area exit waypoint on world map, send message to player and terminate.
   - If yes, terminate.
-If area is empty, check if incoming party has a PCs who has hunted here too recently, or is a party of one.
   - If yes, port PC to area exit waypoint on world map, send message to player and terminate.
    -If no the party can hunt. Make a list of all PCs in party. Save list as the current hunting party. For each PC, save the current time as the last they were here.
     Send message to each PC in party.
[*]The party leader, the designated scout, does skills check against the DC of finding quarry
- If fail, loop through all alfa creature spawn waypoints in area, and set on the alfa spawn system deactivation flag
- If success, loop through the same, and set off the alfa spawn system deactivation flag

-Spawnpoints are set to very rapid respawn (say, 10mins), but after spawning once, they run a script that sets the deactivation flag on. So they will need another succesful scout check to spawn again.
-After the scouting check is made, a script is activated that keeps periodically checking whether the area is empty of PCs. If area is empty, the script wipes the list of current PCs, and shuts itself down.
The area is now ready to host another party.

The main downside is that a party of 4 could split to 2 parties of 2, and get a total of twice the number of spawns - assuming there are 2 competent scouts. Will have to think of this...

The script that keeps on periodically checking whether the area is empty I am unsure of... can that be done effectively? The purpose of not doing that on the OnExit script is to keep robust against players logging while in the area.
The spawn waypoint shutting itself down after spawning once should be simple enough? (set local on object_self?)

Further development would be to tie a separate scouting skillcheck to a placeable spawning waypoint. The placeable would act as AT to a cave interior that has another round of spawns: "You found what seems to be a inhabited cave!"

Help? Advice? Ideas?
Zelknolf
Chosen of Forumamus, God of Forums
Posts: 6139
Joined: Tue Jul 05, 2005 7:04 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by Zelknolf »

Might take a look at our area instancing stuff, rather than checking out areas for use by PC parties.

The first bit of logic would change to:
-- Is the party already in an instance of the area?
---- If so, go there.
---- If not, make one.



Also a fun use case to handle: what do we do if a dirty dirty farmer joins the party after the area is created? Probably not an end-of-the-world loophole if it stays in, but that'd be a hard to catch and it would be harder to substantiate any grumps about players doing it (as the system's guts wouldn't be terribly visible to your average player-- and the ignorance argument has carried the day in cases when it would have been far easier for a player to know that things were wrong).


// eeeeeedit:
Also, you don't need to check periodically. You need to check when people are ATing. If you go instances, keep a list on your prototype area's variables; if you're feeling bold, go CLR and make a collection. If not,

Code: Select all

int output = 0;
for(count = 1; object area = GetLocalObject(OBJECT_SELF, "AREA_INSTANCE_"+IntToString(count)); GetIsObjectValid(area)) { output = count; }
output++;
string sVar = "AREA_INSTANCE_"+IntToString(output);
/* Then you'd make your instance here, and save the area object as a local object with the name sVar */
t-ice
Dungeon Master
Posts: 2106
Joined: Fri Apr 17, 2009 6:24 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by t-ice »

Zelknolf wrote:Might take a look at our area instancing stuff, rather than checking out areas for use by PC parties..
That does sound like the tech savvy thing to do. However I'm already over my head in learning new things, and would maybe rather avoid the project creep for now. Given our player densities, and that these areas are supposed to be a handful to choose between, the use case of overlapping parties seems unfortunately rare to me.

So I'd put this as the third phase in this development: After we have working exterior-interior pairs working as deny-others-while-active "encounters" (that can be extended down caves), then maybe start thinking about making instances out of an array of prototype areas, so that any number of areas can be joined as one encounter instance?
Zelknolf wrote: Also a fun use case to handle: what do we do if a dirty dirty farmer joins the party after the area is created? .
That's why the plan is to take a snapshot of the party when the "encounter" is created, and save that, and compare to that. So party composition only matters in the instant of arriving to the scene. Late arrivers are forcibly ejected. So the dirty farmer could get XP for the kills, I suppose, even while he is not in the area. But that is what happens even now if dirty farmers create a party with members on different corners of the server, hunting different spawns?
Zelknolf wrote: // eeeeeedit:
Also, you don't need to check periodically. You need to check when people are ATing.
I would do that on AreaOnExit, but I figured it would be messed over if people log out while in the area (say, due to crash or ignorance)? Also, DM ports so can't check on using AT, but I figured AreaOnExit runs even if ported. Not sure on logout?
Zelknolf
Chosen of Forumamus, God of Forums
Posts: 6139
Joined: Tue Jul 05, 2005 7:04 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by Zelknolf »

Gotta be in the same area to get combat XP; if you have special funny quest awards, you can use the same check that you're using to eject people to determine whether to run your quest script on 'em.

For area transtion, don't maintain a count on the area-- recheck for the area when people try to enter.

Code: Select all

object player = GetFirstPC(1);
while(GetIsObjectValid(player))
{
    if(GetArea(player) == OBJECT_SELF)
    {
        // Can count players here, or just break and note that the area is occupied.
    }
    player = GetNextPC(1);
}
It's a pretty cheap check to make; not as cheap as reading a local variable, but at least it's reliable.
t-ice
Dungeon Master
Posts: 2106
Joined: Fri Apr 17, 2009 6:24 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by t-ice »

Yeah, on second thought I guess you're right that I dont actually need a separate "area occupied" flag or a reset check.
Ronan
Dungeon Master
Posts: 4611
Joined: Sun Feb 20, 2005 9:48 am

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by Ronan »

If someone can summarize the desired spawn functionality in a single post, I can see about it being incorporated into the spawn system. Sorry but I don't have time to read through all this.
t-ice
Dungeon Master
Posts: 2106
Joined: Fri Apr 17, 2009 6:24 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by t-ice »

Ronan wrote:If someone can summarize the desired spawn functionality in a single post, I can see about it being incorporated into the spawn system. Sorry but I don't have time to read through all this.
The summary is: "Simulate what happens in pnp when the party tells the DM they go hunting for monsters in that area there *points map*" (These geographical areas being much larger than 100 NWN2 areas could cover. Like "Cloakwood" or "Northern Cloud Peaks") So then:
1) Party uses scouting skill to determine what they find (if anything)
2) Party is shunted to what stands as a random combat map of appropriate terrain.
3) Party is tired after being victorious and must go rest before having another go.

And the whole things works with logic of instances: The next party could follow to the same geographical area right after the first, or even at the same time, and what the second finds isn't anyhow affected by what the first did. To start with for technical and coding ability reasons I'm planning on not instances but reserving the area to one party at a time.

So the point is to turn the "wilderness areas as persistent spawn farms with a spawn every X hours that any PC can walk in and kill" -idea on its head. Because the IC world has enough wilderness that when a party goes random monster hunting it doesn't matter what the other PCs in the game have done in the past day. But every PC has a limit how much they can hunt before they go tired. Or in other words, whether respawns happen or not depends on who's looking. Specifically on how long since these PCs where here last, and how good these PCs are at the appropriate skills.

I'm working to code a system. Review of the logic, and advice if and when I get confused and ask here, would be much appreciated. This is a relatively complex one for a first real project on nwnscript, but here goes...
t-ice
Dungeon Master
Posts: 2106
Joined: Fri Apr 17, 2009 6:24 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by t-ice »

Issues I'd need help with so far:
1) How to tag and refer to PCs best?
2) In a OnAreaEnter script, if OBJECT_SELF refers to the area, how do I get the PC object that is entering?
3) How to port a PC to a given waypoint? (I can't figure how to set the subject of the "{Action}JumpToLocation(Location)" script. And what's the point with and without that "Action"?)
4) In GetIsSkillSuccessful script, nskill is the skill to use. Where is the table that maps those integers to our skills?
Zelknolf
Chosen of Forumamus, God of Forums
Posts: 6139
Joined: Tue Jul 05, 2005 7:04 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by Zelknolf »

t-ice wrote:Issues I'd need help with so far:
1) How to tag and refer to PCs best?
include "acr_pps_i" and call ACR_GetCharacterID(object oPC)
2) In a OnAreaEnter script, if OBJECT_SELF refers to the area, how do I get the PC object that is entering?
GetEnteringObject will give you the last object to enter anything in the module. Inside of an OnAreaEnter event, it will reliably be the PC who just ATed.
3) How to port a PC to a given waypoint? (I can't figure how to set the subject of the "{Action}JumpToLocation(Location)" script. And what's the point with and without that "Action"?)
AssignCommand(oSomeDude, JumpToLocation(lSomePlace));

// Edit-- but if you're doing this, do this in the AreaTransition event, not the AreaEnter event; bad things happen if you jump people while they're loading areas.
4) In GetIsSkillSuccessful script, nskill is the skill to use. Where is the table that maps those integers to our skills?
You'll want to use constants whenever possible, for readability and ease of updating. acr_i contains the constants you're looking for (I think you'll inherit it with acr_pps_i but if you don't, it can be included separately).
t-ice
Dungeon Master
Posts: 2106
Joined: Fri Apr 17, 2009 6:24 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by t-ice »

Thanks Zelk!
Zelknolf wrote:
3) How to port a PC to a given waypoint? (I can't figure how to set the subject of the "{Action}JumpToLocation(Location)" script. And what's the point with and without that "Action"?)
AssignCommand(oSomeDude, JumpToLocation(lSomePlace));

// Edit-- but if you're doing this, do this in the AreaTransition event, not the AreaEnter event; bad things happen if you jump people while they're loading areas.
Ok. Could I have a how-to on that, please? Currently I have the OnAreEnter script, which determines that "this PC cannot AT to the area at this time" and then goes "So I will force a port of this PC to the area exit waypoint on the World Map, and send him a message to let him know what's the problem". So ... where and how should I do that port if just putting that AssignCommand(...JumptoLocation) into the OnAreaEnter script is bad(tm)?
Zelknolf
Chosen of Forumamus, God of Forums
Posts: 6139
Joined: Tue Jul 05, 2005 7:04 pm

Re: Spawnpoints & Encounter logic. Local variables & PC tags

Post by Zelknolf »

Check your object that you're using to transition into the area (my guess is that you have a trigger?)

On the trigger's events, look for the On Click event-- in there, you'll probably find something like this:

Code: Select all

void main()
{
    ACR_TriggerOnClick();

    // Custom code goes here.
}
This is where we run the actual guts of an area transition (inside of ACR_TriggerOnClick), and you can send a person somewhere else by handling the area transition before calling into the ACR and returning early.
e.g.

Code: Select all

void main()
{
    object oPlayer = GetEnteringObject();
    switch(d3(1))
    {
        case 1: AssignCommand(oPlayer, JumpToLocation(GetLocation(GetObjectByTag("place_1")))); return;
        case 2: AssignCommand(oPlayer, JumpToLocation(GetLocation(GetObjectByTag("place_1")))); return;
    }
    ACR_TriggerOnClick();

    // Custom code goes here.
}
(but it would obviously need to be a little more complex than that; you can have a look in ACR_TriggerOnClick inside of acr_trigger_i to see the usual area transition handling: we typically allow spot checks to see if you're about to be ganked (which it sounds like you're running a version of anyway) and the custom loading screens require some script callins.

There's some maintenance implications there (namely, if the ACR starts doing something that must happen inside of every area transition, you'll have to update here), but if you do it inside of the AreaEnter event, there's no garauntee that the character object will have a valid location to jump from.


Alternatively, you could wait for PCs to load inside of the area and then jump them. I don't think that'll be any easier, though.
Locked