My problem is that I got many huge area with lot's of script in one module. I'd like to avoid spliting that mod in tiny mods.
Is it better to have all the event related in one script ( a huge script) that is launched once in a while
Or to have many different script that are launched at almost the same time?
NWN2 guru advice required (those that flirt with the limit of the engine)
Débuté par
Shallina
, juin 07 2011 03:10
Retour en haut
#2
Posté 07 juin 2011 - 03:40
Lugaid of the Red Stripes
-
- Members
- 955 messages
What kinds of problems are you encountering so far? Its actually quite difficult to overwhelm a modern processor with scripts, not unless you have some infinite loops or exponential recursion going on.
#3
Posté 07 juin 2011 - 03:43
Shallina
-
- Members
- 1 012 messages
I have many creation/delete object and Object commanded "at once", the sums of all affected object by an action will probably be over 800.
#4
Posté 07 juin 2011 - 04:03
_Knightmare_
-
- Members
- 643 messages
Affecting 800 objects all atthe same time!?! What exactly are you looking to do here? There must be some way to reduce that number (hopefully dramatically)...
#5
Guest_Chaos Wielder_*
Posté 07 juin 2011 - 04:08
Guest_Chaos Wielder_*
Guest_Chaos Wielder_*
-
- Guests
That really is quite a bit. There must be some way to change how you're doing things.
That said, in my own experience I've found that splitting a script up into multiple functions helps performance(and, perhaps more importantly, helps you determine which sections of the script you can change for helping performance).
That said, in my own experience I've found that splitting a script up into multiple functions helps performance(and, perhaps more importantly, helps you determine which sections of the script you can change for helping performance).
#6
Posté 07 juin 2011 - 04:27
Lugaid of the Red Stripes
-
- Members
- 955 messages
The on-area-enter (not client enter) script is a good place to create objects, as the player won't notice any lag. I'm guessing you're doing some module-wide renovations after some plot point. In that case, you might think about changing things area-by-area as the player enters each area in turn.
#7
Posté 07 juin 2011 - 05:44
painofdungeoneternal
-
- Members
- 1 799 messages
I have no idea what you are trying to accomplish frankly. The answer is going to depend on the details, is it roleplay, PW, what is the entire story.
If it's not working right, sometimes you need to rethink your tactics entirely, 800 is a lot of objects and making that many things is more to do with making than many things than with scripting. However often you can rearrange things so it's still taking just as long but it's not perceived as taking as long.
Copying an existing object is less intensive than creating one from a blueprint, which is something you see things like NESS doing. But then i can also say doing delay commands, so it takes 8 seconds to create the objects ( do a script every .5 seconds with creation of 50 each, if the objects are not immediately visible you delay them much longer ) Are those things all visible upon creation, with events being triggered, which might make this even an AI issue?
A scripting problem needs to be fixed in script, not by breaking up the module, find out what part of the script is taking too long and optimize that portion, or rework it.
If it's not working right, sometimes you need to rethink your tactics entirely, 800 is a lot of objects and making that many things is more to do with making than many things than with scripting. However often you can rearrange things so it's still taking just as long but it's not perceived as taking as long.
Copying an existing object is less intensive than creating one from a blueprint, which is something you see things like NESS doing. But then i can also say doing delay commands, so it takes 8 seconds to create the objects ( do a script every .5 seconds with creation of 50 each, if the objects are not immediately visible you delay them much longer ) Are those things all visible upon creation, with events being triggered, which might make this even an AI issue?
A scripting problem needs to be fixed in script, not by breaking up the module, find out what part of the script is taking too long and optimize that portion, or rework it.
#8
Posté 09 juin 2011 - 04:27
M. Rieder
-
- Members
- 2 530 messages
Lugaid of the Red Stripes wrote...
The on-area-enter (not client enter) script is a good place to create objects, as the player won't notice any lag. I'm guessing you're doing some module-wide renovations after some plot point. In that case, you might think about changing things area-by-area as the player enters each area in turn.
Just a side thought, apologies for the off-topic post:
Lugaid,
Would it be good to spawn all creatures for an area, then leave them script hidden until they are needed and then use triggers to script hidden (false), as opposed to using encounters? It seems like this would front-load the lag and the player wouldn't notice it.
Is there a down-side?
#9
Posté 09 juin 2011 - 05:00
Lugaid of the Red Stripes
-
- Members
- 955 messages
That's usually what I do for large battles. I don't use encounters often, so I can't speak too much to their relative merits, but there are a few issues.
1. A good bit of the initial lag in spawning a group is all the on-perception scripts firing at once, which can still be an issue for a group of suddenly un-hidden creatures.
2. Script-hidden creatures can still be affected from all sorts of scripts. I don't know if the standard scripts (e.g. AOE spells, AI) take script-hiddenness into account, but I know that I had to fix a bunch of my own amateur scripts to not unduly affect hidden creatures.
As for replacing standard dungeon-crawl encounters with script-hidden creatures, it might cause an issue with CR scaling, if a low-level PC enters an area, quickly leaves, and then comes back several levels later, they'll still be facing the same low-level monsters. The spawned monsters will also sit there eating up RAM until they're killed.
Script-hidden creatures are also really good for doing multiple waves of enemies. Instead of spawning each new wave all at once, you can spawn them script-hidden one at a time, as the previous wave gets killed off, and then unhide them all at once.
1. A good bit of the initial lag in spawning a group is all the on-perception scripts firing at once, which can still be an issue for a group of suddenly un-hidden creatures.
2. Script-hidden creatures can still be affected from all sorts of scripts. I don't know if the standard scripts (e.g. AOE spells, AI) take script-hiddenness into account, but I know that I had to fix a bunch of my own amateur scripts to not unduly affect hidden creatures.
As for replacing standard dungeon-crawl encounters with script-hidden creatures, it might cause an issue with CR scaling, if a low-level PC enters an area, quickly leaves, and then comes back several levels later, they'll still be facing the same low-level monsters. The spawned monsters will also sit there eating up RAM until they're killed.
Script-hidden creatures are also really good for doing multiple waves of enemies. Instead of spawning each new wave all at once, you can spawn them script-hidden one at a time, as the previous wave gets killed off, and then unhide them all at once.
#10
Posté 09 juin 2011 - 05:27
kamal_
-
- Members
- 5 260 messages
Encounters are dynamically generated groups of designated challenge. So the less linear the adventure, the more difference you can see versus script hidden. You might be able to generate an encounter of creatures that spawn scripthidden and then unhide them though.
