No I have not checked the profile tabs, where exactly should I look for a time waster, just so I know exactly what I am looking for?
Order by execution time total (click header) and after 10 minutes check if there are some insane numbers sticking out. If a trigger/function is running up an execution time of 300 seconds over 10 minutes something is clearly wrong with it.
Late game performance problems are more likely caused by task leaks. This is when a data thread, trigger thread or actor is created and kept running for an extended period of time beyond its usefulness. Eventually enough tasks build up that game performance has to suffer as real time deadlines cannot be met.
Another form of late game performance problems are state complexity. What one might think of as trivial might turn out to be extremely complex to compute. If one uses this too much then eventually performance starts to suffer as game complexity increases. For example stacking a buff with a periodic effect 100 times, so as to allow its effect magnitude to increase, results in the periodic effect firing 100 times for 1 unit, instead of firing 1 time with a stronger effect. Do such a buff to 100 odd units with 100 stack count and performance might easily drop to be unplayable.
Tried using the trigger debugger/profiler? It allows you to see where most of the time is being spent in triggers. At such low frame rates some triggers/functions must be running up significant execution times.
The trigger debugger/profiler can only be run when testing a map from the editor and the game must be in windowed mode for it to be selectable. It can be turned on under the editor preferences (under File menu) when the game is set to test in Windowed mode (not available in full screen mode).
When the map is tested, a new window will pop up which is the trigger debugger/profiler. It works entirely from a galaxy level however within the galaxy trigger names it should be obvious which GUI trigger it corresponds with. If you start to see a trigger running up times such as 300 seconds execution time over 10 minutes there is probably the case of your performance problems. AI functions are also profiled so you can see if AI is the cause.
If no triggers run up high execution times, then it is a data problem.
I have been told not to use triggers like Any unit dies, any unit is created, unit takes damage, because they create lag, and I know this is true.
So are there any less laggy alternatives to using the 'any unit dies' event then a condition so the trigger only uses the unit marine (or events like this)?
I believe you are trying to prematurely optimize... Chances are a single trigger or some badly designed data will be cause for performance degradation before on death unit events like the one you listed above, even with dozens of such triggers.
Such events can cause performance problems however only if an excessive number of such triggers are running at the same time or if the workload is computationally intensive. Unit death is generally such an infrequent event that there is no problem having even 20 such events as long as the workload they run is light weight (eg not iterating through every unit on the map).
If you want this to happen only for marines then your current trigger solution is fine. If you want it for multiple unit types consider combining the triggers into a single trigger and using a case statement to filter for unit type. If you have other generic unit death events you can consider combining the triggers into a single trigger to reduce thread creation overhead.
The most efficient alternative would be to explicitly attach specific unit death events to a trigger for each unit of the type. This requires using the event bind natives as an action, something not part of the standard GUI library and must be manually added or added with a third party extension library. This way the trigger will only fire when those units die.
You can force a units actor to attach to another units actor like it is any other actor. Doing so will dissociate the actor with the unit's position, so it is recommended you make the unit follow the other unit around somehow, eg as an item carried by it, otherwise it might look very weird being able to attack the component nowhere near what it is attached to.
This is done simply by sending the unit actor you want to attach the other unit actor to an "Attach" actor message referencing the unit actor you want to attach and the appropriate attach location (direct, message and site op all are allowed and work so this really is flexible). Should work with both data and triggers. The problem with data is referencing the unit actor you want to attach with respects to the unit actor you want to attach it to. This is where triggers are much more flexible as you can pull both actors from unit references and then send the attach actor method using triggers. In either case you need to use a global actor reference, setup by a "RefSet" (Reference Set) message on the unit actor you want to attach, to instruct the Attach message what actor you want to attach.
You can undo the attachment and return the unit actor back to following its unit as normal by sending an invalid attachment, eg attaching to itself. This produces an error message which is sub optimal. As such there is likely a better way to do this which does not produce an error message however I am currently unaware of one.
1
Order by execution time total (click header) and after 10 minutes check if there are some insane numbers sticking out. If a trigger/function is running up an execution time of 300 seconds over 10 minutes something is clearly wrong with it.
Late game performance problems are more likely caused by task leaks. This is when a data thread, trigger thread or actor is created and kept running for an extended period of time beyond its usefulness. Eventually enough tasks build up that game performance has to suffer as real time deadlines cannot be met.
Another form of late game performance problems are state complexity. What one might think of as trivial might turn out to be extremely complex to compute. If one uses this too much then eventually performance starts to suffer as game complexity increases. For example stacking a buff with a periodic effect 100 times, so as to allow its effect magnitude to increase, results in the periodic effect firing 100 times for 1 unit, instead of firing 1 time with a stronger effect. Do such a buff to 100 odd units with 100 stack count and performance might easily drop to be unplayable.
1
So it is not a trigger problem then as after 10 minutes you checked the profile tabs and saw no major time waster?
1
Tried using the trigger debugger/profiler? It allows you to see where most of the time is being spent in triggers. At such low frame rates some triggers/functions must be running up significant execution times.
The trigger debugger/profiler can only be run when testing a map from the editor and the game must be in windowed mode for it to be selectable. It can be turned on under the editor preferences (under File menu) when the game is set to test in Windowed mode (not available in full screen mode).
When the map is tested, a new window will pop up which is the trigger debugger/profiler. It works entirely from a galaxy level however within the galaxy trigger names it should be obvious which GUI trigger it corresponds with. If you start to see a trigger running up times such as 300 seconds execution time over 10 minutes there is probably the case of your performance problems. AI functions are also profiled so you can see if AI is the cause.
If no triggers run up high execution times, then it is a data problem.
1
I believe you are trying to prematurely optimize... Chances are a single trigger or some badly designed data will be cause for performance degradation before on death unit events like the one you listed above, even with dozens of such triggers.
Such events can cause performance problems however only if an excessive number of such triggers are running at the same time or if the workload is computationally intensive. Unit death is generally such an infrequent event that there is no problem having even 20 such events as long as the workload they run is light weight (eg not iterating through every unit on the map).
If you want this to happen only for marines then your current trigger solution is fine. If you want it for multiple unit types consider combining the triggers into a single trigger and using a case statement to filter for unit type. If you have other generic unit death events you can consider combining the triggers into a single trigger to reduce thread creation overhead.
The most efficient alternative would be to explicitly attach specific unit death events to a trigger for each unit of the type. This requires using the event bind natives as an action, something not part of the standard GUI library and must be manually added or added with a third party extension library. This way the trigger will only fire when those units die.
0.957831325301205
You can force a units actor to attach to another units actor like it is any other actor. Doing so will dissociate the actor with the unit's position, so it is recommended you make the unit follow the other unit around somehow, eg as an item carried by it, otherwise it might look very weird being able to attack the component nowhere near what it is attached to.
This is done simply by sending the unit actor you want to attach the other unit actor to an "Attach" actor message referencing the unit actor you want to attach and the appropriate attach location (direct, message and site op all are allowed and work so this really is flexible). Should work with both data and triggers. The problem with data is referencing the unit actor you want to attach with respects to the unit actor you want to attach it to. This is where triggers are much more flexible as you can pull both actors from unit references and then send the attach actor method using triggers. In either case you need to use a global actor reference, setup by a "RefSet" (Reference Set) message on the unit actor you want to attach, to instruct the Attach message what actor you want to attach.
You can undo the attachment and return the unit actor back to following its unit as normal by sending an invalid attachment, eg attaching to itself. This produces an error message which is sub optimal. As such there is likely a better way to do this which does not produce an error message however I am currently unaware of one.