Not too bad edits (although that mario galaxy one is littered with dots to hell and back), but..
You know you don't need to force trying to begin a topic just to share your stuff, right? by that I mean the "do you think nintendo would actually make these".

You're free to post your content without any need for pretense.

I'll ask for the sake of asking, but.. why are there two discords? what does each of them contain? is server2 just a clone of server1? those are things you may want to specificy.

for your information, depending on how you configure the warp it can cause a crash on actual hardware. emulators ignore the crash, and move along.

you need to figure out how to properly setup warps. I'd recommend you base on warps put in the original levels, as these will not crash.

don't bother getting new hardware to run your ROM. you won't need it.

that's not pixelated, that's corrupted. did you perhaps compress/decompress a file and forget to undo that after editing?

that's the most common route. when in doubt, restore the original files.

you can "leave" the board anytime, but your account and posts stay. the reason for that is because account deletion messes the ID tables and pokes holes in whichever conversation the user participated in.

if you want your problem solved, you need to give as much information as you possibly can. we are not magicians who can guess everything.

firstly, in what way does it "not work" and what edits have you applied to it?

!!!

I'll add that you don't need to be rude and bump dead threads to demand a download.

I'm closing this until further notice.

ah yes, that's definitely what he said.

you aren't going to "find" a multiplayer code. it's not just lying out there up for grabs.
oh by the way, please stop using google translate to make up for your lack of proper english. this hinders communication through frequent mistranslation.

did you replace the music? if not, that means you simply need to replace the sound set (found in the area settings) to something appropriate for the sprites in your level. it needs a bit of a cleanup, but we do have a wiki page that covers the numerous sound sets.

when you don't know what element of your level causes a crash, one thing you can try is making a copy of your level somewhere else and remove sprites 5 by 5 or so until it does not crash anymore. at that point, you've found the culprit.

if the issue has to do with entrances or something else, simply check them once you're done wiping your level clean. no matter how you do it, keep a backup of your level before the wipe.

most likely, something's wrong with your ROM. what NSMBe does when you open a ROM is firstly detect if it's a NSMB ROM via checking the signature in the header (which can be easily modified) and only show the "Level editor" part if it matches that of a NSMB ROM.

What you can do is check if the signature matches yourself.

Open your ROM and navigate to the ROM File Browser tab. From there, click the header.bin file and open it with the "Hex edit" button shown in the screenshot above.


Once that's done, this window will open. Please check whether or not the signature highlighted in the screenshot matches. If it doesn't, please provide us with a screenshot if you can.

The next paragraph may be a bit complex, so do not hesitate to ask if there's something you do not understand.

I recommend that you do not correct the signature within NSMBe if it does not match. Overwriting the header with NSMBe seems to have adverse effects so I'd recommend using an external hex editor for that. Once you've found signature within NSMBe (which in my case is "NEW MARIO...A2DE01") you can search that within the ROM using an external hex editor.

I'll make a more in-depth tutorial on this later, but the gist of this issue is that certain backgrounds have animations attached to them.
These animations are used extensively for world 8 backgrounds to simulate glowing or flowing lava, as seen here.



Here are the rough technical details.
Each background is made out of a small palette of 8x8 tiles (each exactly 8 pixels in width) that are then arranged on a canvas to build the background. Some of these tiles have an animation attached to them which cannot be removed as far as we know. It may be hardcoded, or there may be a reference file for each background. I don't know if anyone looked into this.

Now. When importing backgrounds, NSMBe's algorithm fills the tiles however it pleases in an attempt to output the objective "best result" using the limited tile palette it has to assemble the background. As the palette is tiny, it will merge any tiles that look similar enough in an effort to avoid having near-duplicate and therefore save tiles. It will keep doing this until the palette it needs to build the background is tiny enough to fit into the limited palette the game uses.

NSMBe has no awareness of animated tiles however and makes no effort to avoid using them, which leads to problems as animated tiles end up littered across the resulting background.

In some cases, this can be avoided. For example in the case of the "Volcano 2" TOP background, the animated tiles are situated at the last row of tiles, as highlighted in purple here:



If you reduce the number of tiles necessarily to assemble the background, NSMBe does not need to fill up the entire palette and will leave these tiles blank. Here's an example of a background I modified prior to importing which achieves just that.



Notice how the clouds are very repetitive and how there's only one volcano repeated over and over, as opposed to several of them. This is to save as many tiles as possible in an attempt to free much of the last row of tiles.


Unfortunately, the animated tiles for the Volcano 3 TOP background seem to be located earlier in the palette, thus making it hard to use any of the subsequent tiles using the same method.


You can still use this slot if you can whittle down the required tiles to within the 208 tiles that precede it, but that's a tough task unless you prepare your background optimally.

I advise you use another background slot instead. It's tough since there's a limited amount of them, but you can always use this slot for a simpler background somewhere down the line.

That does not solve the issue that you then have to rearrange the resulting background like a puzzle which can be complicated, and if you don't have free tiles you're going to be missing tiles one way or another.

Oh, I figured you were talking about the tiles from the palette itself, my bad.

To answer your question, yes you can theoretically do that but beware that the way these animated tiles work is particularly wonky due to the amount of hardcoded stuff related to backgrounds and it likely will glitch out if you pair certain top backgrounds with specific bottom backgrounds for some.. reason. All I know is that this wasn't made with flexibility in mind, much less modding.

Foreground bg, background bg, and tileset all influence eachother in some way, this much has been made evident by years of messing with them.

Also, in my testing Volcano 3 seemed to use Volcano 2's animations. You'll have to do your own testing because it might be different for you.

Due to them being incompatible, you cannot hotswap models between both games.

If you wanted to play as Wario, you can download this mod.
Otherwise, you'll have to follow this advanced tutorial to import models in NSMB. Note that if you want to use SM64DS models, you'll have to extract them from that game first or get them from here.

This won't be easy if you're new to ROMhacking, so by all means good luck.

You can use DSBuff to modify the ROM header and icon.
You can also use NSMBe to edit the icon in more detail (banner.bin in the filesystem root).

Note that the title shorthand (S.MARIO64DS for Super Mario 64 DS) is limited to 11 characters long.

You won't need this, but I'll link the header documentation while I'm at it. The header contains a checksum that must be correct otherwise the ROM fails to load.

Their last login was over 1000 days ago (as can be seen on their profile) and the last post in this thread is from 2021. Please check dates prior to posting in order to avoid unnecessarily bumping threads.

Also  Tob if you ever read this, your old password may be reset if you can provide reasonable proof that this was indeed your account. In the meantime, I am closing this thread.

-Threads generate activity. If this can revive the board a little bit (yknow, kind of a "hey we aren't dead" publicity stunt) then I'm all for it.


-Threads are what users see right out of the box, while the wiki is kind of.. tucked into a corner.
(And then brought offsite because it was barely fleshed out at all)

I wouldn't be surprised some people never realized it existed.

Having both the threads and the wiki pages adds some redundancy where each can specialize in an area: threads can be especially beginner-friendly with a lot of padding, while the wiki can be more of a dense, thorough all-purpose reference akin to the Unity documentation if you've ever seen it.

If only the wiki stays up-to-date as it is now, a lot of people will be confused seeing the threads.


-Threads actually notify people and can be replied to. Talk pages are nice, but I never feel compelled to check them. For any given article, nothing tells me ahead of time whether there is anything in a given article's talk page.


-Threads aren't forced to be wiki-shaped. The format can very, some threads will be focused on being newbie-friendly while others will be nerdy with trivial details.


-Acmlmboard nostalgia



There's probably more, but I can't think of anything right now. It's a personal choice I'm sticking with since I'm leading this effort.

(this doesn't mean wiki pages can't be used btw- it just means just that I will be releasing the infobomb packages as threads for the mostpart)

The term "actor" has been in use for a long time by Skawo, MeroMero and the like. I've long internalized that "sprites" are but shells that load the respective actors and "sprite data" is carried over from the "sprite" to the "actor".

In that sense, I don't see what's wrong with the name aside from code consistency.
Personally, I find "sprites" to be more distinct from "objects" (the name used for tiles) which the latest editor still uses. (and also I like the distinction between the container and the actual actor because these two are not necessarily the same in that sprites are but a subset of actors that you can actually place)

Same for tile behavior, it's just a name at the end of the day.


I would do this:



The latter are interchangeable. This is a more classic approach that remains consistent.
Also, be wary of the "my terms are the only correct ones and the rest is bad" because people will call stuff what they want to call them.