As most people should know, Scripting Helpers is a help website, not a request website. Yet there are many questions that come across as requests, but are not, and other questions that are poorly constructed and do not provide enough information to a person answering these questions. With these questions, there also comes along poor answers. This article aims to be a reference to anyone wishing to open up a question or post an answer to an existing question.
Questions
Scripting Helpers allows for two different types of questions. Error Fixing and Concepts.
Error Fixing
- Error Fixing is relatively self-explanatory. If you're experiencing an error or bug with your code, we probably have a good eye to catch your error. These questions should be constructed with a sufficient amount of information. These may include the following:
- Testing Style. Are you testing using Roblox Studio's "Play" or "Run" modes, or a Studio test server? is this issue happening in a live game? These details are important if a script is working in studio as opposed to online. More details can be found in this guide.
- Script Location and Script Type. There are two main types of scripts, regular (also called server-side) and local (also called client-side). LocalScripts show a little character icon while regular scripts show only a scroll icon. LocalScripts can only run from few specific places, such as a player's PlayerGui, PlayerScripts, Backpack, and Character. Server-side scripts are a little more free than LocalScripts as to where they can run from, however will not work from storage containers like ServerStorage. Location and script type matters a lot, and should be included in the question.
- Output and Errors. Some scripters will put
print()statements on multiple lines to try to narrow down the source of their error. Providing errors or output information may help another scripter to more easily find the source of the problem. Reading and understanding these error messages or printing out the value of variables may even help you solve your problem yourself. - The Outcome. When testing your script, what is the actual result? what is your expected result?
- The Code. How is it possible to solve a problem when we do not know your code? Without this information, your question likely will not get very far.
- Attempts. Let us know what you have tried and what result you have obtained. Please ensure thorough testing has been completed on your end so we can better help fix the problem.
- Steps to Reproduce. Only share code that pertains to your problem. However, allow us to be able to replicate the problem as well. If you need to, provide steps to reproduce so we can figure out how to initially set it up. Oftentimes this is not required, however, there are few instances where this is necessary.
- Screenshots. If an explanation doesn't go well, try taking screenshots of what is going wrong. Probably better yet, a gif! There's some free software out there that will take your screen and put it in a gif such as ShareX, ScreenToGif or LICEcap. You can upload these images to Imgur, Gyazo, or PrntScr.
Additionally, make sure questions don't fall under a Common Mistake, some questions can be resolved rather quickly once the problem becomes more obvious.
Concepts
- Concepts are more of the questions for a starting ground. These questions should be crafted carefully so as to not impose the work on the Asker. In other words, they should not appear as requests. These questions are designed for understanding a service, function, method, etc. or to get an idea of what is needed to complete a task.
- Scripters are not for hire here. The primary reason for questions being closed is due to them being requests. These questions are often made by people not willing to put in the effort to learn how to script themselves. Others may offer rewards for working with these askers, which goes against Community Guidelines.
- Show us what you know. We want to understand you have a decent idea of what you're doing. This way when we go to set you in the right direction, you won't find yourself getting stuck.
Moderation
Some things we don't want to see...
- Spam questions (then again who else wants to see spam?).
- Not Constructive questions or requests.
- We want you to understand the code you're writing and the code the community has fixed for you.
- If the code ends up drawing issues three months down the road, you should at least have an idea of how to fix it.
- If it was supposed to be a "Concepts" question, craft it a little more carefully. It may sound like a request to community members, in which case it will likely get closed.
- Off-Topic questions (we are Scripting Helpers, not "Building Helpers" nor Roblox support).
- Broad questions (typically the concepts ones which have a large variety of solutions)
- Non-Descriptive (typically with "Bugs and Errors" questions, it is necessary for us to be provided details of your problem)
- Duplicate questions (most of the time questions posted in the past few days or questions of the exact same topic explained in the past. If your question does not have an answer within a few [three] days, delete it and re-ask).
If your question gets moderated and you feel it is unjustified, contact a support agent. They will be able to give you insight to the problem with your question or even repeal the moderation claim posted on your question.
Answers
Along with bad questions we also see bad answers. Sometimes questions can be answered in the comments, other times the person answering the question does not actually know the topic. Answers may come with simply code or simply with an explanation. There is the need to find that happy medium between giving an explanation and giving code.
Error Fixing
Here are some suggestions you should take into account when constructing a proper answer.
- Problems: point out problems with the asker's original code, what would cause error and such. Explain why the code is providing the error.
- Solutions: after pointing out the problem(s), explain the solution(s) to these problems. Explain why this method will work and why the original script would not.
- Recommendations: provide recommendations if the code is inefficient or could be otherwise improved, such as having fifty lines doing a similar action where a loop could be used, or usage of deprecated methods. Move people toward an easier solution and away from old and bad practices.
- Example or Final Script: you can provide a fixed version of the person's script, or you can simply provide an explanation with instructions on how it could be implemented. Either way, you need the explanation of the code and of the problem.
Concepts
With the carefully crafted questions asking how to achieve a certain goal, we may provide answers with steps or elements to look into. Scripting Helpers is not a request website. If you feel as though a question is a request, you are in control; you can decide if you wish or not to help someone. Please do not report request questions; we wish questions to be moderated by the community, not by website staff.
- Explain the purpose of the pages. Should you redirect an Asker to a reference page, such as a Roblox Wiki tutorial, try explaining the page further. Put it in layman's terms. “You do not really understand something unless you can explain it to your grandmother.” ~Albert Einstein
- Provide example code and explain the code, and why it works. You do not have copy and fix the exact code of the Asker, you can simply provide a general idea, which is usually better.
These answers require a lot of thought and a great amount of detail. Be prepared to be asked further questions down the line, and to answer them in the comments.
Formatting
It's always a good idea to have formatting with your question and answer. Helps it stand out more. There are tools at the top of each editor to add bolded, italicized, and quoted messages. There are options to add code blocks, links, and in-line code. Many questions and answers get edited or overlooked because of poor formatting. Often, the problem lies with the code not being in a code block.
On the questions page, there's a preview button that is highly encouraged. Even when writing an answer, it might be beneficial to preview on this page what it looks like before posting it as a final answer. You can even use an online Markdown previewer such as StackEdit and see how your posts look on there before posting. You can get more formatting information from a forum post made by one of our administrators "How to format questions/answers on the main site."