- Joined
- Sep 6, 2013
- Messages
- 6,742
Asking for trigger support
Introduction
We face many problems during a map development and often want to ask quick questions to the community to get rid of it. Usually Triggers & Scripts, or World Editor Help Zone becomes a good place for that case, but the helping process is not always smooth and so the support can easily become frustrating, delayed, or even denied if essential things are not followed. Here are some tips for both sides, for the one who asks, and for the one who answers back, to have a succeeded conversation in a helping thread.
Maybe a first thing right away. Warcraft 3 is an old game and it's most likely people already required similar help that you need right now. We should use such cases and try to google for related topics, and maybe we find a perfect fitting solution with ease.
Maybe a first thing right away. Warcraft 3 is an old game and it's most likely people already required similar help that you need right now. We should use such cases and try to google for related topics, and maybe we find a perfect fitting solution with ease.
Information
Asking For Help
Providing Help
Good title
Choose a short and descriptive title. It should summarize the thread's content in a subject. Having "Please Help" does not explain anything while "How to periodically spawn units" can give the reader some idea what it is about.
Title is not enough
Describe your problem in plain text and in full sentences in your thread, so others always have the possibility to get a rough opinion on the matter without having to over-interpret the thread title, or to start analysing attached files. Especially if you want to re-create triggers from other games, do always shortly explain what it is about and possibly provide links.
Goal
Assume the reader knows nothing about you and your problem, so firstly always give an explanation of what your concrete goal is. With this, even you maybe already have an approach, the helper has the chance to "think from scratch" and might provide an other, or simpler approach for solving.
Current State
Share your personal finds and experience about trigger behaviour you already found while testing and playing. With knowing "is-" and wanted "target-" behaviour at same time one might easier exlude scenarios or isolate the problem to faulty lines.
Content
Give the user relevant content that might be used to solve the problem. Don't let everyone else create solutions from scratch:
Not too little info
The reader needs to see every information that is related, for example like:
Not too much info
Showing too much unrelated infomation can extremely slow down the helping process:
Choose a short and descriptive title. It should summarize the thread's content in a subject. Having "Please Help" does not explain anything while "How to periodically spawn units" can give the reader some idea what it is about.
Title is not enough
Describe your problem in plain text and in full sentences in your thread, so others always have the possibility to get a rough opinion on the matter without having to over-interpret the thread title, or to start analysing attached files. Especially if you want to re-create triggers from other games, do always shortly explain what it is about and possibly provide links.
Goal
Assume the reader knows nothing about you and your problem, so firstly always give an explanation of what your concrete goal is. With this, even you maybe already have an approach, the helper has the chance to "think from scratch" and might provide an other, or simpler approach for solving.
Current State
Share your personal finds and experience about trigger behaviour you already found while testing and playing. With knowing "is-" and wanted "target-" behaviour at same time one might easier exlude scenarios or isolate the problem to faulty lines.
Content
Give the user relevant content that might be used to solve the problem. Don't let everyone else create solutions from scratch:
- Post your triggers
- Attach a demo map showing the problem
Not too little info
The reader needs to see every information that is related, for example like:
- triggers that interfere with the trigger with the bug
- where and how are variables assigned
- gameplay constants / object editor
- custom functions and libraries
Not too much info
Showing too much unrelated infomation can extremely slow down the helping process:
- When attaching a demo, keep an eye on removing not needed triggers/units, etc, to isolate the problem as good as possible.
- Keep the focus on the problem. It's not optimal if people are required to read 20 lines about some introduction, while only the last line is about the actual problem.
Focus on user-problem
Try to understand what the user asks for. Side-topics, like leaks, efficiency, performance, might be good to note, too, but it shouldn't be major, or happen too intrusive.
Lingo/phrasing
Keep your language and explanation as simple as possible. Hive is a site for hobby modders, and it's not needed to get things explained in a senselessly complex manner. It's a useful skill to explain complex problems in a simple way, while for example it will be worthless to post advanced programming approaches in GUI beginner threads. Try not to over-complicate things.
Why, not what
It's much more useful also to explain why the bug occured instead of only posting a solution without explanations. With having also the theoretical reasoning, it will increase the learning curve for the user and also for future visitors. Afterall we want to provide some platform for learning.
Links, links, links
In many cases there already exist same, or similar questions. Instead of re-explaining things over and over again with potentially forgetting details, it's often more useful to link to an existing tutorial, guide, or other posts which does already solve the respective problem. We should have an eye to have only a few threads with a topic which we outwork in good quality instead of starting each time from scratch.
Try to understand what the user asks for. Side-topics, like leaks, efficiency, performance, might be good to note, too, but it shouldn't be major, or happen too intrusive.
Lingo/phrasing
Keep your language and explanation as simple as possible. Hive is a site for hobby modders, and it's not needed to get things explained in a senselessly complex manner. It's a useful skill to explain complex problems in a simple way, while for example it will be worthless to post advanced programming approaches in GUI beginner threads. Try not to over-complicate things.
Why, not what
It's much more useful also to explain why the bug occured instead of only posting a solution without explanations. With having also the theoretical reasoning, it will increase the learning curve for the user and also for future visitors. Afterall we want to provide some platform for learning.
Links, links, links
In many cases there already exist same, or similar questions. Instead of re-explaining things over and over again with potentially forgetting details, it's often more useful to link to an existing tutorial, guide, or other posts which does already solve the respective problem. We should have an eye to have only a few threads with a topic which we outwork in good quality instead of starting each time from scratch.
Last edited:
