LunaLua Offical Thread - SMBX Usermod Framework

[ROA]

Yep that's exactly what I wanna do, there's no way to make that in 1.3.2 with lunadll ????

[loop]

Yep that's exactly what I wanna do, there's no way to make that in 1.3.2 with lunadll ????

If you are using LunaDLL autocode, probably not. LunaDLL is deprecated anyways.

[ROA]

Well, then only using 2.0 scripts ???

[PixelPest]

I'm pretty sure you need 2.0 to get the version of LunaLua you'll need (could be wrong about this though) and for the API (paralX.lua)

[ROA]

Hell I saw that level .lua file, but idk how to make one myself, anyone help me :p

And what's the program to edit the lua files ????

[Wohlstand]

Hell I saw that level .lua file, but idk how to make one myself, anyone help me :p

And what's the program to edit the lua files ????

Alone question on your "so huge" question: lua-files are just text files and can be edited in ANY text editor like notepad, Akelpad, Notepad++, GEdit, Atom, etc. Suggested to use Notepad++ or similar where a syntax highlighting will make code view better.

How to code? Try read tutorials you will find here:
http://wohlsoft.ru/pgewiki/Category:LunaLua_API

[ROA]

Well, I'll try, ty

I'm spanish and now I realised there's a spanish tutorial xD

[joelcanciones]

Hi: Can someone tell me what is the difference between Luna Lua and Luna DLL and what are those things and if there are any good episodes that use any of those things? Thanks!!

[RudeGuy]

LunaDLL uses autocode, which is really limited. It's also really outdated.
LunaLua uses lua, which is a programming language that is easier to learn and understand than autocode and it's almost unlimited.

[sirvolkers]

LunaDLL uses autocode, which is really limited. It's also really outdated.
LunaLua uses lua, which is a programming language that is easier to learn and understand than autocode and it's almost unlimited.

And where can I download it? Also, how can I install it on my SMBX?
I was looking on forum, but didn't find nothing that help me.

[underFlo]

The main way to use Lua at the moment is SMBX 2.0.

[Kevsoft]

LunaLua v0.7.3.1 has been released, which means that the core API of LunaLua should now match the one in SMBX 2.0.
Changelog:

Spoiler: show

* Added non-ASCII paths support! (LunaLUA-SMBX's root finally can be placed into path with non-ASCII characters. But limit is: don't mix codepages (example: both Russian and Chinese characters in a path, or you will get VB Error "File not found". Same happens on Vanilla SMBX if you have been used non-local characters.))
* Added a test-mode system which can be controlled by PGE.
* Added Graphics.getBits32 which is a fast way to access the bits of a image resource
* glDraw can draw with scene coordinates (sceneCoords=true as named arg)
* Added CaptureBuffer class which allows to capture the screen at a specific render priority
* The max id of Blocks has been increased to 700
* Added lunabase.lua to LuaScriptsLib which is a global user script file.
* Overworld sprite can be patched at runtime
* Added Misc.registerCharacterId which allows to register new characters
* Added Misc.resolveGraphicsFile which only resolve a file from custom folder, episode folder or the graphics folder from SMBX.
* Added Graphics.loadImageResolved which is a handy combination of Graphics.loadImage and Misc.resolveGraphicsFile, with a useful error message if it can't find anything.
* Added PlayingSfxInstance class which represents a sound
* Added some new defines
* Enhanced profile.lua to be useful. Usable by hitting F3 to start and F3 to finish.
* Add force_disable_fullscreen option to luna.ini because the smbx fullscreen is acting up for some
* Add Player.getIntersecting

The development of LunaLua has been slowing down lately due to Rednaxela and me beeing busy with other stuff. Remember however, that there are still a lot of great APIs out there which makes LunaLua a whole lot better. So check it out!

[darkhog]

Suggestion: Add a way to detect layer's offset from origin point (layer's position just after level load, before any processing, smbx or lua, takes place). It would make easier to do complex moving patterns. e.g.:

1. When layer's y offset is 0, set Y speed to 5 until layer's y offset reaches or is greater than 160
2. Then, if x offset of layer is equal to 0 and y offset is greater or equal to 160 set y speed to 0 and x speed to 7
3. After x offset reaches or is greater than 75 and y offset is greater or equal 160 set both y and x speed to 50 until both offsets are greater than 420
4. Then, retrace steps back to 0,0 using negative speed values.

I realize it is possible to do it now, but it requires messing with timing, speeds and doing other "arcane" stuff. Having access to offset information would help.

Related: Ability to set said offset directly would also be useful so e.g. we can clamp at each "point" in case layer oversteps (greater than point's position). Or do stuff like teleporting layers.

[PixelPest]

That's already really easy to do and not at all arcane. You can just grab Layer.x and/or y as a variable onStart() and figure out the offset easily onTick() by finding the difference between the current positions and the value(s) you found at the beginning. You can set Layer.x and Layer.y at any time to move it back or use Layer.speedX and/or speedY

[Hoeloe]

That's already really easy to do and not at all arcane. You can just grab Layer.x and/or y as a variable onStart() and figure out the offset easily onTick() by finding the difference between the current positions and the value(s) you found at the beginning. You can set Layer.x and Layer.y at any time to move it back or use Layer.speedX and/or speedY

That's actually uhh... not at all accurate. You can't set layer positions because of how they work in SMBX. The reason that stuff doesn't exist isn't because we didn't think of it, but because the way it's implemented in SMBX makes it awkward. The same is true for most of the other suggestions you've made, darkhog.

[PixelPest]

Ah. Sorry, my mistake. You could figure out the offset though via Layer.speedX and speedY though, couldn't you?

[Hoeloe]

Ah. Sorry, my mistake. You could figure out the offset though via Layer.speedX and speedY though, couldn't you?

Yes that is doable, albeit a little awkward.

[darkhog]

Well, if we take that offset (0,0) is right when the level start before any movement has chance of ever taking place, then LunaLua could then calculate Layer.offsetX/Layer.offsetY every tick based on speed of each layer. In turn, this would ease the pain of making layers move just right.

Plus I don't think that rendering layers at appropriate positions can be done without SMBX keeping track of each layer's offset from origin point and just changing this offset when movement happens by amount in speedX/speedY. Or at least each layer's X/Y from which offset could be calculated based on the formula for each coordinate: positionatstart + currentposition

[Hoeloe]

No, that's not how layers work. Layers aren't really objects. When a layer moves, it doesn't move some group object, it just moves each object attached to that layer separately. Keeping track of these is possible, but setting position directly is not (without awkward code and side effects anyway)

[PixelPest]

Couldn't you look at all of the blocks, BGOs, and NPCs within that layer since each of the classes has a layerObj variable? If you just grabbed one object that exists in a layer couldn't you use that to keep track of layer? Then you could just check in general if an block/BGO/NPC is part of layer x and if so move it in a certain manner? The starting position of the layer's objects could just be considered 0, 0 onStart() and then from there you just do:

Code: Select all

NPC.x/y, Block.x/y, or BGO.x/y = NPC.x/y, Block.x/y, or BGO.x/y + whatever value;