I'm working on my first map, so I tend to learn things as a go, which means lots of going back and redoing things. One of my biggest worries has been the fact that I've been using a couple of very generic/common events such as "(Any Unit) enters (Region A)" or "(Any Unit) becomes idle". I have since learned that these sort of events are looked down upon because of how often they occur (namely how often their associated conditions have to be checked).
For example, using the debugger I discovered that when I have a couple Battlecruisers fighting in Region A (using the example events above), tons of events are firing off, both events firing for each projectile/missile that the Battlecruisers create when they attack. I don't want to perform any actions for those projectiles, so I of course have a condition that uses a unit filter to filter out the units that I don't want to actually trigger any actions, but this obviously still creates a bit of overhead for the CPU.
I looked into the possibility of adding events to triggers at runtime, which would allow me to specify exactly which units will cause events like that to fire off... but I'm wondering, before I go through the trouble, is it really worth it? Does this sort of thing really have a significant impact on the performance of the game?
Since those are pretty subjective questions, here's a few questions that have more direct answers:
1) Is there a limit to the number of events a single trigger can have? In some cases in my map triggers will end up with hundreds, maybe even thousands, of events throughout the course of a match. Can that be a bad thing?
2) Please correct me if I'm wrong: Keeping track of events is memory intensive. Checking conditions is CPU intensive. If I choose to use dynamic events (or whatever you want to call it), I generally will be sacrificing a bit of memory in exchange for less load on the CPU.
3) Has anyone had an experience (or can think of a situation) where adding events to triggers instead of using conditions actually turned out to be a bad thing?
Any thoughts and personal experience on the subject will be greatly appreciated. Thanks for all the help you guys have given me so far!
no matter what you will end up with big amount of event firing.
My personal approach is that i never use one type of event more than once. I redirect all data to custom actions and then they check is it their data and should they do their logic or not.
I use TriggerAddEvent only when i know i have some collection of objects which otherwise would have to be iterated thru. But that's only the case if i apply actions on triggering object itself, or is easy to identify linked object. Otherwise it makes no sense since i will have to iterate thru collection anyway.
For example i have "Create close button" action for dialogs. It takes dialog, creates button, adds the button event to initially empty trigger, and trigger only references dialog containing used item and hides it.
2 - You can't really say. Heck we don't know if it's for example unitA rising event directly or is found in similar manner as 'any'. There's not enough (if any) technical info about Galaxy.
3 - This is also somehow risky due mentioned lack of info. You don't know what happens with event if linked object does not exist anymore. Sometime it may result in 'Any'
3 - This is also somehow risky due mentioned lack of info. You don't know what happens with event if linked object does not exist anymore. Sometime it may result in 'Any'
Yes, I have noticed that behavior when I create an event that refers to a unit that doesn't exist at the time. However, I haven't ever had it break on me after a live-referenced unit dies... <crossing my fingers>
no matter what you will end up with big amount of event firing.
I'm not sure how I feel about that comment. By creating events on the fly I have in fact been able to reduce the amount of event firing significantly (by over 75% in some cases). But as I mentioned, my main concern is if there are any drawbacks to using this method that I haven't considered yet. I will keep your warning about non-existent objects in mind.
I'm working on my first map, so I tend to learn things as a go, which means lots of going back and redoing things. One of my biggest worries has been the fact that I've been using a couple of very generic/common events such as "(Any Unit) enters (Region A)" or "(Any Unit) becomes idle". I have since learned that these sort of events are looked down upon because of how often they occur (namely how often their associated conditions have to be checked).
For example, using the debugger I discovered that when I have a couple Battlecruisers fighting in Region A (using the example events above), tons of events are firing off, both events firing for each projectile/missile that the Battlecruisers create when they attack. I don't want to perform any actions for those projectiles, so I of course have a condition that uses a unit filter to filter out the units that I don't want to actually trigger any actions, but this obviously still creates a bit of overhead for the CPU.
I looked into the possibility of adding events to triggers at runtime, which would allow me to specify exactly which units will cause events like that to fire off... but I'm wondering, before I go through the trouble, is it really worth it? Does this sort of thing really have a significant impact on the performance of the game?
Since those are pretty subjective questions, here's a few questions that have more direct answers:
1) Is there a limit to the number of events a single trigger can have? In some cases in my map triggers will end up with hundreds, maybe even thousands, of events throughout the course of a match. Can that be a bad thing?
2) Please correct me if I'm wrong: Keeping track of events is memory intensive. Checking conditions is CPU intensive. If I choose to use dynamic events (or whatever you want to call it), I generally will be sacrificing a bit of memory in exchange for less load on the CPU.
3) Has anyone had an experience (or can think of a situation) where adding events to triggers instead of using conditions actually turned out to be a bad thing?
Any thoughts and personal experience on the subject will be greatly appreciated. Thanks for all the help you guys have given me so far!
no matter what you will end up with big amount of event firing.
My personal approach is that i never use one type of event more than once. I redirect all data to custom actions and then they check is it their data and should they do their logic or not.
I use TriggerAddEvent only when i know i have some collection of objects which otherwise would have to be iterated thru. But that's only the case if i apply actions on triggering object itself, or is easy to identify linked object. Otherwise it makes no sense since i will have to iterate thru collection anyway.
For example i have "Create close button" action for dialogs. It takes dialog, creates button, adds the button event to initially empty trigger, and trigger only references dialog containing used item and hides it.
2 - You can't really say. Heck we don't know if it's for example unitA rising event directly or is found in similar manner as 'any'. There's not enough (if any) technical info about Galaxy.
3 - This is also somehow risky due mentioned lack of info. You don't know what happens with event if linked object does not exist anymore. Sometime it may result in 'Any'
Yes, I have noticed that behavior when I create an event that refers to a unit that doesn't exist at the time. However, I haven't ever had it break on me after a live-referenced unit dies... <crossing my fingers>
I'm not sure how I feel about that comment. By creating events on the fly I have in fact been able to reduce the amount of event firing significantly (by over 75% in some cases). But as I mentioned, my main concern is if there are any drawbacks to using this method that I haven't considered yet. I will keep your warning about non-existent objects in mind.