[Solved] Text Tags slowing down game

[Br3akth3w1nd]

I found that the following code is making a huge impact on performance when there are multiple players in the game. Can someone help me rework it? This code is being called by another action that calls it for every active player. It also doesn't impact performance when playing single-player.

The goal is to display overhead text on units of any type and each text waits for the previous one before appearing, that's done by adding the unit to a unit group while other calls wait using the Wait for (Conditions).

The lag that appears from this somehow stays and piles on throughout the gameplay even when there are no texts displaying.

Edit 1: I can't confirm it yet, but i believe that it is caused by the fact that I am not removing the text tags after creation. After adding a destroy at the end, the lag no longer seems to pile on. I thought that Fade Out Duration would remove it on its own after its finished.

Edit 2: I managed to improve performance, in some cases, over 500 times. Proof:

I did this by editing the code like so:

I still can't confirm anything as all my testers are offline. After I release this map I will be releasing a library with useful functions like this one, hopefully all optimized by then. The library will depend on GAx3 and possibly Renee's Warcraft 3 mod.

Edit 3: I can confirm that the problem is fixed.

 

[Dr Super Good]

Edit 1: I can't confirm it yet, but i believe that it is caused by the fact that I am not removing the text tags after creation. After adding a destroy at the end, the lag no longer seems to pile on. I thought that Fade Out Duration would remove it on its own after its finished.

Edit 2: I managed to improve performance, in some cases, over 500 times. Proof:

Yes you need to remove them.

Warcraft III got around this with a 100 tag limit so one could not leak more than 100 before it recycled the last. WC3 also had auto destroy text tags after fade.

I still can't confirm anything as all my testers are offline. After I release this map I will be releasing a library with useful functions like this one, hopefully all optimized by then. The library will depend on GAx3 and possibly Renee's Warcraft 3 mod.

Well posting the problem is all you really had to do. Many people might be used to WC3 so not be aware that text tags can leak.

 

[Br3akth3w1nd]

Yes, and I don't think this is noted anywhere. Still, the fact that the text tag actions creates a thread might lead to an error where the script fails because there are too many threads, so this can't be used for too many units at the same time. I think I had about maybe 800+ units on the map when I got the error. I don't know what the thread limit is and if its dependent on the computer that runs the map.

 

[Dr Super Good]

I don't know what the thread limit is and if its dependent on the computer that runs the map.

These threads are galaxy virtual machine threads, they all run on the same physical thread.

One could solve the problem by making a thread manage many units at once. For example 32 units. In worst case, due to fragmentation, it would be no better than currently. In best case it would reduce the thread count by a division of 32.

One could also use data tables to map tags to units. One could then make a single thread handle all units.

 

[Br3akth3w1nd]

My initial hopes with threading was that I would get a performance boost out of it. I guess that is not the case.

Due to the nature of the action, handling multiple units at once will defeat the purpose of separate text tags for separate players waiting for each other, as when one tags 32 units, the logic needs to wait for some of these units until they are out of the text tag unit group, which would delay text tags in certain situations.

I'm not familiar with data tables yet, but I will try to educate myself on the topic and rework the code.

 

[Dr Super Good]

My initial hopes with threading was that I would get a performance boost out of it. I guess that is not the case.

It is not the case. Anyone who says otherwise has no idea about the complications of real simultaneous multi threading. There is a reason SC2 only uses 1-2 heavy physical threads in the first place...

 

[Br3akth3w1nd]

On that note, I've seen recent games like Battlefield 4 distribute load across all cores quite effectively, while I remember observing that Starcraft 2 puts most of its load on a single core. Multi-threading can be complicated, but if memory serves, Starcraft 2's Havok-based? engine has been in development for quite some time.

On a separate note, it is abnormal that the engine does not support adding abilities to units in-game. Even when I tried doing it with catalog commands, the game gave me a "permissions" error. I was thinking about making a system that changes the description of each button based on unit selection and using triggers to implement different abilities, but the Unit Selected event does not trigger quick enough and there's a bad delay that happens before any actions are executed. A similar system can be made with dialog with the same troubles. Users can work around this by possibly using items as custom abilities and positioning item slots on top of the command card.

Talking about the command card, it is also quite weird to me that buttons on units cannot be repositioned or added during gameplay. This might be possible with a Dialog hook, similar to what Renee uses to display item shop command cards to different players, but the scarcity of information on the subject makes it rather difficult.

 

[Dr Super Good]

Starcraft 2's Havok-based?

That is physics only.. Used for ragdolls.

On a separate note, it is abnormal that the engine does not support adding abilities to units in-game. Even when I tried doing it with catalog commands, the game gave me a "permissions" error.

That is because those fields cannot be upgraded.

I was thinking about making a system that changes the description of each button based on unit selection and using triggers to implement different abilities, but the Unit Selected event does not trigger quick enough and there's a bad delay that happens before any actions are executed.

That is synchronization lag, basically network latency.

Talking about the command card, it is also quite weird to me that buttons on units cannot be repositioned or added during gameplay. This might be possible with a Dialog hook, similar to what Renee uses to display item shop command cards to different players, but the scarcity of information on the subject makes it rather difficult.

One generally does not need to change buttons during game play.

 

[Br3akth3w1nd]

I can confirm that the problem is now fixed, with my fps now hitting above 70 in multiplayer.

The need to change buttons arises from the fact that spells cannot be added to units. Changing buttons can be a simple workaround, one can just add all needed spells and then assign a button for each spell in the command card and simply swap them around depending on the abilities that the player has chosen. I suppose maps like Custom Hero Arena would be impossible to make using the Data Editor, where a hero can choose from more than 100 abilities.

 

[Dr Super Good]

The need to change buttons arises from the fact that spells cannot be added to units. Changing buttons can be a simple workaround, one can just add all needed spells and then assign a button for each spell in the command card and simply swap them around depending on the abilities that the player has chosen. I suppose maps like Custom Hero Arena would be impossible to make using the Data Editor, where a hero can choose from more than 100 abilities.

Such maps being flawed by design aside, people have made them for SC2 already.

One modifies the effect chain and button data for the player. Sure it is only MPI rather than MUI but it is often good enough. One can also stack buttons over the same command card slot and use requirements to hide them.

 

[Br3akth3w1nd]

Such maps being flawed by design aside, people have made them for SC2 already.

One modifies the effect chain and button data for the player. Sure it is only MPI rather than MUI but it is often good enough. One can also stack buttons over the same command card slot and use requirements to hide them.

One could also use the Train ability (up to 30 different effects) and detect the command with a trigger to expand the number of abilities, as each ability in train has its own different ability command.

For my map I was planning to have 50 abilities, and each unit can acquire a random ability during gameplay, up to 5 abilities per unit. That's when I hit all these limitations and I have decided that using items will be the easiest way to go about it. I cannot wait to find out what surprises the inventory system will throw my way.

Also I recently noticed that, any Behavior of type Buff with a Unit Modification type "Life Armor Multiplier" is seemingly bugged, as it does nothing on the unit. While "Life Armor Bonus" works well, "Life Armor Multiplier" does not multiply the armor that the unit already has, which is how the other multiplier modifications work. It is possible that it multiplies the Life Armor Bonus modification, but that seems unlikely and unneeded.

 

[Dr Super Good]

One could also use the Train ability (up to 30 different effects) and detect the command with a trigger to expand the number of abilities, as each ability in train has its own different ability command.

Would an augment ability not be better suited?

Also I recently noticed that, any Behavior of type Buff with a Unit Modification type "Life Armor Multiplier" is seemingly bugged, as it does nothing on the unit. While "Life Armor Bonus" works well, "Life Armor Multiplier" does not multiply the armor that the unit already has, which is how the other multiplier modifications work. It is possible that it multiplies the Life Armor Bonus modification, but that seems unlikely and unneeded.

No idea about that. However unless using a WC3 style armor system it is ill recommended to use multipliers due to how SC2 armor works. It is very easy to get units with so much armor they are as good as unable to die.