Spawning/Encounter Methods?

[Legacy_Vhaeraun Baenre]

                I am currently building a PW and i've just been using the standard toolset encounter system for my spawns. The problem is that it seems to not be very efficient and lags incredibly when spawning in some encounters.

 In order to place certain monsters in strategic locations I often have 2 or more encounters stacked on top of eachother with spawn points where I want them to spawn at. This only adds to the encounter spawn lag and I was wondering if there was a better way to do this? I know of NESS but the system doesn't quite do what I would like it to. ffbj has a nice random spawner but in most situations I would like total control over what and where the monsters spawn.

 Im running on a VERY high end machine and just test playing my module as a single player game it lags like crazy when I trigger some encounters. I cant imagine this being a good thing once the PW is up and running online and 10-40 players are playing at the same time triggering encounters constantly.

 Is there a simple fix to this? Maybe im just not caching the right encounter script or something? Any help/suggestions are appreciated.. I have already populated several entire areas with the default encounter system and would hate to have to redo them all... but it would be even worse if I had a somewhat finished/releasable PW and it was unplayable because of all of the lag.


 Thanks
               
               

               

                     Modifié par Vhaeraun Baenre, 24 décembre 2010 - 07:03 .
                     
                  

            

[Legacy_FunkySwerve]

               Stacking encounter triggers has no real direct effect on encounter spawn, other than the increased number of spawns popping at once, though if you aren't careful in stacking them players will be able to 'creep spawn' them, triggering only one at a time.

If NESS and the other Vault systems aren't doing what you want, you're likely going to wind up coding your own. The bioware encounter system has too many limitations, and there's enough ways to set one up to make any other system likely to work at least somewhat differently than you'd prefer. Plus, their complexity can vary widely, but the level of coding required to do one is not so great as to exlude any determined builder. That said, though I haven't used it, I've heard good things about NESS and it's flexibility, so if you can't make it do what you want, the chance are good you'll need your own setup.

All that being on the table, your spawn system is likely the smallest, and probably a negligible component of, spawn lag. There are a couple of things that contribute far more. A major part is graphics lag - especially if you're popping a lot of critters on a party. This can get so bad that sometimes a monster or two simply won't render properly the first time for a client (often it will be a different critter or critters for different clients, while some clients will see them all anyway), when you get to larger spawn sizes (8-15, varies from setup to setup, loose guideline only). This can be particularly exacerbated by dynamic models wearing a lot of gear. Then, there's the server-side compenent - largely caused by CreateObject, a relatively expensive call. Again, creatures with a lot of gear/loot, rendered or otherwise, are going to exacerbate this - one good reason among several to spawn loot on death, if you have critters dropping it. Third, and likely a non-issue unless you're using custom spawn scripts, is lag from onspawn code. That typically isn't a factor, but we managed to add enough that it - very counterintuitively - increased the rate at which clients were getting invisible creatures caused by failed rendering, indicating that the serverside aspect of rendering for a client - streaming data to them - is perhaps heftier than one might otherwise suspect.

In any event, ALL of these issues can happen even on very high-end machines - NWN is apparently old enough that newer graphics cards are ill-suited for it, in many cases. Even when you split the tasks of server and client on different high-end machines, spawn lag isn't terribly hard to accomplish, no matter the encounter system.

Solutions?
1) Use dynamic models intelligently. If you really need to spawn in 10 custom creatures in a spawn, all with a different weapon, shield, cloak, helm, and armor model to render, go ahead - but consider staggering the spawns on a small delay.

2) Figure out the max typical spawn size your system can handle without lagging, using another computer as client, if you can. Likely this number will be quite large, but it's good to benchmark it, and to remember that that number will decrease as more players log in and consume server resources. You can use this to figure out just how many you should spawn before staggering on a delay.

3) Corollary to 2, figure out how many spawns your server can have going in an area, and plan your area encounters accordingly. Obviously, it's better if you're able to balance incentives against danger to prevent players from mass-spawning areas, but that can be quite difficult, as players can be quite clever when it comes to managing risk. In some areas, we resort to spawn capping, preventing more than 2 or 3 encounter triggers from firing at once, to keep down spawn/combat lag. I think NESS has that capability as well, and you'll likely want it should you write a system of your own. If your system is high end, this number will likely be 100 creatures or more with a party of 10 in the area. The number of players is a major factor in this calculation, because each additional client adds more action to track for the server, as well as another client to stream to. Simply having a large number of players in a single area can make a server lag enormously.

Funky
               
               

               

                     Modifié par FunkySwerve, 24 décembre 2010 - 08:20 .
                     
                  

            

[Legacy_kalbaern]

               I agree with what Funky has said though I still use the Bioware triggers myself. Mainly because they are simpler to adjust and place for the average builder and I work on several cooperative projects with others. The keys I've found to using them are as follows.

- Either place triggers well in advance or drawn large enough that a party spawns creatures out of their line of sight. This along with Funky's suggestions is key to any spawning method. Spawning in creatures too close to PCs will always be laggy, regardless of the method you use.

- When using the Bioware triggers, always also use spawn points. Use more than one too. I generally paint 2-3 where I envision my creatures appearring. With the Bioware triggers and no spawn points, the game engine will attampt to spawn creatures within the triggers boundries - but at a point farthest from the PC triggering them and this is very taxing on the game. Use spawn points always and use more than one in most cases. Also make sure that your spawn points are clear from walls and placeables.
               
               

               

                     Modifié par kalbaern, 24 décembre 2010 - 02:45 .
                     
                  

            

[Legacy_TSMDude]

               I love spawn systems and have tried so many as well as adapted, changed, broken, corruptted, improved, and confused myself in ways that would surprise normal folks. I love randomness from ffjb's to Kilana's to Alzimahers own spawning system.

I have high hopes for the new one that CEP is putting out after the holidays.

In the end though I would suggest following the advice from above but also allow yourself to use more than one system. We use the BioWare's and NESS and have also adapted some other small random systems for ambient wildlife.

There is no real reason to limit yourself when you have the built in Bio System for one, add in NESS which by far has the most documentation I would believe now a days, and then use/adapt a script or two for specfic areas.
               
               

               
            

[Legacy_ffbj]

               I did send you a PM with an overview of my approach. Currently I use 5 different methods for spawning monsters, which includes Bioware one, which I use sparingly about 10% of the time.
The others:
1. Random mobile spawners
2. Placed spawners
3. Moblile spawners (walking spawns).
4. My standard random list spawner.

Thanks for the mention TSM. There are a few spawners on the vault too. Mine is not a complete system, at least what I have on the vault, more of a template, or an add on to other spawning methods. One point is that since the standard Bioware spawner is so deficient, there was lots of room for developement there. Thus you have NESS and a number of others, or like TSM said mix and match or like FS said make your own, or any combitnation of the above.

My own personal favorite of the ones I did is the crowmaster, mostly because it's something you really don't see anywhere else, and because it adds a different element to the game. Of course he only calls in crows, but it's fun, and they have a purpose: to find you. If you can make a spawning method seem natural and at the same time have a certain functionality it really adds to the flavor of the game. The point being that the spawning method(s) you chose should be intergrated into your world in order to create the overall desired effect.

In further regard to your question in that you want specific monsters to show up in that case I would not use the Bioware spawner, as you can see it is very laggy.  My approach using a for loop and merely creating copies/clones of creatures greatly reduces this lag effect.  So perhaps some variation of that would help.  Now if you want many varied creatures to show up at the same time my approach would not be as effective for that, but I made one where 2-4 creatures show up and then a single additional creature would be with them nearby.  So say a few wolves and a goblin masterscout with it's own create line, to add some variation. Finally a resetting int which prevents the spawn from spawning continually until the resetting int is reset.

Here is an example of a triggered spawn in The Kemmering Forest:

 #include "NW_I0_GENERIC"
    void main()
    {
       int nCreature, nNumber;
        string sCreature = "";
        int iReset = GetLocalInt(OBJECT_SELF, "RESET");
         if(iReset == 1)
         return;
        object oPC = GetEnteringObject();
        object oArea = GetArea(oPC);
          if (!GetIsPC(oPC))
          return;
           if  (GetLocalInt(oPC,"Safe") == 1)
            return;
            if (GetLocalInt(oPC,"Run") > 3)
             return;//script will only run 3 times, default would be 3
        int iHdTemp = GetHitDice(oPC);
        if (iHdTemp > 14)
        return;
        object oTarget = oPC;
        float fDistance = 5.0 + (iHdTemp/2 + d4 (2));//higher levels notice things futher away
        location lWP = GetRandomLocation(oArea,oTarget,fDistance);
        location lTarget = GetLocation(oTarget);
        location lWP1 = GetRandomLocation(oArea,oTarget,fDistance + iHdTemp/3);
                  if (GetIsSkillSuccessful(oPC, SKILL_LISTEN, 10) || (GetIsSkillSuccessful(oPC, SKILL_SPOT, 10)))//medium
                      {
                      SendMessageToPC(oPC, "Something is nearby!");
                      GiveXPToCreature(oPC, 15);
                     if ((GetStealthMode(oPC) == STEALTH_MODE_ACTIVATED)&&(GetIsSkillSuccessful(oPC, SKILL_SPOT, 10)))
                     SendMessageToPC(oPC, "Moving in Stealth in hostile area!");
                      GiveXPToCreature(oPC, 25);
                       switch (d4())
                             {
                         case 1: sCreature = "goblinraider"; break;//resref of creature
                         case 2: sCreature = "goblinarcher"; break;
                         case 3: sCreature = "moorwof"; break;
                         case 4: sCreature = "madcrow"; break;
                             }
                         for (nNumber = 0; nNumber < d3(); nNumber++)
                        CreateObject(OBJECT_TYPE_CREATURE, sCreature, lWP, FALSE);
                     object oCreature = GetNearestObjectToLocation(OBJECT_TYPE_CREATURE, lWP);
                     float fDistance1 = GetDistanceBetweenLocations(lWP, lTarget);
                     string sDistance = FloatToString(fDistance1, 2,0);
                     DelayCommand (1.0,SendMessageToPC(oPC, " Some movement, over there! " + sDistance + " metres away."));
                     DelayCommand (4.0, TurnToFaceObject(oCreature, oPC));
                      if (GetIsNight() || (GetStealthMode(oPC) == STEALTH_MODE_DISABLED) || (d100()> 80))
                       {
                     CreateObject(OBJECT_TYPE_CREATURE, "goblinscout", lWP1, FALSE);
                       }
                       if (GetIsNight() && (d100()>50))
                       {
                     CreateObject(OBJECT_TYPE_CREATURE, "goblinarcher001", lWP1, FALSE);
                       }
                      SetLocalInt(oPC,"Run", GetLocalInt(oPC,"Run")+1);
                      DelayCommand (60.0, ExecuteScript("randomspawnlisten",oArea));
                     //comment out the above if only useing spawn once.
                      DelayCommand (10.0,SetLocalInt(OBJECT_SELF, "RESET", 1));//make it untriggerable for a while.
                      DelayCommand (150.0, DeleteLocalInt(oPC,"Run"));
                      DelayCommand (200.0, SetLocalInt(OBJECT_SELF, "RESET", 0));//alter reset up or down.
     }
 }
Of course for your purposes you would want to get rid of the re-execute line, since you want them to spawn only once.  But the idea is you select from a list of creatures wolves, goblins, and spawn some of them and then depending on conditions, night or PC not in stealth you add in a scout and perhaps another goblin archer.
This is just one example of the many I have made to fit various circumstances. Hope that helps.  It's a big important question, imo, that's why I have spent so much time on it.   The way this script is set up the scouts will call more creatures thus the execute script line which summons more goblins into the fight.
You can also see that I don't want this script to spawn for PC over 14 level since they are much too powerful for the encounter.  You could do like wise for lower level PC to prevent a high level encounter from wiping them out if PC lower than 4th for instance return the script.  Something to keep in mind.
               
               

               

                     Modifié par ffbj, 24 décembre 2010 - 05:45 .
                     
                  

            

[Legacy_FunkySwerve]

               

kalbaern wrote...
- Either place triggers well in advance or
drawn large enough that a party spawns creatures out of their line of
sight. This along with Funky's suggestions is key to any spawning
method. Spawning in creatures too close to PCs will always be laggy,
regardless of the method you use.

While I was unaware of the nuances kal mentioned involving the use of spawn-point-less bioware encounters, I completely forgot to mention the above, which can be critical to reducing/eliminating graphical spawn lag. It's sort of second nature to me now, to place the encounter points out of LoS of the tigger whenever possible -not just for spawn lag, but for immersion.

ffbj wrote...

In further regard to your question in that you want specific monsters to show up in that case I would not use the Bioware spawner, as you can see it is very laggy.  My approach using a for loop and merely creating copies/clones of creatures greatly reduces this lag effect.

This is a great piece of advice if you have more than one of a certain creature, as CopyObject is far less expensive than CreatObject.

Funky
               
               

               
            

[Legacy_NorthWolf]

               Huh. Never knew CopyObject was less intensive; would it be better to simply put common spawns in an inaccessible area and copy them into existence or make a single object then copy it repeatedly per spawn when dealing with similar creature types?
               
               

               
            

[Legacy_FunkySwerve]

               The problem with that approach is the added listeners sitting around, assuming you're removing hearbeats from mobs that don't need them (most combat mobs don't unless they need to walk waypoints before or after). You could edit your listening scripts to abort at the outset if the creatures are in certain areas, which would help with that considerably. You could also remove the scripts and readd them, though if memory serves that isn't possible in vanilla nwn (and quite possibly only with linux nwnx).

In general, you should ALWAYS use CopyObject over Create when feasible to do so, be it placeable, creature, item, or what have you. This is one of the few functions significant enough that I mention it specifically in my delagging tutorial:

Streamline your Scripts

Almost all scripts can be written more efficiently. Start with the ones that are called most often, but that you can't get rid of. Many of the changes will be intuitive, obvious changes, while others are more a factor of replacing cpu-intensive operations with lighter ones (GetObjectByTag replaced with GetNearestObjectByTag where logical, for example, or CreateObject with CopyObject where possible). You should also focus on getting rid of database reads where possible, especially if you are using the standard Bioware database. Database reads are very slow. If you use databasing for tracking player statuses, and are checking those statuses at all regularly, you should instead check them only on client enter, and convert them to locals for faster reads later. There are all kinds of tricks like this, many of which you will pick up naturally over time. Be aware of expensive functions, and avoid them where feasible. Again, the lag caused by inefficient scripts is usually entirely serverside, unless the inefficient script in question is also blasting out graphics, for example.

That's in the 1.69 lexicon, linked at the top of this forum by SpiritedLass. I immodestly suggest giving it a read, as it might better equip you to make decisions of the kind discussed in this thread. '>

Funky
               
               

               
            

[Legacy_FunkySwerve]

               Oh, something else I neglected to mention is another factor of creatures with lots of gear, dynamic or otherwise. Each piece fires onqcquire, and onequip if equipped. The heftier your scripts for these events, the more impactful this can be.



Funky



               
               

               
            

[Legacy_ffbj]

               That's important too as each piece of extra equipment adds to the time it takes to create the monster. I mainly arrived at my copy object approach through deduction and trial and error, concluding that simply copying an object would be less cpu intensive than looking up a number of individual creatures as the Bioware method does, though some of them are copied too.
               
               

               

                     Modifié par ffbj, 25 décembre 2010 - 12:21 .
                     
                  

            

[Legacy_Greyfort]

               A little off subject maybe...maybe not.  I quickly typed in NESS on the vault and I found nothing. is this a (Need Encounter System Seriously) cant rember if they call those acronims LOL but I am intrested in NESS sound nice any of you have a link?
               
               

               
            

[Legacy_420]

               

Greyfort wrote...

A little off subject maybe...maybe not.  I quickly typed in NESS on the vault and I found nothing. is this a (Need Encounter System Seriously) cant rember if they call those acronims LOL but I am intrested in NESS sound nice any of you have a link?

Not exactly sure but I think this is the "official" download site for Neshke's Extendable Spawning System: http://www.lrjonline.net/swg/ness.html

-420
               
               

               

                     Modifié par 420, 25 décembre 2010 - 12:41 .
                     
                  

            

[Legacy_TSMDude]

               

Greyfort wrote...

A little off subject maybe...maybe not. I quickly typed in NESS on the vault and I found nothing. is this a (Need Encounter System Seriously) cant rember if they call those acronims LOL but I am intrested in NESS sound nice any of you have a link?

You can also send us a email at tsm.builder@gmail.com and we will send you a copy of the read me which is sometimes hard to find and the little generator for NESS as well.