(shouting)

A Stand-in Devkit Thing (Deprecated)

If you lost something come look for it here
Zygl
Posts: 616
Joined: 11 years ago

A Stand-in Devkit Thing (Deprecated)

Post by Zygl »

I've been holding off on making a devkit for this on the grounds that literally all it would be is the LunaLua download and the latest PGE download rolled into one bigger download and MaGL X2 will immediately deprecate it anyway with all the super neat stuff Horikawa's putting in it.
But given that MaGL X2 won't be released for a few months I decided to put one together anyway (read: Gyra has on at least two occasions been all "blaugh why must making a good level x be so complicated, zyg it's your fault you haven't put together a good devkit yet" so I did).


^Yeah that bit about it being deprecated has happened now. Gonna retool this thread (or maybe make a new one idk) for compiled graphics and NPC edits and stuff like I had some of packed into the devkit, in the meantime go here for the SMBX 2.0 download.
User avatar
Dragon Fogel
Master of Pointlessness
Posts: 1415
Joined: 10 years ago

Re: A Stand-in Devkit Thing

Post by Dragon Fogel »

Oh man, actual organizational stuff! Good work, I should be doing more of that.
Image
Click that banner if you like reading words.
Image
Make levels from unused MAGL X names!
User avatar
Blivsey
forever an obscure pokemons
Posts: 1155
Joined: 11 years ago
First name: liv/livvy
Pronouns: she/her
Location: Ioway
https://blivsey.talkhaus.com/

Re: A Stand-in Devkit Thing

Post by Blivsey »

I'll probably just keep using the devkit I have for the hubs, but this is great for others.
Zyglrox Odyssey wrote:
  • The Official Horikawa NPC, as seen in MaGL X and probably MaGL X2
confirming: it's back
convenient noise thread for stress-relief purposes
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: A Stand-in Devkit Thing

Post by Rednaxela »

Zyglrox Odyssey wrote:e: I didn't expect I'd be the one running into problems with my own devkit thingy but SMBX appears to be crashing on my computer. I'm almost certain this is because of the new OpenGL renderer in LunaLua 0.7, gonna look into what can be done about it and set up a version of the devkit with the pre-OpenGL LunaLua if I can't get it to run right.
What's the crash that you're seeing exactly? if you're running Windows XP, the 0.7 release has some known problems with that, which have since been fixed, so simply using a current development build that's newer than 0.7 would fix it in that case.
Otherwise, if I get more information there's a good chance I can do something about it.
Zygl
Posts: 616
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Zygl »

Rednaxela wrote:
Zyglrox Odyssey wrote:e: I didn't expect I'd be the one running into problems with my own devkit thingy but SMBX appears to be crashing on my computer. I'm almost certain this is because of the new OpenGL renderer in LunaLua 0.7, gonna look into what can be done about it and set up a version of the devkit with the pre-OpenGL LunaLua if I can't get it to run right.
What's the crash that you're seeing exactly? if you're running Windows XP, the 0.7 release has some known problems with that, which have since been fixed, so simply using a current development build that's newer than 0.7 would fix it in that case.
Otherwise, if I get more information there's a good chance I can do something about it.
Basically the moment the level editor comes up and it would in theory start rendering the black square of a new level with nothing in it Windows tells me it "stopped working" and that it's checking for a solution to the problem. I dunno where to get more information than that, sadly.
I dunno how possible it'd be but I'm pretty sure the best/only fix for my problem is to have LunaDLL check if there's enough OpenGL on the computer before cutting in with the OpenGL renderer, I'm almost certain my problem is I don't have OpenGL, or the right version of it or whatever. I've had similar problems to this in the past with OBS and PCSX's OpenGL plugins. (I don't have a 'video card' video card, you see, my computer is mostly a glorified paperweight.)

At any rate, for the time being I've added a version of the devkit with 0.6.1.1 to the OP in case anybody else has similar difficulties.
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: A Stand-in Devkit Thing

Post by Rednaxela »

Zyglrox Odyssey wrote:Basically the moment the level editor comes up and it would in theory start rendering the black square of a new level with nothing in it Windows tells me it "stopped working" and that it's checking for a solution to the problem. I dunno where to get more information than that, sadly.
I dunno how possible it'd be but I'm pretty sure the best/only fix for my problem is to have LunaDLL check if there's enough OpenGL on the computer before cutting in with the OpenGL renderer, I'm almost certain my problem is I don't have OpenGL, or the right version of it or whatever. I've had similar problems to this in the past with OBS and PCSX's OpenGL plugins. (I don't have a 'video card' video card, you see, my computer is mostly a glorified paperweight.)
Could you run the "visualinfo.exe" tool from glew_1.12_visualinfo.zip, and PM me the resulting visualinfo.txt file? This would give me enough information to know A) If it's possible to modify the OpenGL renderer to make it compatible with your system, and if not, B) the precise reason it can't run, and thus be more certain that checks I add in the future would detect that.

Zyglrox Odyssey wrote:At any rate, for the time being I've added a version of the devkit with 0.6.1.1 to the OP in case anybody else has similar difficulties.
I'd strongly advise against using the old 0.6.1.1 devkit for that purpose. Quite a large number of changes, improvements, and bug fixes unrelated to the OpenGL renderer have happened since then.
It's trivial to make a build that's fully up-to-date except with the OpenGL renderer disabled.

Here's a pair of fully up-to-date builds, one with OpenGL and one without:
LunaDLL-0.7Red6Green.zip
LunaDLL-0.7Red6NoGL.zip
There have been a number of improvements in these as compared to 0.7 too, such as drastically reduced CPU usage when in simple levels or when the window is in the background (Yaaaay, no longer making laptop fans go wild for no good reason), fixing a SMBX crash bug (which was present even in vanilla, and was the one that caused crashes during Stary Ocean Pipes in Horikawa's retospective), and fixing Windows XP compatibility which was accidentally broken in 0.7
Zygl
Posts: 616
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Zygl »

Rednaxela wrote:I'd strongly advise against using the old 0.6.1.1 devkit for that purpose. Quite a large number of changes, improvements, and bug fixes unrelated to the OpenGL renderer have happened since then.
It's trivial to make a build that's fully up-to-date except with the OpenGL renderer disabled.

Here's a pair of fully up-to-date builds, one with OpenGL and one without:
LunaDLL-0.7Red6Green.zip
LunaDLL-0.7Red6NoGL.zip
There have been a number of improvements in these as compared to 0.7 too, such as drastically reduced CPU usage when in simple levels or when the window is in the background (Yaaaay, no longer making laptop fans go wild for no good reason), fixing a SMBX crash bug (which was present even in vanilla, and was the one that caused crashes during Stary Ocean Pipes in Horikawa's retospective), and fixing Windows XP compatibility which was accidentally broken in 0.7
Alright cool, thanks, I'll get right on updating the OP with them just as soon as i'm not tired and wanting nothing to do with the half-hour or so of uploading that'd take on my internet connection. Unless of course you have some other neat thing worked out by that point in which case idk we'll see.
Quman
Posts: 31
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Quman »

Zyglrox Odyssey wrote:Horikawa's fake exit star NPC
Does that still replace the blue rupee (npc-252), or does it now replace an NPC that doesn't have a chance of randomly appearing when Link/Sheath kills an enemy or hits a coin block?
User avatar
Dragon Fogel
Master of Pointlessness
Posts: 1415
Joined: 10 years ago

Re: A Stand-in Devkit Thing

Post by Dragon Fogel »

Probably the best option would be NPC-152, which is a Gold Ring from Sonic and so not really useful unless you're making a Sonic reference level or doing some kind of visual gag.

In those rare cases where someone's doing one of those things and including a fake star, they can replace something else according to their own needs.

(Of course, it could be there's a weird property of rings that makes them bad for that, but it seems like the best option from what I know.)
Image
Click that banner if you like reading words.
Image
Make levels from unused MAGL X names!
User avatar
Willhart
Stalker, Doxxer, and Sexual Harasser
Banned
Posts: 2434
Joined: 13 years ago
Location: Finland

Re: A Stand-in Devkit Thing

Post by Willhart »

Dragon Fogel wrote:Probably the best option would be NPC-152, which is a Gold Ring from Sonic and so not really useful unless you're making a Sonic reference level or doing some kind of visual gag.

In those rare cases where someone's doing one of those things and including a fake star, they can replace something else according to their own needs.

(Of course, it could be there's a weird property of rings that makes them bad for that, but it seems like the best option from what I know.)
I think some coins may change to other coins depending on the character you are playing as. I'm not sure if it affects the rings though.
Zygl
Posts: 616
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Zygl »

Quman wrote:
Zyglrox Odyssey wrote:Horikawa's fake exit star NPC
Does that still replace the blue rupee (npc-252), or does it now replace an NPC that doesn't have a chance of randomly appearing when Link/Sheath kills an enemy or hits a coin block?
I just took the download from one of Horikawa's mass PMs during MaGL X2 and put it in there, I figured if somebody needed it to be a different thing they could change it easily but thinking about it it would be better to make it by default a thing barely anybody would use otherwise. I'll change it for the next update, whenever that is.
Zygl
Posts: 616
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Zygl »

Rednaxela wrote:Here's a pair of fully up-to-date builds, one with OpenGL and one without:
LunaDLL-0.7Red6Green.zip
LunaDLL-0.7Red6NoGL.zip
Having a problem with Colliders.
Image
This is with the version in the latter download and with the latest version from the PGE wiki page thing.
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: A Stand-in Devkit Thing

Post by Rednaxela »

Zyglrox Odyssey wrote:Having a problem with Colliders.
<image>
This is with the version in the latter download and with the latest version from the PGE wiki page thing.
That would be a problem with your code where you're using the colliders library.
Based upon that error, you're calling colliders.bounce(a, b) and passing it either true or false for b (at line 23 of your code), which is not how it's supposed to be used. colliders.bounce is expecting both arguments be some type of in-game object or a colliders library hitbox.
Zygl
Posts: 616
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Zygl »

Rednaxela wrote:
Zyglrox Odyssey wrote:Having a problem with Colliders.
<image>
This is with the version in the latter download and with the latest version from the PGE wiki page thing.
That would be a problem with your code where you're using the colliders library.
Based upon that error, you're calling colliders.bounce(a, b) and passing it either true or false for b (at line 23 of your code), which is not how it's supposed to be used. colliders.bounce is expecting both arguments be some type of in-game object or a colliders library hitbox.
It worked perfectly fine before, is the thing. In the MaGL X2 devkit with version 0.6.whatever I don't get an error of any sort.
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: A Stand-in Devkit Thing

Post by Rednaxela »

Zyglrox Odyssey wrote:
Rednaxela wrote:That would be a problem with your code where you're using the colliders library.
Based upon that error, you're calling colliders.bounce(a, b) and passing it either true or false for b (at line 23 of your code), which is not how it's supposed to be used. colliders.bounce is expecting both arguments be some type of in-game object or a colliders library hitbox.
It worked perfectly fine before, is the thing. In the MaGL X2 devkit with version 0.6.whatever I don't get an error of any sort.
Regardless of that, there's no way to debug that without you doing more work from your side to narrow down the problem, or sharing the relevant code from the level.

The second argument you're passing to colliders.bounce is a boolean for some reason. There's no reason to expect that value being a boolean would have ever worked. That error, nor anything I have access to, has any hope of telling us why that value is a boolean. So... you either need to do some debugging yourself to find out where that boolean value is coming from, or share your at least part of the lunadll.lua code.
Zygl
Posts: 616
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Zygl »

Rednaxela wrote:Regardless of that, there's no way to debug that without you doing more work from your side to narrow down the problem, or sharing the relevant code from the level.

The second argument you're passing to colliders.bounce is a boolean for some reason. There's no reason to expect that value being a boolean would have ever worked. That error, nor anything I have access to, has any hope of telling us why that value is a boolean. So... you either need to do some debugging yourself to find out where that boolean value is coming from, or share your at least part of the lunadll.lua code.
It's some code Hoeloe posted a while back when I was trying to make a thing spinjump-proof.
Hoeloe wrote:

Code: Select all

for _,v in pairs(findnpcs(NPCID,player.section)) do
	local bounce,spin = colliders.bounce(player, v);
	if(bounce and spin) then
		colliders.bounceResponse(player);
	end
end
Unless of course it's actually somewhere else but this looks like 'a thing that should not be a boolean being used as a boolean' and is around line 23 in my lunadll.lua so
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: A Stand-in Devkit Thing

Post by Hoeloe »

Zyglrox Odyssey wrote: Unless of course it's actually somewhere else but this looks like 'a thing that should not be a boolean being used as a boolean' and is around line 23 in my lunadll.lua so
So the current released version of colliders.lua has some issues with non-box colliders, but if you're using NPCs or the player, they shouldn't occur. Some code with some surrounding context might be helpful. I also suggest giving me at least the version number at the top of the colliders.lua file you're using, if not the file itself, so I can have a look and see what's going on (although that same code seems to work fine on my end).
Image
Image
Image
Image
Image
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: A Stand-in Devkit Thing

Post by Rednaxela »

Zyglrox Odyssey wrote:It's some code Hoeloe posted a while back when I was trying to make a thing spinjump-proof.
Hoeloe wrote:

Code: Select all

for _,v in pairs(findnpcs(NPCID,player.section)) do
	local bounce,spin = colliders.bounce(player, v);
	if(bounce and spin) then
		colliders.bounceResponse(player);
	end
end
Unless of course it's actually somewhere else but this looks like 'a thing that should not be a boolean being used as a boolean' and is around line 23 in my lunadll.lua so
Based on that error you provided, and after carefully examining the workings of the relevant parts of colliders.lua (assuming you're using the same version as here, v1.0.3, which seems likely the case as the line numbers appear to make sense), and the quote you gave now... I'm very confident that that error you showed would be completely impossible in the code snippet you just quoted, if 100% completely unmodified.

Either what you've included in your level has been modified from what you're quoting (in which case, what it's doing differently is likely key to understanding what's going wrong), or you have a different call to colliders.bounce that's at exactly line 23
Zygl
Posts: 616
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Zygl »

Hoeloe wrote:
Zyglrox Odyssey wrote: Unless of course it's actually somewhere else but this looks like 'a thing that should not be a boolean being used as a boolean' and is around line 23 in my lunadll.lua so
So the current released version of colliders.lua has some issues with non-box colliders, but if you're using NPCs or the player, they shouldn't occur. Some code with some surrounding context might be helpful. I also suggest giving me at least the version number at the top of the colliders.lua file you're using, if not the file itself, so I can have a look and see what's going on (although that same code seems to work fine on my end).
Here's the entire for loop in question,complete with random impertinent debug code-type bits at the bottom and stuff I forget the exact purpose of:

Code: Select all

	for _,v in pairs(findnpcs(76,player.section)) do
		local bounce,spin = colliders.bounce(player, v)
		if(bounce and spin) then
			colliders.bounceResponse(player)
			v:mem(0xF8,FIELD_DFLOAT,6)
		end
		if v:mem(0xF8,FIELD_DFLOAT) == 0 then
			if colliders.collide(player,v) then
				player:harm()
			end
		else
			v:mem(0xF8,FIELD_DFLOAT,v:mem(0xF8,FIELD_DFLOAT) - 1)
		end
		if v.y < -200600 then
			if v.speedX > .4 then
				v.speedX = .4
			elseif v.speedX < -.4 then
				v.speedX = -.4
			end
		end
--		printText(tostring(v:mem(0xF0,FIELD_DFLOAT)),a*32,1)
--		printText(tostring(v:mem(0xF8,FIELD_DFLOAT)),a*32,32)
--		printText(tostring(v:mem(0x100,FIELD_DFLOAT)),a*32,64)
--		printText(tostring(v:mem(0x108,FIELD_DFLOAT)),a*32,96)
--		printText(tostring(v:mem(0x110,FIELD_DFLOAT)),a*32,128)
	end
And it's apparently version 1.0.3, downloaded from here.
Rednaxela wrote:Based on that error you provided, and after carefully examining the workings of the relevant parts of colliders.lua (assuming you're using the same version as here, v1.0.3, which seems likely the case as the line numbers appear to make sense), and the quote you gave now... I'm very confident that that error you showed would be completely impossible in the code snippet you just quoted, if 100% completely unmodified.

Either what you've included in your level has been modified from what you're quoting (in which case, what it's doing differently is likely key to understanding what's going wrong), or you have a different call to colliders.bounce that's at exactly line 23
All I really appear to have done is add a few lines that I wouldn't expect to break it and remove a semicolon that appears to be entirely extraneous, unless I'm forgetting something. Also I checked and that call there is at exactly line 23.

It wouldn't happen to have something to do with the non-OpenGL version of the LunaDLL, would it? I don't suppose either of you would be running that one - you both presumably have actually good computers that can run the OpenGL one - which would explain why Hoeloe can run the code no problem if it were the case.
User avatar
Rednaxela
Maker of Shenanigans
Posts: 897
Joined: 10 years ago
Pronouns: they/them
https://rednaxela.talkhaus.com

Re: A Stand-in Devkit Thing

Post by Rednaxela »

Hoeloe wrote:So the current released version of colliders.lua has some issues with non-box colliders, but if you're using NPCs or the player, they shouldn't occur. Some code with some surrounding context might be helpful. I also suggest giving me at least the version number at the top of the colliders.lua file you're using, if not the file itself, so I can have a look and see what's going on (although that same code seems to work fine on my end).
Zyglrox Odyssey wrote:All I really appear to have done is add a few lines that I wouldn't expect to break it and remove a semicolon that appears to be entirely extraneous, unless I'm forgetting something. Also I checked and that call there is at exactly line 23.
Found the cause. It's a bug in colliders.lua, and has nothing to do with LunaDLL version... except the following:

It probably worked in LunaDLL 0.6.1.1 for you because that version comes with an old version of colliders.lua (no version number at the top of that file) without this bug.
If you put the newer 0.0.3 version of colliders.lua into a LunaDLL 0.6.1.1 install, the exact same error happens over there too.



The boolean value comes from line 146 which is "if(ca == nil) then return false; end;" in colliders.getSpeedHitbox

The caller of colliders.getSpeedHitbox is colliders.speedCollide, which passes this "false" value as the second argument of colliders.collide, unless it's nil. Well... false is not nil, so it'll keep going, and colliders.collide can't handle being passed a boolean, so KABOOM.

The fix should be replacing "if(ca == nil) then return false; end;" with "if(ca == nil) then return nil; end;" on line 146 of colliders.lua
That should do the job for you Zyglrox.

Going to guess Hoeloe probably didn't see it with that version because you can't really trigger this unless memory offset 0x12A is 0, which generally open happens for enemies that haven't spawned yet or have despawned (which often doesn't happen in simple 1-screen code-test levels), or generators (how I managed to reproduce it).
User avatar
Hoeloe
A2XT person
Posts: 1016
Joined: 12 years ago
Pronouns: she/her
Location: Spaaace

Re: A Stand-in Devkit Thing

Post by Hoeloe »

Rednaxela wrote: The fix should be replacing "if(ca == nil) then return false; end;" with "if(ca == nil) then return nil; end;" on line 146 of colliders.lua
That should do the job for you Zyglrox.
Huh. Not sure how that happened. I'll make sure it's fixed in the new version.
Image
Image
Image
Image
Image
Zygl
Posts: 616
Joined: 11 years ago

Re: A Stand-in Devkit Thing

Post by Zygl »

Rednaxela wrote:The fix should be replacing "if(ca == nil) then return false; end;" with "if(ca == nil) then return nil; end;" on line 146 of colliders.lua
That should do the job for you Zyglrox.
Alright everything's working perfectly now, thanks. And apparently something's been done about that other thing I've kept forgetting to ask about (cinematX putting a weird ugly black box over the HUD in any level it's used in), so that's nice.
I'll be sure to include the fix in the next devkit release, which at this point should probably be a thing given the relative importance of this particular change.
acrowdofpeople
Posts: 54
Joined: 8 years ago

Re: A Stand-in Devkit Thing

Post by acrowdofpeople »

The devkit's clean, right? I scanned it with my antivirus prior to unzipping it, and got my first ever "threat detected" on a SMBX-related thing with it.
User avatar
Dragon Fogel
Master of Pointlessness
Posts: 1415
Joined: 10 years ago

Re: A Stand-in Devkit Thing

Post by Dragon Fogel »

Yeah, it's clean. From what I understand, it's just that the way LunaDLL works involves basically doing the sort of things that viruses do. Someone with more expertise could probably give a more detailed/accurate explanation.
Image
Click that banner if you like reading words.
Image
Make levels from unused MAGL X names!
acrowdofpeople
Posts: 54
Joined: 8 years ago

Re: A Stand-in Devkit Thing

Post by acrowdofpeople »

Okay. I've never had a problem with Luna before, so I was a bit worried.
Post Reply