So I've made a modified Mazz 5 map that has a lot of different waves spawning, attacking, random mugering, and respawning to attack the player. But when testing the plug, the scripts start to accumulate delays. Instead of waves respawning quicker the further into the game as designed, they delay longer and longer.
An example:
Waves that were meant to respawn evey two minutes and faster instead start taking five minutes or longer to respawn.
These delays start to be noticeable after about 10 minutes of play, and reach the 5+ minute delay 30 minutes in.
This is a list of the majority of the scripts that would be running in the first 30 minutes, some deactivate, others are reused over and over every 30 seconds to two minutes. They all don't run at the exactly they same time, as they activate each other. Some when activated activate a whole chain of other events. I have, however, counted all the GEOM scripts as I read a lot of those running can cause delays; there are 9 total.
Test Unit: 29
Attack: 19
Unit Control: 15
GEOM: 9
Action Lists: 11
Mungers: 10 (up to 10 at a time, as they are reused)
There are 5 major GEOM attack scripts that are rerun over and over (only 3 of them are running in the first 30 minutes). There are 6 major ranodm mungering attack scripts that all begin running in the first 5 minutes of the game.
Also I use the "Initial Delay Only" flag on most waves when they first spawn, does this flag actually work? Or does Myth not reset the trigger time to zero seconds after the first time the action is used, even if this flag is checked?
I've heard 1.7.1 is optimized for maps with lots of GEOM scripts, but I haven't tested under it yet. Would this help? I'll have to see.
Below I've posted two of the major scripts that are always running.
Here is one of the 5 major GEOM attack scripts:
--Zom N--
{
(subj, monster_identifier)
17711 (NEW ghast(lvl1) normal)
}
--Zom E--
{
(subj, monster_identifier)
17975 (NEW ghast(lvl1) normal)
}
--Zom S--
{
(subj, monster_identifier)
17885 (NEW ghast(lvl1) normal)
}
--Zom W--
{
(subj, monster_identifier)
17788 (NEW ghast(lvl1) normal)
}
Z Wave 1 [Action List]
initially_active, only_initial_delay
deactivates_on_successful_execution
120.00, 120.00
{
Actions to Activate
Z1 N
Z1 E
Z1 S
Z1 W
Random Selection Flag
true
}
More Zombies [Munger]
activates_only_once, initially_active
deactivates_on_trigger
900.00, 1020.00
{
Replace Parameters
Look For Zombies
(_max, integer)
60
}
Z1 N [Munger]
deactivates_on_trigger
0.00, 0.00
{
Replace Parameters
Look For Zombies
Link
--Zom N--
Activate Actions
Look For Zombies
}
Z1 E [Munger]
deactivates_on_trigger
0.00, 0.00
{
Replace Parameters
Look For Zombies
Link
--Zom E--
Activate Actions
Look For Zombies
}
Z1 S [Munger]
deactivates_on_trigger
0.00, 0.00
{
Replace Parameters
Look For Zombies
Link
--Zom S--
Activate Actions
Look For Zombies
}
Z1 W [Munger]
deactivates_on_trigger
0.00, 0.00
{
Replace Parameters
Look For Zombies
Link
--Zom W--
Activate Actions
Look For Zombies
}
Zombies Attack! [Attack]
no_initial_delay
deactivates_never
6.00, 6.00
{
Link
--Zom N--
--Player Units Object--
--Zom E--
--Zom S--
--Zom W--
Attack All Enemies Flag
Attack Nearest Flag
}
Look For Zombies [Geometry Filter]
deactivates_on_successful_execution
10.00, 120.00
{
Entire Map
Results Action Identifier
Current Wave Zombies
Tested items Inside Field Name
subj
Use Markers instead of Monsters
Maximum Number of Items
30
Choose Random Items
Activates on Success
Visible Zombies
Link
Only Use Uncreated Monsters
}
Current Wave Zombies
{
}
Visible Zombies [Unit Control]
deactivates_on_trigger
0.00, 0.00
{
Link
Current Wave Zombies
--Player Units Object--
Visible Flag
Activates on Success
Zombies Attack!
Current Zombies Dead?
Use Monster Entrance Flag
}
Current Zombies Dead? [Test Unit]
deactivates_on_successful_execution
10.00, 10.00
{
Link
Current Wave Zombies
Activates on Success
Z Wave 1
Unit Count Equal To
0
Deactivates On Success
Zombies Attack!
}
Here is one of the 6 major random Mungering attack scripts (the action list chooses randomly from a list of mungers):
NE Group [Action List]
initially_active, only_initial_delay
deactivates_on_successful_execution
60.00, 90.00
{
Actions to Activate
mThrall1-2
mThrall1-2
mThrall1-2
mThrall1-2
mMauls1
mMauls1
mStygs
mMyrms
Random Selection Flag
}
Visible NE [Unit Control]
deactivates_on_trigger
0.00, 0.00
{
Link
Visible Flag
Tain Visibility Flag
Activates on Success
Attack NE!
Dead NE?
}
Attack NE! [Attack]
no_initial_delay
deactivates_never
7.00, 7.00
{
Link
Attack All Enemies Flag
Attack Nearest Flag
}
Dead NE? [Test Unit]
deactivates_on_successful_execution
5.00, 5.00
{
Unit Count Less Than
1
Link
Deactivates On Success
Attack NE!
Activates on Success
NE Group
}
mThrall1-2 [Munger]
deactivates_on_trigger
10.00, 120.00
{
Replace Parameters
Visible NE
Link
Thrall1-2
Replace Parameters
Attack NE!
Link
Thrall1-2
Replace Parameters
Dead NE?
Link
Thrall1-2
Activate Actions
Visible NE
}
Scripts Lagging Behind Game
Re: Scripts Lagging Behind Game
GEOMs are usually the killers, also there is a hard-limit of (I think) six map actions executed per tick, so if you have more than this waiting to be executed then you may end up with actions that are executing every two or more ticks instead.
What are the GEOMs doing? Sometimes it's possible to use a single GEOM that dispatches tasks to other actions a lot more efficiently that by running several simultaneously. Same goes for Test Units.
For example; if you're testing for units within two small areas, then you can actually create a "super test" that tests a rough area that encompasses both, then, if it detects something will activate the "child" tests to see if something should happen. This way you can greatly reduce the number of tests, and only have more running simultaneously if one or more of the "super tests" are triggered. The down-side to that of course is extra actions (the super tests) and the tests themselves may take several ticks to complete, rather than just one, so you'll want to weigh whether this is helpful or not.
Another common case is if you're testing to see if X number of units remain, or if a unit has reached Y health or similar. For example; if you have tests for less-than 15 units remaining, less-than 10 units remaining, and less-than 5 units remaining, then you only really need the less-than 15 units remaining action enabled to begin with, it can then execute the less-than 10 units action on success, which can in-turn execute the less-than 5 units action on success, and similar. This way the relevant actions are still fired, there may again be a slight delay if the player manages to lose a large number of units in a single-tick, but most of the time this won't matter.
What are the GEOMs doing? Sometimes it's possible to use a single GEOM that dispatches tasks to other actions a lot more efficiently that by running several simultaneously. Same goes for Test Units.
For example; if you're testing for units within two small areas, then you can actually create a "super test" that tests a rough area that encompasses both, then, if it detects something will activate the "child" tests to see if something should happen. This way you can greatly reduce the number of tests, and only have more running simultaneously if one or more of the "super tests" are triggered. The down-side to that of course is extra actions (the super tests) and the tests themselves may take several ticks to complete, rather than just one, so you'll want to weigh whether this is helpful or not.
Another common case is if you're testing to see if X number of units remain, or if a unit has reached Y health or similar. For example; if you have tests for less-than 15 units remaining, less-than 10 units remaining, and less-than 5 units remaining, then you only really need the less-than 15 units remaining action enabled to begin with, it can then execute the less-than 10 units action on success, which can in-turn execute the less-than 5 units action on success, and similar. This way the relevant actions are still fired, there may again be a slight delay if the player manages to lose a large number of units in a single-tick, but most of the time this won't matter.
Being Haravikk gets you girls like these:
