[General] How to improve the performance/reduce lags of a map with many units fighting and spawned

[Barade]

Hi there,

I was hosting my Minas Tirith map multiple times on Battle.net and playing it in single player and it really lags when I play 4 vs 4 even with computer players.
Here is an example video:

Even with computer players it really lags on my computer. Now I am not sure what the reason is and I don't know what causes most of the performance issues playing the map.

Some possible reasons:

• Reforged engine sucks (I think it lags with classic as well, can try it again).
• I have installed Reforged on an external disk (no SSD etc.).
• The recording software OBS. The recording might cause additional performance issues or the recording itself simply lags?
• My laptop/hardware is not the best out there.
• The number of units fighting or spawned.
• 1 unit is spawned every 2 seconds for 8 players. The spawn trigger might not be really performant since it goes through 8 barracks and for each barrack through priorities 1-10 and then through like 20 unit types every 2 seconds only to find the first unit type possible to spawn. If executing triggers is really slow, this might cause the problem since it is executed every 2 seconds.
• The missiles of the Trebuchets (someone said online that this might lag?!).
• My triggers of which some run every X seconds.

Maybe someone with a faster PC could download my latest map at tdauth/the-siege-of-minas-tirith and start it 4 vs 4 with computer players to see if it lags or not?
I don't know too much about Reforged to know what causes most performance problems. If the units are the problem I can increase their food cost/reduce food maximum or increase the spawn rate to a higher duration?

I really want to fix this since the map might become unplayable like this. I have ordered a new PC, so soon I can try it again on a newer one but the lag really sucks.

I had an older version of the map which had less lagging:

but played in classic.
The spawn rate was something like every 12 seconds but not only 1 unit but all units possible. Maybe it is really the fast spawn. However, in the end it was lagging as well, so it might be a mix from everything? However, I played it with classic graphics.

 

[pr114]

Even if you have a weak laptop, it would be good to design the game in a way that performs well, so that other uses with a weak pc may join.

-You may enforce SD only. The map is so far zoomed out that there isn't anything to be gained by having those extremely high poly reforged models. The SD models will look just as good and have far less lag. (In my opinion they look better, as the lighting of Reforged models is horrendous, and at a zoomed out perspective their extra detail is lost)
-OBS may cause reduced framerate. You could test the map with OBS off to get a more accurate representation.
-There are lot of units on the map and the zoomout is quite far. This in and of itself has high CPU costs. But I understand this is crucial for this game type, so you wouldn't want to compromise too much on this. If you are worried that specific catapult models or their projectiles cause lag, you could do a specific framerate compare of a situation with and without the catapults.
-Another potential cause for lag is a unit with a ridiculously low attack cooldown. And especially if their attack produces an effect on each attack and/or has AoE. Don't know if you have those in your map.
-Spawning units is a fairly CPU heavy function. However, I think 4 units per second is not THAT much. Lots of TD's have more than that, and they don't really lag.
-You could check your spawn trigger to make sure the barracks are indexed and known variables, rather then obtaining them through area searches every time in cycles.
-Triggering in general can be the causes of lag in your map. Bad stuff is having multiple triggers with the same events. Internally, that means it will fire a trigger execution and then check its conditions multiple times! Rather you would want one single trigger per event, and then check multiple conditions within that one trigger.
-Triggers that fire very often are the most important to make sure there are no multiples of them, and that they have lightweight logic in them. Worst offenders are: -unit enters map, unit is damaged, unit is attacked.
Ideally you wouldn't have these trigger types in your map at all, unless a spell/system absolutely requires it. If you can, in that case attach the trigger event to one single unit instead of making it a generic event.
-Another thing (I mentioned it before) is reduce area searches as much as you can. If you would need multiple area searches to obtain a unit repeatedly, it is much better to index the unit and store it in a variable.
Ideally a map makes very infrequent use of area searches.
-Coding directly in custom script is the most efficient. And make sure you use local variables in the case you would use repeated logic. So instead of repeating 'GetTriggerUnit', save GetTriggerUnit in a local, and use the local from there on out.
-Lua performs better than JASS. If you can, switch map mode to Lua.
-You could try converting all your custom model textures to DDS format. I understood from DrSuperGood that those have lower CPU overhead.

 

[Barade]

Useful answer. Well there is a big spawn trigger which goes through the unit group of barracks (not getting them from the map) etc. Maybe I will rewrite the spawn system in JASS ur LUA and make it a bit simpler. You can see the triggers here: https://www.hiveworkshop.com/resources/the-siege-of-minas-tirith-0-6.81730/preview?trigger=199
and here: https://www.hiveworkshop.com/resources/the-siege-of-minas-tirith-0-6.81730/preview?trigger=200 and https://www.hiveworkshop.com/resources/the-siege-of-minas-tirith-0-6.81730/preview?trigger=201
It isn't the most efficient way to spawn units from barracks as I go through all the units in the group and per unit I check all priorities and for every priority all unit types if they have it or not. At least I could store for every priority the exact unit type to avoid the final nested loop.

Choosing multiple units on the map for something is only done in the beginning, at certain events and when custom spell has to increase damage or something like that.

Switching to HD only would be fine for me. I don't know about people online. The HD graphics only add the automatic shadows. I use custom models anyway. I am not sure if I will get less players then.

There is really lots of spawning and fighting in the map and some units like Trolls damage multiple units at once all the time. Maybe I will turn on/off some triggers during the map and check the performance.

 

[pr114]

Oh cool, it can look through all the triggers in the map now.

The trigger doesn't look bad. It seems to make some light checks before actually doing something.
I do notice it has the 'Number of living units'. This function creates an unpreventable handle leak each time it is called.
Instead of 'Number of living units' use something like 'Number of Units in Units matching (unit is alive)'.

For looping through a group, a static unit group is fine. Better still is a lua list, because then you won't need to repeat 'ForGroup' for every unit you iterate through. That function supposedly starts a new thread for every single iteration, which has some overhead to it.

If you can turn the map into a lua map. Fix the leaks, and rewrite the spawn system in Lua custom script, I think it'd help.

Another thing:
-'Gimli enters the map' - this trigger is preferably rewritten. This trigger will fire every single time a units is created with the spawn system.

There are a bunch of triggers with the event 'Starts effect of an ability' and 'Unit Dies'. It would be preferable if you roll this into one single trigger that checks multiple conditions (for instance a unit type). It's also preferable to use variables there. Like save 'unit type of dying unit' to one variable, and then perform all condition checks on that variable.


What I mentioned about many units having an AoE attack at once. My strategy map used to have a flamethrower unit with flame effects and AoE attacks at a VERY low base attack cooldown. They would lag when they start attacking en masse. Don't think a few trolls (elite unit) with a normal attack speed would have any noticable effect.


Apart from that the lowest hanging fruit would be enforcing SD mode and converting textures to DDS. I believe a large amount of the CPU usage in this game goes to rendering the units and effects. (although I'm not an expert on the matter, DrSuperGood has great knowledge here).

 

[Barade]

Okay thanks for all the hints. I have played the map again without OBS and in SD only and the lag was reduced massively, so the HD mode and maybe OBS seem to have a big effect as well.

 

[SebioL]

I don't think I'm the best person to talk about machine performance. But despite not having a lot of technical computer knowledge, I have had some experience with manipulating maps with colossal amounts of units, but using units at miniature scales and testing from high polygonal/texture definition models and with texture models. SD-Classic. So, I'm going to dare mention some positions regarding the experiences I've had.
I have a reasonably good notebook, of course it's no power, which makes the game engine's performance smaller and more demanding...
From what I saw in the video, even though they are barely noticeable lags compared to other maps I've faced. As for your map... I highlight some points:

1st. - FIGHTING UNITS: Without a shadow of a doubt, I particularly believe that the amount of fighting/attacking units can have a maximum limit for the WC3 engine to be able to perform all attacking moves regardless of the capacity or power of your computer's hardware, the game there should be a limit on the amount of units in battle, even if they are units without major attack special effects, but just hitting the same target, switching targets for new required acquisition distance, or for the models themselves to support their different attack1 animations. attack2 atk3... all this at the same time. This maximum number I have never found, but using all SD units (the lightest Classics), I think I have come up with possible numbers of 3000 units spread all over the map facing each other (only in melee) without any problem of Lag, not harming the maximum game engine that can be supported by WC3.
In this case, within your map, your amount of units I believe is very small for any Lag in this situation.
2nd. - MOVING UNITS: You could have that traditional problem of limiting units (per player) to move at the same time, caused by collisions. Without having pathing problems and big movement speed differences between each unit, or removing the collision, you can reach thousands of moving units without this problem. But I noticed that you split across multiple players in alliance amounts, helping to distribute the maximum micro-movement counts available to each player (maybe the maximum is 60 colliding units per player). I also see that there aren't too many obstacles and not too many units moving from one side of the map to the other at the same time.
3rd. - STOPPED UNITS: Number of standing units (HOLDPOSITION, really without changing positions or changing moves), you can have as many units as you want, I believe the limit is restricted only by the total resources that the game allows. Maybe that's why, if we try to use exaggerated amounts of "ranged" type units fighting each other within ranges, there will be lesser actions and movements, that also don't possessing special effects or heavy emission particles, you can have much larger battles with lag-reduced than you would get if it's just a clash of infantry units attacking each other by swords.
4th. - TRIGGERS FOR MULTIPLE UNIT SPAWNS: This already has a lot to do with most traditionals performance issues, which is very common when using the GUI without a detailed Leaks review, certainly the triggers are not so demanding on your machine's capacity, but too much on the WC3 engine itself. I sincerely swore that Reforged would bring more adaptive trigger reading to support big codes working simultaneously with more leaks or with the GUI providing automatic fixes, but apparently we will continue to become masters of code/triggers and use the community to save us with tricks and juggling.
The spawns of units per second, even with removal of LEAKS by points or group of units, I still believe it can mess up your plans a lot and create a lot of lag, if there are many spawns at the same time (and also at the same creation point), it could be good to check these limits in your triggers.
5th - TRIGGERS INVOLVING ALL UNITS FOR EVENTS OF ATTACKED ACTION OR EVENTS OF SHORTS SECONDs GENERATING NEW MICRO ACTIONS FOR ALL UNITS: This is highly harmful, you will suffer Lag even using all units in SD graphics, check all Leaks or looking for solutions that can avoid the problems of these types of triggers, contributes considerably. As in the case of the conditions for identifying the attacked unit, always point exactly to "attacked unit"=type unit, never use "Random unit type".
6th - GRAPHICS: I noticed that you don't use Zoom in abundance, maybe it isn't even of interest, after all, there are too many units with a lot of special effects, any player would avoid that. Maybe make use of the map in HD, but suggesting that you make use of all settings for "LOW" or inserting lighter models for mass units. If you do a test, SD models should eliminate all of that.
IN BRIEF: We can see here that the number of units doesn't seem to be your problem, but the reforged graphical effects, like the high resolution textures of all these models HD together at the same time, in a way are what should generate the biggest commitments and the use of many simultaneous special effects are what often create these small delays, maybe it's not even so much related to triggers issues or leaks, which are likely to exist and add to their complications, it's important to check the leaks too..
Suggestion: Beyond to remove leaks... You should suggest SD graphics for those users with weaker machines, maybe making a version of this mode Classic available for your map. I believe that only Hardware solves this (for your case, using HD and in high configuration). If I remember correctly, try doing a test during mass combat, switch the display screen to a region of the map that has no excess units or no combat, if it instantly stops the Lag completely, I recall that this would be an FPS issue per failure of your own machine. Delays due to triggers, resource limitations or any game deficiencies, you will continue to experience these delays even anywhere on the game screen in cleaner areas of the map.

 

[Uncle]

I didn't check the other triggers but using Spawn Unit Types from Barrack as an example:

• (Number of living Bannerman units owned by TmpPlayer) Less than LimitBannerman

This Condition creates and leaks a Unit Group. Now take into consideration that you have multiple Conditions like this and that this trigger runs multiple times throughout the game and you can see the problem.

I also see Point leaks in other triggers. Position of unit, center of region, etc. all leak a point:

• Unit - Create 1 Footman for Player 1 (Red) at (Position of (Triggering unit)) facing Default building facing degrees

Also, you don't take full advantage of the ELSE in your If Then Else statements.
Looking at the trigger Change Unit Type Event as an example, you ask at least 15 "questions" in there despite the fact that only 1 of them can be true. If you used the ELSE the way it's intended to be used, the logic would be a lot more efficient. For example like this:

• Actions
  • Set Variable DiceRoll = (Random integer number between 1 and 3)
  • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
    • If - Conditions
      • DiceRoll Equal to 1
    • Then - Actions
      • Game - Display to (All players) for 30.00 seconds the text: Rolled 1
    • Else - Actions
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • DiceRoll Equal to 2
        • Then - Actions
          • Game - Display to (All players) for 30.00 seconds the text: Rolled 2
        • Else - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • DiceRoll Equal to 3
            • Then - Actions
              • Game - Display to (All players) for 30.00 seconds the text: Rolled 3
            • Else - Actions

Like this the logic doesn't need to check if DiceRoll is equal to 2 or 3 if it rolled 1. And it doesn't need to check if it's equal to 3 if it rolled 2. However, in the case that it rolled 3, it would still have to do all 3 checks. But regardless, it will be more efficient most of the time.

Also, your use of (Do nothing) has no actual effect. This Action is no different from a Comment.
The only time you want to use Do nothing is if your If Then Else statement doesn't have multiple functions:

• If ((Player 1 (Red) slot status) Equal to Is playing) then do (Player - Set Player 1 (Red).Current gold to 750) else do (Do nothing)

In this case you're required to put an ELSE action, so (Do nothing) comes in handy. Otherwise, you can leave the ELSE empty.

If your other triggers are anything like the two that I looked at then you're dealing with a lot of memory leaks and some cases of inefficient code. That being said, I can't promise you that fixing these issues will improve your FPS by a substantial amount but it should at least help. Like others have said, Units/Doodads/Special Effects are the main FPS culprits. If you pan the camera away from a large city/battle and into an empty corner of the map you'll see that your FPS increases drastically. The intensity of this change will depend on your hardware. That being said, large amounts of memory leaks generated over the course of a game will cause performance issues as well.

Memory Leaks

C0Memory leaks For a quick lookup on most important actions, read Things That Leak. Introduction Object Leaks Reference Leaks Miscellaneous Conclusion C1Introduction If your computer's memory keeps occupied with stuff you already lost access to, it's called memory leak. It slows down the...

www.hiveworkshop.com

 

[Barade]

thx I wanted to rewrite the barracks spawn system in vJass or something to avoid leaks and improve the performance. Maybe the unit spawn triggers which run every 2 seconds lower the performance.

Didn't know about the dice trigger. I will look at it again.

About the unit limits: I have tried to reduce the number of units by reducing the food limit if 4 vs 4 players are playing. I can also increase the units HP and life time, so no new units have to spawn all the time. I could add a check like used food < max food in the beginning to avoid the whole spawn logic if your full army is alive.
If the units are stronger and live longer a smaller food cap is not an issue since your army takes much longer to get killed and it will respawn in N seconds.

About the graphics: Yes it lags more with HD I think. I can recommend SD but I didn't want to restrict the map. However, you can always have players online joining who have enabled HD and who are using weak hardware, so there is no guarantee then.

Maybe I will change the spawn system more similar to the Helm's Deep map were you can fill Warcraft's unit queue and then the player could apply like "start spawn". This would certainly improve the performance and maybe make it much more simple.

 

[Uncle]

HD will always hurt your performance more than SD, the improved graphics come at a cost. And GUI has all of the necessary tools to remove Leaks, so you wouldn't really be avoiding leaks by using Jass, but yes, the tools and functions Jass offers can improve performance.

The number of units in the game is what really lowers the overall performance. That being said, if you're experiencing "lag spikes" where the game freezes for a moment and then resumes, this is either due to Models being loaded in for the first time (which only happens once so it's not a serious issue), OR the bigger issue, a trigger that does too many expensive things at once. In your case, spawning 100+ units at the same time every 2 seconds would definitely be expensive, especially since you're creating 1000's of memory leaks and checking 1000's of Conditions each time.

To give you an example of how to avoid this problem I attached a map with a spawn system I threw together. It's most likely missing things that your spawn system has to offer but I did make it account for Spawn Limit and Spawn Priority. Note that I wasn't 100% sure how Spawn Priority worked so I did what I thought made the most sense. If you take a look at the triggers in the map you can see that it's pretty basic, I'm using a Hashtable to link each Barracks to a Trigger that is run periodically. This trigger can be customized to spawn units in a specific order with specific amounts. Each spawned unit has it's limit saved in the Hashtable making it easy to prevent them from spawning while the limit is reached.

The goal was to remove any and all unnecessary Conditions and instead make a more function based approach. This way the Human Barracks for example doesn't have to check Conditions related to other Barracks-Types, it does a very specific thing. This removes the need for many unnecessary and taxing conditions and allows for deeper customization.

Things I left out:
One thing I left out that I think may help is if you used Timers to space out the spawning of units. For example, a Spawn Timer expires, a Barracks gets ready to spawn 4 Footman, 2 Rifleman, and 1 Knight, and then another Timer runs once every 0.05 seconds which spawns each unit sequentially. This way the 7 units are spawned over the course of 0.35 seconds instead of instantaneously. This would work best with Local timers or some kind of Timer system, ideally something done in Jass.

Also, I didn't account for Barracks being destroyed. But all you need to do is remove the (dying) Barracks from the SpawnBarracks Unit Group.

 

[Barade]

thx I will rethink how the spawn system should work. It is much easier with vJass and structs to create one and set the unit priorities etc. I think I can improve the map a lot by using a faster/better system and again I will reduce the number of units/make them stronger maybe.

 

[Wrda]

Also, you don't take full advantage of the ELSE in your If Then Else statements.
Looking at the trigger Change Unit Type Event as an example, you ask at least 15 "questions" in there despite the fact that only 1 of them can be true. If you used the ELSE the way it's intended to be used, the logic would be a lot more efficient. For example like this:

• Actions
  • Set Variable DiceRoll = (Random integer number between 1 and 3)
  • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
    • If - Conditions
      • DiceRoll Equal to 1
    • Then - Actions
      • Game - Display to (All players) for 30.00 seconds the text: Rolled 1
    • Else - Actions
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • DiceRoll Equal to 2
        • Then - Actions
          • Game - Display to (All players) for 30.00 seconds the text: Rolled 2
        • Else - Actions
          • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
            • If - Conditions
              • DiceRoll Equal to 3
            • Then - Actions
              • Game - Display to (All players) for 30.00 seconds the text: Rolled 3
            • Else - Actions

Like this the logic doesn't need to check if DiceRoll is equal to 2 or 3 if it rolled 1. And it doesn't need to check if it's equal to 3 if it rolled 2. However, in the case that it rolled 3, it would still have to do all 3 checks. But regardless, it will be more efficient most of the time.

You don't even need to check if it rolled 3, because if you know the roll must be limited to 1-3, then you only need to check if it rolled 1, if that fails, then check if it rolled 2, if it fails, then you know the only option left is that it rolled 3.

 

[Dr Super Good]

Reforged engine sucks (I think it lags with classic as well, can try it again).

Make sure it still lags with classic graphics. If the lag goes away then it is an issue with the overhead of the reforged graphics. Possibly your GPU is not powerful enough or there is an issue with optimisation of the new graphic engine.

I have installed Reforged on an external disk (no SSD etc.).

SSD should improve load times and frame time consistency. It should not improve average frame rate unless the game is literally loading something every frame or two.

The recording software OBS. The recording might cause additional performance issues or the recording itself simply lags?

OBS adds significant overhead and if bottlenecked can create laggy recordings.

With modern GPUs you might be able to use a GPU hardware encoder to significantly improve encoding performance. These are dedicated pieces of silicon on the GPU to handle encoding operations. As they are dedicated, it means they do not directly compete for computation resources with the rest of the GPU, but do still compete with bandwidth and power so will still have a small impact on performance. Logically if the encoder is overloaded, there will be issues such as poor frame rate in the resulting stream which are not present in the original source.

If you have a modern multi core CPU then CPU encoding at high frame rate is still viable, but will always have a larger performance impact. Competing for memory bandwidth, cache and power with the game. If your CPU does not have enough cores, to the point OBS competes with the game at a scheduler level, then performance will tank both in game and in the resulting stream.

My laptop/hardware is not the best out there.

With laptops it can even be thermal related as both GPUs and CPU will downclock if running too hot. If unit integrated graphics it could be due to running out of memory (make sure a few GB are still free when playing). Unless your laptop is a reasonably modern, reasonably expensive gaming laptop then expect poor performance like this. Only in the last few years have they started to be able to cram comparable desktop performance into a laptop, in part due to improvements with energy efficiency.

The number of units fighting or spawned.

Number of units is seldom a direct issue in Warcraft III, unless operates that select units are involved. Units fighting can fall into this category as both target acquisition and splash damage need to select units.

I noticed the map has some long range siege weapons. You can try removing those temporarily to see if they improve performance. I recall from a very old LoaP map with silly units that long range units can cause performance issues. This is likely due them being able to select from a lot of, or even all, units on the map which need to be evaluated to find a target to attack.

1 unit is spawned every 2 seconds for 8 players. The spawn trigger might not be really performant since it goes through 8 barracks and for each barrack through priorities 1-10 and then through like 20 unit types every 2 seconds only to find the first unit type possible to spawn. If executing triggers is really slow, this might cause the problem since it is executed every 2 seconds.

12,800 operations every 2 seconds could cause performance issues, specifically this would be frame time consistency due to having to drop a frame if execution takes long. You could try staggering it to 1,600 operations every 0.25 seconds by offsetting the spawns for each player. It could be further staggered at a different granularity as well but below 0.02 seconds is likely to not improve frame time consistency.

Using more complex data structures there might be other optimisations to be had avoiding the number of operations needed to be executed possibly by removing or decreasing the size of some of the loops. Without knowing the implementation I cannot give more specific suggestions.

The missiles of the Trebuchets (someone said online that this might lag?!).

A lot of missiles in the air can lag. However you are looking at hundreds and not a few dozen, at least for a reasonably modern computer.

If the glaive thrower's pierce functionality is used then that is a well known cause of performance issues. Even a few glaive throwers impacting all the time can cause a significant reduction in frame rate.

My triggers of which some run every X seconds.

These can cause performance issues if a lot are firing all the time. However it depends on the complexity of the trigger firing. Triggers that iterate a lot of units on the map are well known to cause performance issues.

 

[Barade]

thx about the long ranged missiles. They attack one ground target where the flag is. I could disable their auto aiming when the players do not use this one single target.

 

[SebioL]

With just a few more tests after getting back to working with my "full Tiny" maps, I think I've figured out what their biggest tormentor would be for their low FPS rate.
After all, if you claim that even in the SD version there are still some FPS jumps, maybe it's not so much the fault of the Reforged graphics and not so much that your machine can't keep up with the demands of many HD models, you can rule that out, I think !
Huge amount of units on the map confronting each other wouldn't be either, I managed to fight a battle at a medieval level and despite not being in HD and no unit having large area effects abilities, at least once again I proved that the WC3 engine it can handle about a few thousand units fighting simultaneously in various parts of the map.
Leaks? can still occur and contribute to lower rates even in the SD version, however, even if you fix it as much as possible, it could be that leaks are not the main source of your problems either..

You will find out exactly if, this time, you tested the map without the use of "distance throwers"...
Perhaps Dr.SuperGood has once again hit the nail on the head. I unexpectedly found out what caused a leak in my massive battles. My map has drastic changes in scale and data for all my units, but I forgot some units from one of the AIs, inadvertently these still had some units in scale, speed, acquisition distances, collisions, attacks, all within the standard data.
In the difference between some of these and other "tiny" units in massive amounts confronting, I realized that the problem was not the colossal amount of units on the map, maybe Wc3 can do well with massive amounts confronting, the problem is not exactly the number , but its simultaneous ratio of massive effects that have a limitation for the game engine, the massive acquisitions of units to perform mainly "area of effect" tasks at the same time, perhaps are the cause of the main lags. And confirmation of a real limitation of Wc3 mechanics for counting mass units.
Your Trebuchets can have very large acquisition areas, causing huge action consumption when reacting with too many units, similarly to what happened with my map lags, whenever the larger units (datas in standards) faced a large amount of units (tiny-modified) in its attack acquisition and effects of area, caused absurd crashes, already in clashes between units with acquisition requirements for balanced magnitudes, clashes occurred clean of any lags.

In your case, you can try to lower the attack speed of catapults, try to further reduce your attack range or remove some. I realized that they shoot very fast (creating a larger loop for requesting units), in addition to being a lot and still requiring a huge amount of units within their acquisition ranges.
ps: And for WC3 it would really be good to adapt to massive amounts of units, to bring more alternatives for different users, as the new AoE 4, besides being a good micro, brought a colossal macro-management excellent of units, exceeding 1000 per player (just needing to adjust the AI a little more), many players of WC3 and Sc2 will feel aroused, if the new competitor RTS offers a Map Editor that works. Meanwhile, the Blizz stopped in the time!

 

[Dr Super Good]

And for WC3 it would really be good to adapt to massive amounts of units, to bring more alternatives for different users, as the new AoE 4, besides being a good micro, brought a colossal macro-management excellent of units, exceeding 1000 per player (just needing to adjust the AI a little more), many players of WC3 and Sc2 will feel aroused, if the new competitor RTS offers a Map Editor that works. Meanwhile, the Blizz stopped in the time!

StarCraft II also supports thousands of units without issues. Unless the map maker does something computationally intensive with them of course.

 

[SebioL]

StarCraft II also supports thousands of units without issues. Unless the map maker does something computationally intensive with them of course.

I like to make maps and AI Scripts for battle with massive amounts of units and ironically I like to play WC3 even facing as many problems as the limitations that the engine requires, most WC3 modders are afraid of this or have given up on the search for alternatives that circumvent limitations. But i don't, even though I'm not a good technical expert in programming or system computers, I always had perseverance, managing to get rid of almost all limitations. Whether using systems that generate groups of battalions with different types of players, moving at the same time, or even reducing the size of units. I've been asked why I never migrated to Sc2, but how could I... I particularly like the practicality and layout of our dear WE's tools. Lol

I also noticed that, in your case, there are many players. There is another discovery, worth mentioning and I forgot to emphasize, if you are playing in these conditions of excessive amount of units for each playable player :

After many observations... I identified one more limit in the mechanics of our archaic WC3. And this is again related to the number of units per player, but I'm not referring to the issue of Collisions, you can get a solution for collisions and move large armies, just drastically reduce the Collision, decreasing the unit scale and creating movement speeds for values less than 65 or by other juggling alternatives you can find. The issue is now another, the problem exists in a limited computational readability for massive combats between units per players.
I noticed that the game becomes very demanding for the WC3 engine when you accumulate a large amount of units for a single playable player, the more players in these conditions, the greater will be your lags frustrations.

Try to keep a reduction in the amount of units only per "Playable Player", if you have many players, do not exceed 150 units for each active player. Go above 100 as long as you wish to play with only a maximum of 3 Active Players.
Warcraft 3 is a Micro game, so it considers an abundance of details and information for each feature. You creating many Script AI, makes the demands of the units much higher, and having large proportions of units for many activated players, this will generate overload in each unit owned, making the problems clear only when there are massive combats between these players. I can't essentially identify what this is due to, after all, inactive players can clash almost unlimitedly, maybe this only happens for the players active ones by generating many information loops, in the declaration of dead units or for new AI Script request actions.
Even with all the information accumulated in reading new attack acquisitions, between new movement requests and how many times they are receiving simultaneous requests throughout a battle, it is noticed that this is not serious for "non-playable" units, especially if they are simple units (without many abilities and effects). It is concluded that for Wc3, only "playable" units will really have a limitation in their accounting, but depending only and strictly on what they are doing, whether they are standing still or just walking, you can be safe with as many units as possible. want (10k?), but if they are in significant quantities to receive an order that can trigger new actions that are simultaneously related to some kind of performance counter (Ranking) of all "Players" in the score map, as in repercussion created per a massive combat, creating in a short space of time a loop of "dead" / "killed" / "experiences to be gained"... , all this to be identified for each Player... this in itself, already configures a maximum memory accumulation per seconds that the game engine supports.
So the question would be, how many playable units can you have on the map and depending on that amount, how many related to that amount you want, would be the limit for them to be able to enter a combat simultaneously, without impacting any visible lag? Well, I believe that for a map with 1000 playable units, a little more than 500 could simultaneously enter a combat, perhaps?

By my tests, for example, relating these numbers to the number of players, 5 playable players with 300 units each, will witness very high Lags when there is a confrontation of two armies of 300 (x2), totaling 600 units confronting, until the end of the battle with the dead units, this will result in a accumulation of information for the engine to retrieve all units and their exact matches by each player.
The greater the number of playable units and players, biggest the headache you will have. Another proof of this relationship, per example, is that you can have a clean battle of 3000 x 3000 units in Warcraft (it's possible), all being distributed among various types of players, but as long as these opposing players are not active (playable) on the map. Since the old WE, we've heard that the maximum amount of pre-placed units cannot exceed 4320 units, but through triggers, the game supports much more than that, and even confronting each other, but to you not to experience this type of lag, you will solve distributing the Spawns of large amounts of units being inserted in the map only by "Unplayable" players.
I have never seen a WC3 video on the internet with 2000 vs 2000 split only between 2 players, because of course there will be tremendous Lags. (and these delays, I'm not referring to the classic "stop and go" of collisions).
In short, the problem is not so much in the amount of units facing each other, you can solve this by distributing to inactive players, just inserting them into alliances, but you will have to support problems in computational readability when you exceed 200 combatant units in between numberless players with actived Ai Script to dispute for the victory of map.

 

[FeelsGoodMan]

I haven't read through all the replies, sorry if I suggest something that has already suggested but I have noticed that shadows are extremely resource intensive, especially when there are a lot of models on screen. Try disabling shadows completely and see if that makes it better.