A Stand-in Devkit Thing (Deprecated)
A Stand-in Devkit Thing (Deprecated)
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.
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.
- Dragon Fogel
- Master of Pointlessness
- Posts: 1418
- Joined: 10 years ago
Re: A Stand-in Devkit Thing
Oh man, actual organizational stuff! Good work, I should be doing more of that.
- 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
I'll probably just keep using the devkit I have for the hubs, but this is great for others.
confirming: it's backZyglrox Odyssey wrote:
- The Official Horikawa NPC, as seen in MaGL X and probably MaGL X2
convenient noise thread for stress-relief purposes
- Rednaxela
- Maker of Shenanigans
- Posts: 897
- Joined: 10 years ago
- Pronouns: they/them
- https://rednaxela.talkhaus.com
Re: A Stand-in Devkit Thing
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.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.
Otherwise, if I get more information there's a good chance I can do something about it.
Re: A Stand-in Devkit Thing
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.Rednaxela wrote: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.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.
Otherwise, if I get more information there's a good chance I can do something about it.
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.
- Rednaxela
- Maker of Shenanigans
- Posts: 897
- Joined: 10 years ago
- Pronouns: they/them
- https://rednaxela.talkhaus.com
Re: A Stand-in Devkit Thing
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: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.)
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.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.
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
Re: A Stand-in Devkit Thing
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.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
Re: A Stand-in Devkit Thing
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?Zyglrox Odyssey wrote:Horikawa's fake exit star NPC
- Dragon Fogel
- Master of Pointlessness
- Posts: 1418
- Joined: 10 years ago
Re: A Stand-in Devkit Thing
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.)
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.)
- Willhart
- Stalker, Doxxer, and Sexual Harasser
- Banned
- Posts: 2434
- Joined: 13 years ago
- Location: Finland
Re: A Stand-in Devkit Thing
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.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.)
Re: A Stand-in Devkit Thing
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.Quman wrote: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?Zyglrox Odyssey wrote:Horikawa's fake exit star NPC
Re: A Stand-in Devkit Thing
Having a problem with Colliders.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
This is with the version in the latter download and with the latest version from the PGE wiki page thing.
- Rednaxela
- Maker of Shenanigans
- Posts: 897
- Joined: 10 years ago
- Pronouns: they/them
- https://rednaxela.talkhaus.com
Re: A Stand-in Devkit Thing
That would be a problem with your code where you're using the colliders library.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.
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.
Re: A Stand-in Devkit Thing
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.Rednaxela wrote:That would be a problem with your code where you're using the colliders library.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.
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.
- Rednaxela
- Maker of Shenanigans
- Posts: 897
- Joined: 10 years ago
- Pronouns: they/them
- https://rednaxela.talkhaus.com
Re: A Stand-in Devkit Thing
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.Zyglrox Odyssey wrote: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.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.
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.
Re: A Stand-in Devkit Thing
It's some code Hoeloe posted a while back when I was trying to make a thing spinjump-proof.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.
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 soHoeloe 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
Re: A Stand-in Devkit Thing
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: 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
- Rednaxela
- Maker of Shenanigans
- Posts: 897
- Joined: 10 years ago
- Pronouns: they/them
- https://rednaxela.talkhaus.com
Re: A Stand-in Devkit Thing
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.Zyglrox Odyssey wrote:It's some code Hoeloe posted a while back when I was trying to make a thing spinjump-proof.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 soHoeloe 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
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
Re: A Stand-in Devkit Thing
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: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: 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
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
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.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
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.
- Rednaxela
- Maker of Shenanigans
- Posts: 897
- Joined: 10 years ago
- Pronouns: they/them
- https://rednaxela.talkhaus.com
Re: A Stand-in Devkit Thing
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).
Found the cause. It's a bug in colliders.lua, and has nothing to do with LunaDLL version... except the following: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.
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).
Re: A Stand-in Devkit Thing
Huh. Not sure how that happened. I'll make sure it's fixed in the new version.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.
Re: A Stand-in Devkit Thing
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.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.
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.
-
- Posts: 54
- Joined: 9 years ago
Re: A Stand-in Devkit Thing
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.
- Dragon Fogel
- Master of Pointlessness
- Posts: 1418
- Joined: 10 years ago
Re: A Stand-in Devkit Thing
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.
-
- Posts: 54
- Joined: 9 years ago
Re: A Stand-in Devkit Thing
Okay. I've never had a problem with Luna before, so I was a bit worried.