You are right, it will not accept nybble 0, or possibly entering 0-1.

Oh, and I am going to update all activation IDs. I think they should be called input/output IDs instead. After all that is how the game sees the data. So instead of activator and source, I think input/output makes more sense, and is more user friendly for new users.

Okay. The "nybble 0" bug is fixed. Damn PHP arrays.

I'd name them "Input Event ID" and "Output Event ID" instead, though. because "ID" just means "Number"...
And maybe explain it further in the comments field "This Event ID will be activated when the switch is hit" or somehting like that

Wait, I don't think I've ever understood this ID thing. So let's say we have sprites A and B. And let's say that both have Triggering Event IDs and Target Event IDs. So, let's also say that Sprite A has a Target Event ID of 1, and Sprite B has a Triggering Event ID of 1. So, if Sprite A's activated, it will trigger Sprite B to do something, right?

And, if that's the case, is Output ID the same as Target Event ID, and Triggering Event ID the same as Input ID?

I think "event" is redundant. It will always be an event.


And as for the "target", "triggering", and the countless other names we have had in the past, I think having a consistent naming system that is simplified would be best.

Only one quick explanation needed now.

Input ID = the Sprite you are editing will be receiving an input from something else.
Output ID = the Sprite you are editing will be send out and ID to another sprite.

Easy, and as simplified as possible. All sprites can be named like this, and there is never a question of what is meant.

Cool, then. But please keep "Event" even if it's redundant. Maybe it seems obvious to us, but not to a new NSMB hacker.

I think the most important thing is to make the descriptions;

1. Clear
2. Simplified
3. Consistent
4. Descriptive

The way I changed the descriptions to "input/output" does just that. Picture the sprite data box next to the editor map. Short ans sweet is key here. Saying event, I would like to request again is completely redundant. When would it not be an event? I know you are used to calling it that, or reading that. But to a new person, an input/output system is a lot more direct and clear, than an event. There is no event if you think about it. There is one sprite outputting an ID number to another sprite which receives the input data. Just like a network works. There is no "event", only data transfer.

Any new users should know how the sprite really works, after all the better they understand what is going on, the less questions and guesswork will be there when the 5.2 release comes out. And, don't forget, we will not be dealing with dumb people here for the serious users. You all know, in order to make a successful hack, you have to have computer knowledge and skills to begin with. Anyone attempting a hack will know what I/O function is on some level.

Again, I would really like to plead this case. I have spent a week trying to think of the most simple and best way to clean these up. They have been a mess for a long time. And please try not to make a decision based on how things used to be, and more on what is most obvious.^ My thoughts are based on the 4 rules above.


edit... I can add event back in if you guys all decide. I will be doing a lot of database work on the activators. But can we try this system for a couple days.

hmmmoookay.

Whatever you want. You have some good points

These are all just suggestions. I am updating the database to be as user-friendly as possible. The sprites are getting a lot more consistent. But if anyone has any input, please add it. Or if anyone wants to help identify and label functions, maybe well can fill in all or most data.

Is it possible to make a view, path, and zone database that can be edited? I have a lot of ways to match them to sprite info that would help.

Uhm, how?
View/path/zone database? But what data would we store there?

Or you mean some extra field types such as "Zone ID" or "Path ID" so that the editor somehow asks the user to select a zone/path/view? Hmm, yes, that could be really interesting :9

Yep. Still, there are only 6 unknowns, so making a database for just 6 things will be overkill

I was thinking of updating the existing ones so they match the sprites better. Or describe things better.

Like I still haven't figured out what the view bottom offset etc. really mean. They don't make sense with the descriptions. But if we can test and edit them to make more sense, it will be more user friendly. So a database that we can edit and update just like sprites.

The database is basically a user update-able way to make editor revisions. Otherwise, I wouldn't know how to code to improve the editor.

Oh and almost forgot, the different settings for the backgrounds. Scrolling speeds, movement, etc. With trial and error I think I can find out the hex changes. But, I would not be able to put it into the editor. Or, there is no way for people to select it like a sprite edit. I think there should be a background editor just like the sprite, object, entrance tabs. Instead of editing through the configuration screen only. Maybe just behaviors in the map editor.

Yes, that's something I have thought of too. Move the Level Config panel to the level editor itself. I've never liked how it creates a separate dialog. Plus, you can easily "loose" it behind other windows

the "View bottom offset" and similar settings control how exactly the camera scrolls vertically in relation to Mario. I dont remember exactly how, but the main idea is that the camera keeps Mario vertically in a defined region in the screen. If then Mario goes out of it, the camera will scroll to keep it in view.

These settings allow you to offset vertically the region limits.
the "Special" set of settings applies in special Mario actions like jumping up a rotating springboard, or climbing a vine/fence.

If you can come up with a better name for these settings so that it still fits in the editor panel then it would be great
But I'm afraid it still requires additional explanation