Sprite database methodology

I Semantics
    1 Trigger IDs
    2 Target IDs
    3 Comparatives
    4 Upper cases
    5 Common parameters
    6 Official names

II Sprite Data

III Eventual changes


I Semantics

1 Trigger ID:
Trigger ID: A Trigger ID, like its name implies, is a trigger that allows a sprite to take action.
Trigger IDs often acts themselves as checks, that is if the Trigger ID is null, the sprite will simply ignore it.
More often than not sprites happen to have a second Trigger ID, in that case it must also be null for the sprite to ignore it.
In that case Trigger ID on bytes 2-3 is the first one, while Trigger ID on bytes 0-1 is the second one.
Rarely, in cases were the sprite have 2 Trigger IDs, you must call at least Trigger ID 1 to pass the check.
Some sprites have a bit whose sole purpose is to act as the Trigger ID check instead(called Use Trigger ID in the sprite DB); if this bit is active then the sprite will take action only after the Trigger ID has been called, otherwise the Trigger ID is ignored.

There are several categories of Trigger ID besides itself:

Bridge ID: This is a Trigger ID used by Bowser, Dry Bowser and Giant Bowser.
This is the ID the Skull Switch targets to, it triggers the falling animation of the aforementioned bosses.

Starter ID: This is the first Trigger ID called by the Multi-chainer controller.

Finisher ID: This is the last Trigger ID called by the Multi-chainer controller.
Note that Finisher ID must be superior to Starter ID since the Multi-chainer controller increments by +1 each time a Trigger ID is called.

Destroyer ID: A special case of Trigger ID.
While a Trigger ID usually spawn a sprite, a Destroyer ID, as its name implies, will despawn the sprite upon being called.

No matter the category of the Trigger ID, its effects can be reversed by disabling it.


2 Target ID:
Target ID: The Trigger ID's counterpart. A Target ID is a Trigger ID the sprite will set On once it takes action.

Random ID: A special case of Target ID called by the Random output controller to determine which of the 4 Random ID is going to be called.


3 Comparatives:
Bigger, smaller, longer, shorter, slower, faster: those are the likeliest comparatives you'll run into when browsing into the database.
Comparatives are special in that they should be one of the few cases you should use the check box at all.
Example: You see a check box saying: "Load from checkpoint".
At this point you should think: "But wait, what if I don't tick the check box? What'll happen? Where this sprite will load? Will it load at all?"
Whereas if you see a check box saying: "Faster", you'll logically think: "So if I don't tick the check box, I know that this sprite won't be as fast as it could be."


4 Upper cases:
Multiple words beginning with upper cases should be allowed only on sprites that have an official name AND are labeled as such (for example Banzai Bill Blaster where all the words begin with an upper case letter).
Else please… please people, don't abuse upper cases letters for the sprites' names, thank you.


5 Common parameters:
We want consistency, so we want to use these whenever possible:

Loads from: usually as a 'Level start' and 'Midway point' list
Height: if it has more than 2 settings; use a comparative + check box otherwise
Length: if it has more than 2 settings; use a comparative + check box otherwise
Size: if it has more than 2 settings; use a comparative + check box otherwise
Speed: if it has more than 2 settings; use a comparative + check box otherwise
Starting direction:
Starting position:
Direction:
Rotation:
Shift position:
Sticks to a line: as a Yes-No list
Trigger ID:
Target ID:
Zone ID:
Path ID:
Starting node:
Last node behavior:
Use Trigger ID: as a Yes-No list
Use Zone ID: as a Yes-No list
Timer:
Tiles to move:


6 Official names:
Several objects from NSMB got an official name, use them whenever possible.





II Sprite data formulas and calculations

For each Class ID, parameters are listed from the likeliest used parameter to the unlikeliest used parameter.
For the Speed parameter: default speed is often 60 pixels per second.

Sprite 28 (Class ID 35): Self-destruction, if set, happens in 240 frames, or 4 seconds.

Sprite 33 (Class ID 237): Small version bounce up by 6 tiles (11 if Mini). Big version bounce up by 18 tiles (29 if Mini).

Sprite 34 (Class ID 151): The shift position bit, if set, also make the Red Ring respawn if its Area is reloaded.

Sprite 68 (Class ID 161): Length formula is 1+(N₁₁ mod 8).

Sprite 71 (Class ID 165): Length formula is 1+(N₁₁ mod 8). Height formula is 2^{N₈ mod 4}.

Sprite 72 (Class ID 166): Height formula is 2^{N₈ mod 4}.

Sprite 73 (Class ID 169): Max tilting formula is 60/2^{N₈ mod 4}.

Sprite 77 (Class ID 173): Length formula is 2+2×(N₁₁ mod 4).

Sprite 103 (Class ID 79): Size formula is 1+(N₆ mod 4).

Sprite 119 (Class ID 228): Amplitude formula is 11.25×N₅. Oscillation period formula is 1024/N₆.
Starting position formula is:


Sprite 126 (Class ID 230): Maximum angle formula is 11.25×N₇.

Sprite 136 (Class ID 98): Height formula is 2+(N₁₁ mod 8).

Sprite 233 (Class ID 184): Height formula is 4+(N₁₁ mod 8).

Sprite 239 (Class ID 191): Actual movement is N₉-N₁₀. + will go up. - will go down.

Sprite 249 (Class ID 209): Length formula is 4+(N₁₁ mod 4). Height formula is 4+(N₈ mod 4).

Sprite 268 (Class ID 124): Horizontal shifting formula is 2×N₁₀.

Sprite 297 (Class ID 167): Height formula is 2^{N₈ mod 4}.





III Changes proposals

Due to new discoveries, standard goes up and what used to be breathtaking yesterday could be considered sub-par today, such is the side-effect of progress.
With that I mean that it would be nice if the Sprite database was switched to a Class ID database instead.
Since the Sprite is merely a link to the Class ID, the one who holds the real data is the Class ID.
This would allow us to put the data found in this thread most notably.
NSMBeditor would still have to read the Class ID via the Sprite, which can be done by decompressing overlay 0 and reading the 652 bytes (rather 326 words) from:

On the same vein, Sprite sets really are Class ID sets.





IV Notes

The sprite database overhaul was an issue brought up Sep. 6th 2014, and I only put it in motion May 3rd 2015.
I sure took my sweet time, oops…


I already changed most of the data as to satisfy the methodology.
There's still much left, but the DB is getting there.


Data that make the game crash on a real NDS have NO business in the database (with the notable exception of Sprite 274), the reasoning being what point would be achieved to know that putting nybble 11 at 2 on sprite 43 will crash the game for example?

Lel I'm going to set it on 2 anyways *plays on real NDS, play, play, play, playity, play, oh encounters Chain Chomp**crashes the game*. Wow! Amazing! Except for crashing the game, I've made no advancement, geez I wonder why?

See for all intents and purposes data like that should be wiped out the database, it does absolutely nothing for the average players except maybe confusing them.



If anyone as something to say, feel free to do so.

I'm always astonished again how much work you invest in this board or hacking in general o.O That's amazing.
(But there will be some stupid guys which will crash the system again because they don't think about their actions )
_________________________
Super Mario Bros. - The New Worlds | Full release
Super Mario Castle 2 | Full release

My Youtube channel
Best friends forever

As they say: "The best time to do those changes was 20 years ago, but the second best time is now."

The DB overhaul is something that should have been done looooooong ago, but hey at least it's there now.

It just happens to be the week-end, so I said: "Why the hell not?"
And the rest is history.


It would be boring though if everyone was smarter than average… oh wait

Good work with this.

We can still keep defunct values in the description though? I agree they have no practical level design use.

Something like this is OK:
"Value X CRASHES the game. DO NOT USE IT!".

Yeah. As long as its is recorded. I appreciate that it is clutter if it is included with the working parameters.

----

Is this how names should be?:

* Can stay as they are
** Bill Blaster
** Koopa Troopa
** Fire FG effect 2
* Should be changed
** Toad House Block
*** to Toad House block

----

Can we agree to call platforms either "platform" or "lift". I prefer lift.

----

I think we also need to agree on what words we should use to describe sizes.

E.g. should "giant" be used for objects a certain amount taller than Super Mario? And "large" be used for another (smaller) amount?


----

Should Trigger ID flags be labeled as such (e.g. Trigger Flag ID).
As opposed to Phantom Hand IDs, etc.

Actually Block is capitalized in Mario games, so Toad House Block is correct.

But for example Moving Mushroom (sprite 174) should be labeled as Moving mushroom, since AFAIK we don't know its official name.
Or anything that right now has Controller capitalized when it shouldn't (or at least I think so).

___________

Platform actually is the official generic name for nameless platforms (Donut Lift is an example of a named platform).
But since it's a generic name, it should be capitalized (unless it is the first word of course).

___________

For "Giant", "Mega", "Big", "Super", etc. first we should look at the official name, and only if it doesn't have one should we should follow that order: "Big", "Super", "Giant", and last "Mega".
Also those should only be used if a smaller scale version of said object exists.

Examples include: Big Piranha Plant, Giant Spiked Ball, Super Thwomp, Big Dry Bones.


__________

Special flags ID should stay as-is.
For example Phantom Hands ID is not a category of Trigger ID because you can't activate that ID with Sprite 152.

Well... its capitalized as part of an offical name like "Brick Block". But the toad house blocks don't have offical names. I guess if they did - block would be capitalized.


Indeed. Those things don't have offical names.


I don't think they are particully refered to as "platforms" in any game. But they have been referred to as "lifts" (see SM64/DS and NSMBU). And in my experience they are always referred to as "lifts" in the game's files.


Large versions of enemies don't really have official names (only made up names that were written in manuals). But they are called "large/big" "small" "medium" by internal (in-game data) names.

___________

Some questions/ideas based on your recent sprite database edits:
* "Platform moving up & down" - what is wrong with horizontal/y?
* "? Switch" - why did you remove the other stuff? I quite liked the the NSMBW spritedata names
* "Aquatic bubble current" - Can't we keep it simple, by calling it "Water bubble current"?

___________

To sort the problem of object searchability, NSMBe's search feature should be able to search the description and data files. Then you can type in whatever and you will get what you want because it would find the keyword in the description of the actor, tags (which could be a separate field, but can go in description for now) and data filenames.

This way, it doesn't matter so much what the main name is.

___________

New categories might help things. Also, the ability for sprites to go in more than one category.
Category ideas:
* Items and Blocks
* Spawners

I don't totally agree with this.
The sprite list looks more professional if we use the official names,
but I think there are things you shouldn't change,
because it's also important people can easily recognize the sprites with their names.

For example: I think there aren't much people who know what 'Sushi' is.
You can better call it 'Shark' in the sprite list, because then anyone immediately knows which sprite it is.

Those 'Sushis' aren't even famous enemies in the world of Mario.
If you're talking about enemies which appeard in many Mario games, then you can do that.
(For example: Skeleton Bowser --> Dry Bowser)


Another not-very-famous enemy is Crowber, but there it doesn't really matter if you call it with it's official name,
because if you don't know it's name, but you do know that it's a crow, you can search the sprite list for 'crow', and you'll find that sprite too.



I agree with that. I'm also wondering, why these name changes?

Rotating Bullet Bill Cannon--> Bill Blaster Turret
Spinning Spike Ball --> Ball 'N' Chain

This sort of thing is exactly why NSMBe's search function needs to be able to search descriptions.

Okay, then we will go with a lower case block.



I already put Arrow Lift for the sprite 187, maybe keeping lift for consistency wouldn't be so bad.



Out of my 4 examples, this is only true for the Giant Spiked Ball.
Big Piranha Plant, Super Thwomp, and Big Dry Bones are sanctioned names by Nintendo (courtesy of Mario Wiki).



*Well, answer me this: how many sentences beginning with 'Vertically' and 'Horizontally' do you know?
That's why I changed them, but 'Lift moving horizontally' do sound good (unlike Horizontally moving lift).

* ? Switch is the official name (yeah I'm annoying you can say it )

* I think Aquatic accords itself with current much better than Water do, but that's just me.




Good thinking you got there.



Is there any other category you have in mind?



Fair enough, but for easily forgotten enemies you can call them like this for example: "Crowber (crow)" or "Sushi (shark)".
Which is what is already done for some sprites.



Ball 'N' Chain is the official name (yeah, once I say 'official name' enough times, everyone can send me their hate letters, but first let me finish the database).
Bill Blaster Turret is as close as an official name we can get, and the term was coined there:

This is a video from the official British New Super Mario Bros. U Channel, which in turn is an official Nintendo channel.

I'm going to quote the whole description of the video:
Enter the hidden room where the Star Coin is located. Keep performing wall jumps and stomping the Bullet Bills being shot out from the Bill Blaster Turret for a chance at consecutive 1-Ups!

IMHO, I'd at least change that to "Bullet Bill Blaster Turret" for the sake of easy searches.

We really shouldn't use MarioWiki for a source. They often use bad sources like Prima guides (Prima often make up names), even though their rules say in-game names are the "most official".

----

I think we should go with MarioWiki's policy on this. Nintendo's YouTube channels aren't run by the game devs, but the games are. The bullet bill launchers are called "Bill Blasters" in-game in English-language Paper Mario.

----

I agree with adding extra words to titles for searchability, until NSMBe's/database's search tool can search descriptions.

----

@Sharks
I agree with your that "Platform moving up and down" sounds nicer than "Horizontally moving platform". But I think they are both grammatically correct.

To continue my obsession with internal names, NSMBU's actor names seem to be sentences like that, but that may just be because of the fact they are in Japanese.

----
Do you (addressing anybody reading this ) think that the data fields are needed, if we finish off the file list?

----

Another category idea:
* Sub-actors (stuff like Snow Spike snowball, Flame Chomp fire

Yet at the same time I wouldn't totally ditch them either, they do provide in-game use evidence for Big Piranha Plant and Big Dry Bones for example.
And in cases like the Blockhopper, they do have a [citation needed] tag, which mean that the name is officious at best, but by no means official.

Also no one ever objected the idea that the classic Bullet Bill launcher was called Bill Blaster (when it is de facto its official name).
We were talking about the Bullet Bill rotative cannon (Sprite 241), just to clear any misunderstanding.

Out of curiosity what sources do you deem official/as close as official as you can get (discounting Nintendo obviously)?


I'm fine with it, but only as a patch-up solution, once NSMBe search tool will be improved (if another version is ever released) the extra words will be erased.



If anything you should do a topic to list all the data files instead, that way we won't get as many questions about which folder to search for Tweedledee and Tweedledum.



While I agree wholeheartedly, we can't do much for now except being sitting ducks as first we need this to be implemented:

My stance on official names is pretty much the same as MarioWiki's, maybe with some differences though.

----

I guess if we are going to work on files, we should do it via the file list, so we can finish everything off, not just the files used by sprites.

So, I've been using the db with changes, and I have a question about a couple things.

1) Why is the "Mirrored" option on Signboard a list now? Was a checkbox and it seems like it should be that.
2) What about things that say "See NSMBW's sprite data" on them? Like, say, Autoscroller's "Last node behaviour"

1) Dunno. I've changed it. (Sharks may disagree though)
2) I dunno what I was doing when I wrote that. I didn't actually test any of it, and I didn't even get the write nybble. Unfortunately I can't find any nybbles that make the auto-scroll go back, but I may be looking in the wrong way. I've fixed the sprite data.

Well, why did you switch 1)? Makes no sense this way.

*Sees a checkbox for a parameter called Mirrored*
*Train of thought: if I tick the box it will mirror the image, if I don't tick the tickbox then it won't change the image and it implies that it exists already*

…
…
Touché

It would be the same thing for a hypothetical parameter called Wingless for example, if you don't tick the box it pretty much implies the item in question has wings to begin with.

Also, say, for star coin (and possibly others), the "Shift by" was made into a list. Wouldn't two checkboxes:

Shift right 8px
Shift down 8px

make more sense? Ticking both would get you the third effect from the list, ie. both right and down. Unless, uh, NSMBe isn't coded to do that.