I spent about three HOURS trying to solve the Oculus runes by traditional method (pen and paper) and eventually decided I'd had enough of it. Special Note: The rest of the Illuminatorium puzzles took me less than 5 minutes a piece to complete. I had a success after about five minutes of running it. It took me about an hour to work out all the kinks and try different iterations of this script, but this is the simplest and most effective version. When the oculus has been rotated 5 times, the script attempts to make you enter the portal (assuming success.) If that fails, it moves on to flipping the current first rune until count restarts it. You only get 15 moves, so when the 15th move occurs, it restarts the script. These triggers (put them in a class folder so you can easily disable them later) produce two variables: which counts how many times the oculus has been rotated, and which tells the script how many times runes have been flipped. The same goes for IF statements/functions etc.The first line directly under the pattern # is the actual trigger pattern. If you wish a variable to be LOCAL to the script or loop you create it in, then you must create the variable this way:īe aware that if you create it inside a for loop, it will not exist outside the loop.
Mudlet temptimer how to#
The value will not persist between sessions though - if you want to learn how to save values between sessions, ask that question separately (and check out the remember() function. If you create a variable as I did above, then it is available globally to any script. I apologise if I explained what you already knew. NOW that I am sure you're on the right page, I'll answer your question. This is pretty neat - it lets you contain/compartmentalise scripts, making them easy to share and resistant to being interfered with by other scripts given to you by other people. Now you can see that you can have a single table with multiple TYPES inside - in this case, simple strings (text data), a true/false, and a function. You'll get the same result - because by default, we can reference individual keys in the global table without having to specify the _G (however, sometimes it can be really useful to do so, which is why I mentioned it). You are just adding another entry into the global table, which is called _G The value can be a string, integer, function, boolean, another table, or probably one of a few other types that have slipped my mind, or I just don't know about.Įven when you create a "simple" variable, that is to say: When you create a function, for example, the function name is the KEY in some table, and the function itself is the value.
A table is a key = value structure (in cmud, a database variable, or record variable). Hope this gives you something of a start!Įverything in lua is a table. Create a function to return a gsubbed string, and then do send("say ". You could develop it from there, that's by no means the most efficient way or the most pared-down script you can do.įor the opposite, in turning out the language, you could do the same thing, only in reverse. I'm sure there are other ways you can do that bit, but that's the quick-and-dirty, no-research-done, no-questions-asked kind of thing I'd do. Local translation = translate_d(matches)Ĭecho("(yellow) - replace () with html brackets here - ". Here, you would need to create a check that runs a string.findpattern on matches, and if it doesn't detect a word of your language, to stop running the trigger.
Then what you do is trigger say to something like: Local translation = arg:gsub("vir", "hello"):gsub("wer", "world") One is a gsub for accepting the language as a trigger, that would look like this: What I would do if I were to take a first cut at this is create two different subroutines. There are a couple of ways you can do this.
0 kommentar(er)
