Things You Should Know When Using Triggers / GUI

[Zwiebelchen]

ill check on making the description for the op-limit a little more.
i did miss an explanation on threads.
This tutorial does have a lot of info. i wanted it to be that way. some of the stuff i wanted to stress the importance of them so i did make the explanation a little longer for those. I want to add more links to more detailed tutorials just like i did with a few of the tutorials in Section 4. Like i said b4 if u have any tutorials u think i should link to this then post me the link. I dont see this as an overkill because i dont explain every little detail for everything. this is one reason y i need more tutorials so i can say that there is a more detailed tutorial on that specific chapter. this way they can get a basis from this tutorial then move onto the more advanced / more detailed tutorial for a better understanding.

It shouldn't be like that, really.
Stressing important topics is neccessary, I totally agree on that.
However, I'm missing a certain logic behind your tutorial.

I understand this is an "all in one" tutorial and yes, I think there is a need for something like that. However, such an all in one tutorial should imho never give a real explanation of specifics or details of each topic.

You basicly jump from 'not giving any useful information on one topic' to just 'mentioning a problem' and then again to 'mentioning lots of details, but not doing it in the full scope'.
Sometimes you cover the details of a topic, but don't give a general idea about it.

I simply feel that you haven't decided for a target audience with your tutorial. Some topics require absolutely no knowledge, which is good for starters, some topics already require extended GUI knowledge and some topics even require JASS skills.
You should pick one target audience and always make sure the target audience can follow. Always have that in mind when writing. If that means starting from reinventing to wheel, then so be it!


Also, I think that you should never get into detail with any of the topics, as this is clearly a redirectional tutorial.

In each topic, I recommend to always ask the following three questions:
1) does the user understand what the topic is about and why it is a problem
2) is the user able to decide wether it's important for his map or not?
3) is there a quick and small solution to the problem worth including directly into the tutorial, or is it better to link to a dedicated tutorial?


The reason I'm saying that is because you tend to lose yourself in unneccessary details on the topics you like and only scratching the surface of topics you are not quite fond of.
Your tutorial, as an "all in one", should go in neither of those directions. Scratching the surface is bad, because it implies that a problem might be easier to fix than it actually is. Going into detail is also bad, because it makes the tutorial redundant and way too lengthy.

Take for example your Locals tutorial. There's no need to go into detail how to use locals. It just stretches your tutorial and by going into detail, you mention only one aspect of locals actually, which might cause the reader to think that your solution is the only one that exists, which is not the case.

Also your MUI and waits tutorial. Mention what is MUI, mention what the problem is with waits and then just link to one of the dedicated MUI tutorials.

You should always do it like this. There should only be three steps for each topic in your tutorial:

1) explanation of the problem
2) explanation of why it is important to know
3) if it is a topic without tutorial or with a minor scope: explain the solution, covering ALL aspects OR: if it is a major scale problem, link to a dedicated tutorial covering ALL aspects.


All in all:
Either cover all details of a problem or don't cover it at all and just link to another tutorial. Covering only parts of a problem confuses the reader and makes the reader most likely make false assumptions.


Just an example of how I could imagine the waits tutorial:

- You start with an explanation of the different methods of creating time delays, as there are:
waits, waiting for conditions, timers, timer events, game time events
All of those have their unique purposes which they shine at, whereas timers are only accessable with Custom script and are the most accurate and universal solution.
- You explain the pros and cons of each type of delay and the situations where they should be used and where not
- You don't go into detail with each type of delay
- You mention that there are several methods to make time delays work as desired and cross-reference hashtables, locals, general MUI ideas, etc. and help him select the most appropriate one by giving pros and cons (Note: You just only mention those methods and link to the dedicated chapters/tutorials! Don't go into any detail!)

This is the structure of a good tutorial, imho. Notice how like that you presented the reader with the full scale of the problem, without steamrolling him with information? The reader now understands the problem and will decide which solution is the best in his case and read the specific topic/tutorial about it.

 

[deathismyfriend]

cool thx gonna try to update this today. lets see how it goes lol

 

[GreeN!X]

Nice tut.. I've been triggering for a year now but I guess there's still a lot to learn.. + rep from me

BTW, since you included channel there, why not link users to this tut?
Spells - Channel

 

[deathismyfriend]

thanks juno will add that to tutorial link list. thanks for the rep also. gonna be adding some stuff and probably getting rid of the gameplay section and the object editor section. but for now ill put it in there. Gonna make them into a new tutorial if enough ppl want me to shorten this.

 

[Zwiebelchen]

I took the time to get through the tutorials on hive and found a lot of tutorials that nailed your most extensive topics much better. Especially the trigger thing.
I really recommend you stomp your trigger part down to a bare minimum and link to this instead, as the tutorial covers a lot more information and presents it in a more understandable and logical approach:
http://www.hiveworkshop.com/forums/...ials-278/importance-efficiency-coding-120105/

In the hashtables chapter, instead of trying to explain how to use hashtables on your own, link to this instead, it's written for unexperienced users and contains lots of information and examples:
http://www.hiveworkshop.com/forums/...9/complete-beginners-guide-hashtables-197381/

Probably one of the best tutorials if not the best on the hive:
Trigger enhancing spells: http://www.hiveworkshop.com/forums/...als-279/basics-trigger-enhancing-spells-7334/
This is the reason why you should remove a lot of stuff from your triggers section in your tutorial. Because this tutorial presents it in a much better way.

These are also a good tutorials on MUI in addition to magtheridons:
http://www.hiveworkshop.com/forums/...279/mui-spells-using-artificial-waits-223315/
http://www.hiveworkshop.com/forums/...279/multi-instancible-gui-spell-making-34393/

Also, you can remove your debugging chapter and instead link to this:
http://www.hiveworkshop.com/forums/general-mapping-tutorials-278/debugging-188204/

 

[deathismyfriend]

i added them down in the other tutorial section. ill have to see about if i want to change the explanations.

 

[mindwarper06]

keeping this safe, very useful
I would +rep you, bt if I can't rep you twice in a row, I can't rep you three times in a row.(and by the looks of the comments, this must be a common thing for you, kudos on being so talented lol.)

 

[deathismyfriend]

lol thx for the comment mindwarper06

 

[EmoBrother]

Questions :
Are we need to null the variables that have been used ?

call DestroyForce() - Player group
//My player group var cannot be set to any value after destroyed.Will it work if I null it after it destroyed ?
//Thanks for your time, please reply ~~

 

[MasterTrainer]

Questions :
Are we need to null the variables that have been used ?

call DestroyForce() - Player group
//My player group var cannot be set to any value after destroyed.Will it work if I null it after it destroyed ?
//Thanks for your time, please reply ~~

I believe so, yes. I think it's to avoid leaks... I'm not sure. Well, it also removes the something from the game memory... I forgot but it's pretty important. Correct me if I'm wrong and possibly fix the missing details form my post, great coders.

 

[deathismyfriend]

nulling a variable removes the pointer to the object thats y u need to destroy it b4 u null.

if u are using it throughout the game u do not need to destroy it.
u should only destroy handles when ur done using them then u null them after.

 

[Almia]

^ You should add the Pointer system.

 

[deathismyfriend]

pointer system ?

 

[Almia]

Yes
Wait ill show you
http://www.hiveworkshop.com/forums/2326193-post21.html

 

[deathismyfriend]

ooo good point i did mention that they are pointers but this definitely helps.

 

[MasterTrainer]

Why is this not approved yet?

 

[deathismyfriend]

i dont think purgeandfire has looked it over yet

 

[MasterTrainer]

But in the case purgeandfire does look over this tutorial again I'm sure this will be approved. Good job on making it

 

[deathismyfriend]

But in the case purgeandfire does look over this tutorial again I'm sure this will be approved. Good job on making it

hopefully it will lol and thanks again.

 

[EmoBrother]

How many hours you used to create this tut ??
Wish your tutorial got approved ~

 

[Xonok]

I just wish this tutorial existed when I was just a poor little GUIer.

 

[MasterTrainer]

I just wish this tutorial existed when I was just a poor little GUIer.

I agree with you... I would've been a pro spell maker if this tutorial has been created much earlier.

 

[deathismyfriend]

I agree with you... I would've been a pro spell maker if this tutorial has been created much earlier.

lol dont forget i only did GUI for about 2 months and recently ive been asked through pm by so many ppl help with this or this and so on. i dont mind helping at all i just thought this could help them a lot thats y i made it.

How many hours you used to create this tut ??
Wish your tutorial got approved ~

umm to type it all up and do all the triggers about 4 to 5 hrs at max.

the triggers slow me down a lot looking for the right thing lol.

i actually had to shorten it as i hit the 80,000 letter limit lol.
im also hoping it gets approved just gotta be patient and see what purgeandfire has to say when he gets a chance to look at it.

 

[PurgeandFire]

Overall it looks like it should be approvable after a couple of changes. I don't usually like the "all-in-one" tutorials, but people seem to be responding well to this, so I think it should be fine.

Here is my feedback:

• A Handle is basically a pointer to the internal data structure.
  A Widget is a type of object. A few examples are an item, destructable, doodad...
  These are the types of variables that are not handles. All other variables are handles.
  It is important to know these variables because all handle variables should be nulled and destroyed/removed when needed.

  Doodads aren't widgets. The only widgets are the types that extend widget (unit, item, and destructable). There are only 3.
  
  As for the next line, "These are the types... ", there is a reference issue. The reader won't know whether you are referring to the widgets or the handles in the list below. I recommend that you say: "Here is a list of the variables that are not handles:", show the list, then you can add the "These are the types... " text and whatever follows.

• Arrays have a max index of 8190. This means they have 8191 indexes to use. These index are from 0 to 8190.

  The max index is 8191. There are 8192 indexes available (2 ^ 13).
• Overall, the organization of "Dealing with array sizes" is a bit odd. You might want to rearrange some of the sentences or rewrite it. I understand what you mean, but you keep switching between the op-limit and the array sizes. You should just introduce the op-limit, and say that if you specify a size too large in the variable editor, you may have issues with hitting the op-limit. Also, you should mention that the array "size" you are talking about is the one that is listed in the variable editor (when you make a variable), otherwise people might confuse it with the index in the brackets [].
• For variable shadowing, does that still exist? I'm just confirming, because I haven't tested it myself. I know there were some issues with it a while back. (it was removed, but maybe it was readded)

• Waits are also very inaccurate.

  This is true when the wait time is about 1 second or less, but for wait times higher than that, it is usually fine. You might want to add that stipulation.

• These will cause desyncs and possible game crashes if destroyed / nulled.
  - Player group All Players
  - Rect Entire Map
  - Rect Playable Map Area

  Are you sure? I know it will mess up triggers that use them (since they are globals), but I don't think it will cause a desync or a crash.
• I suppose the GetLocalPlayer() part is fine the way it is, but I think it is a bit misleading. Technically, yeah you can create weather effects in the block because they have a separate handle stack, but for things like effects and units, you can't create them locally. You should add an example of something that does desync, or maybe add a bit more information.
• For DoNothing, I don't recall any bugs with it. It is useless, yes, but it doesn't bug out afaik.
• For texttags, an example would be good. You don't have to include one, but it would be better than its current state since a ton of people use them.

Otherwise, it should be good. It is a nice, comprehensive tutorial; but light at the same time.

 

[deathismyfriend]

Overall it looks like it should be approvable after a couple of changes. I don't usually like the "all-in-one" tutorials, but people seem to be responding well to this, so I think it should be fine.

Here is my feedback:
Doodads aren't widgets. The only widgets are the types that extend widget (unit, item, and destructable). There are only 3.

As for the next line, "These are the types... ", there is a reference issue. The reader won't know whether you are referring to the widgets or the handles in the list below. I recommend that you say: "Here is a list of the variables that are not handles:", show the list, then you can add the "These are the types... " text and whatever follows.

thx this is now fixed. added the widgets in a list format.

The max index is 8191. There are 8192 indexes available (2 ^ 13).
Overall, the organization of "Dealing with array sizes" is a bit odd. You might want to rearrange some of the sentences or rewrite it. I understand what you mean, but you keep switching between the op-limit and the array sizes. You should just introduce the op-limit, and say that if you specify a size too large in the variable editor, you may have issues with hitting the op-limit. Also, you should mention that the array "size" you are talking about is the one that is listed in the variable editor (when you make a variable), otherwise people might confuse it with the index in the brackets [].

I thought there was a bug with array index 8191 ?
reorganized and adjusted numbers.

For variable shadowing, does that still exist? I'm just confirming, because I haven't tested it myself. I know there were some issues with it a while back. (it was removed, but maybe it was readded)
This is true when the wait time is about 1 second or less, but for wait times higher than that, it is usually fine. You might want to add that stipulation.

variable shadowing does work now i have tested every trigger i put in the tutorial.

Are you sure? I know it will mess up triggers that use them (since they are globals), but I don't think it will cause a desync or a crash.

Whenever i did that it either crashed the game the next time a trigger tried to call them or it caused a desync if it was triggered by a specific player

I suppose the GetLocalPlayer() part is fine the way it is, but I think it is a bit misleading. Technically, yeah you can create weather effects in the block because they have a separate handle stack, but for things like effects and units, you can't create them locally. You should add an example of something that does desync, or maybe add a bit more information.

ok ill have to add something that shows desync.

For DoNothing, I don't recall any bugs with it. It is useless, yes, but it doesn't bug out afaik.

ive had some odd bugs when i took them out it stopped. Im not sure y and it was when i was first starting GUI. If u want i will take this out ?

For texttags, an example would be good. You don't have to include one, but it would be better than its current state since a ton of people use them.

ill see if i can include one.

Otherwise, it should be good. It is a nice, comprehensive tutorial; but light at the same time.

thx for everything

updated to include everything i said above.
note: did not add the 2 examples yet.

 

[ap0calypse]

Very good idea for a tutorial (and well executed), here are a few remarks:

Unit-group variables with array shouldn't always have an increased array size.
This is because unit-groups can be created in GUI (whereas dialogs and timers cannot).
It can be useful to increase the array size for unit-groups, but not if you use "set Group[x] = (...)". Then you're just asking for trouble .

Waits don't have to be "very inaccurate": only very short waits suffer from that problem.
(With a 0.50-second wait, the actual wait-time is about 50% off, but a 60-second wait is only about 0.4% off).
I just noticed Purge mentioned that as well, so here's some more info .
You can actually counter-act the inaccuracy of the wait: a wait will always add time, never subtract.
On average, the time it adds is about 0.25 seconds. If you need a 1-second wait, you better turn that into a 0.75-second wait (which will be somewhere between 0.90 and 1.1, way more accurate than a 1.0-second wait).

I see many new people who copy/paste every trigger 12 times for each player.
Perhaps you could dedicate a little paragraph to the DRY-principle for coding?
(You can always use 1 trigger with 12 events that works just the same as 12 separate triggers).

Final note: I don't like the yellow / teal colors .

 

[deathismyfriend]

Very good idea for a tutorial (and well executed), here are a few remarks:

Unit-group variables with array shouldn't always have an increased array size.
This is because unit-groups can be created in GUI (whereas dialogs and timers cannot).
It can be useful to increase the array size for unit-groups, but not if you use "set Group[x] = (...)". Then you're just asking for trouble .

unit groups can be created in GUI ? without local scripts i mean. ive never used them in gui haha

Waits don't have to be "very inaccurate": only very short waits suffer from that problem.
(With a 0.50-second wait, the actual wait-time is about 50% off, but a 60-second wait is only about 0.4% off).
I just noticed Purge mentioned that as well, so here's some more info .
You can actually counter-act the inaccuracy of the wait: a wait will always add time, never subtract.
On average, the time it adds is about 0.25 seconds. If you need a 1-second wait, you better turn that into a 0.75-second wait (which will be somewhere between 0.90 and 1.1, way more accurate than a 1.0-second wait).

this i did not know about. i will definitely include this.

I see many new people who copy/paste every trigger 12 times for each player.
Perhaps you could dedicate a little paragraph to the DRY-principle for coding?
(You can always use 1 trigger with 12 events that works just the same as 12 separate triggers).

true i should include a little something on this.

Final note: I don't like the yellow / teal colors .

what colors would u suggest ? i want to make them stand out a little.

 

[ap0calypse]

unit groups can be created in GUI ? without local scripts i mean. ive never used them in gui haha

Yeah, if you do something like "Set UnitGroup = (whatever)", you're creating a new group .

what colors would u suggest ? i want to make them stand out a little.

I'm not too good with colors myself, unfortunately .
I'd say something in the same style (Yellow/Cyan), but then a bit softer on the eyes.

Test1

Variables That aren't Handles

• Integers
• Reals
• Strings
• Booleans
• code

Title color = #ffc0c0
List color = #bbffcc

Test2

Variables That aren't Handles

• Integers
• Reals
• Strings
• Booleans
• code

Title color = #8d8dff
List color = #c0e0ff

 

[deathismyfriend]

Yeah, if you do something like "Set UnitGroup = (whatever)", you're creating a new group .

I'm not too good with colors myself, unfortunately .
I'd say something in the same style (Yellow/Cyan), but then a bit softer on the eyes.

Test1

Variables That aren't Handles

• Integers
• Reals
• Strings
• Booleans
• code

Title color = #ffc0c0
List color = #bbffcc

Test2

Variables That aren't Handles

• Integers
• Reals
• Strings
• Booleans
• code

Title color = #8d8dff
List color = #c0e0ff

ooo using the unit groups like that creates them ? i didnt know that. thanks

as for the colors what do u think about the purple for the header and the orangish for the text ?

edit updated.

edit 2: added a chapter to explain how to use coloring for texts using hexadecimal coloring.

 

[Zwiebelchen]

I love how you completely ignored my posts (http://www.hiveworkshop.com/forums/2324638-post51.html and http://www.hiveworkshop.com/forums/2325649-post55.html)
But well, it's up to Purge to decide wether this is approvable or not...

And let's face it: There have been worse tutorials getting approved, so I'm fine with that.
I still think this needs a lot of improvement from a writing perspective.

 

[deathismyfriend]

I love how you completely ignored my posts (http://www.hiveworkshop.com/forums/2324638-post51.html and http://www.hiveworkshop.com/forums/2325649-post55.html)
But well, it's up to Purge to decide wether this is approvable or not...

And let's face it: There have been worse tutorials getting approved, so I'm fine with that.
I still think this needs a lot of improvement from a writing perspective.

i didnt ignore them i had a power outage and lost a few things when i was updating. forgot to go back to make sure i had everything listed. also im not shortening any of the chapters.

updated to include the tutorials in ur earlier post.

 

[PurgeandFire]

I agree with Zwieb in that there is still room for improvement, but this tutorial still has a decent merit on its own. I think it could be organized a bit better an some areas could be changed in terms of comprehensiveness (some could have more details, others could lose some), but people have been responding to this really well, so it seems that it persists to be effective.

I guess the important thing to think about is that it suits its purpose in giving a rough intro/insight into the mentioned topics. I just need to edit it for fact-checking and grammar/spelling/phrasing revisions.

Good work and thanks for the updates. Consider this tutorial in purgatory--I'll have it updated and moved to the proper section when I have time.

 

[deathismyfriend]

I agree with Zwieb in that there is still room for improvement, but this tutorial still has a decent merit on its own. I think it could be organized a bit better an some areas could be changed in terms of comprehensiveness (some could have more details, others could lose some), but people have been responding to this really well, so it seems that it persists to be effective.

I guess the important thing to think about is that it suits its purpose in giving a rough intro/insight into the mentioned topics. I just need to edit it for fact-checking and grammar/spelling/phrasing revisions.

Good work and thanks for the updates. Consider this tutorial in purgatory--I'll have it updated and moved to the proper section when I have time.

cool cool when u make the the changes ill keep those. so i can still update it when needed. Also im not the best at explaining so if u can explain some things better plz feel free lol. as for removing some info i still dont like that idea. i would like it if u didnt remove any data.

 

[PurgeandFire]

cool cool when u make the the changes ill keep those. so i can still update it when needed. Also im not the best at explaining so if u can explain some things better plz feel free lol. as for removing some info i still dont like that idea. i would like it if u didnt remove any data.

I'm not removing data, don't worry. I was just making a point. Most of my edits will be minor edits for clarification, phrasing, and grammar/spelling.

EDIT: In the process of editing. I only did the first two sections so far. I saved it for now and I'll make more updates later. I have a copy of the original tutorial as well as a word doc with comments on it.

 

[deathismyfriend]

I'm not removing data, don't worry. I was just making a point. Most of my edits will be minor edits for clarification, phrasing, and grammar/spelling.

ok cool haha ill take in consideration on removing some data on things i explain a little to much. thanks for the fixing i hope there isnt to much lol. i never spell or use correct grammar on the internet. So when i was typing this i may of made some mistakes lol. as for phrasing well i suck at that at times.

edit: sweet almost 1k viewes lol

 

[Almia]

• Set integerArray[((Player number of (Triggering player)) + 20)] = 1[TRIGGER]

 

[deathismyfriend]

• Set integerArray[((Player number of (Triggering player)) + 20)] = 1[TRIGGER][/QUOTE]
• whats this referring to ?

 

[Almia]

Broken bb code silly

 

[deathismyfriend]

ooo ok i fixed it. i hate when updating i gotta start putting a version number lol. i lost some data when i was making this like the timer chapter and the rest of the floating text chapter. gonna have to make all that crap again

 

[gorillabull]

nice tutorial to use as a reference i wish there was something like this when i was using gui

 

[MasterTrainer]

nice tutorial to use as a reference i wish there was something like this when i was using gui

You and me too brother.

 

[deathismyfriend]

thx gorillabull.

 

[Kyrbi0]

Very interesting. Will have to fully read. Just a quick question:

Isn't this:

• MUI
• Events
• Unit - A unit Dies
• Conditions
• Actions
• Wait 10.00 seconds
• Hero - Instantly revive (Triggering unit) at (Center of (Playable map area)), Hide revival graphics

not MUI because it references a location (center of (playable map area)) which leaks?

//EDIT - Oh wait, I might be confusing MUI with leaks.

 

[MasterTrainer]

Very interesting. Will have to fully read. Just a quick question:

Isn't this:

• MUI
• Events
• Unit - A unit Dies
• Conditions
• Actions
• Wait 10.00 seconds
• Hero - Instantly revive (Triggering unit) at (Center of (Playable map area)), Hide revival graphics

not MUI because it references a location (center of (playable map area)) which leaks?

//EDIT - Oh wait, I might be confusing MUI with leaks.

A trigger may be MUI with leaks.

In my knowledge.

 

[deathismyfriend]

yes this is MUI and yes it does leak. MUI and leaks have no correlation to each other.

 

[Pr0blemBro]

How to use SetUnitPropWindow in GUI! :/

 

[deathismyfriend]

u need a custom script.
like this

• Custom script: call SetUnitPropWindow( udg_tempUnit, udg_tempReal)

the unit is the unit u want affected. the tempReal is the angle. it is a real variable.

 

[Pr0blemBro]

Aah thaanks :d

 

[deathismyfriend]

np lol.

 

[Daffa]

Very nice tut for GUI-er

But you should consider removing your signature on the second post.