Pull request updated with the addition of the Zoom:
nsmb-editor-380b.zip

Also for those who want to tamper with the Actor 77 ASM and the Worldmap icons ASM:
nsmb-editor-actor77.zip



Example:

I also took into account the case where the Scrapped width is equal or above the Zone Width while the latter is not equal to 0.

Don't put words in my mouth,  MarioKart7z, I never said that those were NSMB U beta pipes.

 Hiccup already asked me this anyways on that one video, and the pipes were scaled down directly from the official artworks of NSMB U.

First post updated with some slight improvements to the code + a new download link for the palette.

It should work well now.

It's actually relatively easy to darken an area.

You have to change one of the following nsbtx in the polygon_unit folder :
evf_cloud1 (sprite 315)
evf_haze1 (sprite 310)
evf_tree1_a (sprite 324)
evf_tree1_b (sprite 325)
Why these and not the others ?
Because those 4 are the ones who have an opacity setting.

From there you proceed to fill all the texture with black color.
And then you can adjust the opacity with the corresponding sprite.

Here you have, your dark area

Pretty much what Wesley said, buuuuuut I just wanted to clarify something, actually it's NOT hardcoded, otherwise you wouldn't be able to modify it without ASM.



This is caused by the bytes 11 to 14 in block 5 (block 3 if it was a bottom background) having their values as FF.

Revision b376 only.

Whenever I try to change Value 5 or 6 of any path node given with the arrows/mouse, NSMBe throws me that error :



Notes :
_No prior manipulation needed, error will happen no matter what
_Values 1 to 4 works fine though
_Manually typing a value works too (even for value 5 and value 6)


Also I will report something else but since I don't know if it's a bug or something actually intended I won't create another thread, here I go anyway :
In revision 375 and 376 when you change the tileset, NSMBe doesn't visually auto-update anymore, you have to close and open the level again to see the changes.

So I did further research on (E) rom, found some interesting things (as well as some obnoxious ones):

_The culprit is the byte located at RAM address 021C1A9F (again on (E) ROM, but it shouldn't be that far of on other versions)
_That byte is 00 by default (slopes enabled)
_Somehow whenever Mario or Luigi uses the tightrope the value magically changes to 04 (slopes disabled)

You can guess what I did next ?
I used an internal cheat to force that value to 00, and :


TLDR GG Nintendo

I found 2 interesting things regarding background scrolling while I was messing with the values :
(Note 1 : for all intents and purposes, the bytes are numbered considering the first byte as byte 1 and values are in hex)
(Note 2 : the modifications should be applied to blocks 3 and 5 for bottom and top backgrounds respectively)

Disabling vertical scrolling

Works for both top and bottom background

This is achieved by putting a value of 40 for byte 13 and by putting a value of 10 for byte 16.
By doing that the background will stay vertically static to the camera.
Sadly I have yet to find a method to block horizontal scrolling (or at least one who doesn't involve disabling the HDMA).



Automatic horizontal scrolling

Works for both top and bottom background

It only works for backgrounds who already have a horizontal animation, you can achieve this by putting a value of 10 for byte 16 and it will animate the whole background instead of partially animating it.
(Note : if byte 13 value is somewhere between 40 and 4F, this effect will be overridden and instead the vertical scrolling will be disabled)

Good job on gathering the data, there's this too who can prove to be interesting.

Nah you can't add palettes just by importing a larger image. I tested that and I got denied loool.
But yes you're right about manually adding palettes, this is how I used to do but it gets impractical when you basically have to redo a tileset from scratch, you are better off importing the Beach tileset and work from there .

 MarioSunshine, to resize the palette file (this is for tileset only), just follow those steps :
_choose a tileset and open it

_choose the Graphics tab, and note the .ncg used right now

_for example tileset 11 (Forest) , use d_2D_W_M_tikei_jungle_ncg.bin, so you want to add palette to its corresponding .ncl in the BG_ncl folder, which is d_2D_W_M_tikei_jungle_ncl.bin

_the .ncl files are LZ compressed, you want to LZ decompress them first to bring back the file size to 1024 bytes

_each palettes use 256 colors, and each color are stocked in a token which take 2 bytes (note that the first token of each palette is transparent no matter its bytes' values)

_if you do the math 256×2=512, since there are 2 palettes 512×2=1024 bytes

_you can use up to 4 palettes in a tileset, thus 512×4=2048 bytes (which is also 1024 × 2)

_click Hex Edit, and then right-click, Select All, right-click, Copy, go to the end of the file, right-click and Paste, if done correctly the last byte should be located at 000007FF

_save and exit

_don't forget to LZ compress the .ncl file

_enjoy your 4-palettes tileset, now you can import an image large enough to take into account the new palette size


Note : actually you can import more than 4 palettes, surprinsigly enough it doesn't crash the game, but ultimately this is useless thanks to the modulo 4, thus objects who should use the palette 5 will use palette 1 instead, palette 6 use palette 2 etc.

I don't know how if you can add more palettes to things like d_2d_UI_O_menu_title_o_d_ncl.bin for example since this is not a tileset, so you're on your own here.

This is it, this is how you manually add palette to a .ncl file

What Nintendo didn't take into account was the floaty mechanics of Mini-Mario/Mini-Luigi, you can actually glitch your way out if you grab a GREEN right-end-of-ledge object close enough to the ground.

There's no trick involving view's width at all lol, heck I even tested the stairs with a simple 256×192 view and they work.

You only need to do know one thing, ghost house stairs are activated with an output ID of 14 (base 10).
Yep, it's a special event ID.

What the title says.

I apologize in advance if this problem was already described in the past, but whenever you save and quit the tileset editor, any Map 16 tile who has a value of -1 will reset its control byte to 0.
That means that if you want a -1 tile that works you have to hex edit manually its control byte if it's different from 0.

The screens came from the US version, but I had to test for all 5 versions to retrieve their respective address.

When you want to search for an offset, just type 30618 (or any other address for that matter) without the 0x

While there is a glitch, that issue was addressed here since this is something that shouldn't happen.

But what you are showing me is something that shouldn't have occurred regardless of the issue I have described above, I tested on a U version to make sure, and the donut lifts worked fine and showed the right colors.
The only way that could have happen is if you recently modified the jyotyu tileset.

Since the jyotyu palette is determined by the bottom background, try to put another background that uses the same jyotyu palette as the stalactite background like the underground one (number 3) for example.
If the same oddity occurs then the fault lies in the jyotyu tileset, but it doesn't really matter if the jyotyu is at cause or not since you can always import a fresh jyotyu tileset from a vanilla ROM to fix the problem.

Well he did say that though.


But I know how to fix the problem :
JLavin I bet when you want to open your ROM with the latest builds you get that window :

And judging by the depiction of the bottom screen in your picture, I can safely assume that you're using one of the 2 SKJmin's hacks as a base ROM, either NSMB3 or NSMBorigins.

Well it's because later builds of NSMBeditor checks for the romGameCode, and if it doesn't recognize those 4 bytes, you'll get that 3 tabs window instead of the 6 tabs one (which is the reason why you get only 3 tabs when you try to open a Chinese NSMB ROM).

The fix:
Open your ROM in a hex editor, and you'll see this:


See the 4 bytes beginning from address 0x0000000c, the ones that form the word NMB3 ? This is the GameCode, and you want to change that :
_if you used NSMB3 as a base, change NBM3 into A2DP (European GameCode for NSMB)
_if you used NSMBorigins as a base, change SKJ3 into A2DE (American GameCode for NSMB)


Of course don't forget to save.
You can close the hex editor now.
Now try to open your ROM with the latest build of NSMBeditor, you should get this now :


And now you gain access to the latest functionalities available
…
Now for your cannon problem, well, let's say I am none the wiser

Everything you need to know is explained nicely here

It still doesn't work… but I managed to patch it anyways.

That's because when you created the patch, you used a base ROM who had its overlay 0 decompressed.
Yes older versions of NSMBeditor will automatically decompress the overlay 0 of a NSMB rom upon opening if it isn't already decompressed ; later versions instead will decompress the overlay 0 only when you open the jyotyu tileset and click save.

That's why I always keep a folder full of NSMB roms who were never opened with NSMBeditor, so that they serve correctly their purpose as base roms.


I said I managed to patch it right ?
_Copy / Paste your clean NSMB rom (we will call it NSMB_original)
_Open your copied NSMB rom (codename : NSMB_source) with an older version of NSMBeditor (personally I used revision 356)
_Fine, now close NSMBe and copy / paste NSMB_source (the copy will be codenamed NSMB_destination)
_Now you can use XDeltaUI and patch the ROM by having NSMB_source as the base ROM and NSMB_destination as the destination ROM.

Now, you can enjoy Mario Bros Super Star

Of course the Fairy-type replace the unused-??? type (well, Curse but yeah )

Actually grid (I have the right to call you like that ?) it's fairly easy to add a functional item, in fact in my test ROM I made for myself the Pixie Plate and for all intents and purposes it works, complete with the ×1.2 boost for Fairy-type moves

The problem lies in the code who tampers with Arceus' type, also the code is not gathered into 1 single subroutine (6 actually IIRC).
I tampered with the code to see if Arceus could stay in ???-form and I managed to do so, that is until I realized that in-battle the game still considers it Normal-type, which means the code to tamper with Arceus' type effectiveness as a defender is somewhere else.

Multitype-code, as it is right now, has no way to handle the case for type 9 (???-type) for the case is inexistent in the code.

Also items like the Plates have what I call an item-effect ID, for the Plates the effect ID are values between 7E and 8D inclusive.
There's 146 of them (from 01 to 92), so you could say if I want to add the Pixie Plate I will copy the code for the [random] Plate and change the effect ID for 93.
And you would be almost right, almost.

There's another problem, the Multitype-code (on top of checking if the Pokémon bearing Multitype is Arceus) will check for the item-effect ID 7E only, and then will add +1 until the 15^th loop (or 16^th I don't remember clearly) which is where the code will abort the operation (meaning the code has found no match thus assumes Arceus as a Normal-type), so it means that the effect ID for the Plates need to be CONSECUTIVE.
Then we will have to change the effect ID between 7E and 8D to values between 93 and A2, of course this means that the Pixie Plate will inherit the effect ID number A3 !

And I have yet to gather the attitude to dare and attempt to modify the code hahah.

I hope I haven't lost you with my explanations

In theory Arceus' idea would work, in practice this get a lot more complicated.

See that would work if when an enemy fall in the lava, it get defeated instantly so it works for example with Goombas, Koopa (Para)Troopas, Spinies, Buzzy Beetles, etc.

But some other foes simply fall through the lava (that is without taking any damage), for example Non-pipe Piranha Plants!

And because of that the sprite 168 doesn't count those enemies as defeated, with the exception of Snailicorns.
By no means this means that those foes are unbeatable, simply that you have to beat them the old fashioned way (Fire flower, Starman).

An alternative would be to K.O. those Fire Piranha Plants with the Bob-Ombs, but alas turns out that while regular/giant Piranha Plants get defeated by those, Fire Piranha Plants don't!


That's as close as you can get without heavily tweaking your level.


Settings:
Sprite 122 instead of sprite 124
Sound set: 37 (55 in decimal)
Sprite sets : 1-1, 5-1, 6-6, 10-3