How to organize your triggering to be as efficient as possible.
How to make your coding more flexible and clean.
We will go over some basic coding knowledge: Records, Action definitions, etc...
Well lets get to it!
Part 1
Organization
First off I'd like to go over some of the main reasons why organization in your triggering is one of the most important aspect.
Keeping your codes organised through folders and labeling them correctly (by name and label Icon) can help you find information in your map better. This will speed up your coding time because you will not have to search for well... anything.
So lets take a look at what a very well organised map would look like.
Here we see the main folder of the map named: The Battle of Terratonix.
Inside we see four folders. Each folder is very straight forward as to what is inside. So let's go ahead and open the folders up and let's see whats inside.
Inside our function folder. We have action, conditions and events folder. Placing your triggers like this is very good because everything of relevance is very easily found.
So I think its pretty clear where I am going with this. So lets open up some more folders and look how everything else is referenced.
As you can see everything is really detailed about what is inside. Making sure everything is at one place is key to finding what you are looking for quickly.
How do you set the icon's for your folders?
Right-click on the folder you want to set an Icon to. Then go down to Label and select the one you think is appropriate.
If you are comfortable with the standard green folder icon that is fine too but having an icon helps you spot that folder faster than with just the name in a sea of green folders. lol...
So is there anything else I can do/need to know to speed up my coding?
Personally, I hate having to right-click and select what type of element I want to create. So I learned all the short-cuts and it helps, A LOT.
Short list of the most useful Short-cuts
New Element: CTRL-W
(This is the most used Short-cut. I use it when I want to add a parameter to a function or when I want to create the previously created item. Yes if you make a folder then press CTRL-W, it will create a new one.)
Create Record: CTRL-U
Create Variable: CTRL-B
Create Folder: CTRL-G
Create Comment: CTRL-/
Create Action Definition: CTRL-ALT-R
Organization Conclusion
So in other words. Keep all your variables in one folder and specify what they are linked to with other folders and comments. Same for triggers, actions, etc...
===================
Part 2
Keeping your code clean.
Read me first
I'm not enforcing my way to code on anyone. This is my own personal method, if you have a better method that you think is better, more power to you. Please let me know if there is anything I should re-phrase or remove.
==========
First and foremost: You need to develope a coder's perspective. Coders, like all humans, are lazy. While making your triggers, use your lazyness to your advantage. You need to think and make everything as flexible as possible. You need to try and use the least amount of scripts to get the result you are after.
"Coding is like writing an essay. Except in this case the shorter the essay, while still getting the point across, the higher the grade. The less time the CPU takes "reading" the essay the more time it has to do other things."
-FockeWulf
First we start with an event (ie. something happends!!!). Each event has variable inputs (ie. Triggering player) that can be aquired depending on what event has taken place.
ie.: An event triggers and then we can then run action definitions to filter and manipulate data inputs to use in "actions" to do something (ie. like create a unit).
ie.: For instance: the "Dialog item is used" event. We can use this to trigger a chain of events that can result in anything from casting spells to declaring war. Okay, so pretty basic stuff right?
Now something that I've seen in a lot of maps is multiple triggers with the same event.
Two or more differant triggers like this can lead to inefficient execution. I have also seen this along with hundreds of unique variables.... This is, and I am sorry to say, wrong. We are going to see how we can use only 1 trigger with a unique event (that is no 2 triggers have the same event) to affect every system in the game.
We are going to remove that "Sea of variables" and replace it with an organised variable database that all your friends will envy! Lets get started!
In part 1, I covered the basics of organising your codes. Your coding should evolve around your organisation. Understand that, in time,
as your project gets bigger it gets harder and harder to keep track of everything. While this is true; there are many ways to optimize your coding
to reduce the growing mess you have been getting by adding more and more data into your map.
Records
If you already know what "Records" are you can skip ahead. Of course a nice refresh is always nice. :)
These cannot be used in every situation but they are extremely helpful in most situations. Records group variables together and lets us work cleanly and orginized. Frankly, I use them for almost everything. To understand the real power behind Records, we need to understand arrays.
A variable with an array of three is exacly the same as four separate variables with the same type. (Four because 0 counts as 1. So from 0 to 3 = 4).
"To give an extremely simple understanding of arrays, imagine a game of tic-tac-toe. There are 9 boxes right? This is what is called a 3x3 array. Each box can have a piece of information stored in them. This information can be of many different types. The difference is that instead of having to use 9 variables for 9 different things now we can use 1 for the 9. The method we use to locate the particular "box" the data is stored in or will be stored in is via it's "index". In a 3x3 array, the index [2][2] means the middle box. Arrays in StarCraft 2 can go up to 4 dimentions (the tic-tac-toe being a 2 dimensional array) so a tremendous amount of data can be stored. The fewer the variables the more efficient the execution."
-FockeWulf
Here we see a "Dialog" variable with an "array" of three. Right under we see four separate "Dialog" variables. Those two are basically the same thing. This is what "arrays" are. They create separate values of the same variable which we can later recall by inputing a value in the "array's index". The essence of arrays comes down to how the computer uses the RAM. For those of you who are novices in this field, all you really need to know is that arrays are better than a lot of single variables. Eventually you will get used to it.
This is where records come in. When you set up your record, you have to link it to a variable. That variable can have arrays. So lets go ahead and create a dialog record.
Here we have our record and I have stored some variables in it already. On the right you see the variable linked to the record. It has two arrays. One of 14 and one of 20. The first one represents the player and the second one represents which dialog we want to use. What this means is, for every PlayerID index and every DialogID index I have a separate record created. Each instance has one dialog variable and one dialog item variable with an array of 20.
Okay that is all very nice, but how is this useful?
We can use this technique to store multiple dialogs into one record. Making our code both less clutered and more efficient.
Action Definition's & Parameters
I have to say: I love Action Definition's. They make coding for this game really fun. They are used to filter through data and apply action's according to the values of the input variables. They act as plugin-scripts into a trigger and give you much more flexability with trigger execution.
Lets stay we have four dialogs, each for a differant system. Obviously we want our dialogs to have functionality so the "Dialog item is used event" comes into play in a single trigger instead of four separate triggers.
Here we see that I used the action definition twice with a differant value at the end. This value represents a dialog.
Now remember this map isn't finished, but it is pretty far in its development nonetheless. So now we only use one trigger to control the actions of all the dialogs. Nice. Lets go see how the action definitions for this are generally set up.
Note the name of the action definition. It starts with a +. This allow's me to quickly show my actions in the new action menu.
It is still very indirect as to what I'm going to do with the action definition.The name is quite simple, +Dialog item is used. We have three parameters: one that get's the dialog item ID from the trigger that fired. One that refers to the player (PlayerID) and an other that dictates which dialog to perform actions on.
Parameters
Parameters act as gateways between triggers and functions (Action definitions, conditions, functions, etc). They allow outputs from the event of a trigger to be used in a function. So for instance: often times you will want to reference exactly what player caused the event and use it in a function to preform some actions.
So let's break down what happends.
We have the parameters DialogID (To reference what dialog), PlayerID (to get the player who caused the event) and a constant, TrueID, which we will go over soon.
"Used dialog Item" is used as an input for the "Which Item?" parameter
"Triggering Player" is used as an input for the "PlayerID" parameter
"TrueID Action bar" is an integer constant. I have used the value "1" for this. I've set it in my DialogID parameter.
Note: Notice the "Create Thread" next to action in the options section of the action definition. Create thread essentially means that the trigger will not wait for the action definition execution to complete. This is the key that allows you to run dozens of functions in a single trigger. This makes for very effecient script execution thus making it a very powerful tool.
There are cases where "Create Thread" must not be used.
ie. Say you have a trigger in which you have an action definition that you created that runs actions that are required to have finished executing before the rest of the trigger you originally ran can continue executing. Checking the "Create Thread" option would make it that when you call that action definition, every actions that run in that thread are independent of the original trigger thread thus letting your original trigger thread finish executing and since you needed the values that were executed in a separate thread to continue the trigger you will get errors.
Why is this important?
"Only one trigger can run at a time. All of the triggers in a map have to execute in the same "thread" because of how StarCraft 2 is coded. Only Blizzard can change this. Google "multi-threading" to get a better definition. What matters for you is that effecient script execution in StarCraft 2 boils down to how few triggers you can use in a map. In many cases its better to do things in the data editor where this single thread limit does not exist. But the data editor is extremely confusing and rather buggy and many map makers prefer to do as little as possible in it. Also for things like first and third person movement systems and shooters: "create thread" is what allows them to be possible at all. Do not underrate this aspect."
-FockeWulf
So what did we accomplish?
Most people would have a separate trigger controling each dialog. This is not efficient and certainly not clean at all. Filtering the data with action definitions is the best way to keep your code clean and efficient.
We used one trigger to affect multiple dialogs. We used action definitions to filter the data efficiently and execute actions with the minimal amount of "clock time" on the CPU.
So what did we learn so far?
We learned that it is possible to make a map using on 1 trigger per event to filter through data to execute the appropriate actions to multiple aspects of your map.
We also learned that keeping a well orginized trigger and data tree makes for better and more effecient script execution. This means less potential for latency in your map.
Personally, I think putting all variables in one folder, all triggers in one, all functions in one etc is a bad idea. It might work out for a small project but as the project grows you'll suddenly have to look through a sea of variables to find the one you want.
I like to think that my trigger editor is decently well organized right now. I'm creating the map with a friend so it really helps to have it all organized.
First of all, I organize everything into a folder. Nothing should really be left outside. I usually keep variables for a specific part in a sub-folder named variables since I don't have to mess with them too much. For bigger dialog systems I also have a separate sub-folder for constants. In the end, it's a matter of preference, I guess.
Here's a tip I found out a while ago that is pretty useful:
When your project gets bigger, you'll find it hard to keep track of things in your different folders just because all top-layer folders open up when you open the editor. So if you have 15 different folders for different parts of the map, they'll all open when you start the trigger editor. This makes things cluttered since you probably didn't want to mess around with all of those.
The solution is to place all your folders in a single folder at the top. If you do this, all folders will be closed when you start the editor(except the folder that contains all the other folders).
I have a project with over 1500 variables, 15.000 actions and 12.500 function recalls and if everything would be arranged like you did it would be a mess. I also made a über-folder which contain the other 300 folders.
I agree with everything you say. Then again. My tutorial isn't finished yet. This all falls in part 2 of my tutorial which I am still putting together due to the amount of detail I want to put into this subject.
I will explain in detail how to avoid getting a "Sea of variables".
Please be patient and give me time to write part 2.
Okay I'm losing patience here. I'm covering all this in the second part of the tutorial. I understand everything you are saying and I felt the same way too before. Give me time to finish the second part properly and give me to cover all of this information in detail. Everything you just talked about. everything. I cover in great detail. I know how to keep a HUGE project clean simple, organised and most importantly optimized. I will show all of this in my tutorial....
I'll be honest, I feel attacked. I try to share knowledge and I only get negative criticism.
For the record, nothing I wrote was meant as an attack or negative criticism. I think you did a good job with the tutorial and I understand it'll be more thorough when the next part is written. I just wanted to give another way to organize things, as well as share the tip with the top folder to make all the other folders start as closed.
For the record, nothing I wrote was meant as an attack or negative criticism. I think you did a good job with the tutorial and I understand it'll be more thorough when the next part is written. I just wanted to give another way to organize things, as well as share the tip with the top folder to make all the other folders start as closed.
You're doing good work, keep it up.
I second that. When I saw this post I remembered the problems I had at the start. Over time I saw pictures of how different people organized their triggers and I built upon that.
In my excitement I posted my personal experience without regard for how that may reflect upon others. In the future I will try to remind myself how whatever I say may be affect or be interpreted.
Very good writeup and well done, DarlD and FockeWulf. :)
I didn't know about the folder's icon. I wondered about these a lot already.
But I think one good thing is missing which you didn't apply in your screenshot:
- Disable the default value in action definitions, if you want the user to see what the parameter's name is. That's great if you have a function/action definition that uses multiple integers, so you can easily identify which parameter slot had which meaning instead of seeing "MyActionDefinition(0,0,0,0,0,0,0,0)".
Default values are really only useful for fields that you won't use with a value different from the default value very often.
- If you some things are special in your function/action definition like having a boolean with the following meaning: true -> team A, false -> team B, you can use the hint text to make this information visible, if someone uses your function. Then the user won't have to look it up or guess it.
Actually DarID and I taught eachother on this subject. He didn't know about create thread and catalogs and I didn't know about records.
So this was no merely a one person work here. For the most part I just rendered actually understandable in English what a French Canadian wrote. Besides the "Create Thread" part that was the extend of my contribution.
Thanks alot DarID! I learned alot from this tutorial about triggers and keeping it clean and organised :) I liked it ofcourse ;)
See my before and after screenshot :P
I'm glad you enjoyed reading this tutorial.
The important part is that you understand yourself in your organisation of course. Setting your folders like so must speed up your production, not slow you down. I'll start working on a part 3 of this tutorial. I will be covering Algorithms and other advanced triggering subjects. I'll also add some information to part 1 and 2 as time passes. Thanks for reading my tutorial.
I think this way of organizing is good for either library or folders with contents only for 1 job/system.
Example:
Where "The Battle for Terratonix" would be a folder for example "Inventory handling"
Imo what you just described is a bad example of how this organisation should be used. If you separate the systems there is a chance you will create some stuff (variables triggers actions) twice and there for rendering your coding less effective. Your coding should evolve around your organization. Systems/Jobs should be organized in their corresponding folders. You are doing dialog actions. They should be stored in the Dialog Folder then stored in its system folder. The name of the action should explain very clearly in a few words what it affects/does just like in the tutorial example: +Dialog Item is Used.
Added some more detail to part 2. Video tutorial is underway. I'll post my progress here. I will be covering in detail every aspect of the triggering editor. This video will be meant as a boot camp for new people. Also added two links at the end of the tutorial to two similar tutorials that cover pretty much the same basics in other words and examples.
If someone reads this tutorial and the two others linked at the end of this tutorial. They will never have triggering problems. That is a fact.
Thanks for reading everyone and stay tuned for the video version!
What does this particular example mean about "Create Thread" :
"Also for things like first and third person movement systems and shooters: "create thread" is what allows them to be possible at all. Do not underrate this aspect."
Perhaps I'll gain a better understanding of the the significance of "Create Thread" if you can explain how FPS and TPS movement systems suffer from not having "Create Thread " checked.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Keeping your code clean and organised
Hi there.
As stated in the title we will be covering;
How to organize your triggering to be as efficient as possible.
How to make your coding more flexible and clean.
We will go over some basic coding knowledge: Records, Action definitions, etc...
Well lets get to it!
Part 1
Organization
First off I'd like to go over some of the main reasons why organization in your triggering is one of the most important aspect.
Keeping your codes organised through folders and labeling them correctly (by name and label Icon) can help you find information in your map better. This will speed up your coding time because you will not have to search for well... anything.
So lets take a look at what a very well organised map would look like.
Here we see the main folder of the map named: The Battle of Terratonix. Inside we see four folders. Each folder is very straight forward as to what is inside. So let's go ahead and open the folders up and let's see whats inside.
Inside our function folder. We have action, conditions and events folder. Placing your triggers like this is very good because everything of relevance is very easily found. So I think its pretty clear where I am going with this. So lets open up some more folders and look how everything else is referenced.
As you can see everything is really detailed about what is inside. Making sure everything is at one place is key to finding what you are looking for quickly.
How do you set the icon's for your folders?
Right-click on the folder you want to set an Icon to. Then go down to Label and select the one you think is appropriate.
If you are comfortable with the standard green folder icon that is fine too but having an icon helps you spot that folder faster than with just the name in a sea of green folders. lol...
So is there anything else I can do/need to know to speed up my coding?
Personally, I hate having to right-click and select what type of element I want to create. So I learned all the short-cuts and it helps, A LOT.
Short list of the most useful Short-cuts
Organization Conclusion
So in other words. Keep all your variables in one folder and specify what they are linked to with other folders and comments. Same for triggers, actions, etc...
===================
Part 2
Keeping your code clean.
Read me first
I'm not enforcing my way to code on anyone. This is my own personal method, if you have a better method that you think is better, more power to you. Please let me know if there is anything I should re-phrase or remove.
==========
First and foremost: You need to develope a coder's perspective. Coders, like all humans, are lazy. While making your triggers, use your lazyness to your advantage. You need to think and make everything as flexible as possible. You need to try and use the least amount of scripts to get the result you are after.
"Coding is like writing an essay. Except in this case the shorter the essay, while still getting the point across, the higher the grade. The less time the CPU takes "reading" the essay the more time it has to do other things."
-FockeWulf
First we start with an event (ie. something happends!!!). Each event has variable inputs (ie. Triggering player) that can be aquired depending on what event has taken place.
ie.: An event triggers and then we can then run action definitions to filter and manipulate data inputs to use in "actions" to do something (ie. like create a unit).
ie.: For instance: the "Dialog item is used" event. We can use this to trigger a chain of events that can result in anything from casting spells to declaring war. Okay, so pretty basic stuff right?
Now something that I've seen in a lot of maps is multiple triggers with the same event. Two or more differant triggers like this can lead to inefficient execution. I have also seen this along with hundreds of unique variables.... This is, and I am sorry to say, wrong. We are going to see how we can use only 1 trigger with a unique event (that is no 2 triggers have the same event) to affect every system in the game. We are going to remove that "Sea of variables" and replace it with an organised variable database that all your friends will envy! Lets get started!
In part 1, I covered the basics of organising your codes. Your coding should evolve around your organisation. Understand that, in time, as your project gets bigger it gets harder and harder to keep track of everything. While this is true; there are many ways to optimize your coding to reduce the growing mess you have been getting by adding more and more data into your map.
Records
If you already know what "Records" are you can skip ahead. Of course a nice refresh is always nice. :)
These cannot be used in every situation but they are extremely helpful in most situations. Records group variables together and lets us work cleanly and orginized. Frankly, I use them for almost everything. To understand the real power behind Records, we need to understand arrays. A variable with an array of three is exacly the same as four separate variables with the same type. (Four because 0 counts as 1. So from 0 to 3 = 4).
"To give an extremely simple understanding of arrays, imagine a game of tic-tac-toe. There are 9 boxes right? This is what is called a 3x3 array. Each box can have a piece of information stored in them. This information can be of many different types. The difference is that instead of having to use 9 variables for 9 different things now we can use 1 for the 9. The method we use to locate the particular "box" the data is stored in or will be stored in is via it's "index". In a 3x3 array, the index [2][2] means the middle box. Arrays in StarCraft 2 can go up to 4 dimentions (the tic-tac-toe being a 2 dimensional array) so a tremendous amount of data can be stored. The fewer the variables the more efficient the execution."
-FockeWulf
Here we see a "Dialog" variable with an "array" of three. Right under we see four separate "Dialog" variables. Those two are basically the same thing. This is what "arrays" are. They create separate values of the same variable which we can later recall by inputing a value in the "array's index". The essence of arrays comes down to how the computer uses the RAM. For those of you who are novices in this field, all you really need to know is that arrays are better than a lot of single variables. Eventually you will get used to it. This is where records come in. When you set up your record, you have to link it to a variable. That variable can have arrays. So lets go ahead and create a dialog record.
Here we have our record and I have stored some variables in it already. On the right you see the variable linked to the record. It has two arrays. One of 14 and one of 20. The first one represents the player and the second one represents which dialog we want to use. What this means is, for every PlayerID index and every DialogID index I have a separate record created. Each instance has one dialog variable and one dialog item variable with an array of 20.
Okay that is all very nice, but how is this useful?
We can use this technique to store multiple dialogs into one record. Making our code both less clutered and more efficient.
Action Definition's & Parameters
I have to say: I love Action Definition's. They make coding for this game really fun. They are used to filter through data and apply action's according to the values of the input variables. They act as plugin-scripts into a trigger and give you much more flexability with trigger execution.
Lets stay we have four dialogs, each for a differant system. Obviously we want our dialogs to have functionality so the "Dialog item is used event" comes into play in a single trigger instead of four separate triggers.
Here we see that I used the action definition twice with a differant value at the end. This value represents a dialog.
Now remember this map isn't finished, but it is pretty far in its development nonetheless. So now we only use one trigger to control the actions of all the dialogs. Nice. Lets go see how the action definitions for this are generally set up.
Note the name of the action definition. It starts with a +. This allow's me to quickly show my actions in the new action menu.
It is still very indirect as to what I'm going to do with the action definition.The name is quite simple, +Dialog item is used. We have three parameters: one that get's the dialog item ID from the trigger that fired. One that refers to the player (PlayerID) and an other that dictates which dialog to perform actions on.
Parameters
Parameters act as gateways between triggers and functions (Action definitions, conditions, functions, etc). They allow outputs from the event of a trigger to be used in a function. So for instance: often times you will want to reference exactly what player caused the event and use it in a function to preform some actions.
So let's break down what happends.
We have the parameters DialogID (To reference what dialog), PlayerID (to get the player who caused the event) and a constant, TrueID, which we will go over soon.
+Dialog Item is Used((Used dialog item), (Triggering player), trueID Action Bar)
"Used dialog Item" is used as an input for the "Which Item?" parameter
"Triggering Player" is used as an input for the "PlayerID" parameter
"TrueID Action bar" is an integer constant. I have used the value "1" for this. I've set it in my DialogID parameter.
Note: Notice the "Create Thread" next to action in the options section of the action definition. Create thread essentially means that the trigger will not wait for the action definition execution to complete. This is the key that allows you to run dozens of functions in a single trigger. This makes for very effecient script execution thus making it a very powerful tool.
There are cases where "Create Thread" must not be used. ie. Say you have a trigger in which you have an action definition that you created that runs actions that are required to have finished executing before the rest of the trigger you originally ran can continue executing. Checking the "Create Thread" option would make it that when you call that action definition, every actions that run in that thread are independent of the original trigger thread thus letting your original trigger thread finish executing and since you needed the values that were executed in a separate thread to continue the trigger you will get errors.
Why is this important?
"Only one trigger can run at a time. All of the triggers in a map have to execute in the same "thread" because of how StarCraft 2 is coded. Only Blizzard can change this. Google "multi-threading" to get a better definition. What matters for you is that effecient script execution in StarCraft 2 boils down to how few triggers you can use in a map. In many cases its better to do things in the data editor where this single thread limit does not exist. But the data editor is extremely confusing and rather buggy and many map makers prefer to do as little as possible in it. Also for things like first and third person movement systems and shooters: "create thread" is what allows them to be possible at all. Do not underrate this aspect."
-FockeWulf
So what did we accomplish?
Most people would have a separate trigger controling each dialog. This is not efficient and certainly not clean at all. Filtering the data with action definitions is the best way to keep your code clean and efficient. We used one trigger to affect multiple dialogs. We used action definitions to filter the data efficiently and execute actions with the minimal amount of "clock time" on the CPU.
So what did we learn so far?
We learned that it is possible to make a map using on 1 trigger per event to filter through data to execute the appropriate actions to multiple aspects of your map. We also learned that keeping a well orginized trigger and data tree makes for better and more effecient script execution. This means less potential for latency in your map.
===================================================================
I hope you all had as much fun reading this tutorial as I had fun writing it. Please feel free to leave a comment or feedback! - DarlD
===================================================================
Special thanks to FockeWulf for his contribution to the create thread section and for correcting the English correctly!
===================================================================
Common Sense 101 - is an other tutorial covering some of the topics covered in this tutorial. Be sure to check it out. Knowledge is power!
===================================================================
Action Definitions and Advanced Triggering Made by ZeldaRules
===================================================================
Reserved!
Video Version TBD
Personally, I think putting all variables in one folder, all triggers in one, all functions in one etc is a bad idea. It might work out for a small project but as the project grows you'll suddenly have to look through a sea of variables to find the one you want.
I like to think that my trigger editor is decently well organized right now. I'm creating the map with a friend so it really helps to have it all organized.
First of all, I organize everything into a folder. Nothing should really be left outside. I usually keep variables for a specific part in a sub-folder named variables since I don't have to mess with them too much. For bigger dialog systems I also have a separate sub-folder for constants. In the end, it's a matter of preference, I guess.
Here's a tip I found out a while ago that is pretty useful: When your project gets bigger, you'll find it hard to keep track of things in your different folders just because all top-layer folders open up when you open the editor. So if you have 15 different folders for different parts of the map, they'll all open when you start the trigger editor. This makes things cluttered since you probably didn't want to mess around with all of those.
The solution is to place all your folders in a single folder at the top. If you do this, all folders will be closed when you start the editor(except the folder that contains all the other folders).
Everything Siretu said so far is fairly true.
I have a project with over 1500 variables, 15.000 actions and 12.500 function recalls and if everything would be arranged like you did it would be a mess. I also made a über-folder which contain the other 300 folders.
@Siretu: Go
I agree with everything you say. Then again. My tutorial isn't finished yet. This all falls in part 2 of my tutorial which I am still putting together due to the amount of detail I want to put into this subject.
I will explain in detail how to avoid getting a "Sea of variables".
Please be patient and give me time to write part 2.
Thank you for your input.
Deleted for inappropriateness on my part.
@DarlD: Go
My bad. :( sorry.
I just really wanted to share my knowledge too. :(
Deleted above post.
For the record, nothing I wrote was meant as an attack or negative criticism. I think you did a good job with the tutorial and I understand it'll be more thorough when the next part is written. I just wanted to give another way to organize things, as well as share the tip with the top folder to make all the other folders start as closed.
You're doing good work, keep it up.
I second that. When I saw this post I remembered the problems I had at the start. Over time I saw pictures of how different people organized their triggers and I built upon that.
In my excitement I posted my personal experience without regard for how that may reflect upon others. In the future I will try to remind myself how whatever I say may be affect or be interpreted.
I am looking forward to seeing the second part.
Tutorial has been completed. Enjoy!
Very good writeup and well done, DarlD and FockeWulf. :)
I didn't know about the folder's icon. I wondered about these a lot already.
But I think one good thing is missing which you didn't apply in your screenshot:
- Disable the default value in action definitions, if you want the user to see what the parameter's name is. That's great if you have a function/action definition that uses multiple integers, so you can easily identify which parameter slot had which meaning instead of seeing "MyActionDefinition(0,0,0,0,0,0,0,0)".
Default values are really only useful for fields that you won't use with a value different from the default value very often.
- If you some things are special in your function/action definition like having a boolean with the following meaning: true -> team A, false -> team B, you can use the hint text to make this information visible, if someone uses your function. Then the user won't have to look it up or guess it.
@Ahli634: Go
Actually DarID and I taught eachother on this subject. He didn't know about create thread and catalogs and I didn't know about records.
So this was no merely a one person work here. For the most part I just rendered actually understandable in English what a French Canadian wrote. Besides the "Create Thread" part that was the extend of my contribution.
Thanks alot DarID! I learned alot from this tutorial about triggers and keeping it clean and organised :) I liked it ofcourse ;)
See my before and after screenshot :P
I'm glad you enjoyed reading this tutorial.
The important part is that you understand yourself in your organisation of course. Setting your folders like so must speed up your production, not slow you down. I'll start working on a part 3 of this tutorial. I will be covering Algorithms and other advanced triggering subjects. I'll also add some information to part 1 and 2 as time passes. Thanks for reading my tutorial.
I think this way of organizing is good for either library or folders with contents only for 1 job/system.
Example:
Where "The Battle for Terratonix" would be a folder for example "Inventory handling"
Imo what you just described is a bad example of how this organisation should be used. If you separate the systems there is a chance you will create some stuff (variables triggers actions) twice and there for rendering your coding less effective. Your coding should evolve around your organization. Systems/Jobs should be organized in their corresponding folders. You are doing dialog actions. They should be stored in the Dialog Folder then stored in its system folder. The name of the action should explain very clearly in a few words what it affects/does just like in the tutorial example: +Dialog Item is Used.
@DarlD: Go
I won't argue. Personal preference.
Added some more detail to part 2. Video tutorial is underway. I'll post my progress here. I will be covering in detail every aspect of the triggering editor. This video will be meant as a boot camp for new people. Also added two links at the end of the tutorial to two similar tutorials that cover pretty much the same basics in other words and examples.
If someone reads this tutorial and the two others linked at the end of this tutorial. They will never have triggering problems. That is a fact.
Thanks for reading everyone and stay tuned for the video version!
-DarlD
@DarlD: Go
What does this particular example mean about "Create Thread" :
"Also for things like first and third person movement systems and shooters: "create thread" is what allows them to be possible at all. Do not underrate this aspect."
Perhaps I'll gain a better understanding of the the significance of "Create Thread" if you can explain how FPS and TPS movement systems suffer from not having "Create Thread " checked.