This topic serves a simple purpose: to explain what programming is, and most of all, what programming is
not. While I love helping people out, recently I've been getting pretty annoying with a number of requests (no, not you, person-whom-I-still-owe-a-bit-of-coding-that-I-can't-seem-to-get-around-to) of people who are struggling with a programming problem. But in all reality, most of these problems are nothing more than a lazy person who doesn't want to use google, or doesn't want to use their head. I know these people are actually pretty smart, and that's why catering to those questions makes me cringe. Anyhow, now that my annoyances have been adressed, let's get on with it.
Step one: THINK!QUOTE
Programming is nothing more than breaking down a process into little chunks and identifying what is needed to do something else. Once you know the chunks, you know how to write it in the language you program in. If you don't know how to do something, you can search the net for your very specific action (e.g. popup a window, split a string by the commas in it, calculate the remainder of a division) and you'll find an example of that in no time. All it takes then is to adapt it to your situation.
That is what I wrote elsewhere on these forums. You do not need to code to do the first and most important step of programming: thinking. Split a lengthy process up in pieces before trying to type stuff out. For example, let's say you want an auto-sipper.
CODE
I want to sip when I get low.
... becomes ...
CODE
1) I want to sip health when below 2000 health.
2) I want to sip mana when below 1500 mana
But how? The information is all in my prompt!
CODE
1) Use the prompt to do the following:
1.1) I want to sip health when below 2000 health.
1.2) I want to sip mana when below 1500 mana.
But, wait wait wait. I get my prompt all the time. What if it gets spammy? I don't want to empty my health vial like crazy when I am low and I get a lot of other prompts. So when -should- I sip? Hrm... I can only sip when I have had the 'you can sip another health or mana elixir.' message.
CODE
1) Use the prompt to do the following:
1.1) See if I am allowed to sip.
1.1.1) I want to sip health when below 2000 health.
1.1.2) I want to sip mana when below 1500 mana.
1.1.3) If I did either of those, forbid myself from sipping again.
2) Use the 'sip again' message to:
2.1) Keep track of whether or not I can sip.
That's looking to shape up just fine. But think about it, are we missing something? Oh crap, yes we are. What if I am sleeping while trying to sip? What if I have stupidity? Amnesia? I won't be sipping, and worst of all, I'll never sip again. So what do I want to happen?
- I want to retry sipping every 5 seconds when something doesn't go through, until it actually happens.
- After it went through, I still need to wait until I am allowed to sip again.
CODE
1) Use the prompt to do the following:
1.1) See if I am allowed to sip and whether I should (re)try sipping.
1.1.1) I want to sip health when below 2000 health.
1.1.2) I want to sip mana when below 1500 mana.
1.1.3) If I did either of those, remember to sip again in 5 seconds if I haven't.
2) Use the drinking-from-a-vial message to:
2.1) Tell myself that I don't need to retry drinking again.
2.2) Forbid myself from sipping again.
3) Use the 'sip again' message to:
3.1) Keep track of whether or not I can sip.
Now, that looks just about perfect! Maybe we didn't reason all this far, and ended up coding at one of the previous steps, because we didn't foresee sipping not going through. That's not a problem, since programming is an iterative process that is about comparing the various steps with what you know, understand and expect to happen in turn. Likewise, the above example can be improved to take account for illusions: a crafty syssin or illusioner could make the sipper we 'thought up' lock up in a state of not sipping. How and why this happens is an exercise to the reader, as well as thinking of a way to solve this.
Step 2: HOW?This brings the next issue, okay, how can we do what we want it to do? Well, due to the nature of the plan we wrote, we actually have the solution, but we do not know the way to make the client we use do what we want. And since I don't know what you use, I am not going to go into any specific language, be it Zmud, Python, VBScript or others, since the things of interest are pretty much the same.
Basically, everything you want to do depends on two things: remembering stuff and the ability to make choices based on that stuff.
Remembering stuff can be done through
variables. Essentially, they're ways to refer to some information you can change to your liking. You decide what to put in it, and what you consider to be acceptable values. Often, you have a yes/no choice for something. An often made choice is to pick the number 1 to denote 'yes' and the number 0 to mean 'no'. How to use variables and what intricacies come with them in your client, is something you'll have to find out for yourself. The magic word is 'variables'.
Making choices is done through if-statements. They basically exist out of a condition, action(s) to perform when the condition checks out, and possible action(s) to perform if the condition does not check out. In other words, an if-statement is a simple yes-or-no kind of question. An example (in words, not code!) would be: if my target variable is 'kylan', THEN I want to lick him, OTHERWISE (else) I want to bash my targets brains in. How to do things like these in your language of choice, you'll have to find out for yourself. The magic words are 'if statement'.
Now, these two essential tools to programming simple logic also introduce you to the fact programming means you have to stick to the rules of the language. Something that may make sense to you, may sound like chinese to the computer and make it unable to understand what you mean. So if you get errors, DOUBLECHECK YOUR CODE. I can not stress this enough. For example, pretty much every language has a means of saying 'this is the end of the actions to be performed for this if-statement'. So don't leave it away because it is the end of the script, but just be nice and tell the computer the if-statement is done. To take it a step further, you can consider any command as a mold where you fill in the blanks. For example, 'IF <condition> THEN <action> END' could become 'IF target is kylan THEN lick kylan END'. You don't ever remove the parts of the mold. If you bother me with errors, and you're not sticking to the basic mold (also called syntax in programmers language) I'm killing you, understand?
Step 3: RINSE & REPEATStuff can go wrong. Stuff will go wrong. There's no escaping it. Some things that might pop up are as follows.
You'll probably get (flashy) errors because you make mistakes in syntax. Figuring out where you go wrong should usually be simple to deduce if you compare your code with a working example of an if-statement, for example.
Or maybe you make a mistake in the logic. Essentially, you'll have to go back to the first step, and think it over. Where did it go wrong? How can I improve and adjust for that situation to not happen again? (Oh, by the way, find out how to turn your triggers off. You don't want to empty ten vials if you happen to forget your 'can I sip?' condititions with your prompt!)
In any case, it involves finding out what went wrong. And <insert-your-favorite-searchengine-here> will help you find what you need, as long as you state your questions simple. Not 'track health change zmud doesn't work' but rather the error message itself. You'll probably end up at a page explaining what you did wrong, and with a bit of adjustment, you can usually fix it in a matter of moments. That and you've learned yet another thing.
All together, programming is slow to start out. The more experience you get, the more you skip step 1, step 2 and step 3, and the more they all mingle together, especially for small projects like a sipper. Don't get discouraged if it takes you a few days to get your sipper working if you haven't programmed before, but keep working at it and try to find your own solutions, since that will make it oh so much more satisfying.
Step 4: PEOPLE READING THISIf people want to ask questions here, fine. If you want to help them, even better. But try to stick to the general ideas suggested in this thread, since I do not want another 'best things in zmud' topic or a 'lua over vbscript' discussion here. Also, don't give clear-cut answers. If people ask here, they clearly want to learn, so show them where thought-processes go wrong. Thank you.
Oh, and people learning.. thanks for putting up with reading this far and I hope it will help you any in whatever you're going to produce.
An introduction to programming, Client does not matter, it is all about the right mindset!
Oct 29 2007, 02:47 AM
