Grurf
Ultra Cool Member
- Reaction score
- 30
Nothing really special, just a list of things I have found to come in handy when mapping and especially triggering. I will edit this to add things when I want to share them. Feel free to post if something is wrong or hard to understand.
- Wait actions
- Unit Group - Pick every Unit in [anything] and do Action(s)
- Debugging your triggers
- Unit - Damage Target
- General Programming Knowledge
- Backupping!
- Wait actions
Normal Wait Actions will keep running when somebody is lagging, which is very inconvenient if for example a shop appears for a certain amount of time, then somebody starts lagging. When he/she is finished, the wait action has had it's time and the shop disappeared. Nobody will have been able to buy anything. You can use game-time seconds instead, they are lag-resistant. But remember that you can't fully count on them, because the game-time get's synchronized with the host every now and then. You can't fully count on wait actions anyway. If a lot of triggers are running at the same time (actually warcraft doesn't run them at the same time, but keeps a queue for actions to be ran) then a wait action will just take the trigger out of the queue for the time it takes, and place it back in. Then warcraft still has to finish the queue before the actions after the wait action are being executed. The best way to implement a wait is using a countdown timer without showing it. This is the most precise timer and it is lag-resistant, but does only synchronize on start.
- Unit Group - Pick every Unit in [anything] and do Action(s)
This action is a little weird. Remember that it is a loop. All the actions in the loop will be run once for every picked unit. Also, if no units are picked the actions will not be executed. If you want to count the units in a unit group do it like this:
This will work, even if the unit group is empty. Because the variable is of the Unit Group type, it will always be a unit group. Even if there is nothing to pick, then it will just be an empty unit group, with 0 units. Another advantage of this way is that it doesn't leak the unit group but stores it in a variable, which can be destroyed afterwards.
Code:
Set [UnitGroupVariable] = Pick every unit in [anything]
If Number of Units in [UnitGroupVariable] Is Equal to 0
- Debugging your triggers
Strange that I have never seen this method being mentioned on the internet before. I many times create triggers that do not work as they should. What I do then is putting it full with text messages saying what it is doing and, if any variables are set, the value of those variables. When something doesn't run or a variable isn't set correctly, the messages will report this, so you know where to seek the error. This way I can fix deep errors in very short times, because I don't have to check every step of the trigger, just the ones that are reported to be wrong.
- Unit - Damage Target
This action is not a normal attack. No animations are played, range doesn't matter. I personally use it for my triggered spells. The strange thing about it is: it does attack invulnerable units. It doesn't do any damage, but makes the AI think the invulnerable unit is attacked, and if it has no attack, and has no orders, it will start running away. This was very inconvenient in my map, because you could make an invulnerable dude run to a place, and if you did it good enough he would block off a lane. Solutions: Make all your spells unable to target invulnerable units or make the invulnerable unit unable to move.
- General Programming Knowledge
If you ever wonder why some people create triggers in a very efficient way that you would have never thought of, it is because of this: General Programming Knowledge. This is the kind of logic a prgrammer uses. Triggering actually is a kind of programming, with crappy functions that leak and without a hard-to-learn syntax. If you know how to trigger well, it is easier to learn a programming language, and vice-versa. If you want to be able to write perfect, efficient triggers, you might want to follow one of those programming tutorials to teach yourself that logic. But, if you start learning to program anyway, why don't you learn jass? That way you can write even more efficient triggers, while you have more possibilities and great tools (like vexorian's caster system) to help you. Another advantage of jass triggers: local variables. Those variables allow you to make triggers multi-instanceable: If you make a spell in jass with local variables, an unlimited amount of units can cast it at the same time (even from the same player) and the variables won't be a problem. Yes, it is possible to integrate local variables into normal triggers, but to do that you need WEU with advanced triggers that increase your map's size with about 200kb and are very unstable if you don't use them right. They are also known to suddenly corrupt your map in certain cases. And that brings me to the next subject:
- Backupping!
This is very important for the mapmaker. After every major change, and after every big piece of work, you should save under a new name. Personally I use numbers. For example, my map is at number 36 now. Version 1 only had 2 spell triggers and the terrain, 2 heroes and some creeps, while number 36 is a fully playable alpha version. I have also backed up some of the version to the server here, so if something happens to this computer (if I manage to mess the MBR up again) I will just reinstall it, take the backup and go on with my map. Losing your map is quite frustrating, trust me. Backing up isn't that hard to do, and it can save you months of work. Make multiple versions so that if one gets corrupted, you just switch to the one before that and make sure you don't do again what corrupted it. And if you don't have a server, back it up to a cd-rw, webspace, an usb-stick, your pda/mp3player etc. Anything that isn't inside your computer.