So the impression I am getting is that if you can do something with the data editor instead of the trigger editor, your game will be better off. I have been dinking around with the editor since release and I feel like I am starting to get the hang of it.. however, for me at least, the trigger editor seems a lot more intuitive and easy to grasp. The data editor, on the other hand, is so in depth and contains so many different fields that it can be incredibly daunting to try and do something that seems so easy to do with a trigger.
I am working on a fairly large project, so my concern is that if I do everything with triggers I will eventually end up with a lot of lag and perhaps a lot of wasted time going back and converting all of my triggers to a data version. So what I am wondering is, from your own experience, does each method have its pros and cons? Should I strive to implement my ideas through the data editor first, and resort to using triggers only as a last resort? Or is it merely a preference thing? Thanks for any input on this subject :D
So the impression I am getting is that if you can do something with the data editor instead of the trigger editor, your game will be better off. I have been dinking around with the editor since release and I feel like I am starting to get the hang of it.. however, for me at least, the trigger editor seems a lot more intuitive and easy to grasp. The data editor, on the other hand, is so in depth and contains so many different fields that it can be incredibly daunting to try and do something that seems so easy to do with a trigger.
Triggers can be very quick and easy ways to do some things, and some things can be done both in data and in trigger editors, while others can only be done individually.
But you must remember how the trigger editor works, it is hundreds over thousands lines of code that are being read over and over depending on the trigger, and that really really slows the game down, not to mention is less stable and direct than the data editor.
Triggers like while or for loops, or maybe periodic events are serious lag makers and should be kept at small numbers.
Data editor is harder to learn, use and master, and there are so many things you need to learn about data, but once you learned even 1 of them, (and I think you can compare what I'm saying to the very first things you learned with data, like changing unit stats and scale etc) you get the feeling like you've opened yourself so many doors to new things you now know how to do. Well this keeps happening over and over, for every new things you learn in the data editor. and you know what? no one completely 100% mastered the data editor or even learned everything it had to offer, some things are still being discovered and some are still unlearned by the community.
I'm still learning it, and I learn a new thing every so often, for you these things can now seem complicated, as they did to me once to, but now? pfft they're a joke to me, while other tabs in the editor frighten me, cus in there I'm a total noob .
So what I'm trying to say is data is worth learning, trigger is best kept for the things that data cannot do, which is campaign making, map control, etc.
You can even take your imagination further, and make abilities and other amazing things using triggers.
Triggers are meant for scripted sequences that happen in response to events. The server will need to keep everyone synced to the triggers currently running on the map.
But, for data, since everything is available on each client, the server has less work to do. See, the client can assume what the new game state will be. This results in less latency for your map.
Yes indeed. I do feel like although it will add a number of months to my learning process, it will be well worth it. Perseverance is key and will make the difference between quality and half-assedness.
My map is going to be single player, but I guess if the map is being played through battle.net it won't make much difference. (Although from what I have read, the more players you have, the more lag you're going to see.)
The data editor for me is actually easier than triggers have been, I really like the data editor best because as long as I get it to work for me I know it will work for everyone. There are some limitations to the data editor and sometimes it takes less work to do something I triggers but those above who have said it best try and limit your triggers to stuff you absolutely can't do in the data editor. Our team has tried very hard to do this because of the lag issues when you have to much going on. It can add up faster than you think. I don't really thing one is better than the other they just serve different purposes.
I do believe the game has been optimized to give data edtior stuff such as actor events, and periodic behaviors doing things, a higher prioity then triggers.
Speaking of actor events. There is much greater control in when you want things to happen with actor events then Trigger events, its just that you may need more then one event response on an actor then a trigger where one event can have have multiple actions.
Well I think triggers > data :) Triggers are really easy to copy, paste and modify. Data editor is basicly just a huge mess of linking. Doing simple triggers is much easier for beginners than making something basic in data editor like new hero unit. Many people only want to copy unit, rename it and change its damage and they need to do huge amount of work for that simple thing. Anyway everything depends on it what you are exactly going to do for your map.
On the one hand, anything with dynamic numbers is going to be slower and more cumbersome in the Data Editor. Take Chain Lightning, for instance. Several people have posted Data Editor solutions, but they involve a lot of objects and still aren't flexible enough for my tastes. So a while back I did a draft of a ability that uses only 2 effects/actors and lets scripting handle the rest. With 50 measly lines of code I can arbitrarily change any part of the ability at runtime—more or less forking, more or less damage per fork, crits, evasion, whatever—and the whole thing sits in a single Andromeda file, so the organization is also much better than it would be in the Data Editor.
On the other hand, sometimes the Data Editor is necessary because Blizzard simply hasn't exposed certain functionality to Galaxy (Blizzard's motto when designing the SC2 Editor seems to have been "so easy, a caveman could do it." Thus we have degrees instead of radians, points instead of coordinates, lots of missing functionality, etc.). When it comes to things like site operations, for instance, the Data Editor is your only real choice. And you're always going to need some data anyway, since that's the only place to manage buttons and other things. So when you need to use data, use data.
In short: choose the right tool for the job. More often than not I think that's scripting, but sometimes it's the Data Editor.
Nota bene: while lots of people have been exploring the Data Editor and posting their findings, relatively little has been said about Galaxy. Rest assured, however, that its secret powers (like ) are out there waiting to be discovered and immortalized in tutorials by ProzaicMuze's evil scripting twin.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
So the impression I am getting is that if you can do something with the data editor instead of the trigger editor, your game will be better off. I have been dinking around with the editor since release and I feel like I am starting to get the hang of it.. however, for me at least, the trigger editor seems a lot more intuitive and easy to grasp. The data editor, on the other hand, is so in depth and contains so many different fields that it can be incredibly daunting to try and do something that seems so easy to do with a trigger.
I am working on a fairly large project, so my concern is that if I do everything with triggers I will eventually end up with a lot of lag and perhaps a lot of wasted time going back and converting all of my triggers to a data version. So what I am wondering is, from your own experience, does each method have its pros and cons? Should I strive to implement my ideas through the data editor first, and resort to using triggers only as a last resort? Or is it merely a preference thing? Thanks for any input on this subject :D
Triggers can be very quick and easy ways to do some things, and some things can be done both in data and in trigger editors, while others can only be done individually.
But you must remember how the trigger editor works, it is hundreds over thousands lines of code that are being read over and over depending on the trigger, and that really really slows the game down, not to mention is less stable and direct than the data editor.
Triggers like while or for loops, or maybe periodic events are serious lag makers and should be kept at small numbers.
Data editor is harder to learn, use and master, and there are so many things you need to learn about data, but once you learned even 1 of them, (and I think you can compare what I'm saying to the very first things you learned with data, like changing unit stats and scale etc) you get the feeling like you've opened yourself so many doors to new things you now know how to do. Well this keeps happening over and over, for every new things you learn in the data editor. and you know what? no one completely 100% mastered the data editor or even learned everything it had to offer, some things are still being discovered and some are still unlearned by the community. I'm still learning it, and I learn a new thing every so often, for you these things can now seem complicated, as they did to me once to, but now? pfft they're a joke to me, while other tabs in the editor frighten me, cus in there I'm a total noob .
So what I'm trying to say is data is worth learning, trigger is best kept for the things that data cannot do, which is campaign making, map control, etc. You can even take your imagination further, and make abilities and other amazing things using triggers.
I hope I answered your questions.
-38dedo
Triggers are meant for scripted sequences that happen in response to events. The server will need to keep everyone synced to the triggers currently running on the map.
But, for data, since everything is available on each client, the server has less work to do. See, the client can assume what the new game state will be. This results in less latency for your map.
Yes indeed. I do feel like although it will add a number of months to my learning process, it will be well worth it. Perseverance is key and will make the difference between quality and half-assedness.
@Klishu: Go
My map is going to be single player, but I guess if the map is being played through battle.net it won't make much difference. (Although from what I have read, the more players you have, the more lag you're going to see.)
The data editor for me is actually easier than triggers have been, I really like the data editor best because as long as I get it to work for me I know it will work for everyone. There are some limitations to the data editor and sometimes it takes less work to do something I triggers but those above who have said it best try and limit your triggers to stuff you absolutely can't do in the data editor. Our team has tried very hard to do this because of the lag issues when you have to much going on. It can add up faster than you think. I don't really thing one is better than the other they just serve different purposes.
I do believe the game has been optimized to give data edtior stuff such as actor events, and periodic behaviors doing things, a higher prioity then triggers.
Speaking of actor events. There is much greater control in when you want things to happen with actor events then Trigger events, its just that you may need more then one event response on an actor then a trigger where one event can have have multiple actions.
Correct me if I am wrong.
Well I think triggers > data :) Triggers are really easy to copy, paste and modify. Data editor is basicly just a huge mess of linking. Doing simple triggers is much easier for beginners than making something basic in data editor like new hero unit. Many people only want to copy unit, rename it and change its damage and they need to do huge amount of work for that simple thing. Anyway everything depends on it what you are exactly going to do for your map.
It depends on what you want to do.
On the one hand, anything with dynamic numbers is going to be slower and more cumbersome in the Data Editor. Take Chain Lightning, for instance. Several people have posted Data Editor solutions, but they involve a lot of objects and still aren't flexible enough for my tastes. So a while back I did a draft of a ability that uses only 2 effects/actors and lets scripting handle the rest. With 50 measly lines of code I can arbitrarily change any part of the ability at runtime—more or less forking, more or less damage per fork, crits, evasion, whatever—and the whole thing sits in a single Andromeda file, so the organization is also much better than it would be in the Data Editor.
On the other hand, sometimes the Data Editor is necessary because Blizzard simply hasn't exposed certain functionality to Galaxy (Blizzard's motto when designing the SC2 Editor seems to have been "so easy, a caveman could do it." Thus we have degrees instead of radians, points instead of coordinates, lots of missing functionality, etc.). When it comes to things like site operations, for instance, the Data Editor is your only real choice. And you're always going to need some data anyway, since that's the only place to manage buttons and other things. So when you need to use data, use data.
In short: choose the right tool for the job. More often than not I think that's scripting, but sometimes it's the Data Editor.
Nota bene: while lots of people have been exploring the Data Editor and posting their findings, relatively little has been said about Galaxy. Rest assured, however, that its secret powers (like ) are out there waiting to be discovered and immortalized in tutorials by ProzaicMuze's evil scripting twin.