25 réponses à ce sujet

[leo_x]

I couldn't find any discussion about this, but DelayCommand doesn't seem to work when OBJECT_SELF is an encounter.  Is this my imagination or is this a known issue/feature?

[Shadooow]

nevermind, thought you talking about triggers:unsure:

Modifié par ShaDoOoW, 14 février 2014 - 01:57 .

[Lightfoot8]

I have not heard of them not working before, But since encounters do play by some of there own rules, I can see the need to do a little testing ( I currently do not have the time to do it right now).

Encounters tend to shut thing down when they are not active. You may want to run a few tests with the encounter in an active/inactive/exhausted state to see if they give different results.


EDIT: Keep in mind that the encounters HB only works when the encounter is active.

Modifié par Lightfoot8, 14 février 2014 - 01:44 .

[Pstemarie]

Not sure if this would work, but have you tried DelayCommand(fDelay, ExecuteScript(OBJECT_SELF, "Some_Script")); and have the effect you desire excuted by "Some_Script"?

Modifié par Pstemarie, 14 février 2014 - 04:02 .

[leo_x]

Good idea. I looked into and tested a bit more. I don't think it works regardless of whether active or not.

The event is created and everything, but the encounter event handler just seems to throw it away.

[leo_x]

Pstemarie wrote...

Not sure if this would work, but have you tried DelayCommand(fDelay, ExecuteScript(OBJECT_SELF, "Some_Script")); ?

I'll give it a try.

[Pstemarie]

pope_leo wrote...

Good idea. I looked into and tested a bit more. I don't think it works regardless of whether active or not.

The event is created and everything, but the encounter event handler just seems to throw it away.

Maybe you need to identify the encounter object's trigger by its tag - object oEncounter = GetObjectByTag("Encounter_Tag")?

ShaDoOw may be on to something because, if I understand them correctly, the encounter is actually activated by the PC entering trigger - kind of like the way traps work. This being the case, wouldn't the script events fire for the trigger? I'm at a loss here - I use encounters, but usually don't script things from them.

Modifié par Pstemarie, 14 février 2014 - 04:08 .

[Lightfoot8]

It would help if we knew what command you whrer trying to delay.

[leo_x]

I was scripting an encounter system, the delay was for creating creatures. So it's not a big issue to work around by assigning to the module, but it's doubling the cost which I was hoping wasn't necessary.

[Lightfoot8]

Ok, After testing it appears that delay commands do not work at any time on encounters.

I guess now the question on my mind is.

If you are scripting your own encounter system why are you using an encounter and not just a plain old trigger?

[_Guile]

Lightfoot8 wrote...

Ok, After testing it appears that delay commands do not work at any time on encounters.

I guess now the question on my mind is.

If you are scripting your own encounter system why are you using an encounter and not just a plain old trigger?

Yeah, I like triggers myself, it's far easier to create a script template that doesn't use delay command at all, which to me is a Server Resource Hog (when many players are running over encounters the # of DelayCommands running could reach hundreds if not many thousands!!!)...

[Shadooow]

_Guile wrote...

Yeah, I like triggers myself, it's far easier to create a script template that doesn't use delay command at all, which to me is a Server Resource Hog (when many players are running over encounters the # of DelayCommands running could reach hundreds if not many thousands!!!)...

When you mentioned it, can you post the code you do use to check the time passed?

[leo_x]

Lightfoot8 wrote...

Ok, After testing it appears that delay commands do not work at any time on encounters.

I guess now the question on my mind is.

If you are scripting your own encounter system why are you using an encounter and not just a plain old trigger?

In this case I'm using NWNX to access spawn point locations and increment the internal encounter "number spawned" counter, and setting the creatures encounter.   That way the game engine will still take care of exhaustion, reseting the encounter, its timers, etc.

It seemed to me at the time that this would be much simpler and probably much faster than a trigger system.  I'd guess that a trigger system would have waypoints to act as spawn points, which would probably have to be uniquely named for every painted trigger at least in a single area.  Or is there a better way that someone has found to do a trigger system?

Modifié par pope_leo, 15 février 2014 - 07:17 .

[FunkySwerve]

In this case I'm using NWNX to access spawn point locations and increment the internal encounter "number spawned" counter, and setting the creatures encounter.   That way the game engine will still take care of exhaustion, reseting the encounter, its timers, etc.

Clever bastard.

It seemed to me at the time that this would be much simpler and probably much faster than a trigger system.  I'd guess that a trigger system would have waypoints to act as spawn points, which would probably have to be uniquely named for every painted trigger at least in a single area.  Or is there a better way that someone has found to do a trigger system?

There's a slightly better way. We use triggers and waypoints, with bitflags on the waypoint. Encounter 1 uses only waypoints with the 1 bit, 2 with the 2, 3 with 4, 4 with 16, etc. Allows re-use of waypoints for multiple encounters. Also requires a lot of attention to detail to avoid TMI infinite loops if you screw up, due to some of our optimizations and customization. Those get found and fixed quickly on the first test-runs, though. Bitmath also gets a bit cumbersome to back-of-the-hand past 16384 or so, but I usually keep to about 12 triggers per area. Can post some code if you're curious, but it's hewn pretty close to what we wanted it to do, without too much room for customization. Uses a lot of local string sets to create differing-rarity spawn tables.

Funky

[leo_x]

FunkySwerve wrote...
There's a slightly better way. We use triggers and waypoints, with bitflags on the waypoint. Encounter 1 uses only waypoints with the 1 bit, 2 with the 2, 3 with 4, 4 with 16, etc. Allows re-use of waypoints for multiple encounters. Also requires a lot of attention to detail to avoid TMI infinite loops if you screw up, due to some of our optimizations and customization. Those get found and fixed quickly on the first test-runs, though. Bitmath also gets a bit cumbersome to back-of-the-hand past 16384 or so, but I usually keep to about 12 triggers per area. Can post some code if you're curious, but it's hewn pretty close to what we wanted it to do, without too much room for customization. Uses a lot of local string sets to create differing-rarity spawn tables.

Funky

Please do, I'd love to see how you implemented this.

Modifié par pope_leo, 16 février 2014 - 10:16 .

[FunkySwerve]

I'll post the code now, which is acaos' implementation, not mine. It's pretty dense, so I'll post some example encounters and area enter scripts with do-once string sets a bit later, to make it more comprehensible. The system has evovled over time to allow various different setups. In the most recent iteration, in our Abyss areas, we set it to use one tag of waypoint per trigger, both for ease of visibility, and for ranged attacker waypoints specifically. It's had a lot of functionality built into it, but in ways that are not terribly end-user friendly so much as they are efficient. More later, here's the pastebin:

ac_encounter

That's the script that fires from the trigger's onenter. No other scripts, though there are lots of variables on the trigger set in the toolset, and more variables set on either trigger or area once the area is entered.

Funky

Modifié par FunkySwerve, 16 février 2014 - 08:12 .

[leo_x]

Very cool. Thank you for sharing!

In practice is the 0.1 delay between spawns enough to reduce spawn lag or do you override that a lot?

[FunkySwerve]

No overriding that I'm aware. We don't get TOO much spawn lag to begin with, as we apply most itemprops/effects dynamically on either hide, weapon, or creature, instead of dumping a bunch of items on them, with the exception of mobs that need armor, shield, or helm to achieve the right look. Either way, no spawn hiccups for us to speak of.

Here are a bunch of example triggers. Aside from the listed variables, the only thing on the trigger at the time its set down in the toolset is the above-linked script in onenter. The rest is handled by a do-once setup in the area enter scripts, which I will pastebin after each relevant set of variables.

Myconids (one of the first places we used this system - just sets triggers to Active and specifies a respawn period of 60 minutes - rest done in enter)
EncActive int 1
EncRespawn int 3600

Myconid onenter

Pit of Moliation - Second Deep (new vars showcased here include Chance, which is the chance the trigger will stay active and respawnable, Include, which is the bitmask I mentioned (I wound up cycling the first 4-5 bits a lot when area layout permitted - I only used higher bits when there was a lot of overlap requiring it), TargetSpread, which specifies whether the spawns are spread out over mutliple waypoints of those available, SpreadLimit, which limits the number of randomly chosen candidate waypoints they're spread over, and TargetWaypoint, which is both the default waypoint tag and the number of GetNearestByTag-ed waypoints to check (and skip, if it starts with a number other than 1). Allows us to scan only those nearby for the Include bitmask. Not the most efficent strictly speaking, but a bit more end-user friendly. We were still tinkering:

EncActive int 1
EncChance int 87
EncInclude int 1
EncRespawn int 3600
EncTargetSpread int 1
EncTargetSpreadLimit int 2
EncTargetWaypoint string mol_enc#1-6

This one, still in Second Deep, highlights how we do a set-piece encouter, in this case a group of Meenlock Spitters, using the EncCategory string (see the onenter script for the rest):

EncActive int 1
EncCategory string SPIT
EncChance int 100
EncInclude int 8
EncRespawn int 3600
EncTargetSpread int 1
EncTargetSpreadLimit int 2
EncTargetWaypoint string mol_enc#1-9

Here's the onenter. Note at this point that we've started doing other things, like priming secret triggers, from onenter. Keeps the mod tidy and until the vars are actually needed. We also condensed down to one script, instead of the two from myconids.

mol_onenter

Here's three encounters from Elysium Fortress of the Sun (boss area), highlighting a number of variant setups, and a boss spawn:

EncActive int 1
EncChance int 80
EncInclude int 2
EncTargetSpread int 1
EncTargetSpreadLimit int 2
EncTargetWaypoint string ely_enc#1-3


EncActive int 1
EncChance int 80
EncInclude int 4
EncTargetSpread int 1
EncTargetSpreadLimit int 2
EncTargetWaypoint string ""

boss encounter:

EncActive int 1
EncChance int 100
EncInclude int 16
EncTargetSpread int 0
EncTargetWaypoint string ely_enc#1-2

Here's the onenter:
elysium_enter

I think we actually did that one before pit of moliation, as we were still setting loot variables directly on placeables at that point. Anyway, that shows a boss encounter setup, along with random encounter spawning, and that area, the Fortress of the Sun, also highlights the tiering mechanism of the system - new spawnsets are used once x number of encounters have triggered. We usually use quite a bit fewer tiers of spawnsets that you see there.

Here's one from the Elemental Plane of Air, a wide-open, no bosses, free-ranging area set:
EncActive int 1
EncChance int 90
EncRespawn int 720
EncTargetSpread int 1
EncTargetSpreadLimit int 2
EncTargetWaypoint string ele_enc#3-6

Only thing of note there is that the waypoints are typically set to NOT spawn at the two nearest - due to the wide-open nature of the area set. At that point we were setting the variables directly on the area - ick. No area entry paste for that, as a result.

And lastly, some encounters from one of our Abyss layers, the Gaping Maw:

Gaping Maw, the Screaming Jungle
EncActive int 1
EncChance int 63  
EncIndex int 2 (on enc 2, using melee and ranged 2)
EncRespawn int 3600
EncTargetSpread int 1
EncTargetSpreadLimit int 3
EncTargetWaypoint string aby_enc_melee_2#1-*

Lemoriax miniboss enc trigger 5
EncActive int 1
EncCategory string MINI
EncChance int 100
EncIndex int 5 (on enc 5, using melee and ranged 5)
EncRespawn int -1
EncTargetSpread int 1
EncTargetSpreadLimit int 3
EncTargetWaypoint string aby_enc_melee_5#1-*

Demogorgon's Chambers final (boss) trigger 12:
EncActive int 1
EncCategory string BOSS
EncChance int 100
EncIndex int 12 (on enc 12, using melee and ranged 2)
EncRespawn int -1
EncTargetSpread int 1
EncTargetSpreadLimit int 3
EncTargetWaypoint string aby_enc_melee_12#1-*

Those highlight the spawn system as we're moslty using it nowadays. With larger area sets, we would make a bunch of preconfigured triggers, 1-15 or so, and waypoints tagged to match, which would get used in each area. The default waypoint is for meleers. The ranged attackers would be set on aby_enc_ranged numbered waypoints to match. The #1-* tells it to check all waypoints of the appropriate tag in the area. As you can see in the area enter script, ranged attackers are designated a special set of ranged waypoints to use with @, like we used to do for special encounters. The I is the Index number, matching the one set on the trigger, and the melee waypoint's number as well:
aby_enter

Hope that was of use to you.

Best,
Funky

[leo_x]

Thanks for taking the time to share all that up. The vars really help get a better notion of how things work. You've definitely give me some ideas on things to try.

I do have a couple more questions:

Is the scaling aspect of the system something you use much or do you have expected party sizes?  For me I'm pondering area instancing...each with encounters designed for larger groups.  My server is pretty small so it really has to support soloists and party groups that maybe reach half-dozen players.  I'm not sure how best to tackle this.

On the difficulty level escalation, is this for another system? I couldn't see how it was factoring into the encounter system.

EDIT: Add a few more details.

Modifié par pope_leo, 17 février 2014 - 07:12 .

[Shadooow]

Spawn lags are almost always client-side caused by graphic. Too high poly models (illithids from CEP are those I have experiences with), or too bad graphic card and too high details set, etc.

I use trigger based encounters too but I use simplet targetting than Funky. As I see it, Funky's approach might include less waypoints per area, but requires way more planning where to place them and which ones to use for which trigger-encounter. My trigger-encounter search for a waypoint with a tag #tag_of_trigger#_WP. In case there is more of those waypoints it automatically chooses farthest, which duplicates the behavior of the bioware encounter. Later I added the possibility to set different waypoint for each creature in spawn - this is done via a integer value such as 1 and the my trigger-encounter then seeks #tag_of_trigger#_WP1. Its perhaps bit more labour intensive but offers high flexibility.

here is my trigger-encounter setup leo:

MIN_GROUP_1 int 2
MAX_GROUP_1 int 5
NPC_GROUP_1 string "sh_golem_guard1,sh_golem_guard1,sh_golem_horror1"
MIN_GROUP_1_1 int 1
MIN_GROUP_1_2 int 1
MAX_GROUP_1_1 int 1
MAX_GROUP_1_2 int 1
WP_GROUP_1_1 int 1
WP_GROUP_1_2 int 2
RESPAWN int 500

explanation: two two golems will be spawned on a preset positions, will be spawned always but there wont be more than two of them ever, the 0-3 helmed horrors will be spawned either into player face or on the farthest waypoint depending whether I set up the default waypoints or not.

no scripting needed and almost every values are optional so the basic trigger-encounter looks like this:

NPC_GROUP_1 string "sh_goblin1,sh_goblin2,sh_goblin3"

> spawns 1-2 goblins (randomly chosen from the list) on the farthest waypoint or into players face, respawn is 360 sec

Just giving you thoughts. I am also willing to share this, but I guess you will want to bake something in middle

Modifié par ShaDoOoW, 17 février 2014 - 08:19 .

[FunkySwerve]

ShaDoOoW wrote...

Spawn lags are almost always client-side caused by graphic. Too high poly models (illithids from CEP are those I have experiences with), or too bad graphic card and too high details set, etc.

This is not my experience, though it matters less than it used to, with newer computers. There's a hefty object-creation lag invoved as well, which was pretty easy to notice in our drow areas - all the creatures spawning there have 4-8 pieces of gear. 10 of those at a go, and you definitely get  a server, not a client, hiccup (or did, back in the day, on a crappier server). They're on the old bioware encounter system, though, so they also all spawn at once.

Funky

[FunkySwerve]

pope_leo wrote...

Is the scaling aspect of the system something you use much or do you have expected party sizes?

We do SOME scaling, and more now that we used to, but with a minimum expected party size of 5 or so (if you're level-appropriate, you need that many just for the various class mixes you need). The system can definitely handle much more scaling than we do pretty easily - most likely the best way would be via onenter.

 For me I'm pondering area instancing...each with encounters designed for larger groups.  My server is pretty small so it really has to support soloists and party groups that maybe reach half-dozen players.  I'm not sure how best to tackle this.

The number of spawns is controlled in the area enter script, so you could pretty easily handle it there - even put it outside the do once so it rechecks whenever a pc enters and spawns accordingly.

On the difficulty level escalation, is this for another system? I couldn't see how it was factoring into the encounter system.

No, that's for this system - that was the bit I said was showcased by the Fortress of the Sun Area. It has around 6 different 'difficulty' tiers, which are basically upgrading encounters based on the number tripped, with the last being the boss.

It works pretty well, so long as you draw your triggers nice and broad so that fast-moving pcs don't accidentally bypass any. We had to redraw a number, and still (if rarely) have issues. We mostly do set-piece encounters instead of the difficulty scaling nowadays, though it's still fully functional, and I'd probably still use it for areas with encounters that got harder the more you stuck around prior to area respawn - just not for set bosses, which is still how Elysium works.

Please don't hestitate to ask if you have more questions. I can send you a few areas by way of example, if you want to peep them. They just require CEP 2.3, by and large, though we take them right out of the temp0 directory, since the er****g utility no longer works on our mod (compiler issues).

Funky

[leo_x]

@ShadoOow Thanks for the ideas.

FunkySwerve wrote...
The number of spawns is controlled in the area enter script, so you could pretty easily handle it there - even put it outside the do once so it rechecks whenever a pc enters and spawns accordingly.

That would be simpler than my original plan. My only concern is that some of my players are on slower connections and are really slow through transitions. So there will be people that won't wait, start fighting a weaker encounter. That's pretty minor tho and could probably be worked around pretty easy by summing all the players in any of a run's areas.

FunkySwerve wrote...
No, that's for this system - that was the bit I said was showcased by the Fortress of the Sun Area. It has around 6 different 'difficulty' tiers, which are basically upgrading encounters based on the number tripped, with the last being the boss.

Ok, I missed that. It makes more sense to me know. I could see this as a nice way of discouraging farming/camping, overspawing, etc.

FunkySwerve wrote...
Please don't hestitate to ask if you have more questions. I can send you a few areas by way of example, if you want to peep them. They just require CEP 2.3, by and large, though we take them right out of the temp0 directory, since the er****g utility no longer works on our mod (compiler issues).

Funky

I am curious if you have any retrospective on how the encounter system ended up influencing area design. I imagine at your spawn/party levels you have to keep things pretty spacious in general.

I would love to take a look at an area, but don't go through a lot of trouble. I think I have a good idea on what's going on now.

If you're curious, this is where I'm at after all your help/feedback/ideas: https://github.com/j...s/pl_drow_1.lua all the spawns are just for testing/illustration.

I'm mocking up my system in Lua rather than NWScript, because I really want to do config style files rather than set local vars directly. I think it's pretty readable, except ':' is like the C++ '.' operator. I'll either keep everything in Lua or use them to prime waypoints with local vars on mod load or something for a NWScript system.

Modifié par pope_leo, 18 février 2014 - 11:09 .

[FunkySwerve]

Hm.  In general, I think it was mostly the converse - our area design influenced how the system was set up.

We began with a pretty stringent set of requirements for area design. We do try to keep things spacious, adhering for the most part to best practices when it comes to where to put placeables and where not. Most of our areas are built to be linear in playthrough, at least ones with bosses/set loot/accomplishments, though we try to make them not obviously so via use of keys and locks, etc.

Placing ranged attackers can be a niusance, since, while you want them where they can't be easily meleed, you also want them where the party can't easily seperate them from the melee combantants in the encounter. That's resulted in a lot of switchback designs and chokepoints in places where the party can't easily backtrack. It was the desire to be able to place them carefully vis a vis the meleers in the encounter that lead to our current arrangement in the encounter system.

Similarly, in boss encounters, we began using giant 'boss push' triggers to keep the party members from getting too much milage out of convoluted area design by seperating them from their minions. You can sometimes do this via area design, but porting the pcs into a final fight area gets pretty tired pretty quickly. Yeah, the push trigger is a bit metagame, but it's not apparent unless the players are already metagaming by abusing the limits of NWN's ai. We generally have it warn them and zap them with rapidly increasing amounts of damage to quickly get them out of places we don't want them. Also, the push triggers aren't strictly a part of the encounter system - I just mention them because it's another example of area design driving trigger design.

Likewise, the desire to be able to slap down the same triggers for wide-open 'farming' areas lead to the mutability of the waypoint setup. Being able to use a single tag waypoint for all the spawn points in an area is very convenient, when you don't need to be able to see what waypoints relate to which triggers. If you do, however, I like to use premade templates, using waypoints of different appearances, so that you can easily spot the different encounters' waypoints.

Desire to keep the overall object count down originally drove the bitmask approach to waypoints, but it can make seeing the larger picture in the toolset difficult - a typical sort of tradeoff between useability and efficiency. It only matters while you're still tweaking spawn positions to keep them from appearing in odd places, though (it's amazing how unpredictable this can be, if you're spawning in a lot of mobs of varying sizes).

Good question, but as far as I can see, it's all been the other way 'round, with design shaping the tools. Which I guess is how you ideally want it, anyway, rather than the tools you have limiting your design.

Here's a link to the area files for Elysium and Gaping Maw:

Click Me

Funky

Modifié par FunkySwerve, 18 février 2014 - 12:58 .

[leo_x]

Thank you, it's really generous of you to share those.

I love the boss push triggers and am going to start using that.

After all the monsters have been spawned, I'm curious how you handle PC targeting. I tried a fairly crude scaling system in the past, but it was susceptible to a kind of mob blob effect. Monsters would target the encounter spawner. If that was a tank that could handle them, PCs win, if not it started a domino effect.