tain.totalcodex.net

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

}

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.