Hey, Can any of you guys think of a way to remove events from a trigger?
The only way I can think of is to destroy it then recreate it. But the application I hope to use this for requires a universal trigger that is shared between all players.
For example, if I add an event that is based on player 1, and a different event for player 2, attached to a trigger that increments a players value by 1.
Player 1 needs to accumulate a value of 10, while player 2 must accumulate a value of 20 before their respective events are removed.
This way destroying the trigger when player 1 reaches 10 would stop player 2 from ever reaching 20 as player 2's even is destroyed along with it.
This could be fixed by reapplying player 2's event. But I was wondering if there is a better workaround to this.
A different approach would be to interconnect other triggers which only run your main trigger.
So for every event you want to apply to your main trigger you would create a new trigger.
I drew you a pic :3
Whether it's a better way of doing it? I don't know.
I think it would be useful with you have lots of events on your main trigger. If it's just one per player then your initial idea is probably better.
This looks much more feasible than my idea. Every player has his own dedicated event trigger right? This way when player 1 triggers gets enough markers, I can just destroy his trigger and recreate with a different event later when it's needed again. A good way to recycle triggers IMO. Do you agree that this would work?
It's for quest tracking. If I have 50 quests that all respond to different events, that means i'd need 50 conditions in an annoying cascade of if-else or switch, which i feel is kinda.. inefficient? =/
Trigger destroy only removes the events bound to a trigger variable - it won't do anything to the actual code that the triggers point to. So you can use
triggert1=TriggerCreate("myfunc");triggert2=TriggerCreate("myfunc");TriggerAddEvent(t1,...);TriggerAddEvent(t2,...);TriggerDestroy(t1);// will not affect t2
Personally I would Write one trigger to handle all the quests(it wouldnt handle the actually tasks of the quests just adding and removing players from quests.) for all players
This would involve very complicated switches and such
Doing a seperate trigger for each player i would think would make things maybe a bit simplier at first but... when you find bugs... you would have to make the changes to every players trigger which in the end is more complicated
As well has handling stuff you add. You would have to make the changes to every trigger rather then one.
As for the specific quests I would write a seperate trigger / function to handle the individual quests.
I would have variables that track what players are on what quests.
My over all quest handler would run checks to see what quests people are on and then checks to see if they have met the requirements to complete them.
I generally stick to the rule of.... if the same code is run against multiple players the code should be written to handle multiple players rather then seperate chunks of code FOR each player
As well as the quests - the quests should be written to handle all the players as well.
All and all a quest tracking system could end up being alot more complicated then it sounds at first
All players would use the same trigger actions. Not just a copy (in this case you really would have to change it for everyone individually) but they would literally use the same script. But there would be several triggers, so every player can have his own events.
And I would agree that, if you only have a few conditions, such a handler would be a better solution.
But with 50+ condition it'd be horribly long and ugly.
So.. In theory By destroying t2, t1 would not be destroyed along with it right?
Yes, it's not exactly what I meant in the first place, but it's probably an even better solution.
But if you use something like this you should make sure to have as little conditions as possible in that function and have this event be as exact as possible.
So instead of "Any unit dies" and "dying unit == xx" you should immediately use "xx dies". Otherwise you'd just have one trigger for each players which ALL get executed all the time.
As well has handling stuff you add. You would have to make the changes to every trigger rather then one.
As for the specific quests I would write a seperate trigger / function to handle the individual quests.
I would have variables that track what players are on what quests.
My over all quest handler would run checks to see what quests people are on and then checks to see if they have met the requirements to complete them.
I generally stick to the rule of.... if the same code is run against multiple players the code should be written to handle multiple players rather then seperate chunks of code FOR each player
As well as the quests - the quests should be written to handle all the players as well.
What I currently have is a quest handler that can pretty much perfectly track what quest every player is doing and cross them off once it's done. Similar to you, I do not support the idea of using separate chunks of code for each player. I make it a habit to reuse my functions wherever I can. Main point here is that i'm trying to have 1 trigger to handle all quests via quest indexing (track which quest was chosen and attach the event accordingly) as opposed to 1 trigger to handle each quest. I don't think events can be stored in an array though, so there probably won't be any escape from switch when it comes to adding events. But it's still better as opposed to having a messy pile of conditions IMHO.
A different approach would be to interconnect other triggers which only run your main trigger.
So for every event you want to apply to your main trigger you would create a new trigger.
I drew you a pic :3
Whether it's a better way of doing it? I don't know.
I think it would be useful with you have lots of events on your main trigger. If it's just one per player then your initial idea is probably better.
I thought i would give an extra approch to this you should keep in mind. The idea s3rius had posted first has one very nice extra possibility and thats multithreading
Check out this page sc2mapster multitreading topic
If the triggers have alot of actions and dont use the same global variable then this could prove to be a very nice preformance gain ingame.
I have been testing quite abit with multi threading to see if it actually works and i can say it most definitly does.
On my core i7 that is. Dont know how older systems handel it but i expect that any multi core proccesor would show major benefits using this tech
Are you working with galaxy?.. Because i tried getting multithreading to work with custom script. didn't have much luck.
Mutlithreading is basically just creating a trigger and running it.
Every instance of a trigger is created as a new thread.
Even GUI does it that way - it creates a dublicate of the function which is used as a trigger function, then passes the parameters using global variables.
@s3rius: Go
Sorry for bumping this up. Got one more question regarding trigger events and I felt it was appropriate to post it here.
I'm currently in a coding situation where I am forced to recreate dialogs whenever I need them. Recycling is not an option due to some design constraints.
I'd like to understand better how the game engine handles trigger events.
If I have a dialog d, with a dialog control item dc assigned to a trigger t upon clicks. And I destroy dialog d. Will it correctly remove the event where dc is clicked from trigger t? Or will the events attached to t continue to increase taking up memory? If this is a yes, It's a potential memory hazard from what I understand..
If that is the case its gonna be kinda shitty because I'd have to make 1 trigger for each dialog instance and destroy each associated trigger appropriately whenever a dialog instance is destroyed -_-
It'll probably clean up nicely.
Dialog items are represented by integers, These integers do get recycled if I'm not completely mistaken. So to prevent that a recycled number suddenly can fire triggers it isn't supposed to anymore it'll probably clean up nicely.
It also really depends on how they handle it internally. It might be that they store the event information not in the trigger but in the object which fires the event. In this case it'd be surely cleaned up when the object is destroyed.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Hey, Can any of you guys think of a way to remove events from a trigger? The only way I can think of is to destroy it then recreate it. But the application I hope to use this for requires a universal trigger that is shared between all players.
For example, if I add an event that is based on player 1, and a different event for player 2, attached to a trigger that increments a players value by 1. Player 1 needs to accumulate a value of 10, while player 2 must accumulate a value of 20 before their respective events are removed.
This way destroying the trigger when player 1 reaches 10 would stop player 2 from ever reaching 20 as player 2's even is destroyed along with it. This could be fixed by reapplying player 2's event. But I was wondering if there is a better workaround to this.
Any thoughts?
A different approach would be to interconnect other triggers which only run your main trigger.
So for every event you want to apply to your main trigger you would create a new trigger.
I drew you a pic :3
Whether it's a better way of doing it? I don't know.
I think it would be useful with you have lots of events on your main trigger. If it's just one per player then your initial idea is probably better.
Why mess around with the events at all....
Just use conditions and variables to track whether or not it should actually increment something
@s3rius: Go
This looks much more feasible than my idea. Every player has his own dedicated event trigger right? This way when player 1 triggers gets enough markers, I can just destroy his trigger and recreate with a different event later when it's needed again. A good way to recycle triggers IMO. Do you agree that this would work?
Then attach a mouse click event for player 1 to t1, and a keyboard press event for player 2 to t2.
So.. In theory By destroying t2, t1 would not be destroyed along with it right?
@SouLCarveRR: Go
It's for quest tracking. If I have 50 quests that all respond to different events, that means i'd need 50 conditions in an annoying cascade of if-else or switch, which i feel is kinda.. inefficient? =/
Trigger destroy only removes the events bound to a trigger variable - it won't do anything to the actual code that the triggers point to. So you can use
@FuzzYD: Go
Personally I would Write one trigger to handle all the quests(it wouldnt handle the actually tasks of the quests just adding and removing players from quests.) for all players
This would involve very complicated switches and such
Doing a seperate trigger for each player i would think would make things maybe a bit simplier at first but... when you find bugs... you would have to make the changes to every players trigger which in the end is more complicated
As well has handling stuff you add. You would have to make the changes to every trigger rather then one.
As for the specific quests I would write a seperate trigger / function to handle the individual quests.
I would have variables that track what players are on what quests.
My over all quest handler would run checks to see what quests people are on and then checks to see if they have met the requirements to complete them.
I generally stick to the rule of.... if the same code is run against multiple players the code should be written to handle multiple players rather then seperate chunks of code FOR each player
As well as the quests - the quests should be written to handle all the players as well.
All and all a quest tracking system could end up being alot more complicated then it sounds at first
GOOD LUCK
@SouLCarveRR: Go
All players would use the same trigger actions. Not just a copy (in this case you really would have to change it for everyone individually) but they would literally use the same script. But there would be several triggers, so every player can have his own events.
And I would agree that, if you only have a few conditions, such a handler would be a better solution.
But with 50+ condition it'd be horribly long and ugly.
Yes, it's not exactly what I meant in the first place, but it's probably an even better solution.
But if you use something like this you should make sure to have as little conditions as possible in that function and have this event be as exact as possible.
So instead of "Any unit dies" and "dying unit == xx" you should immediately use "xx dies". Otherwise you'd just have one trigger for each players which ALL get executed all the time.
@s3rius: Go
Great. Thanks for the feedback everyone :)
What I currently have is a quest handler that can pretty much perfectly track what quest every player is doing and cross them off once it's done. Similar to you, I do not support the idea of using separate chunks of code for each player. I make it a habit to reuse my functions wherever I can. Main point here is that i'm trying to have 1 trigger to handle all quests via quest indexing (track which quest was chosen and attach the event accordingly) as opposed to 1 trigger to handle each quest. I don't think events can be stored in an array though, so there probably won't be any escape from switch when it comes to adding events. But it's still better as opposed to having a messy pile of conditions IMHO.
I thought i would give an extra approch to this you should keep in mind. The idea s3rius had posted first has one very nice extra possibility and thats multithreading Check out this page sc2mapster multitreading topic
If the triggers have alot of actions and dont use the same global variable then this could prove to be a very nice preformance gain ingame. I have been testing quite abit with multi threading to see if it actually works and i can say it most definitly does.
On my core i7 that is. Dont know how older systems handel it but i expect that any multi core proccesor would show major benefits using this tech
@Bezerker18: Go
Are you working with galaxy?.. Because i tried getting multithreading to work with custom script. didn't have much luck.
Mutlithreading is basically just creating a trigger and running it.
Every instance of a trigger is created as a new thread.
Even GUI does it that way - it creates a dublicate of the function which is used as a trigger function, then passes the parameters using global variables.
@s3rius: Go Sorry for bumping this up. Got one more question regarding trigger events and I felt it was appropriate to post it here.
I'm currently in a coding situation where I am forced to recreate dialogs whenever I need them. Recycling is not an option due to some design constraints. I'd like to understand better how the game engine handles trigger events.
If I have a dialog d, with a dialog control item dc assigned to a trigger t upon clicks. And I destroy dialog d. Will it correctly remove the event where dc is clicked from trigger t? Or will the events attached to t continue to increase taking up memory? If this is a yes, It's a potential memory hazard from what I understand..
If that is the case its gonna be kinda shitty because I'd have to make 1 trigger for each dialog instance and destroy each associated trigger appropriately whenever a dialog instance is destroyed -_-
@FuzzYD: Go
It'll probably clean up nicely.
Dialog items are represented by integers, These integers do get recycled if I'm not completely mistaken. So to prevent that a recycled number suddenly can fire triggers it isn't supposed to anymore it'll probably clean up nicely.
It also really depends on how they handle it internally. It might be that they store the event information not in the trigger but in the object which fires the event. In this case it'd be surely cleaned up when the object is destroyed.