Month: January 2020

SMBX2b4 is the newest stable release of SMBX2, including all the features from the preview builds MAGLX3 and PAL, with new fixes and features on top.

The specifications of the software can be found in the slightly-updated handbook included in the download. You can download SMBX2b4 here. An elaborate list of updates can be found here. Please report any bugs you find either on the SMBX forums topic or directly in the codehaus discord server. Thank you!

Below you will find a brief overview over how to handle various potentially critical changes (highlighted in yellow on the changelog).

HOW TO UPDATE

If you have been making levels on the previous preview build and find inconsistencies, here is what you can do in various situations:

All my NPC packs broke because of what you did to Extra Settings!!!

Sorry! Won’t happen again. We dealt with some weaknesses of the extra settings system and now they’re in a good spot. Making ID-agnostic extra settings required us to change the structure to avoid conflicts with variable names. While previously the settings were all put into npc.data._basegame despite not being _basegame variables, you can now find them in npc.data._settings for the ID-specific settings, and npc.data._settings._global for cross-id settings. Also! No extra settings value will ever be nil anymore, so the default value of your extra settings file now matters more than ever!

If you’re not a developer of NPC packs and all this talk went right over your head, please request the makers of the packs you’re using to update their packs to the new system. Implementing the change, although unfortunately a hassle we couldn’t avoid, ought to take no more than a couple of minutes. For more information see the previous blog post.

I have previously loaded scripts from the scripts/npcs/ and scripts/blocks/ directories.

Due to the move to the npc-n and block-n system, a lot of NPC and Block files were either moved or removed. This change in structure is one-time and we have now completed the move to the new system! Regardless, you will have to rewrite at least some of your code. You are likely to find what you need in the scripts/npcs/ai directory or scripts/blocks/ai directory, where all common behaviours are now located. If you cannot find what you need, take a closer look at the npc-n/block-n file of a basegame entity sharing the behaviour you were emulating. You can copy that file over and edit values where necessary to achieve the same result your code had before.

I have previously relied on newblocks.lua.

Now that newblocks no longer exists and blocks use the same system as NPCs, please look into rewriting your block code in accordance with the block-n system. Chances are, you will see a performance boost after doing so, too. Especially if it relied on onCollideBlock!

The new isheavy flag is breaking setups in one of my levels.

The isheavy config flag can be disabled on a per-id basis by putting “isheavy=false” (without the quotes) into a npc-n.txt file, where n is the ID of the NPC that’s causing trouble.

Springs no longer bounce essential noblockcollision NPCs!

You can add NPC IDs to the spring whitelists by loading springs.lua and calling the springs.whitelist(id, type) function, where “id” is the ID to whitelist and “type” is the type of spring to whitelist from. If you leave this empty, it whitelists for all springs. The default types are “UP” and “SIDE”.

Why does the NPC passthrough block no longer work in multiplayer?

Previously, there was a bug where NPC passthrough blocks would react weirdly to all thrown NPCs. While fixing that bug, we unfortunately had to temporarily break multiplayer support on that block. Multiplayer support will return in a future update, when we make sure all characters and obstacles work with multiplayer (which is currently not yet possible). Please keep an eye out! I hope the current behaviour of the block ends up being more benefitial than harmful to your levels.

For further issues, please take a look at the highlighted sections in the patch notes. There are some things highlighted that are self-explanatory in how they can be resolved, so I didn’t touch upon them here.

VERSIONING CHANGES

Due to the confusing names of preview builds, with this release we are trying out a new, consistent version numbering system. With the new system, beta versions will be prefixed with a b (e.g. 2.0.0.b3 for Beta 3), and preview versions with a p (e.g. 2.0.0.b4.p2 for PAL). Patches and hotfix releases will also have their own version number, and it will be possible to check your version number in Lua. Hopefully this should help make things a bit less confusing, since everything will use a consistent numbering scheme.

We have also rewritten the launcher update check code a little so you can decide what severity of updates you would like to receive notifications for – If you’re happy developing your episode for 2.0.0 you’re probably not interested in half-working shenanigans from the 2.0.1p preview builds.

I hope you enjoy what we have made for you today! Thank you for reading and have a great time.

~Enjl

Hey, today I want to share with you some changes coming in Beta 4 that can break compatibility with NPC packs made on the PAL and MAGLX3 builds. If you have developed some of those packs (like I have), please pay attention!

The changes are all related to the editor “extra settings” framework, with which NPCs can be customized on a per-entity basis. You might’ve seen it on Boo Circles, or the Fire Snake.

So, I have good news and bad news. The good news is that we have expanded the extra settings framework further to be even more useful. Most importantly, we added a way to create cross-ID extra settings, which is insanely useful for episodes that wanna have settings to be able to give any NPC imaginable a mustache. Yes, even the bloopers! With just one extra settings file! The bad news is that in order to do this we had to adjust the way the variables are stored in lua. Here’s a brief overview over what’s changed:

So, let me explain. Instead of npc.data._basegame, you will now have to use npc.data._settings to access the extra settings variables. Simple enough! There is a second change, though. It’s a little more subtle: Previously, if someone didn’t adjust the extra settings value in the editor, the field would not be saved to the file and the value would be nil. This can no longer be the case. The middle fire snake actually has a length of 4 according to the save file. If you relied on extra settings being nil anywhere, this needs to change. One example of NPCs relying on nil would be for cases where an extra settings field overwrote a NPC config default variable. Some basegame NPCs that did this now use a checkbox to toggle a boolean that controls whether the fields below should do anything in the code, or if the defaults should be used instead.

If you would like to be prepared for the update when it comes out later this month, take a couple minutes out of your day to upload an alternative version of your NPC packs that have this change implemented to your NPC pack threads on the forums. It’s a quick adjustment that ensures your NPC packs will stay compatible forever, hooray!

Thanks for reading. I hope you’re looking forward to Beta 4!

~Enjl

I also have some ceral as an apology for breaking your packs!