Lua help thread

[Zygl]

Hm, is there a way to trigger some sort of autoscroll with lua?

I want the autoscroll to start at section 2 instead of 1 and to change directions, but the way the engine works, you can only do autoscroll in section 1, with only one direction.

Funnily enough, autoscrolling with lua is the very thing most of this thread has been about.

Code: Select all

left = 198
right = 800 - left
speed = 2

function onLoadSection0(asdf)
	frame = false
end
function onLoopSection0(asdf)
	if asdf == 1 then
		screen = player.sectionObj.boundary
		if frame == false then
			screen.left = player.x - left
			screen.right = player.x + right
			frame = true
		end
		screen.left = screen.left + speed
		screen.right = screen.right + speed
		player.sectionObj.boundary = screen
	end
end

That should start up autoscroll in section 1 from wherever you enter it from, be it the start of the level, a midpoint, or a warp (haven't tested the warp though). I haven't quite implemented stopping it yet, but for the purposes of putting together the autoscroll section I don't expect that it'd be all that important.
(left is how far from the left side of the screen you start, speed is of course the speed)

Code: Select all

function onEvent(event)
	if event == "[your event name here]" then
		speed = [your new speed here]
	end
end

Just drop that in the bottom of your lunadll.lua (replacing [your event name here] with your event name and [your new speed here] with whatever speed, of course) and it'll change the speed when the event's triggered. And if you need any further speed changes just put another

Code: Select all

	if event == "[your event name here]" then
		speed = [your new speed here]
	end

in that function define thing.

Only difference is in your case you'll wanna use onLoadSection1 and onLoopSection1 instead of 0, for the direction change you just need to set the speed to a negative value.

e: Unless of course the direction change isn't intended to conveniently happen on a SMBX event, in which case it'll take a bit of X-position-dependent code or something.

[Sorel]

Well, I skipped reading all the posts since I had limited time to send my, so I didn't really know that this has been asked a lot.

Anyway, thanks! I'll see if I can make it work once I get to my PC.

[TaviTurnip]

Is this incorrect or did I mess up copying it somehow?

You didn't mess up copying... there must be something else happening with the way your level is set up, because I pasted exactly what you had there and nothing else into a test level, and it worked perfectly. The player was in fact not able to control the horizontal camera movement at all.

Test level to show this is attached.

ScrollTest.zip

I can 100% outrun the camera in your level as I please. Is it just something weird with my SMBx version? <_> I'm using the devkit build for anything related to MaGL X2, so...

[Hoeloe]

Is this incorrect or did I mess up copying it somehow?

You didn't mess up copying... there must be something else happening with the way your level is set up, because I pasted exactly what you had there and nothing else into a test level, and it worked perfectly. The player was in fact not able to control the horizontal camera movement at all.

Test level to show this is attached.

ScrollTest.zip

I can 100% outrun the camera in your level as I please. Is it just something weird with my SMBx version? <_> I'm using the devkit build for anything related to MaGL X2, so...

The devkit has a very outdated version of LunaLua. I recommend updating if you haven't already.

[Kevsoft]

The one raocow will be using (as well as the one bundled with the downloadable version of MaGL X2) will be using a since-substantially updated version of Lunalua.

If you don't need the new Audio API then I would recommend v0.6.0.3.
If you need the new Audio API then I would recommend v0.6.1.1

[Rednaxela]

The one raocow will be using (as well as the one bundled with the downloadable version of MaGL X2) will be using a since-substantially updated version of Lunalua.

If you don't need the new Audio API then I would recommend v0.6.0.3.
If you need the new Audio API then I would recommend v0.6.1.1

(Or if you need the increased warp count, as Willhart indicated he may find use for, the next version to be released that hasn't been yet)
Any reason you know of to not just use the most current version at time of release though Kev? We've been trying to be pretty careful about backwards compatibility after all.

[Kevsoft]

The one raocow will be using (as well as the one bundled with the downloadable version of MaGL X2) will be using a since-substantially updated version of Lunalua.

If you don't need the new Audio API then I would recommend v0.6.0.3.
If you need the new Audio API then I would recommend v0.6.1.1

(Or if you need the increased warp count, as Willhart indicated he may find use for, the next version to be released that hasn't been yet)
Any reason you know of to not just use the most current version at time of release though Kev? We've been trying to be pretty careful about backwards compatibility after all.

I know and it is safe to use the most recent version. But if she wants to be on the most safe safe safe safe safe safe³*safe²³ side.

[Willhart]

There's going to be substantial testing of the full game by multiple parties once it's done and we settle on a LunaLua version.

That is good to hear. Wider testing should make for better results at the end.

[TaviTurnip]

The devkit has a very outdated version of LunaLua. I recommend updating if you haven't already.

I updated all my Lua files but I don't know specifically what needed to be updated, since it's still happening.

[Rednaxela]

The devkit has a very outdated version of LunaLua. I recommend updating if you haven't already.

I updated all my Lua files but I don't know specifically what needed to be updated, since it's still happening.

Hmm, odd. What if you download a full SMBX installation from http://engine.wohlnet.ru/LunaLua/ and copy your worlds directory over?

[TaviTurnip]

Hmm, odd. What if you download a full SMBX installation from http://engine.wohlnet.ru/LunaLua/ and copy your worlds directory over?

Updating it that way helped, thanks! Everything's finally working the way I want now ;w; (Though when Lua triggers autoscroll for the first time, the camera jumps behind by one tile's length and causes a minor graphical glitch and slight mistiming in oncoming event-related NPCs...)

[Rednaxela]

Hmm, odd. What if you download a full SMBX installation from http://engine.wohlnet.ru/LunaLua/ and copy your worlds directory over?

Updating it that way helped, thanks! Everything's finally working the way I want now ;w; (Though when Lua triggers autoscroll for the first time, the camera jumps behind by one tile's length and causes a minor graphical glitch and slight mistiming in oncoming event-related NPCs...)

Untested, but if you replace

Code: Select all

screen.left = player.x - left
screen.right = player.x + right

with

Code: Select all

screen.left = player.x - player.screen.left
screen.right = screen.left + 800

I think that'll fix it and make it scroll from exactly where the camera was before the scrolling started.

[TaviTurnip]

Untested, but if you replace

Code: Select all

screen.left = player.x - left
screen.right = player.x + right

with

Code: Select all

screen.left = player.x - player.screen.left
screen.right = screen.left + 800

I think that'll fix it and make it scroll from exactly where the camera was before the scrolling started.

Yep, also worked!

Now I'm having another issue ;D I actually tried to solve it myself for once and it ended up not working, unfortunately. Hoeloe gave me some Lua code for playing music before the deadline for MaGL X2 was up and I just went for that, but the error message claims this:



I'm simply trying to:

Code: Select all

function onEvent(event)
   if event == "SlowScroll" then
      PlayMusic(3);
   end
end

Did this command change recently, or was it not used correctly by me?

[Rednaxela]

I'm simply trying to:

Code: Select all

function onEvent(event)
   if event == "SlowScroll" then
      PlayMusic(3);
   end
end

Did this command change recently, or was it not used correctly by me?

No, it hasn't changed, try "playMusic" not "PlayMusic".

[Dog In Da Grass]

gonna bump this over here since it might relate to Lua too:
basically I've been wondering if it's possible to start an event after grabbing a stopwatch down from your reserve power-ups? I had an idea where it could be used similarly to a p-switch but I'm not sure if my idea is valid or could work.

[Dog In Da Grass]

I need some LunaLua help!

How do I filter characters in the LunaLua thing?
I want to change to luigi after an event happens but I dont know where to look for a player filter as it keeps pointing me back to
"FilterPlayer,0,1,2,0,0,0" and this is the completely the wrong thing unless there's an "onEvent" that works for it too

[Hoeloe]

I need some LunaLua help!

How do I filter characters in the LunaLua thing?
I want to change to luigi after an event happens but I dont know where to look for a player filter as it keeps pointing me back to
"FilterPlayer,0,1,2,0,0,0" and this is the completely the wrong thing unless there's an "onEvent" that works for it too

There's a page on the Lua wiki that gives you a tutorial on how to do this.

[TaviTurnip]

So if triggerEvent("Name") is the way to trigger an event, what would the command be to stop one? D: I tried waitEvent and that was apparently not the answer, but now the PGE Wiki is giving me search errors so I can't find the answer right now ;w; Is there a command to just flat out kill/stop everything an event is doing?

[S1eth]

So if triggerEvent("Name") is the way to trigger an event, what would the command be to stop one? D: I tried waitEvent and that was apparently not the answer, but now the PGE Wiki is giving me search errors so I can't find the answer right now ;w; Is there a command to just flat out kill/stop everything an event is doing?

An event does not have a duration and therefore cannot be stopped. (because it has already finished the moment you call it)
The event just does a one-time change to some values. And you'd have to just call a second event that reverts these changes.
Like setting layer speedX in event A and later calling event B to set layer speedX back to 0.

[Hoeloe]

An event does not have a duration and therefore cannot be stopped. (because it has already finished the moment you call it)
The event just does a one-time change to some values. And you'd have to just call a second event that reverts these changes.
Like setting layer speedX in event A and later calling event B to set layer speedX back to 0.

While this is true, it's got me thinking. It would be neat if, in future versions of Lua, we could add this functionality. Obviously it wouldn't apply to things such as text boxes, but layer movement, etc. could work well with it. Here is how I would do it:

On triggering an event, cache two values for each memory location changed by the event - the value that location was before the event occurred, and the value it is immediately afterwards.
On calling "stopEvent" or some similar function, check that the current value of each memory location changed by the event is what we would expect it to be if the event had just been called. This would stop us from interfering with layer movement that had been subsequently changed by some other event, for example.
If it is, then revert the value to what it was just before the event was called.

There are some caveats to this method, but it should provide reasonable functionality for most use cases, and simplify this kind of thing.

Probably not a top priority, but could be neat.

[Zygl]

Is there any way to check if there are any blocks between two arbitrary and moving points? Like, for instance, to determine if there are any obstructions in a Koopa's "line of sight".

[Hoeloe]

Is there any way to check if there are any blocks between two arbitrary and moving points? Like, for instance, to determine if there are any obstructions in a Koopa's "line of sight".

Difficult, and I'm not certain it's possible currently. You can probably make an approximation as it stands, though.

My suggestion is to generate collision volumes for the level, so you can access the block bounds in code (the colliders library makes this bit quite easy), then I'd loop over that and perform a raycast operation (which is something you'll have to implement yourself, currently). All it requires is "does this line intersect this object?", which is usually a reasonably straightforward operation. If so, then the line of sight is blocked.

This may prove to be a very expensive operation, and may be awkward to implement. I'll probably add a raycast function to the new version of the colliders library eventually though.

[Rednaxela]

This may prove to be a very expensive operation, and may be awkward to implement. I'll probably add a raycast function to the new version of the colliders library eventually though.

I find myself wondering if it could make sense to kind of re-implement the colliders stuff in the C++ code. Could also consider using some spatial search data structures though would need to be very careful in how to update them to make sure they don't get out of sync.

(Alternatively I find myself also thinking "wonder if there would be any issues trying to switch from plain Lua, to LuaJIT given the sort of stuff Hoeloe wants to do in it..." and then I find stuff noting that Luabind has quite a bit of overhead and that the preferred way in LuaJIT is FFI... and then find myself pondering the notion of re-implementing the surface/OOP layer of the API in Lua code using a FFI backend to C functions... that would be the highest performance way to use LuaJIT by the sound of it... hmmm....)

[Hoeloe]

This may prove to be a very expensive operation, and may be awkward to implement. I'll probably add a raycast function to the new version of the colliders library eventually though.

I find myself wondering if it could make sense to kind of re-implement the colliders stuff in the C++ code. Could also consider using some spatial search data structures though would need to be very careful in how to update them to make sure they don't get out of sync.

(Alternatively I find myself also thinking "wonder if there would be any issues trying to switch from plain Lua, to LuaJIT given the sort of stuff Hoeloe wants to do in it..." and then I find stuff noting that Luabind has quite a bit of overhead and that the preferred way in LuaJIT is FFI... and then find myself pondering the notion of re-implementing the surface/OOP layer of the API in Lua code using a FFI backend to C functions... that would be the highest performance way to use LuaJIT by the sound of it... hmmm....)

Yeah, the colliders stuff being put directly into C++ would definitely be the least performance-hungry way to do it (or even translating some stuff into PhysX or similar, but that may be going a bit far). I actually went ahead and implemented raycasting earlier today (still not published yet, still waiting on OpenGL commands). I'm still missing block and BGO collisions too, because I can't easily grab their bounds directly yet.

If we're going to be diving into collisions in C++ though, there are a couple of things that would be nice to have. First off, I've been thinking about, when grabbing block colliders, generating one large polygon collider, rather than a bunch of tiny box colliders. It could save a lot of computation if we can do it. Secondly, it really bothers me that we can only grab the entire block array in Lua currently. It would be really beneficial to have some form of space partitioning, so we can grab localised clusters of blocks, rather than searching the entire array.

[Rednaxela]

(still not published yet, still waiting on OpenGL commands).

Could you clarify what you're looking for out of it? The very initial pass at it won't contain any extra Lua APIs (except perhaps a enable/disable legacy compatibility thing). It's certainly not hard to add some "draw rectangle" stuff shortly after though. (As a note, made some good progress getting the OpenGL renderer closer to prime time last night)

First off, I've been thinking about, when grabbing block colliders, generating one large polygon collider, rather than a bunch of tiny box colliders. It could save a lot of computation if we can do it. Secondly, it really bothers me that we can only grab the entire block array in Lua currently. It would be really beneficial to have some form of space partitioning, so we can grab localised clusters of blocks, rather than searching the entire array.

My current thought is that if we had proper spatial search structures, there would be little need to make large polygon colliders from groups of blocks, and the spatial search structures can be more generally useful than just collisions. Also it may be worth doing deeper research into what data structure SMBX is doing internally already using for collisions with blocks, because I know from the result of manipulating the block structure that it has to be storing some collision data elsewhere and it's likely doing it for efficiency reasons.