Coding for Newbie - Vol. 1

coding
By Rio Rivera-Young

 

Are you the type who has trouble remembering how to code even the simplest things? Does your targeting alias work just about as often as Helena Bonham Carter’s hairdo? Does the word alias mean as much to you as your neighbor’s antique bowling ball collection? If so, this tutorial is for you! In the first part of a series on learning basic coding strategies for your favorite online text game, I’ll teach you how to overcome the first hurdle when it comes to preparing yourself for the game: how to target.

 

MUD Coding 101

Now, before I get to the tutorial on targeting itself, there are a few definitions that one needs to know to understand what we’re doing. (Remember, the purpose of this article is to help those who are brand new to coding learn to code, advanced programmers, this will cover nothing new to you and likely be of no use!) A variable is a name given to a value that is changeable, when referencing the name you will be given the value instead. For an example, let’s think of simple math. In every arithmetic problem, there is a variable in our head; most people call it “answer” (although, for arguments sake, it could be called solution, resolution, or doo-dad). In the equation 2 + 3 = 5, the variable “answer” is equal to five. However, if our equation is 2 + 4 = 6, the variable, “answer,” changes to be six. An alias is an easier, mnemonic name that references a long, difficult, or inconvenient command.

 

For another real-life example, think of a regular household chore – laundry. When someone says they are going to do the laundry, the meaning of what they are about to do isn’t entirely clear. “Doing the laundry” is an alias for a sequence of events: taking dirty clothes to put in the washer, placing them in the dryer once that is finished, removing them from the dryer and folding them and putting them away in their proper place. Finally, a trigger is an automatic, coded reaction to a certain pattern of text.

 

One of our real life examples for this is a horror movie. As the music starts to reach its apex, the horribly naïve (albeit courageous) protagonist rounds the corner in the basement – only to find a bloody, axe-wielding, sexually-ambiguous, hulking mass murderer who lets out a blood-curdling screech. For most of us, our body’s natural reaction is to jump, whimper, or make an unattractive face. In this case, the trigger is the villain’s visage, and the reaction is whatever your body does in response to fear.

 

Alias and Variable for Targetting

Now, to set up targeting, we will need only two simple things! We need an alias, to change our target, and a variable, to store our target. Now, the manner in which you do this will depend on your client and your MUD – for this tutorial, I’ll feature a few clients and the online text game Achaea. First, we are going to make the variable. For Zmud and Cmud, this process is really simple – you can do your coding from the command line (the place you input text to get to the MUD, or where you type stuff and hit enter).

 

To make a variable, we use the #VAR function. It was designed to work like so -- #VAR {} {}. For our targeting variable, let’s do this: #VAR {target} {Cinya}. To make an alias, we use the #ALIAS function. It works thusly: #ALIAS {} {}. So, for a targeting alias, we will do #ALIAS {t} {#VAR {target} {%1}}. Some of this may be a bit confusing, and you may not know the purpose of the wildcard [%1] or curly brackets [{}], but we’ll cover those in another, advanced tutorial.

 

The same basic idea can be taken to Mudlet. Mudlet, unlike Z/Cmud, has no pre-made method of making or seeing your variable – so we’ll go straight to the alias part! In mudlet, click on the Aliases button, the third one from the left. Click Add Item, and a new alias will pop up. The form has four values, and we’ll fill in three of them. First, under alias name type “Targeting alias.” This allows you to easily search for, enable, disable, and reference the alias should you need to. Under pattern, we’re going to put in the following pattern “^t (.*)$” (without the quotation marks, of course!). We’ll cover the functions of the caret [^], dollar sign [$], and wildcard [(.*)] in another tutorial – for now, just treat it as magic.

 

Now, for the final touch, in the big blank white box, type “target = matches[2]”. Now, to use this, it’s very simple! We type “t ” and it changes our target appropriately. For example, if I’ve killed Cinya, and it’s time to move onto the rest of her family, I could “t Fyr” to change my target to Fyr or “t Nephenee” to attempt to kill her child.

 

Now, a targeting alias and variable are useless if you don’t reference them! Let’s make another alias, for the kill feature in Achaea! In Z/CMUD, all we have to do to reference a variable is to put the “at” symbol in front of it. So, remembering above where we talked about making an alias in the command line, type #ALIAS {kl} {kill @target}. In Mudlet, we click on the Add Item button within the Alias menu. Let’s name it “Kill Alias,” and the pattern will be “^kl$”. The pattern that we put in the biggest white box is slightly different, though. We must SEND what we want to the MUD, so we type “Send(“kill ”..target)”.

 

This alias, every time you type “kl” will attempt to use the command kill on whatever your variable “target” is. If our variable was Nephenee, typing “kl” would send “kill Nephenee” to the MUD. And there you have it! Your very own targeting and bashing aliases for Z/CMUD and Mudlet!

 

Tune in next time for mystery, intrigue, and triggers!

 

Now that you know how to target, set your sights on conquering some of the most epic MMORPGs there are.

 

Rio Rivera-Young is a text game enthusiast and currently plays games from Iron Realms.

Comments

Helena Bonham Carter is a handsome woman. You apologize.

I only pick on those that I love. :D

^^

The biggest tip that I could offer, regardless of which game you are playing, or what you are coding, would be to take advantage of the fantastic communities each game has to offer. Each game has a wide variety of coding types, from the social genius that enjoys sharing every bit of code they create with the community as a whole, to the more quiet coder that appears to be the one coming up with the most innovative ways around common coding problems. More times than not, somebody somewhere will be able to assist you with any problems that arise in your code-crunched snippet of script- all you need to do is ask.

Ask

Yea if you are having trouble what can it hurt to ask. You would be amazed at how much help people can be if you are nice about it.

In Achaea, there are OOC clans for most of the major clients, that you can join and get help from.

Always, ALWAYS save your work. Whether this means archiving, copy-pasting to a text document, or some other such thing, there's nothing worse than losing hours worth of code.

One of the better tips I found out about was commenting portions of code out to find bugs easier. This can be done in Mudlet by putting -- at the beginning of the script line. By doing this it ignores that part of the code, so if you have a complex script that isn't working right, you can comment out one whole section. If the script then works, that section was causing the issue. If not, move on and try other parts.

Some lessons learned from 6 years of tweaking a system.

*If there's a piece of code you're going to use in two or more places, put it in an alias and use the alias in those places. That way, if you need to change it in the future, you only need to change it once. Having to edit 400+ curing triggers isn't as much fun as it sounds.

*Every programming teacher you will ever have will try to drive the need to add comments to your code into you. You will dismiss it as crap because you know what you're doing and this isn't that complex anyways. When you find yourself looking back at 700 lines of code you wrote 3 years ago at 5am when you were barely awake, you will sorely regret that decision. You will never regret spending ~5 seconds to type "// Builds the elixlist display", but you can easily regret not doing so.

*Name your variables clearly. You don't want to be changing something 2 years down the road and find yourself asking "What's $sphvc supposed to be?"

Bad idea, because you're cluttering up the aliases and might inadvertantly run an alias code that you do not mean to. 

 

What you should be doing for code reuse is putting code into standalone functions and then calling those functions actions when you need to do something. This still allows you the ability to 'write once, use again' for nearly everything you should need to do.

thanks for the tips!

Very helpful!

Very helpful indeed. I had someone walk me through setting up my first target alias. It took me a long time to understand what it was doing and how it worked at all. This sums it up a little better.

Now teach me how to sccript!

need to get better at this scripting stuff.

^^^ i will agree with what this fellow says ^^^

Here's my coding tips.
1: Read. READ! REEEAAAD. Zmud has an entire tutorial library. People hate when you go on the forums and ask something like, "How do I make a rat counter?"

2: Take advantage of online storage. Emailing yourself your zmud files is a great way to access them when you don't have your computer. I was working on a very lengthy script when my hard drive died. I had to dig up an older version I'd emailed myself, it was fairly out of date but atleast I didn't have to start from scratch!

3: Good anti-illusion is not triggering **ILLUSSION** to +T and -T your class folder. Just don't!

4: Don't echo the exact mindnet message, especially on Party. You'll end up looping and spamming everyone until you crash.

5: If you like to highlight things in combat, use ~^ to make sure you're highlighting the exact phrase. Otherwise, your zmud will highlight every instance of the word where it's not necessary (room descriptions, etc)

There are a lot of resources out there to find help with coding. I'm horrible at coding and one thing I've found that really helped me out was searching on youtube. Yes, youtube- I don't know about Z/C mud, but I know that mudlet has youtube vidoes that show you how to make various triggers/aliases in the client. I'm a visual learner, so being able to SEE what they're talking about has helped me to better understand how code triggers and aliases. It also helped me to get more familiar with the mud client too.

I'll have to check the videos out as I am also more of a visual learner.

Often helps just seeing sample code from others.

by asking you get help, but you also have ot be careful where or how you ask. It is a game where most people do not like OOC interactions.

enable/active them. Most made mistake in coding.

This may seem a bit basic, but they're good tips.

-Before you start coding, sit down and think about EXACTLY what you want the code to do when you're done. Make a template to use if you've got several of the same trigger to make (such as for defenses or healing), and test your code THOROUGHLY before you spend a few hours putting every trigger into effect! It takes less time to plan and do it right the first time,than to fix every individual trigger later if you find a mistake.

-Try as hard as you can to break it, while testing. If you can't break it when you try your hardest, you may be ok down the line.

-Get existing code to look at. Not to steal, that defeats the purpose of coding for yourself! But a place to look and analyze and say "THAT'S how they did it!" Can help a newbie coder along a lot.

-Patience! Coding can be frustrating when you don't know what you're doing. Stick with it anyway and ask for help when you need it. And no matter how tempting it becomes, taking a hammer to your computer IS something you'll likely regret later.

-Use Google. You will find just about all the information and resources you need.

First:
Check your spelling. You'll regret it when something is broken and after an hour or possibly more of trying to find the problem it turns out to he a simple spelling mistake.
Example: The mudlet function is send() not Send().
Second:
You'll never know everything. When you think that you've reached your limit and know everything there is to know someone could think up a way to do something way easier that you wouldn't have seen.
Third:
Never be afraid to ask for help. There are several people I tend to go to for help, because they know a lot more than me, and I learn a lot from asking for their help.

More to come hopefully. For mudlet if you need help you can reference the manual, ask for help on the forums, ask on the mudlet clans available ingame, or asking on the mudlet-help irc channel which you can access from either the mudlet website or straight from mudlet in the latest update.

From someone who's been developing IRE combat systems for the last ten years:

  • Don't use zMUD or CMUD. They cost money, have limited capabilities, and can be quite quirky in executing certain scripts. MUSHclient and Mudlet are far more capable and stable, not to mention free.
  • Learn Lua. It's a very user-friendly, fast, and powerful scripting language.
  • Don't re-invent the wheel. Building your own scripts can be a great joy, and I don't discourage it. However, it's also a smart idea to reference the freely available work of others in doing so. Be sure you have the author's permission to borrow from their code, however.
  • Optimization can be the key to a speedy script. Keep iterations in loops down to a minimum. Use lookup tables when possible. Arrange conditional logic (if-else) to evaluate as little as possible, such that the most common reason to stop checking things will be the first one checked.
  • Ask lots and lots of questions, when in doubt. Other coders are typically very willing to share their experiences and knowledge with those just starting out. All they ask in return is that you put forth a fair effort and don't expect code to be handed to you on a platter.
  • Be patient. Larger scripts can take months to work out completely. Set short-term goals for bigger jobs, such as "get balance tracking coded" and then "check sip balance before healing." A solid foundation built from a good plan is the best way to make a working system.

Some truely excellent tips here!

Thanks!

I started "back in the day" using tintin++ as my client; I am a huge proponent of knowing how to type commands right into the prompt line (as opposed to opening "Aliases," etc. and editing through a window). A couple tips for zMUD that can help:

1) #ac {mud-text} {triggered-command}
...This is the short way to write a trigger. I've used this more than any other command in the years I've MUDded.

2) #cw {mud-text} {color1,color2}
...This is the short way to make a color line trigger. But what are the colors? ...

3) #help {zMUD command}
...I love being able to read the helps without a ton of searching (and this gets easier the more you build your client). For example #HELP CW will bring up how the color trigger works and a table for many of the colors that will display.

4) Don't forget to #save when you are finished, and you like what you've done through the command line!

Some of these are deprecated or incomplete thoughts, mainly because of the power and flexibility of many people's client builds. However, these things can help you with starting in a pinch until you get your feet under you and grasp what you want.

The above info is great, but don't be dissuaded for paying for a client (zMUD/cMUD). Someone put a lot of love and time into these clients, and they work very well for what you're doing. The zugg license will carry over with any future versions of the software too!

Not for CMUD.

> Join forums - Lots of heads are better than one. Help others out with their projects and they will be inclined to do the same. Contribute to other people's work too; don't be a leech.

> Benchmark - if you want to do something, chances are someone else has already done it, even if it's in an unlikely place.

> Read what other people read. Use programs that other people use. THEN branch out.

> Before you ask a question: try it yourself. To this end, keep a profile or document etc, that you can screw around with, without being afraid to lose it/crash it/maim it/kill it with fire. Errors and crashes are very informative.

> State what you want to do in general terms with English, (or whatever your primary language happens to be), and then gradually rephrase it using more precise and technical code language.

> Listen to Mars Volta and drink Tab energy drink?

Good suggestions, except for that last one. *makeface*

This bit of advice is VERY important for Lusternia.

NEVER use the same variable for your bashing target and influencing target. This way, you won't get killed by your own guards.

Speaking from experience Tulemrah?

The only tip I can really give is to have patience. Not -everyone- is immediately good with coding. To some it simply is a jumbled mess of WTF??!! And I include myself in that group.

Read it all, be patient and practice (usually on friends!) See if there are any clans out there for the client you are using, or see if your friends are using the same one.

Either that or do what I did, and get a really smart person to do it for you! :D

I've found that you can learn a lot by modifying or building upon existing scripts. In Lusternia, a certain player has made an excellent display window for potions, poisons, magical items and herbs. Since I have Tarot as a skill, it would be cool if it could also display how much cards I am carrying around on-screen.

Had I have to code this from scratch on it would have taken me a lot of extra time, headache, and errors. Instead, adding it as an extra tab in the display window, I saved myself quite some trouble. Errors were still made, and those are in the end vital to the process of learning, but picking apart a script piece by piece and discovered its good and bad sides teaches you a lot of things that tutorials or building from scratch will not.

Definitely! I poked at the same scripts to get what I needed and learned a lot in the process.

in order not to pull one's hair when coding (or attempting to) though.

I remember when I didn't know the first thing about coding. This article would of been so helpful back then.

yeah.. patience..

! also save a lot and export settings as a backup

Coding gives me headaches

same

this is awesome. even though i've been playing achaea for almost 6 years straight, i never could get a simple targeting command down more often than not every time i changed clients. i look forward to more!

Isn't that bad - just need to learn it's limitations.

I am a supernewbie in coding. I just figured out targetting and bashing scripts for some clients. Now I al setting the reflexes, so I have a long way to go. However, coding is a good exercise for the mind, and part of why I love Mudding so much!

I LOVE YOU! This is awesome. I look forward to the next one.

When you ask a question in #mudlet, please give people time to reply, instead of leaving 5 minutes after. People might not be looking there all the time!

Saving your work. Learning how to export/import. Leaving comments in your work to help you remember why you wrote what you did.

I really appreciate this sort of post since I have next-to-no knowledge of coding. Some day if I have the time, I might learn enough to do more than the most basic stuff.

Though I'm trying to work on that.

This is a great article. Thank you all for the excellent information and tips! 

I learned to code in Mudlet (kinda, not that great by any means) and then I switched to MUSHclient. Now it's a struggle to do anything :/

 

ah well at least I'm having fun

thank you, maybe I should start tinkering with the open source system I use

Heh I'm one of the few ppl who used mostly my own system. Just needed the tigger lines as no way I could compile them.

that's always a good place to start.

Aye

Mhm

I think generally you can figure out what to do by going off of example. There's a lot of code snippets that are floating around that you can fairly simply adjust to match whatever you need. The real difficulty is finding all those weird syntaxes and the little nuances in each language, I feel.

Ideas and examples go a long way toward learning. Yay.

Aye!

Coding is a very vital part of the game, and it can be fun! This should be a must-read for aspiring IRE players, so they can experience the joy that is MUD coding. :D

 

And you'll never know! Maybe that newbie over there is the next Vadimuses! You just have to give them a jump start, and this is a great article for that.

It is a must read for new players

Or someone whose looking for new ways to make life in their IRE game easier!! I've been playing off and on for bout 5 years, and only mastered the basic alias for hunting, in the help alias file someone pointed to me in game.

is a list of coding terminology. Even words that I SHOULD know the meaning of become confusing when trying to wrap my head around code

#if @sex=female {plow} {runawai}

Ok?

Ha!

Wish I read this years ago when I started! Still, nice to see and helpful nonetheless.

I've been coding for muds for years, and any and all help on the subject is helpful.

take a beginning programming class at the local community college...another line for your resume and it will give you the basic concepts for good MUD coding...win/win scenario

I'm just not sure it adds to the game.   Good game with overly complicated combat system where computers duel it out.

Nah

It's definitely still the players fighting. I like the reliance on systems because since you can work out certain reactions automatically, the fights are more about intelligent planning and less a battle of typing speed.

I know how to code, so I didn't really have a problem.

save your work

^This, absolutely.

 

I suck at coding, but learning

We need the next volume! (I need the next volume...). Thank you. I learnt a lot, however since my previous post.

+1

+1

Whee!

III!

An amusing intro to coding. Although I no longer need it, still looking forward to the next part.

I want to eventually make my own simple curing system, but I have no clue how to get started. I can do aliases and triggers and whatnot, though.

I want one of these for some of the more complex stuff in mudlet that I can never understand for the life of me

Very useful.

Some really great tips here, even if you use a different client to some above, their concerns and tips, spelling, capitalisation, generally being careful, thoughtful and observatn are great things to keep in mind for anyone writing any code.

Whoa, helpful stuff. I have to agree with saving and commenting work, especially. I've had a few troublesome times when somehow mudlet crashes and I lose lots of stuff I did. It is saddening. :(

Another newbie coding tutorial if you're wanting to do a bit more with z/cmud:

 

http://paladins.bubble.ro/index.php?page=zmudtutorial

Where is Volume two?

Yes please, bring on volume 2!  

I like volumes

Thank you for doing this. The first paragraph describes me to a T.. ask Soopay he is my longsuffering coding teacher. Looking forward to more articles.. and yes I can now make a target alias all by myself without too much angst or hair pulling. Yay mudlet!

Wish I'd had this as a newb!

coomment

I'm not a newbie at scripting thigns anymore, but good read anyways.

This is a great idea!

And its free. See "you tube" for all your basic how tos.

thank you! This helped my hunting a lot!

Why didn't I spot this a few days ago.

Huge thank you for this!

oi... this hurts my head... sticking to lua.

Fun stuff.

oh

oh

I should really start checking out the scripts section.

comment

when is part 2?

A good thing to have on here. Coding can be confusing for newbies.

Confusing. I hate coding.

I'm lucky I figured out an auto-rewear trigger

We must SEND what we want to the MUD, so we type “Send(“kill ”..target)”.

 

Mudlet is declaring a .lua error in the command Send(“kill ”..target). I'fve spent four hours trying to both find, and figure out on my own, how to debug it, with no success.

 it is: send("kill "..target)

It should be: send("kill "..target)

It should be: send("kill "..target)

There should be more articles like this.

Fixing post two of three...

 

Fixing a triple post.

yes

more articles like this

More like this. I think the inability to code is tragically holding me back

hmmm.... interesting

Hmmm.... interesting.

Free credits.

Hmm... interesting.

Nice, very helpful

Yeah, coding is part of the requirements for MUDs these days. Good to see people still give a helping hand with tutorials where needed! Great job.

Nice tips

Nice tips

This is helpful~!

This is helpful~!

I've just started this bit and its always useful to see otehr peoples mindsets when doing this

Interesting read

Fascinating.

Still have lots to learn, but learning lua has been another fun component of the game. I'm very thankful to those who have shared code, as I learn best by example.

These are the most useful of the IRE articles. Keep 'em coming!

Agreed!

Agreed