LunaLua Offical Thread - SMBX Usermod Framework

[ShadowStarX]

Guys, I'm going to ask an other script if it's not a problem.
I guess you guys know the blue and the orange lasers from undertale. If not, I'm going to explain it:
If the player touches the blue laser meanwhile moving, he/she will get hit, but if the player is stand still, he/she will not be harmed. It works vice versa for the orange lasers.
So, can I ask a script for that? (if possible, no SMBX 2.0 because that doesn't work on WinXP)

EDIT:
Sorry for asking a lot, but can I get a glued floor script too? (basically, you can jump but you can't walk at all)

[HenryRichard]

I would guess you'd want to make some BGOs with the lasers and use BGO.get() to get them. Then you could test if the player is touching them (shouldn't be that difficult to figure out) and use the player.__KeyPressing fields to check if they're moving. From there you could just use player:harm() to hurt them if they're (not) moving.

EDIT: and for the glued floor you can check if a player is touching a block with Block:collidesWith(player) and override the player.__KeyPressing fields (you'd have to do it in onInuptUpdate()).

---

Is there any way to fix this? I tried using Graphics.drawImageToScene, but that caused it to wiggle when you walked.

Spoiler: show

[underFlo]

I would guess you'd want to make some BGOs with the lasers and use BGO.get() to get them. Then you could test if the player is touching them (shouldn't be that difficult to figure out) and use the player.__KeyPressing fields to check if they're moving. From there you could just use player:harm() to hurt them if they're (not) moving.

However, that way, if the player is falling w/o pressing anything, he wouldn't get hurt by a cyan laser even though he is moving. As such, you should save the player x/y from the last frame and check if either is different from the x/y on the current frame.

Speaking of those things:

http://imgur.com/svE9KDJ

[PixelPest]

In my SMW Borderlands project I'd like to have the Mario and Luigi HUDs be the same as that of Peach. Mainly, I just want to have the heart counter. Could someone provide me with some code or a helpful link I could use?

[HenryRichard]

However, that way, if the player is falling w/o pressing anything, he wouldn't get hurt by a cyan laser even though he is moving. As such, you should save the player x/y from the last frame and check if either is different from the x/y on the current frame.

...oh I misunderstood what he said. In that case, just use player.speedX and player.speedY.

[underFlo]

Oh right, I forgot that those exist,

[lighthouse64]

Hey, I was just wondering today. Is there any way to set the amount of lives for an npc such as a handcar?

[Emral]

What's a handcar?
Also: http://engine.wohlnet.ru/pgewiki/HealthPoint

[lighthouse64]

oh ok thanks enjl

For some reason I thought that the health points were like lunadll

[Quantumenace]

Well, this is irritating. When I set a layer's speed to 0 with layer.speedY = 0, the layer's speed then registers as 0 but a printout of a block's position says it's still moving very slowly. The block's speedY reads as 9.9999997473788E-5, like the float was trying to make it 1/10000 instead of 0. It moves about a pixel every 5 minutes. If I use layer:stop() it does this in both x and y directions.

It DOES work to use triggerEvent to call an event that sets the speed to 0.

I also got massive lag for the first time supposedly related to setting layer speeds in Lua, but it may have been because I had just used Block.spawn, which I never use. The lag remained in editor tests until I restarted the editor.

[HenryRichard]

Does onExitLevel() not work in the editor?

[Imaynotbehere4long]

Okay, I have a problem with LunaLua. I have the latest version, but if a custom graphic file is too large, I get this message:

Spoiler: show

However, the graphic doesn't require or even use LunaLua at all; in fact, there are no LunaLua codes in the level or episode, and the graphic displays just fine in SMBX 1.3 with no issues. Why is it that 1.3 can handle something LunaLua can't?

[4matsy]

Okay, I have a problem with LunaLua. I have the latest version, but if a custom graphic file is too large, I get this message:

*insert error message here*

However, the graphic doesn't require or even use LunaLua at all; in fact, there are no LunaLua codes in the level or episode, and the graphic displays just fine in SMBX 1.3 with no issues. Why is it that 1.3 can handle something LunaLua can't?

Oh boy. It's this problem. D: Ran into it myself on my old computer with Stabyourself.net's fangame Mari0, too. :p

I may have some bad news for you, buddy. ^_^; See, the problem that happens when you turn to hardware acceleration (that is, depending on the graphics processor(s)) to draw everything is this: Graphics cards have a certain power of two that is their limit on how big, in either dimension (horizontally or vertically), a texture can be. Usually, on a decent card, this is low-to-mid-4 digits, but on some cheaper cards and integrated chipsets, the limit can be 512 or even smaller than that. >_>;

So, yeah. It's not really LunaLua's fault for switching to OpenGL so much as your graphics setup not being able to handle teh awsum gfx shenanigans™ that the game has to offer now. D:

[Imaynotbehere4long]

How can the problem be my graphics card if the exact same custom GFX works perfectly in SMBX 1.3 on my exact same computer with the exact same graphics card setup?

[Emral]

Okay, I have a problem with LunaLua. I have the latest version, but if a custom graphic file is too large, I get this message:

*insert error message here*

However, the graphic doesn't require or even use LunaLua at all; in fact, there are no LunaLua codes in the level or episode, and the graphic displays just fine in SMBX 1.3 with no issues. Why is it that 1.3 can handle something LunaLua can't?

Oh boy. It's this problem. D: Ran into it myself on my old computer with Stabyourself.net's fangame Mari0, too. :p

I may have some bad news for you, buddy. ^_^; See, the problem that happens when you turn to hardware acceleration (that is, depending on the graphics processor(s)) to draw everything is this: Graphics cards have a certain power of two that is their limit on how big, in either dimension (horizontally or vertically), a texture can be. Usually, on a decent card, this is low-to-mid-4 digits, but on some cheaper cards and integrated chipsets, the limit can be 512 or even smaller than that. >_>;

So, yeah. It's not really LunaLua's fault for switching to OpenGL so much as your graphics setup not being able to handle teh awsum gfx shenanigans™ that the game has to offer now. D:

my 32000x32 sprite worked on 1.3 and stopped working with lunalua.

[4matsy]

How can the problem be my graphics card if the exact same custom GFX works perfectly in SMBX 1.3 on my exact same computer with the exact same graphics card setup?

The original SMBX 1.3 used Windows' own built-in software renderer to draw all the graphics (which is also why it's so slow - it didn't use hardware acceleration for the graphics); also, Visual Basic 6, the language Redigit used to code SMBX, didn't have support for hardware acceleration because it was so old.

my 32000x32 sprite worked on 1.3 and stopped working with lunalua.

Oh yeah, that's right, I remember you mentioning that a while back. Wonder now if this problem was the cause; 32000 sounds way too big. What is it, a racetrack? :p

[Wohlstand]

Since OpenGL uses hardware to render, it uses texture buffer provided by video card, but it usually gives limits in a max width/height, be careful!
for example 4096x4096 is a max size on ATI Radeon 9200

[Emral]

my 32000x32 sprite worked on 1.3 and stopped working with lunalua.

Oh yeah, that's right, I remember you mentioning that a while back. Wonder now if this problem was the cause; 32000 sounds way too big. What is it, a racetrack? :p

[Imaynotbehere4long]

The original SMBX 1.3 used Windows' own built-in software renderer to draw all the graphics

Since OpenGL uses hardware to render, it uses texture buffer provided by video card, but it usually gives limits in a max width/height, be careful!
for example 4096x4096 is a max size on ATI Radeon 9200

So, in other words, there's nothing you can do about it and some 1.3 levels will be incompatible with LunaLua, correct? If so, this should be reported to the SMBX 2.0 devs since they think all 1.3 levels will be compatible with LunaLua.

[Quantumenace]

Often you can grab an item like a vegetable or a frozen enemy and hold it in a boss's hitbox to damage it repeatedly. I wanted to avoid that, so I wrote this:

Code: Select all

--enter the boss id or table of them
--enter the list of problem NPC ids that the player can hold inside a boss and damage them repeatedly
function NoBossExploit(bossids, NPCids, section)
	boss = NPC.get(bossids, section)
	npcs = NPC.get(NPCids, section)
	for i,b in pairs(boss) do
		--check to see if the boss has invincibility frames and was recently damaged
		if b:mem (0x156, FIELD_WORD) > 0 then
			for k,n in pairs(npcs) do
				--check to see if the NPC is being held
				if n:mem(0x12C, FIELD_WORD) ~= 0 then
					--check to see if it intersects the boss
					if (n.x + n.width >= b.x) and (b.x + b.width >= n.x)
					and (n.y + n.height >= b.y) and (b.y + b.height >= n.y) then
						--if all of these are true we destroy it.
						--it may still be possible to damage the boss and pull the item away,
						--but it requires frame-perfect timing and may require the boss to be moving
						n:kill()
					end
				end
			end
		end
	end
end

--example: SM3 Bowser and Mother Brain jar as bosses, vegetables and frozen enemy ice block as NPCs
--some bosses react to NPCs differently
--for example, you can hold a shell and damage the jar repeatedly, but not Bowser
function onLoopSection0()
	NoBossExploit({86,208}, {92,139,140,141,142,143,144,145,146,147,263}, 0)
end