SMBX2 BETA 4 Release - Feedback and Suggestions here!

[ShadowXeldron]

Currently, the Local Battle Mode is practically broken, therefore, an improved/working version would be EPIC! Plus, I'd like the ability to make your very own Battle Levels, and maybe even Battle Level Packs for others to play. Hope this gets in!

You always could make your own battle levels. Just drop any level in the battle folder and the game will register it as one.

Am I supposed to create the Battle Folder? Or can I find it somewhere?

You have to create the battle folder, although do remember that battles ARE broken. Specifically, they won't end due to both players having unlimited lives and require maps to be in the LVL format. I'd recommend that you download TheXTech and use that for battles instead, since they work perfectly in that version and some are also included with it. Note that TheXTech only supports 1.3 levels.

[KurttheKing]

You always could make your own battle levels. Just drop any level in the battle folder and the game will register it as one.

Am I supposed to create the Battle Folder? Or can I find it somewhere?

You have to create the battle folder, although do remember that battles ARE broken. Specifically, they won't end due to both players having unlimited lives and require maps to be in the LVL format. I'd recommend that you download TheXTech and use that for battles instead, since they work perfectly in that version and some are also included with it. Note that TheXTech only supports 1.3 levels.

OK then. Hopefully in the full release of 2.0, we get Fixed Battles

[Chanceux2]

[quote=Dragon0307 post_id=393570 time=1656750840 user_id=19492]

You have to create the battle folder, although do remember that battles ARE broken. Specifically, they won't end due to both players having unlimited lives and require maps to be in the LVL format. I'd recommend that you download TheXTech and use that for battles instead, since they work perfectly in that version and some are also included with it. Note that TheXTech only supports 1.3 levels.
[/quote]

Not just 1.3 levels. Also .lvlx levels

[deice]

Not just 1.3 levels. Also .lvlx levels

xtech can read lvlx files but to my knowledge it does not support all of the features that the format provides.

[ShadowXeldron]

I'm pretty sure that TheXTech actually supports more features of the LVLX format itself. What it doesn't support is SMBX2's exclusive features.

[deice]

I'm pretty sure that TheXTech actually supports more features of the LVLX format itself. What it doesn't support is SMBX2's exclusive features.

in any case, i was talking about the lvlx specification from the moondust standard (e.g. variables are yet to be implemented even in xtech, unless there have been massive updates that i just missed), but you are correct that smbx2's lvlx format has minor differences (things such as lack of extra sections and per-instance z-offsets come to mind, as well as the lua-reliant settings which obviously don't work in other versions).

[ShadowXeldron]

I'm pretty sure that TheXTech actually supports more features of the LVLX format itself. What it doesn't support is SMBX2's exclusive features.

in any case, i was talking about the lvlx specification from the moondust standard (e.g. variables are yet to be implemented even in xtech, unless there have been massive updates that i just missed), but you are correct that smbx2's lvlx format has minor differences (things such as lack of extra sections and per-instance z-offsets come to mind, as well as the lua-reliant settings which obviously don't work in other versions).

Ah, okay, thanks.

[Wohlstand]

Not just 1.3 levels. Also .lvlx levels

xtech can read lvlx files but to my knowledge it does not support all of the features that the format provides.

I'll say more: LVLX format is the native format of Moondust Project together with WLDX (analogue for world map with more features) and SAVX for game saves with more data support. These formats were invented by me for Moondust Project exclusively but started to be used in other games too (X2 is the first non-Moondust project that supports one of my formats).

Both LVLX and WLDX files are primary formats of the TheXTech engine as they are flexible and extendable without pain. LVLX and WLDX files are the only formats which able to store all supported data by SMBX64 LVL and WLD and by SMBX-38A LVL and WLD, even these features aren't supported by engines, files by theme selves can hold much more than we actually support. Therefore, having the same file format, X2 and TheXTech have different extended functionality supported on each side. For example, X2 uses extra settings (generic user-data field at every object of the LVLX format), while TheXTech uses a set of native features such as extra options of warps and modern better controllable auto-scroll inherited from SMBX-38A (uses different options, located at per-section event setup among background, music, and geometry, unlike legacy auto-scroll stored at the own spoiler). However, to avoid confusion for users when they use an alien level on an incompatible engine, each level file takes the config pack ID, and the game pops up with the notice that the level was not created for this engine and it will error.

LVLX and WLDX files do use the PGE-X data format. These files have a set of key=value data entries, and this allows almost complete backward compatibility of these files between different engines, because they are allowed to have any extra garbage without breaking compatibility, and missing fields will be automatically filled with built-in defaults.

[0lhi]

Heya. I'd like to make a suggestion regarding the TNT Crates.

Currently, spin-lumping on it will activate the Timer as normal:



This creates two disadvantages:

1. It forces to wait at certain parts, which is boring.
2. It's inaccurate to the Source Material:



Crash actually allows to skip the Timer by making a (well-timed) Spin-Jump on the TNT-Crate. Allowing the same on SMBX2 would fasten up the gameplay and make interactions with the TNT more satisfying.

[Alucard648]

Heya. I'd like to make a suggestion regarding the TNT Crates.

Not possible to do - explosion will instantly hurt the player, like Nitro.

[0lhi]

Not possible to do - explosion will instantly hurt the player, like Nitro.

Couldn't the explosion happen with a short delay on the condition that a Spin-Jump is recognized? Just enough to get the Player out-of-range, if the Jump Button is kept pressed?

[Emral]

Regardless of jump button press or not, the minimum delay appears to be 6 frames, at least for the default configuration of player jump speed and bounce response. Here is a slightly hecked up modified onPostBlockHit for a custom range TNT I tested with. It's imperfect, however, as bizarrely TNT doesn't actually seem to know at this point whether or not a player activated it. So it will also use the short timer if the player happens to be spinjumping while an NPC triggers it...:

Code: Select all

function block.onPostBlockHit(v, u, pl)
	if v.id ~= blockID then return end
	
	if pl and (pl.hasStarman or pl.isMega or pl:mem(0x50, FIELD_BOOL)) then
		blockutils.detonate(v, 4)
	else
		if v.data._basegame.timer == nil then
			v.data._basegame.timer = 0
			if player:mem(0x50, FIELD_BOOL) then
				v.data._basegame.timer = data682.timer - 6
			end
		end
	end
end

My concern with the suggestion is more about practicality. While it indeed does make certain obstacles in levels a bit faster, it could just as well make other kinds of obstacles less accessible. Someone building a TNT bridge now has to be extra careful, as a player using the spinjump could get themselves killed very easily. I don't foresee the default configuration changing due to this potential for accidental deaths and how it makes designing around TNT more difficult.
I think in general it's up to the designer on whether they include wait sections in their levels, and with access to the block's block.data._basegame.timer variable, as well as the potential of making custom range variants of the blocks, I think solutions for individual levels that would prefer different timer configurations are already covered fairly well.

[0lhi]

It's imperfect, however, as bizarrely TNT doesn't actually seem to know at this point whether or not a player activated it. So it will also use the short timer if the player happens to be spinjumping while an NPC triggers it...:

Oh, that doesn't seem ideal :/

Someone building a TNT bridge now has to be extra careful, as a player using the spinjump could get themselves killed very easily.

Is that a bad thing? TNTs are supposed to be dangerous. Accidental deaths around them when being careless seem perfectly appropriate.

Spinning around them in Crash could get you killed very easily. That aspect is completely missing in X2. Worst case you'll lose a Power Up.

I think in general it's up to the designer on whether they include wait sections in their levels

Sure, but in case of TNTs, I'd argue that waiting is more of a side-effect most of the time rather than an intentional design choice. The GIF I think is a pretty good example for where the 3 seconds don't add any benefit at all.

and with access to the block's block.data._basegame.timer variable, as well as the potential of making custom range variants of the blocks, I think solutions for individual levels that would prefer different timer configurations are already covered fairly well.

An inconsistent behavior seems worse, as it will increase the chance of accidental - and unfair - deaths for sure. If X2 was out of Beta there would be a strong case for not changing the default behavior. Changing it now would still give time to get devs and players adjusted to a new conditional behavior that will add a long-term gameplay benefit.

[Emral]

I'm not convinced that there are actual long-term gameplay benefits to the change, but I'm looking forward to hearing what others think.

[deice]

Spinning around them in Crash could get you killed very easily. That aspect is completely missing in X2. Worst case you'll lose a Power Up.

i fail to see how losing a powerup in mario isn't analogous to losing an aku-aku mask in crash bandicoot. usually the extra punishment for careless tnt handling in crash would be something like losing access to other crates or an extra life getting flung off-screen.

The GIF I think is a pretty good example for where the 3 seconds don't add any benefit at all.

in my opinion, the opposite actually holds true. that gif is a pretty good example of a setup that doesn't benefit from having a tnt there instead of one of the million other things you can use to trigger a question block from the side. in fact, if you want my two cents, putting a throw block there would not only let you get the powerup but it would also give you the choice of not getting the powerup and saving it, which is more interesting than what's currently showcased (effectively the same as just putting a question block you can normally hit from the bottom)

[0lhi]

i fail to see how losing a powerup in mario isn't analogous to losing an aku-aku mask in crash bandicoot.

That is analogous. The problem is about situations where you don't have a Power-Up.

When base Crash spins into TNTs, he dies instantly.

In X2, when base Mario spins into TNTs, nothing happens unless you willingly wait for those 3 seconds to get you.

I just learned that this not only applies to spinjumps, but also directly spinning into TNT Crates with a leaf, which is as close to Crash as you can get.



This is just wrong.

in my opinion, the opposite actually holds true. that gif is a pretty good example of a setup that doesn't benefit from having a tnt there instead of one of the million other things you can use to trigger a question block from the side.

It makes sense in context. This particular level is full of TNTs later on. The purpose of the first one here is to show you how they work. So if this is the first time you encounter a TNT, there is a benefit to it being here.

[Emral]

i fail to see how losing a powerup in mario isn't analogous to losing an aku-aku mask in crash bandicoot

I wouldn't call them analogous. Crash doesn't freeze for a second when taking damage. Mario does (and the TNT or Nitro chain reaction does not).
As such I don't think source material accuracy is even a point worth considering. If anything, a more accurate TNT might make sense as a third kind of block of this kind. A more volatile version of TNT with more easily triggered immediate explosion rules, as a middle ground between TNT and Nitro.

[deice]

I just learned that this not only applies to spinjumps, but also directly spinning into TNT Crates with a leaf, which is as close to Crash as you can get.

it would make sense if they instantly exploded here but the only realistic scenario where you would accidentally spin into one is if you were to land right next to it during a spinjump. (tail spin in smbx isn't as frequently useful as, say, smw's cape thwack) it's entirely up to the devs whether they want to expend the effort on something that minute.

Crash doesn't freeze for a second when taking damage. Mario does (and the TNT or Nitro chain reaction does not).

this actually completely slipped my mind lol. crash even usually gets a little bounce when he gets hit. i personally wouldn't be against a third block at all if other people were interested too. the more tools the merrier ^^

[Sednaiur]

Just make the TNT-block trigger normally by jumping, spinjumping, tailswiping etc but make it explode immediately after another hit, so two consecutive hits can fasten up the process of detonating it if wanted. This way the player can decide to speed up the process if he likes.

[Alucard648]

Just make the TNT-block trigger normally by jumping, spinjumping, tailswiping etc but make it explode immediately after another hit, so two consecutive hits can fasten up the process of detonating it if wanted. This way the player can decide to speed up the process if he likes.

Imagine fast autoscrolling daredevil level and path is blocked by TNT`s. Have fun.