For whatever reason, I've got 2 triggers that seem to have faulty events. They both worked before I took an extended break from the map, but I deem it unlikely that they were broken in a patch. In both cases I have removed all conditions to see if they were causing the problems (which they are apparently not).
The first is "Unit Uses Ability", firing when a unit executes the ability "LeaveBase - Abandon Base" (it's a dummy ability that has a dummy effect):
Unit - Any Unit uses LeaveBase - Abandon Base at Generic3 - Execute stage (Ignore shared abilities)
The second is a "Unit Research Progress", firing when a unit completes research of an upgrade. At this point of debugging any upgrade should activate it, though in there end it will be 1 of 6:
Unit - Any Unit research progress is Completed
I see nothing wrong with the events, and the triggers will run if I use the "trigrun" command (with expected errors). I don't know if that makes them run if they are enabled/initially on, but the triggers are both of those regardless. Am I missing something, or is there another way to get these same events?
If you crash the trigger initialization thread during map load (which registers triggers with their events) then you will get something similar to what you describe (some trigger events fail to work while others still work). How it could possibly be crashing I am unsure but hopefully some error should be printed in the trigger debugger.
Hopefully events are attached sequentially in the order triggers are declared by the Trigger editor. In which case the trigger/element directly before the first one with broken events will be the cause.
If you are not familiar with how Galaxy triggers work here is a brief explanation. The actions and conditions of a trigger are placed inside a function which takes and returns various standard parameters (I recall it takes 2 bool and returns a bool but have not used SC2E in a while so am unsure). A trigger object is then constructed by passing it the function name in the form of a string. This trigger object can be passed to various event registration natives which all take a trigger and some appropriate arguments for their purpose.
If the trigger object fails to be created or the event registry natives are never called then the trigger will not work as its code is un-reachable. To some extent you can use the trigger debugger to test if the trigger object is created as it will list all current trigger objects in one of the panels.
It is possible that something else might also be the cause of the problem (eg another trigger turning that trigger off, or perhapse too many events of the same type, who knows what else it could be). If you still need help finding the cause of the problem after reading the above it is recommend you provide the map so experts can investigate it.
Thanks for the info; it's good to know how triggers actually work. I doubled checked my triggers referencing the 2 in question. The research one was getting turned off instead of on, simple enough but still gave me enough problems (I recreated the trigger action by action until I got far enough to realize I need to double check everything). Going to wack my head against a wall for that one.
I'm still working on the "unit uses ability". I've checked enough of the trigger, and created other functional test triggers, that I'm resorting to the "ability isn't acting as ability anymore". I'm not terribly convinced, but I can't find another reason. Maybe something changed and my ability won't execute yet the button still does, or - because it doesn't have an effect that does something - it won't trigger any ability execution stage (even generic - any).
I wanted to avoid the "button pressed" event because the trigger isn't important enough to warrant the excessive stress on clients. I ended up adding "cancel attack orders" to the dummy ability's effect (the unit can't attack anyways) and suddenly everything works.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
For whatever reason, I've got 2 triggers that seem to have faulty events. They both worked before I took an extended break from the map, but I deem it unlikely that they were broken in a patch. In both cases I have removed all conditions to see if they were causing the problems (which they are apparently not).
The first is "Unit Uses Ability", firing when a unit executes the ability "LeaveBase - Abandon Base" (it's a dummy ability that has a dummy effect): Unit - Any Unit uses LeaveBase - Abandon Base at Generic3 - Execute stage (Ignore shared abilities)
The second is a "Unit Research Progress", firing when a unit completes research of an upgrade. At this point of debugging any upgrade should activate it, though in there end it will be 1 of 6: Unit - Any Unit research progress is Completed
I see nothing wrong with the events, and the triggers will run if I use the "trigrun" command (with expected errors). I don't know if that makes them run if they are enabled/initially on, but the triggers are both of those regardless. Am I missing something, or is there another way to get these same events?
If you crash the trigger initialization thread during map load (which registers triggers with their events) then you will get something similar to what you describe (some trigger events fail to work while others still work). How it could possibly be crashing I am unsure but hopefully some error should be printed in the trigger debugger.
Hopefully events are attached sequentially in the order triggers are declared by the Trigger editor. In which case the trigger/element directly before the first one with broken events will be the cause.
If you are not familiar with how Galaxy triggers work here is a brief explanation. The actions and conditions of a trigger are placed inside a function which takes and returns various standard parameters (I recall it takes 2 bool and returns a bool but have not used SC2E in a while so am unsure). A trigger object is then constructed by passing it the function name in the form of a string. This trigger object can be passed to various event registration natives which all take a trigger and some appropriate arguments for their purpose.
If the trigger object fails to be created or the event registry natives are never called then the trigger will not work as its code is un-reachable. To some extent you can use the trigger debugger to test if the trigger object is created as it will list all current trigger objects in one of the panels.
It is possible that something else might also be the cause of the problem (eg another trigger turning that trigger off, or perhapse too many events of the same type, who knows what else it could be). If you still need help finding the cause of the problem after reading the above it is recommend you provide the map so experts can investigate it.
Thanks for the info; it's good to know how triggers actually work. I doubled checked my triggers referencing the 2 in question. The research one was getting turned off instead of on, simple enough but still gave me enough problems (I recreated the trigger action by action until I got far enough to realize I need to double check everything). Going to wack my head against a wall for that one.
I'm still working on the "unit uses ability". I've checked enough of the trigger, and created other functional test triggers, that I'm resorting to the "ability isn't acting as ability anymore". I'm not terribly convinced, but I can't find another reason. Maybe something changed and my ability won't execute yet the button still does, or - because it doesn't have an effect that does something - it won't trigger any ability execution stage (even generic - any).
@Landmine752: Go
I'm assuming the ability is an instant and has a default button right? If that's the case, there's always the "Button Pressed" event.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
@willuwontu: Go
I wanted to avoid the "button pressed" event because the trigger isn't important enough to warrant the excessive stress on clients. I ended up adding "cancel attack orders" to the dummy ability's effect (the unit can't attack anyways) and suddenly everything works.