Rory Noonan
Posts: 2816
Joined: 12/18/2014 From: Brooklyn, NY Status: offline
|
Hello and welcome to the tech support forum. Unless you're just looking around, you're probably here to get help. To get to the bottom of your problem and find a solution quickly, avoid the following common mistakes: • Not providing a save file • Asking if it’s okay to ask a question instead of just asking it • Implying your question instead of asking it directly • Asking your question on the wrong subforum or thread • Writing an unspecific post headline or email subject, such as “I have a problem” or “Please help” • Saying “this doesn’t work” but not explaining how you want it to work • Not including the full error message if one appears • Not explaining what you’ve already tried • Not giving operating system or version information • Asking someone to write a script or make a scenario for you This list of “don’ts” isn’t just for decorum; these habits prevent your helpers from helping you. Your helper’s first step will be to try to reproduce your problem. To do so, they’ll need a lot of information about the specific issue they're looking at, your computer, and your intentions. There are nearly endless variables here so we ask that any tech support post is accompanied by a save file showing the issue. With a save file, we already have the information we need to solve >90% of issues, and a good start for the remainder. It’s far more common to provide too little information than too much. If you remember nothing else when making a tech support forum: Please, please provide a save file. The next several sections explore what you can do to prevent other common mistakes. Limit Back and Forth by Providing Your Information Upfront If you approached someone in person, asking “Can I ask you a question?” would be a short, pleasant means to see if your helper was available. But on online forums, your helper can hold off on a reply until they have the time to do so. Because there could be hours between replies, it’s best to supply all the information your helper might need in your initial post instead of asking for permission to ask your question. State Your Question in the Form of an Actual Question It’s easy to assume that your helpers know what you’re talking about when you explain your problem. But Command is an expansive simulation, and they might not have experience with the particular area in which you’re having trouble. So it’s important to state your question in the form of an actual question. Although sentences that begin with “I want to . . .” or “This isn’t working” can imply what your question is, be sure to include explicit questions: literally, sentences that end with a question mark. Otherwise, it’s probably unclear what you’re asking. Ask Your Question in the Appropriate Place Asking a tech support question in a new release thread or an strategy question in tech support will likely be unproductive. We have stickied posts (like this one) in each subforum with useful information, plus a comprehensive FAQ. Summarize Your Question in the Headline The benefit of posting your question to an online forum is that future users who have the same question can find it and its answers using an internet search. Be sure to use a headline that summarizes the question to make it easy for search engines to organize. A generic headline like “Help please” or “Why isn’t this working?” is too vague. If you’re asking your question in an email, a meaningful subject line tells your helper what your question is as they scan their inbox. Explain What You Want the Sim to Do The question “Why doesn’t this work?” omits the critical detail of what you want the simulation to do. This isn’t always obvious to your helper, because they don’t know what your intention is. Include the Full Error Message Merely describing your error, such as “I’m getting an out of range error,” doesn’t provide enough detail for your helper to figure out what is wrong. Also, specify whether you always encounter this error or if it’s an intermittent problem. If you’ve identified the specific circumstances in which the error happens, include those details as well. Provide a Save File Provide a scenario file showing the issue. That way, your helper can run the exact same setup on their machine under a debugger to examine what is happening. Always produce a minimum, complete, and reproducible (MCR) example that reliably reproduces the error you’re getting. The MCR term comes from Stack Overflow and is discussed in detail at https://stackoverflow.com/help/mcve/. Minimal means your scenario file example is as small as possible while still reproducing the problem you’re encountering (e.g. encountering an issue dropping bombs in a >2,000AU scenario; removing all units except the aircraft dropping bombs and its intended target--otherwise the developer is looking at the AI calculations of 1,998 uninvolved units!). Complete means that your code example contains everything it needs to reproduce the problem. Reproducible means that your example reliably reproduces the problem you’re describing. Adapted from Swiegart A, 2020
< Message edited by Rory Noonan -- 11/23/2020 5:11:19 AM >
_____________________________
|