How to Ask Questions & Receive Good Answers

[Rake]

Game Name

N/A

Anticheat

N/A

How long you been coding/hacking?

7 years

Coding Language

N/A

Most Important

99% of questions are answered in the Beginner's Guide, do it before asking a question.

If you ask a question that is answered by doing the Beginner's Guide, you're a garbage farmer.

No Hack Requests. Post in the correct section. Search the forum first. Read the rules.

How to make a good post:

• Thread title must be descriptive
• Write in clear, grammatical, correctly-spelled language
• No 1 sentence posts, use full sentences
• Fill out the form correctly
• Tell us the game name & coding language
• Post everything we need to know to help you
• Ask specific questions, be descriptive
• Post errors, line numbers & screenshots
• Post all code snippets using code tags
• If it's a large project, zip it up and attach it

We want to answer your question!

But we don't want to help lazy, immature or stupid people.

Hackers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true.

People who do not do their homework before asking questions are lazy. We do not respect lazy people.

If you post a good question, you will get an answer.

Blame yourself before blaming anything else - 99% of problems are user error

Before You Ask

1. Search the forum
2. Look up the topic in our guides
3. Read the documentation
4. Try to find an answer by inspection or experimentation.
5. Try to find an answer by reading the source code.

Be precise and informative about your problem

• Describe the symptoms of your problem or bug carefully and clearly.
• Describe the environment in which it occurs (machine, OS, application, whatever).
• Describe the research you did to try and understand the problem before you asked the question.
• Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
• Describe any possibly relevant recent changes in your computer or software configuration.
• If at all possible, provide a way to reproduce the problem in a controlled environment.

Describe the goal, not the step
What are you trying to do, and why are you trying to do it? You might be doing it 100% wrong.

When you ask

While you ask questions make sure you take care of the following:

• Describe your problem as much as possible, with much words etc
• Describe the symptoms of your problem or bug carefully and clearly.
• Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor's distribution and release level
• Describe the research you did to try and understand the problem before you asked the question.
• Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
• Describe any possibly relevant recent changes in your computer or software configuration.

If at all possible, provide a way to reproduce the problem in a controlled environment.

Add the source code of where your problem is

Don't ask others to debug your broken code without giving a hint what sort of problem they should be searching for. Posting a few hundred lines of code, saying "it doesn't work", will get you ignored. Posting a dozen lines of code, saying "after line 7 I was expecting to see <x>, but <y> occurred instead" is much more likely to get you a response.

source https://www.catb.org/esr/faqs/smart-questions.html

 

[NTvalk]

Before you create a new thread with your question please read these rules/guidelines, it will help you to get the right answer and help others to understand your problem.
In the world of game-hackers, the kind of answers you get to your technical questions depends as much on the way you ask the questions as on the difficulty of developing the answer. This small guide will teach you how to ask questions in a way more likely to get you a satisfactory answer.

The first thing to understand is that we actually like hard problems and good, thought-provoking questions about them. If we didn't, we wouldn't be here. If you give us an interesting question to chew on we'll be grateful to you; good questions are a stimulus and a gift. Good questions help us develop our understanding, and often reveal problems we might not have noticed or thought about otherwise. Among hackers, “Good question!â€￾ is a strong and sincere compliment.

Despite this, hackers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true.

What we are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions. People like that are time sinks — they take without giving back, and they waste time we could have spent on another question more interesting and another person more worthy of an answer.

We realize that there are many people who just want to use the software we write, and who have no interest in learning technical details. For most people, a computer is merely a tool, a means to an end; they have more important things to do and lives to live. We acknowledge that, and don't expect everyone to take an interest in the technical matters that fascinate us. Nevertheless, our style of answering questions is tuned for people who do take such an interest and are willing to be active participants in problem-solving. That's not going to change. Nor should it; if it did, we would become less effective at the things we do best.

We're (largely) volunteers. We take time out of busy lives to answer questions, and at times we're overwhelmed with them. So we filter ruthlessly. In particular, we throw away bad questions and spend our time on good questions.

If you find this attitude obnoxious, condescending, or arrogant, check your assumptions. We're not asking you to genuflect to us — in fact, most of us would love nothing more than to deal with you as an equal and welcome you into our culture, if you put in the effort required to make that possible. But it's simply not efficient for us to try to help people who are not willing to help themselves. It's OK to be ignorant; it's not OK to play stupid.

So, while it isn't necessary to already be technically competent to get attention from us, it is necessary to demonstrate the kind of attitude that leads to competence — alert, thoughtful, observant, willing to be an active partner in developing a solution. If you can't live with this sort of discrimination, we suggest you pay somebody for a commercial support contract instead of asking hackers to personally donate help to you.

Before You Ask

Before asking a technical question on this section of the forum:

Try to find an answer by searching the archives of the forum.

Try to find an answer by searching the Web.

Try to find an answer by reading the manual (comments and such).

Try to find an answer by inspection or experimentation.

Try to find an answer by reading the source code.

When you ask

While you ask questions make sure you take care of the following:

Describe your problem as much as possible, with much words etc

Describe the symptoms of your problem or bug carefully and clearly.
Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor's distribution and release level
Describe the research you did to try and understand the problem before you asked the question.
Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
Describe any possibly relevant recent changes in your computer or software configuration.

If at all possible, provide a way to reproduce the problem in a controlled environment.

Add the source code of where your problem is, try to add as much source code but at the same time not too much

Adding words like (URGENT!) won't help you, remember we are volunteers.

Choose the right subject header

On mailing lists, newsgroups or Web forums, the subject header is your golden opportunity to attract qualified experts' attention in around 50 characters or fewer. Don't waste it on babble like “Please help meâ€￾ (let alone “PLEASE HELP ME!!!!â€￾; messages with subjects like that get discarded by reflex). Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description instead.

Write in clear,grammatical, correctly-spelled language

We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding (often enough to bet on, anyway). Answering questions for careless and sloppy thinkers is not rewarding; we'd rather spend our time elsewhere.

Describe the goal, not the step

If you are trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you are blocked on.

Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this.

Stupid:
How do I get the color-picker on the FooDraw program to take a hexadecimal RGB value?

Smart:
I'm trying to replace the color table on an image with values of my choosing. Right now the only way I can see to do this is by editing each table slot, but I can't get FooDraw's color picker to take a hexadecimal RGB value.

Don't ask others to debug your broken code without giving a hint what sort of problem they should be searching for. Posting a few hundred lines of code, saying "it doesn't work", will get you ignored. Posting a dozen lines of code, saying "after line 7 I was expecting to see <x>, but <y> occurred instead" is much more likely to get you a response.

source catb.org

 

[Crazywink]

Hey guys, Agent Smith and I have been talking lately and we've noticed (as a lot of you have too I'm sure) that people come and request and ask for help on topics that are clearly completely out of their scope on knowledge.
The forums get BOMBARDED with aimbot and ESP help requests when the person doesn't even know how to create a project in VS.

This goes to everyone: PLEASE don't request help on aimbots, ESP's, or anything that is clearly out of your knowledge base.

Fleep has excellent tutorials for beginning and you can work your way up to these hacks, but PLEASE stop asking for help and expect people to spoon feed you code.
We are here to help and we enjoy doing so, but you need to understand WHAT we're saying.

Start with Fleep's simple C# trainer tutorial
Video Tutorial - How to Make a TRAINER C# LEARN TO HACK TUTORIAL DIFFICULTY [1/10]

Work your up through his other tutorials
GH Hack Video Tutorials

He has dedicated a lot of time to making these tutorials and even giving you a rating of how difficult they are. Don't skip over them if you don't know what you're doing.

From here on out, if you post asking questions which shows it is completely out of your range and you haven't taken the time to learn, the thread will be closed.


Sincerely,
Your Friendly Guided Hacking Moderating Team. ​

 

[squeenie]

Been waiting for this post

 

[Solaire]

You need to go through this checklist before posting a question.

1. Do you know the language you're coding that hack in?

a. No? Go back and learn the language
​

2. Is it your source?

a. No? Did you study it to a point where you understand it completely? If not, go back and do that.
​

3. Did you set breakpoints and step through the code to spot the area where the error is occurring?

a. No? Go and do this now.
​

4. Did you Google extensively to try and find another solution to your problem?

a. No? Go and do this now.
​

 

[Obsta]

I never understood breakpoints, doesn't VS just point out where your issue is when the application crashes? Obviously i know i'm misinformed because everyone swears by them.

 

[till0sch]

I never understood breakpoints, doesn't VS just point out where your issue is when the application crashes? Obviously i know i'm misinformed because everyone swears by them.

You can set breakpoints in Visual Studio yourself, which, yea break, when a certain spot gets hit like a debugger..
I think this stands in comparison with Cheat Engine's or OllyDbg's breakpoints, just that you can place them directly in visual studio.

As I am always injecting with Cheat Engine and not with Visual Studio, which I think is possible (attach process, or not?) I am not sure whether you can in DLL codes place such breakpoints, which with another memory editing debugger you probably can.

 

[Solaire]

You can set breakpoints in Visual Studio yourself, which, yea break, when a certain spot gets hit like a debugger..
I think this stands in comparison with Cheat Engine's or OllyDbg's breakpoints, just that you can place them directly in visual studio.

As I am always injecting with Cheat Engine and not with Visual Studio, which I think is possible (attach process, or not?) I am not sure whether you can in DLL codes place such breakpoints, which with another memory editing debugger you probably can.

You attach visual studio to the game process, set your breakpoints, then inject. They will be hit and you can step through your code and watch the variables.

The reason I put debugging in the checklist is because it will solve 90% of your problems.

 

[PwndDepot]

You should update the links for the newbies

 

[Rake]

I updated this to be a shorter and easier read