LunaLua Offical Thread

[SAJewers]

I have a new, very small, library I made!

<span>[url=<a href="https://dl.dropboxusercontent.com/u/30847069/musix.lua]Musix[/url]">https://dl.dropboxusercontent.com/u/30847069/musix.lua]Musix[/url]</a></span>

This is an extremely simple Lua library for making music codes! It simplifies the creation of music codes so all you have to do it write down the string you want (it does have some other customisation available, too).

I've also added the documentation to the wiki.

Just a suggestion, but instead of displaying a specific string, could you instead make it so it can read/display the IDv3 tags of the mp3?

[Hoeloe]

Just a suggestion, but instead of displaying a specific string, could you instead make it so it can read/display the IDv3 tags of the mp3?

That's a lot more complex, and will require C++ code behind it in order to work, unfortunately.

[Rixithechao]

In my personal experience, ID3 tags are tricky to work with no matter what engine or language I use. I probably just pick the worst languages for that stuff, though.

Regarding the library pages, the general structure is great and I'm probably going to use it as a template for mine. The documentation tables are a bit visually confusing, though. It'd probably be best to use a variation of the tables in the hardcoded API pages.

[Hoeloe]

The documentation tables are a bit visually confusing, though. It'd probably be best to use a variation of the tables in the hardcoded API pages.

The issue with those is that they don't allow discussion of the individual arguments, which is extremely important. Perhaps my layout wasn't the best way, but I recommend using something like the C# documentation, which is some of the best documentation I've ever seen.

[Rixithechao]

I figured maybe it would be cool if you could hover over each parameter to get more info about them, so I added basic tooltips and they're okay, but then I did some digging and I found out that MediaWiki includes this JQuery thingamabob and JQuery includes something called Tipsy, so I'm trying to figure out if I can turn that into a template.

In the meantime, you can use this for the regular tooltips:

Code: Select all

{{H:title|Testing, testing, 1... 2... 3...|Hover over this text}}

EDIT: Looks like I can't include them myself, an admin would need to do it.

[Rixithechao]

Double-posting instead of editing because I'd like to get some opinions on something.

I'm thinking of splitting up cinematX into two or more smaller, more manageable libraries; at the very least I'd be moving the NPC animation stuff into its' own script. I figure that way, folks can start working with different chunks sooner instead of having to wait for the whole thing.

What do you guys think?

[Kevsoft]

Well it can't get bad if you split your libraries. Also if you do an example I recommend to pack a whole own level as example because the setup might be difficult for newbies.

[Hoeloe]

Double-posting instead of editing because I'd like to get some opinions on something.

I'm thinking of splitting up cinematX into two or more smaller, more manageable libraries; at the very least I'd be moving the NPC animation stuff into its' own script. I figure that way, folks can start working with different chunks sooner instead of having to wait for the whole thing.

What do you guys think?

Sounds sensible to me, as long as it can work with cinematX properly (though I can't see any reason why it wouldn't).

[TiKi]

Hoeloe: what would my friend need for that red coin thing to work?
1. Lunadll for lua
2. Said code - is it a world/global or level code?
3. Anything else other than the posted code? Would he need the shop library?

[Hoeloe]

Hoeloe: what would my friend need for that red coin thing to work?
1. Lunadll for lua
2. Said code - is it a world/global or level code?
3. Anything else other than the posted code? Would he need the shop library?

1. Yes.
2. Depends if he wants it to work in every level or just one. Using lunaworld just means the script runs in every level rather than a specific one, but it still restarts every time you enter a level. Code in lunaworld acts the same as code put into the lunadll.lua of every level, it just means you don't need to copy and paste the code into every level.
3. The shop library simply does this for you, for dragon coins, along with a few other things. If all you want to do is count how many of an NPC you collected, within a level, then you don't need the shop library, as the code I posted does that for you.

I'd recommend taking some time to try learning what that code actually does, and why it gets the result you want. Even if you don't care to go into all the inner workings of LunaLua, it will help in the long run.

[TiKi]

Okay, so I tried to delve into your lunaworld code to get what controlled the "RaoCoins x" image, and here are my problems.

1. Lua seems to be less organized than auto code. Every auto code function was on a new line, but it seems lua bunches similar-in-the-timeline things together.
2. Lua seems to take more to do the same thing. There don't seem to be any one-line codes like you can do in auto code.

The kinda sad for me thing is, every "serious" person is moving to Lua and putting out their libraries in Lua, and it appears that only I prefer the "compartmentalization" of auto code. Is there some sort of editor besides notepad that makes it better? And I'm gonna be honest, it seems kinda jump-the-gun to use a real programming language as an editing thing when not everything in SMBX is understood in the first place. If I could genuinely make new stuff in SMBX, this may be alluring, but as an alternative to auto code and doing the same things (which reminds me of npc codes in a good way), eh.

[Hoeloe]

1. Lua seems to be less organized than auto code.

Going to stop you right there. Shorter does not mean less organised. Lua is a hundred, thousand times more organised than autocode, because it allows you to do two things.

First, it lets you group pieces of code by their functionality. In autocode, to do something like move a platform back and forth required multiple functions, all separated from each other. In Lua, these are all together. That isn't less organised, it's more organised, because it's much clearer what each of those individual elements actually does, since they're bunched together in the same function.

Secondly, it lets you name functions. Having a function called "givePlayerFireflower" is so much more understandable than a function called "1000" that does the same thing.

Autocode is fundamentally similar to a machine code. It's not user friendly, and if you don't know the ins and outs of exactly how it works, very, very hard to learn. High level languages like Lua were invented solely so that people didn't have to use unmanageable code like that all the time.

Lua might look like it takes "more to do the same thing" to you, but when you get right down to it, it doesn't. It has more lines because the divides between elements are more clearly defined, but the actual functional code is either the same length, or smaller, and is a lot more easily readable.

Now, I will admit that my coding style, particularly when I'm in a hurry, is not the easiest to read. I tend to forgo making comments when I'm rushing because they take time, and I'll only add them when I know I won't remember why I'm doing something. But this doesn't make the medium as a whole more difficult to understand. Trust me, it's much, much easier to manage if you give it a try. You wouldn't expect to jump into autocode and to be able to do everything immediately, and the same is true of Lua, except in Lua's case, the learning curve is much, much shallower. It might look daunting, but try some basic Lua tutorials to learn some of the operations and syntax, and suddenly it will make a lot more sense.

Autocode might look simpler, but that's only because it's so bare bones that it doesn't actually have much of a syntax - there isn't much to learn about how to structure programs, but the programs themselves get a lot more complex because of this.

Let's take an example: I want to call some function, it doesn't matter what, particularly, a dynamic number of times. Let's say that on the first frame, I want to run it once, on the second frame, I want to run it twice, on the third, three times, etc.

In autocode, this would look something like this:

Code: Select all

#-1
SetVar,0,0,0,1,frameCount

#0
SetVar,0,1,1,0,1,frameCount
SetVar,0,0,0,1,counter
Trigger,0,1000,0,0,1,0

#1000
$counter,CompareVar,0,2,0,1001,0,frameCount
$counter,CompareVar,0,0,0,1002,0,frameCount

#1001
SetVar,0,1,1,0,1,counter
Trigger,0,1000,0,0,1,0

#1002
[FUN STUFF]

Now, I'm not that great at autocode, and this probably isn't the best way I can do this. I'm not even sure if this actually works, and that's part of the problem with autocode - getting your head around the logic is a lot harder than just copy and pasting a few basic solutions. Another place it fails is readability. Even assuming this did work, I challenge you to read and understand it without looking anything up in the documentation. At all. My guess is you have to look up something, even if it's just which arguments of which functions are doing what.

Now, let's look at the Lua alternative:

Code: Select all

local frameCount = 0;

function onLoop()
	frameCount = frameCount + 1;
	for i = 0,frameCount,1 do
		[FUN STUFF]
	end
end

This is not only shorter code, but much more focussed, and much easier to understand. It's clear to see at a glance that the variable "frameCount" is incrementing every frame, and while someone more familiar with other languages like me might need to refresh their memory on the exact syntax of Lua for loops, it's still reasonably clear, even at a very quick read through, that [FUN STUFF] is executed multiple times per frame, related to the value of "frameCount", which we already established is incrementing each frame.

The strength in Lua, or high level programming languages in general, doesn't lie in a very simple, single-rule syntax, but it lies in simplifying complex operations, to make them much, much easier to handle. This was only a very simple example, imagine doing something with loops that's a lot more complex. Autocode quickly becomes unmanageable, where Lua still remains relatively focussed (maybe needing comments every now and then to help understanding of the more difficult bits).

This is why Lua is a better tool, and why everyone is switching to it.

P.S. I thought I should add that, for a programming language, organising things by the time they are executed is a very, very good thing. If you're dealing with variables, for example, it's amazingly useful to know exactly when those variables are going to be updated, or otherwise might change their value. I've had many, many bugs in programs appear over the years because a variable has changed its value somewhere that I wasn't expecting, and they can be some of the hardest to find the route cause if not dealt with correctly. Taking away the linear structure from programs makes this even harder. Besides, if you wanted to, you could put each separate operation in a different function. In fact, a lot of programmers will tell you that separating parts of your program used for different purposes in this way is good practice. I tend to not do it because it's unnecessary, but there's nothing actively stopping you. You could just as easily write:

Code: Select all

local variableA = 0;
local variableB = 1;

function onLoop()
	updateVariableA();
	updateVariableB();
end

function updateVariableA()
	variableA = variableA + 1;
end

function updateVariableB()
	variableB = variableB * 2;
end

As you could this:

Code: Select all

local variableA = 0;
local variableB = 1;

function onLoop()
	variableA = variableA + 1;
	variableB = variableB * 2;
end

Functionally, they're identical. I would recommend if you take this route, though, that you don't just separate every line, but rather separate things by what they actually do. If you're moving a platform, put all the code managing that platform into a function (you can even call functions from within that function if you think it's a bit too unwieldy). If you're changing some NPC behaviour, put that in a function, too. But if you're moving a platform up and then down, don't separate your up motion from your down motion. Make sure you at least have a function along the lines of "updatePlatform", which then can deal with up and down separately. This will make your code much easier to read in the long run.

It's not just that, though. If you're moving the player, for example, you might want to do some collision detection before you do. This requires that you be absolutely certain that your code moving the player has not executed when you attempt to run the collision test. A simple example of this scenario might be where the player presses a key to teleport to a location in the level, but depending on whether they are standing on a special teleport pad, this might take them to different locations. If you perform the warp before the collision test, then the player might end up in the wrong location, which totally breaks your mechanic.

P.P.S. I've been watching a lot of Extra Credits videos these past few days (if you're really into a lot of the really intense details on how game design works, and the decision behind practically everything that you find in games, whether you notice it on the surface or not, go and check them out, they're awesome for that), so my writing style is a little more verbose than it might otherwise be, but hey, maybe it's helpful in explaining things. This is a really difficult topic to discuss, but fundamentally the question you're asking is "why do high level languages exist?" and if you want a proper answer, I suggest having a look at some places like StackOverflow, where people more capable and less tired than me might be able to explain it better.

P.P.P.S. I know this is getting ridiculous, but let me address one more thing. Lua isn't a "real programming language". Lua is a scripting language. There is a very important distinction. Lua is designed to be a peripheral tool tacked onto another piece of software, that allows people to interact with the software in ways that internal tools can't. Lots of games that even touch on the idea of sandbox games use them, and Lua is one of the most common (An old game called Neverwinter Nights, for example, had a purpose-built scripting language attached to its editor, which was based on C). A programming language is a tool designed to build this software in the first place, and this is radically different. It may seem silly to you, but this difference changes a lot about the languages themselves. They use different design decisions all over the place to facilitate this difference. Autocode is a scripting language that did not do much to facilitate this, but it is still a scripting language. It's a language based more on the style of execution of machine code, which is generally too hard for humans to write complex programs in, but easy for the machine to read. Lua is a high level language, which is much easier for a human to wrap their head around (primarily because it uses structures we can understand more easily, and actual words and everyday symbols to describe operations. A direct example would be Lua's "+" versus Autocodes "1", used in the correct function).

Please, just trust me on this. Lua is better in every way for the person making the levels. You may not be used to it, but once you get the hang of it (which really is unlikely to take long), you will thank me for it.

But yeah, as I say. Complex topic. My huge, rambling, post doesn't even scratch the surface of this. Unless you're willing to do some digging yourself, you're going to have to just trust me when I say a high level language is just better in every way (in this circumstance at least. There are cases where lower level languages have the edge in performance, but since these are both scripting languages, they both have pretty much the same performance bottleneck).

Fundamentally, Autocode was designed in the 50s, when we had no idea how to design a good language, and couldn't make use of a lot of neat tricks and tools that make our programs easier to use. Lua, on the other hand, was born in 1993, long after we had a pretty good idea of what makes a decent language. Lua is easily the better choice, and no-one with any real knowledge of logic or programming will tell you otherwise. I guarantee it.

[Rixithechao]

Sorry for the lack of updates on cinematX and animatX (new name for the animation library because theme naming),
I've been jumping around with a lot of different stuff, but I'm back to working on them.

I'm aiming to record the previously-mentioned video sometime this weekend. Before that, though, I have to ask... does input cause skipped frames in LunaLua-enabled levels for anyone else?

Disable Frameskip helps but doesn't fix it completely. This has been going on for a while, and I figured it was an issue with my code or my computer... but Hoeloe's raocoin system is in a separate world folder and it has the same issue, and when I played several levels from A2XT E1 they had perfect framerates.

EDIT: Hmm, this only seems to happen when playtesting in the level editor.

[Mabel]

I've had no lag issues SO far. The only time I lag is when something is leaky/left open.

[Rixithechao]

Wait, it's not the input, it's the audio... and it's the default SMBX audio, not sounds called by playSFX (which, incidentally, work regardless of whether the game's sound is enabled).

[Hoeloe]

Wait, it's not the input, it's the audio... and it's the default SMBX audio, not sounds called by playSFX (which, incidentally, work regardless of whether the game's sound is enabled).

Default SMBX audio has always been laggy, I believe.

[Rixithechao]

Wait, it's not the input, it's the audio... and it's the default SMBX audio, not sounds called by playSFX (which, incidentally, work regardless of whether the game's sound is enabled).

Default SMBX audio has always been laggy, I believe.

Except it's only noticeable in LunaLua levels. When I jump or turn left or right there's a tiny pause, and repeatedly tapping left and right causes a lot of dropped frames because of the skidding. This doesn't happen when I playtest any levels from A2XT Episode 1 or playtest with the sound off.

[Hoeloe]

Wait, it's not the input, it's the audio... and it's the default SMBX audio, not sounds called by playSFX (which, incidentally, work regardless of whether the game's sound is enabled).

Default SMBX audio has always been laggy, I believe.

Except it's only noticeable in LunaLua levels. When I jump or turn left or right there's a tiny pause, and repeatedly tapping left and right causes a lot of dropped frames because of the skidding. This doesn't happen when I playtest any levels from A2XT Episode 1 or playtest with the sound off.

Weird. I've never noticed that issue, even when playtesting in the editor.

[Rixithechao]

Arright, it's a bit late but here's that video. Chipmunked because sure why not.

[Hoeloe]

Arright, it's a bit late but here's that video. Chipmunked because sure why not.

That's awesome and I want to see that used in every level with a talking NPC in it.

I also really like that alternative Demo graphic. It's much cleaner than the existing one.

[Willhart]

This looks like you might have got the wrong thread.

Moved my post to the review thread. I may have had multiple tabs open and mixed them up.

[Hoeloe]

...

This looks like you might have got the wrong thread.

[TiKi]

So thanks for the reply. It was informative, especially about what Lua's purpose was.

Is it possible to use lunadll v8 AND lua together?

[Willhart]

So thanks for the reply. It was informative, especially about what Lua's purpose was.

Is it possible to use lunadll v8 AND lua together?

It looks like both of them are going to be used on the next episode, so I'd assume it is possible.

[Rixithechao]

Finals are done, back to working on cinematX. I've decided to keep it as one script after all, that's a can of worms I'll dig into some other time. Or however the expression goes.

I spent the day finally doing what we discussed like a million pages ago: the library's been reworked to use a custom Actor class for keeping track of extra member variables and stuff. I'm this close to getting the NPC animation functionality working again -- as of writing this I'm trying to squash a stubborn bug with the NPC message key tags.

Oh, I also started working on this ugly app thingamajig to help folks prepare sprite sheets for cinematX -- you import the sheet, specify where the different animations begin and end, assign each animation a name, preview them individually, etc, etc, etc, and then output a block of code and maybe an npc txt file too. I dunno, I'm working out the details as I go along.



And now to go grab dinner because I've had no nutritional intake for the past twelve hours.