Coding Basics!

edited February 2018 in Tech Support
The Basics to Coding!

Recently I've been helping a few people out that have been putting in an honest attempt to learn like me, and the Mudlet LUA guide is super intimidating if you're just trying to learn the basics. I figured I'd make a small post that anyone can add to that is just the basics. Nothing super advanced, but a way for the building blocks to come out of the box and get all sorted!

             = and ==

So we'll start with '=' and '==' which seems to get a lot of people confused.

They're never sure why they need to add another = to a == statement, or aren't sure why the == is incorrect and need to remove another equals sign.

= is a statement. It's a fact. apple = red, bob = smelly, mary = pretty. It will never be a question so if you ever look at your = statement, ask yourself. "Is this a question, or am I stating a fact?" And you should be good to go! (E.g matches[2] = target)

== is more a question! Is the apple red? if apple == red then..., if bob == fat and mary == pretty then etc, etc 

The best way to look at it for terms like this (or at least the way I do it) 

if bob == fat. Is bob fat? No, bob is smelly. bob = smelly. 

To use both of these in a string would look like this!

^You glance over (\w+) and see that \w+ health is at \d+/(\d+)\.$

if matches[2] == target then matches[3] = tar_health

We're asking here, is matches[2] the target? It is? Great! Then our target's health is now what we apply it to. This is a fact, this is not a question, so we use =.

             <, >, ~=

Less than! Greater than! Not equal to!

These are some basic math operators! They're fairly self explanatory but can be hard to envision. You specifically use these with numbers!

You can do things as precise or as lazy as you generally want, and in Achaea specifically you'll be using (or seeing) less than < and greater than > a lot in limb counters, or when you go in to change limb counter settings yourself! 

             IF, THEN, ELSEIF, ELSE, AND, OR, END

These are the operators! These are what you depend on! 

********* IF *********

Most statements (if not all of them) begin with if!
IF toggle1 == true... 

********* THEN *********

THEN is typically used to state what it should if checkpoint A is cleared

IF toggle1 == true THEN...

********* ELSEIF *********

ELSEIF is simply a way of going to the next line while using a variable! It's like saying but!

If Bob is stinky then he should take a bath! BUT if Bob is clean then lets congratulate him, because he's working hard on turning his life around!
This is actually a messy way to end the function off, line 3 should be used with ELSE which we'll go over below!

    To note the reason we'd use ELSE here is because we only have the options STINKY and CLEAN, if we had a third variable maybe SCRUFFY then we'd use ELSEIF for line 3, but since we only have 2 variables then we should've used ELSE for line 3. More below!!

********* ELSE *********

ELSE is used if kind of in a final scenario with more than two statements, so...

So this is a little confusing but I'll explain it in detail. If toggle1 is activated (remember it's a question being asked. Is toggle1 turned on? Yes? Awesome, do line 2!) then we send("Hello")
BUT IF (elseif) toggle2 is on instead, then we say goodbye!

Now we use ELSE here, not ELSEIF, because we have no more scenarios and instead of doing if toggle1 == false and toggle2 == false then...
So instead we do ELSE send("Wait, nevermind")

This is important because it's a very effecient way of saying, 'alright this is the last situation of the string' and just makes things look cleaner!

********* AND *********

AND is used to meet multiple requirements. Typically if they're true! So let's say... Penwize has touched his shield tattoo and smoked rebounding!

Rebounding isn't up quite yet, so it's 0 (or nil/false) so we press our button to attack Penwize that has the trigger:

So think to yourself right now, what line is going to go through? Let's work through it together here!

if tarShield and tarAura then...

Okay! The system goes to checkpoint A! It asks, "Hello, is the Target's shield up?" and it replies, "Why, yes it is!" So we go to checkpoint 2!

The system goes and asks, "Hello, is the targets rebounding up?" it replies, "No" so all the requirements are not met and it slumps away in defeat.

So now it goes down to line 3, skipping line 2 because the requirements were not met.

"Hello, is the target's rebounding up yet?" It asks. "No" It replies. So it slumps away in defeat and skips line 4.

Line 5! "Hello! Is the target's shield up" It asks. "Why yes, yes it is!" It replies, and so now our system opens the gates to line 6

cecho("EDUCE COPPER!") --breaks shield

And because it fired on line 6 it now does not have the energy to try another line, it can only do things one button press at a time. It is a lazy function.

So it never gets to meet line 7.

But wait! You say. "There's nothing on line 7. It's just else!" 
That's right, just like above when we went over the ELSE function, it covers the final scenario which is if tarShield = 0 and tarAura = 0.

********* OR *********

OR is a bit harder to use! But can still be accomplished! Try to imagine you're in a combat scenario, and you've coded this awesome system that tracks your broken limbs and whatnot. 

Okay, so, lets say you're fighting Penwize and suddenly you arm breaks! Uh, your left arm! Suddenly!

my_leftArm = 1

Oh no! The flag for your arm arm is now marked as broken! You're going to be rift locked! You just know it! But you cant type the function to switch your priorities fast enough!
Luckily for us we have the OR function! This can help you cover a lot of ground instead of having to make seperate scripts/triggers for each limb!

Okay so what happens here? Well, unlike other functions, this one allows our request (the guy who approaches the checkpoints and asks to be let through) to be a lot more skippy or energetic. Because if any criteria is met from an OR statement, it'll immediately jump to the next line. This is typically how auto tumblers are made! See how easy it is? You can literally just do:

This is not something I suggest setting up, but it gets the point across I help!

********* END *********

What's a good story without an end? Your scripts want an ending too! But guess what? Endings are lazy! Super lazy! So very lazy! In fact they're so lazy an ending will go to the closest available function. This is a bit hard to explain so bear with me here.

Okay, so we have THREE whole IF statements. For every statement it needs an ending. Imagine it like a period. You can't end a sentence without punctuation. But each line is their own story, okay? So C has it's own ending.
B has it's own ending.
A has it's own ending.

But Vaniel, why did you not go from A-C? Why did you go C-A? 

Wow, viewer you're so smart! Good catch! Remember how I said we have lazy functions? Okay, great! That's because the closest end wants to make the smallest journey possible. So you'd think because it starts at A and reaches END first, that means it'd be the first function to complete. This is natural to assume but you're wrong. A /is/ read first, but function C is the function to end first.

We have an if statement inside an if statement inside an if statement. 

-----------------> CLICK ME <------------------

See the above gif? It shows you that this is all one big IF statement, but there's sub sections.
See how C can be closed away to only show the IF statements of A and B?
Then I close B so that we only see the A statement.

This is true in coding, C will be completed first, then B, then A!

From an Achaean combatant's perspective imagine envenoming! It's not the first venom you put on your weapon that gets afflicted, it's the last venom! The same applies here! The last statement is the first to complete!

envenom sword with asthma, paralysis, voyria, sleep, stupidity
-> Target has been afflicted with stupidity
-> Target has been afflicted with sleep
etc etc

So here's an example of a basic toggle that works 100% but isn't optimized, but shows even if you don't know how to properly use else, or if you use every possibly variable, it'll still function!
This covers almost just about everything we went over here!


toggle1 = true
toggle2 = false
toggle3 = false



if toggle1 == true and toggle2 == false and toggle3 == false then
	toggle1 = false
		toggle2 = true
			cecho("\n<red>Toggle 2 is enabled")
elseif toggle1 == false and toggle2 == true and toggle3 == false then
	toggle2 = false
		toggle3 = true
			cecho("\n<blue>Toggle 3 is enabled")
elseif toggle1 == false and toggle2 == false and toggle3 == true then
	toggle3 = false
		toggle1 = true
			cecho("\n<yellow>Toggle 1 is enabled")



	if toggle1 == true then
		send("em waves hello once.")
	elseif toggle2 == true then
		send("em waves hello twice.")
		send("em waves hello three whole times.")


  • Antonius said:
    I'm on my phone so these are brief points (and will probably come across slightly harsher than intended due to brevity - or because I'm waiting for a train after only two hours sleep and am being a grumpy bastard), but:

    Lua has boolean types. Please don't write a guide for people new to coding that uses 1 and 0 to represent true and false. It's a really awful habit to get into and makes the intention of the code considerably less clear. Lua - unlike JavaScript - evaluates a variable containing 0 as true, not false, if you just use the variable alone in the condition (e.g. if var then rather than if var == 1 then), so using 1 and 0 actually makes a lot of your later example code snippets incorrect.

    You don't only (you said specifically) use less than, greater than and not equal to with numbers. You can - and should - compare strings and booleans using at least some of those too. You can in theory compare any types of variables using all of them, but the exact results of comparing variables of different types is well beyond the scope of a beginner post.

    OR is not a function. It's an operator. So is AND. =, ==, ~=, < and > are also operators. In fact, you use the word function multiple times incorrectly, and not even consistently (you use it to refer to a variable later on). You don't seem to cover the idea of what functions are at all, so I would guess that every time you've used function it's been incorrect.
    Gotcha my apologies. Like I said self taught. And no one has ever written a newbies guide through google or the forums, so I took a crack at it.

    Sorry about the lingo confusion! I had about 7-8 people proofread this and it was never brought up!
  • May I say, thanks for this - I'm in the process of trying to learn coding! And thanks Antonius for the corrections and whoever else that may comment in the future.
  • @Makarios @Nicola can we get a pin for this?
  • Having this on the Mudlet wiki would be useful - for one, it'd be editable!
  • Thank you very much for this. Usually, when I ask a coding question, the answers I get generally assume I know more about coding than I actually do. Which means that I understand very little that the one trying to help says.

    The very basics of coding, explained in an easy to understand way, is what we need here. So, your work is appreciated.
    Give us -real- shop logs! Not another misinterpretation of features we ask for, turned into something that either doesn't help at all, or doesn't remotely resemble what we wanted to begin with.


    Current position of some of the playerbase, instead of expressing a desire to fix problems:

    Vhaynna: "Honest question - if you don't like Achaea or the current admin, why do you even bother playing?"

  • is there a guide like this for the nexus client?
  • Arjhan said:
    is there a guide like this for the nexus client?

Sign In or Register to comment.