Dammit… I may very well have lit the nuke that will cause my own end…  



I'm really sorry in advance for the off-topic,  skawo, I know full well that I might get mauled for this.






To  pinet and  Luluca, even though there is no malicious intent behind my action it's very possible you might hate me after this, not counting the fact that I might very well be mistaken, but I have a serious question for both of you:
_are you married with each other?



This would allow me to answer this:

and this:

by saying that if indeed my assertion is correct, then Pinet did say that but most likely just to tease Luluca.




As for why I reached this conclusion:  Luluca and  pinet behaviors toward each other, but I have also other good reasons that I won't communicate for now.

Pull request done on GitHub with the following files/folders waiting for the update:
_Sprite Images
_Resources.resx
_NSMBSprite.cs


Details:



If you don't want to wait for the pull request to be accepted, here is a direct download link:
nsmb-editor-380b.zip

Pull request was updated with the following:

_Added support for Chinese NSMB Rom.
_NSMBe can open .ids files now.
_iQue protection byte will automatically be set to 0 for any NSMB ROM regardless of the region.
_When drawing the sprites in the Level Editor, NSMBe now takes into account the Actor itself rather than the Sprite.




Preview:
Enemy generator:


Lakithunder:


Monty Tank:


Rotation:


Draw Bridge:


Pendulum:




Download link:
nsmb-editor-380b.zip







I can try to get it done by next update, but I'm not making any promises.

Continuing Skawo's saga but in NSMBDS this time:


Also some gems in level designing:



Similarities between 3-1 and 4-3:


Similarities between 5-3 and 8-4:

Pull request updated with the following:
_Conveyor Belts direction highlighted as per  Hiccup request
_Tileset, FG and BG names updated according to  KingYoshi's list


Conveyor belts only display their arrows when Tileset is either 1 (Castle) or 39 (Tower).
The check is done on Tile Numbers rather than Tile Behaviors because the conveyor animations are tied to the former.

Download link:
nsmb-editor-380b.zip

nsmb-editor-380b.zip
I finally completed my end of the bargain.

On top of the previous changes, what this update brings to the table is something else entirely:
_Sprites will take the ActorData from the Actor they are linked to;
_Sprites' names on the level editor will now take into account their respective Actor rather than the Sprite itself;
_Changes to Sprite<>Actor associations in the table located in overlay 0 will be reflected correctly on the Level Editor upon restarting the NSMBe;
_spritedata.xml, while it keeps its name, now holds the data for the Actors themselves rather than the Sprites as it previously did;
_the ids in the spritedata.xml field tags now take ids from 1 to 48 (bit), improved from the previous range of 0 to 11 (nybble).
_last but not least, SpriteData.cs was modified to make the Level Editor capable of reading and writing SpriteData (or rather ActorData now) bit per bit as opposed to nybble per nybble, allowing for far more accurate parameters (as in taking into account modulos when data was read nybble-wise), or even new parameters that couldn't be previously specified, as shown in some examples below:

NEW: Starting direction




NEW: Direction




NEW: Color




NEW: Scrapped width






The only thing left, modifying this page, is up to  Dirbaio now.

I know what happened :
Your zone is actually taking into account the yellow arrow, which the sprite 168 considers an enemy !
To rectify that mistake just shorten the zone by 16 pixels like this :

Challenge MOD

This is a simple tutorial about how to change which area will have Challenge Mode or not.

When you make a level you don't necessarily think about Challenge Mode, but problems arise when it prevents you from finishing the level because it doesn't have the same template as the original level in that slot.

This will come to an end now, here is a simple to understand (I hope) guide.

How to change Challenge Mode values :

Step 1 : Open the NSMB-Editor

Step 2 : Go into Tools/Options Tab and click Decompress ARM9 binary

Step 3 : Go to the Filebrowser and open arm9.bin with the Hex-Editor :

Step 4 : Go to the following offset :


There are 177 (176 in US version) areas in total and each value points to 1 area only, those are in the same order as in the course folder.
As a reminder here is the course folder pattern:


Step 5 : You may want to change a value, this is what each value does :
00 : nothing
01 : Blocks left scrolling
02 : Blocks bottom scrolling

Step 6 : Save

And that's all you have to do to change a Challenge Mode value to one who fits your needs.

Some last minute tips :
_If main area doesn't have Challenge Mode, neither should bonuses areas.
_Bosses rooms and Cannons levels shouldn't have Challenge Mode enabled.

Says the guy who wrote this


and this




Truth be told you had it coming, you can't bite the hand that feed you and expect to get away with it now do you ?

And Dirbaio, nice update here, but there's a little wrench here, now the karma pretty much acts as your "score" kinda, which makes the real score feature seems kind of useless no ?

Yep. Those two levels do have an alternate exit (that lead to W4 and W7 respectively), but they're not secret exits in the strictest sense of the term.

How ?

Instead of a boss battle, try to put a normal flagpole at the end of the level (like you would in a classic level) , it works and will take you to the next world, right ?
Now try to put a red flagpole instead, technically it should lead you to W4 / W7 ? Not really, it will still take you to W3 / W6 !

That's because to trigger the alternate exits in those 2 levels, you have to finish the level while being mini.
So no matter the color of the flagpole, if you finish the level while mini, the game will take you to the secret worlds (4 or 7), otherwise it will take you to the normal worlds (3 or 6).

If you want to get rid of boss battles, keep this information in mind and design your level accordingly ; otherwise players can abuse this to take the alternate exit even though that wasn't the hacker's intent, like in the commemorative hack for the 3 years of NSMBHD where you can finish the level 5-Castle while being mini to gain access to World 7.

If we want to overhaul the DB, we need to set up guidelines to follow.



First and foremost, should sprites be named by their official names or easier-to-understand names?


example: Unagi or Eel.
I admit that I'm a bit of an "official-policy" freak, but I can adapt if needed.
(btw  Freeze actually the sharks are called Hojiro in japanese, not Sushi but that's besides the point)



Should the data be listed in the order they appear or should they be listed by category?


example: for the Star Coin, should we list its attributes like this:

Or should we list them in order:




Value of 0 for things like speed, size, etc.


Speed should only have a default value of 0 only AND only if it means the sprite won't move at all.

Think about it, you set up a sprite and you leave the speed at 0, it means the sprite will stay idle.
In my head a speed of 0 means 0 km.h^-1, it means 0 mph, it means 0 m.s^-2, it means no acceleration, no momentum, no speed, NO MOVEMENT.
If the sprite has even the faintest movement, then it's not idle thus its speed is not equal to 0.
If that's the case, put a default value of 1 in the sprite DB.

What I said for speed also goes for length, size, opacity, etc.
I just can't count anymore the number of times I had to go to the sprite DB and put a value of 1 (or more sometimes) because of that technicality.



Event controllers:


 Freeze, IIRC event controllers always had shitty parameters on the Database.
I mean usage mode: unknown???
Jesus Christopher Christ, it should be "On while trigger ID is on".
On that note:
_Target Event ID should be Output ID (target)
_Triggering Event ID should be Input ID (trigger)





Controversial cases:


Nybble 5 for Sprite 155 (Warp): as you know ticking this will disable sounds when you change area but it works only on emulators, if you try that on a real NDS the game will freeze the moment you go through the Warp.

Should we leave the parameter, knowing it will break on a real NDS?

I always thought that attribute shouldn't be there.
 Hiccup, on the other hand thinks the opposite.
I would like more opinions on this.



Modulos

That's more like a current limitation of NSMBeditor, but I suggest there should be another column called modulo when you edit a sprite.
For example the opacity setting gets applied a modulo 32, so if we type in the hypothetical cell called modulo to value 32, only the values between 0 and 31 can be selected.



Sprites 83 and 84

There's simply too much subtle details for all of them to be taken into account without ending with a huge ass description for said sprites.



Goal / Suggestions


The idea I'm trying to convey is that we should get an idea of the formatting before attempting to update the database.

I'm more than honored that you think highly of me  MarioSunshine, but this not something I (or anyone else for that matter) should do as a lone wolf, that's something that should be decided as a team, for that we could elect a council with some of the most sensible users.
10 users seems good enough, give or take 2.
That pretty much rules out members who mass-modified the sprites just to change ONE lower-case letter to a upper-case letter on the sprite's name *cough*.

Of course  ray and  Freeze your input will definitely be useful here, after all you are the ones who came up with the thread.


I say if a sprite has all its data documented (complete with the models it uses) then it should be locked to prevent any further modification (kinda like the wiki pages).

We should have some people granted with the title of Database Keeper.
It may seem elitist but really database used as mean for information is not something to be tampered with everyday.
I mean once data is documented, usually it's here to stay, no to be changed left and right.

If someone with made a discovery but has not the right to modify the database, it can still put in the modifications but they will saved in a queue instead, waiting for one of the database keeper to approve (or disprove) the modifications, the user will be "credited" for the modification if it get approved though.
That should prevent noobs to modify the database on a whim.



I probably have forgotten some things, feel free to add suggestions if you feel like it

Self-explanatory video

Download : Zoom.zip

Nothing impressive, but it should cover the basics.

The tile with the 84 inside is the tile where the sprite is positioned.
Vertical / horizontal black line is the vertical / horizontal axis (duh).
If width = 0, the leftmost and rightmost tiles will be colored (infinite width).
If height = 0, the topmost and bottommost tiles will be colored (infinite height).
Scrapped width is actually zoom right / 32 rounded down.

Width and height accept values between 0 and 15 included.
Both zoom accept values between 0 and 255 included. Modulo 32 is applied afterwards.

Theoretically if height / width is set to infinite you should be able to activate the zoom from anywhere while you're in the red zone; in practice the zoom will activate only if you are close enough from the sprite (10 tiles max or so while you are in the red zone).
So yes you may need to put multiple zoom sprites if your level layout demands it.


Yes this is an .html file (shame on me), because I can't make a real program for shit

Luckily for you, one of the best synonyms for endless is infinite, turns out that the infinity symbol (∞) is symmetrical in nature, albeit spreads out horizontally rather than vertically.
The lack of vertical spreading can be fixed by filling the remaining space with the planet Earth's symbol, so either the female/planet Venus symbol flipped vertically (♁), or the globe with the equator and a meridian (ⴲ).

Good luck with your hack

Banzai Bill (Class ID 238) has the exact same sprite data as Bullet Bill (Class ID 27).

When SMW meets NSMB !



Thunder (Class ID 97) can only be heard once per view, no matter how many copies of the sprite there are in a single view.


Oh and Classes ID 255 and 256 mean that sprites 169 and 171 are technically not defunct.
In fact they are fully functional as long as their parent, the Spin-Block (sprite 95) is present in next to moderate vicinity.

 Hiccup, you want to fix those:
Raining debris should have Class ID 121 instead of 122.
Unknown camera actor should have Class ID 236 instead of 238.

Also, here have a +1 (surprised the OP didn't get any more +1, you got a GOOD idea here).

EDIT: surprised the OP didn't get any more +1 That's more like it.

An alternative would be to go and grab the NSMB IDA database from  Dirbaio (who have my thanks BTW), this is how I figured and tested most of the data.

______________________

Tempo hacks:

Time to activate the Fast Tempo:

Overlay 0
Data type: Qword
Relevant data: 64 (100)
Full data: 64 00 50 E3 08 00 00 CA*
Offsets:
0×A0BC (US)
0×99E8 (EU)


Actual Fast Tempo value:

Arm9
Data type: Word
Default data: 66 01 (358)
Offsets:
0×57474 (US)
0×473DC (EU)


Secondary Fast Tempo value:

Overlay 0
Data type: Word
Default data: 66 01 (358)
Offsets:
0×A4EC (US)
0×9E18 (EU)


Fast Tempo check on Area load:

Overlay 54
Data type: Word
Default data: 66 01 (358)
Offsets:
0×C644 (US)
0×B954 (EU)

*If the Fast Tempo check is different from the Secondary Fast Tempo value, then the Hurry Up tune will play on level start if the timer is set on 100** or less, not unlike New Super Luigi U.
This is the only reason you want to consider changing the Fast Tempo check at all.
Be warned though that in doing so the Hurry Up tune will play every time the game needs to load an Area (merely changing the View is not enough thankfully).

To circumvent a bit that problem change 64 00 50 E3 08 00 00 CA on Overlay 0 into 64 00 50 E3 08 00 00 1A; changing that lone nybble from C to 1 is enough to change the conditional branching from BGT to BNE.
Now the Hurry Up tune will play only AND only if the timer is at 100 (not 99, 50, 101, 300, whatever… just 100).
It doesn't resolve the problem completely since if you happen to change Areas when the timer is at 100, the Hurry Up tune will play again, but at the very least the problem is scaled down by quite a margin.

**Assuming default settings.

Download link updated in the footer.
Anyone is free to use this ROM Hack as a base.

If somehow you were working on a non-European version of NSMB and still want to use all the modifications done on the code, know that NSMBeditor allows you to extract and replace whole folders, and if you click replace, every destination file within that folder whose name matches that of the source file will get replaced.
This comes handy if you want to export all your work on a European version of NSMB.

Next thing to come from me won't be an ASM Hack but a tutorial on how to learn and master the "Background Sharing Method".

d_2d_W_M_back_jungle2_ncg.bin


This tutorial looks a lot like the one I did for the Bottom Background 36, well this is because the modus operandi is mostly the same.

Step 1 : Open the NSMB-Editor

Step 2 : Go into "ROM File Browser" tab and look at overlay9_0.bin size:

If it's over 200,000 bytes, proceed directly to step 6.
Else if it's only around 120,000 bytes, then :

Step 3 : Go into "Tilesets" tab and open Tileset 0 (Jyotyu) :


Step 4 : Save without modifying anything and close the Tileset tab :

What you just did here is decompressing the overlay9_0.bin so that it's over 200,000 bytes.
For the Chinese version, decompress overlay 0 with an older version of NSMBe (revision b356 for example will do).

Step 5 : Now you can go back to "ROM File Browser".

Step 6 : Open overlay9_0.bin with the Hex editor :


Step 7 : Go to the following offsets and change the values:


The first value refers to the graphics (.ncg), the second to the design (.nsc) and the last one to the palette (.ncl).

Step 8 : Save and Exit the Hex Editor.

Step 9 : Close NSMB-Editor so that the changes are registered and open it again.

Step 10 : Now go to "Backgrounds" tab and open BOTTOM 51 :



By doing this little trick, you just gain one more background to use!

As you are aware, some tilesets load textures from the polygon_unit folder.
Here are listed all the tilesets (sans Jyotyu) along with their Map16 Tile Numbers who link to a texture:



Textures are drawn on a higher layer than the tilesets.
This means that if an object is drawn on one of the Tile Numbers respective to one of the tilesets specified above, it will simply and purely get overwritten by the texture (also this is done behind the scenes, by that I mean that the texture is drawn before the area being loaded fades in).
But this is not bad since that means we don't have to draw those textures in the tileset at all, this allow us to save space on the tileset.


For example look at the vanilla Desert tileset:


By erasing the quicksand from the tileset, you can use 8 more 8×8 tiles.



Tip 1: you can optimize your tilesets (other than Jyotyu and Sub Nohara) by making them 256×144 pixels large instead of the usual 256×112 pixels, but keep in mind that Sub Nohara will be sacrificed in the process for any tileset above 256×112, so do that only if you are sure that you will never need Sub Nohara for the tileset you want to expand.

Tip 2: This is already known but it doesn't hurt to remind everyone about this; use 4 palettes per tileset, there's no reason not to.

As a teaser for the next tutorial, know that tilesets can be made up to 256×208 pixels large, but this requires overlapping into the foreground and into Sub Nohara.

No tileset use 256×144 pixels (or more than 256×112 for that matter) and for good reason actually, you'll see why.


As for resizing the tilesets, then:

_Go into the BG_ncg folder;
_LZ Decompress the tileset you want;
_The filesize should be brought to 28,672 bytes (0×7000);
_Click on Hex Edit;
_Select the last 8,192 bytes (0×2000), the best way to do that is to go to offset 0×5000 and begin the selection from there;
_Copy/Paste until the filesize reaches 36,864 bytes (0×9000);
_Save and exit the Hex Editor, now you can click on LZ Compress and you'll be able to import 256×144 images into the tileset that was modified.




But don't do that until you're absolutely sure that the tileset you're using can afford to sacrifice the Sub Nohara tileset!

This is something that completely escaped my notice until now because the one tileset on which I applied that modification was (of course) the one tileset I didn't need to Sub Nohara to begin with.

But still if you want to try that method, tilesets used only for Castles or Towers for example are a good start since it's unlikely you'll need to use Sub Nohara in conjunction with the aforementioned tilesets.