Maybe you could eventually create an options panel for NSMBe and have a checkbox whether to do this or not.
There's lots of misc settings that would be nice to be put into an options panel. Maybe you could store these settings in "settings.ini" in the same directory as NSMBe.

Or, you probably don't want to change this. Because, if you accidentally change the sprite and you forgot to copy the data, then you would have lost it and would have to figure out the data again, which is kind of a hassle. It's easy enough to just select the data and put in a whole bunch of 0's to reset it.

Or, you could have a button to reset it to all 0's.

The problem is that it is a lot more likely that incorrect data gets transferred into the new sprite. Copying the same sprite would keep the data. It is when a new sprite is selected that it gets reset to zeros. That is what I was suggesting.

Check all your hacks and you will find a lot of this unwanted data. There was a lot in mine. Especially when a value with 2 nybbles is copied into a new sprite with only one. The copy paste also does not make corrections for the nybble issue. And when you select the text box in the new sprite, it will only change the value of the new sprite, it will not correct wrong data coming from the old. So when you look in your hacks, I am sure with all the new data that has been added to the sprite DB, you will see things that you did not want selected.

So by default, the data would not copy unless you are copying the same sprite. IMO this makes the most sense. I am positive a lot of errors are caused by the current copy/paste method. And they go unnoticed because you cannot see it in the text boxes above.

So when you are making multiple sprites that are the same, the time saving feature is there. And when you make a new sprite, no unwanted or error causing data gets transferred.

Umm when you create a new sprite, the data is all 0s.

I don't understand what you mean by the copy/paste errors.

And to save time, we could just put in the button that resets sprite data to all 0's for that sprite and have the data be copied over when you copy that sprite and change the sprite type.

Hitting control/click is the copy and paste method. When you click and drag the new sprite over.

But this is the problem, transferring the data by default. The point is that you do not want that incorrect data transferred. A lot of time is lost tracing bugs that were a result of this bad data. Especially for people just learning the editor. Or even people that have been using it for a while. Again, I recommend that everybody checks their hacks to remove all of this data. Not only does it create wrong data, but it also can change data when either 1 or 2 nybble values are used between sprites.

And, I wonder how many people have tried to use sprites and couldn't get them working right. Then just gave up and used something else. When the whole time this problem was the reason.

And finally, how many sprites share data that copy and pasting will be a help anyway? Other than data between the same sprite, I can't think of any times where this does work right. This has changed with all the new data added to the database.

I wouldn't make the sprite data reset when you change the sprite type.

Mostly because if you change it accidentally and then switch it back, the sprite data will be erased without being noticed. It'd be very very confusing.

Yeah. That's a nice idea

A small button with a red X next to the sprite data. Nothing else.

That would be helpful, but keep in mind there will still be the unwanted data transferring, that will make sprites not work right, unless people know to hit erase, no how to use the hex data. Otherwise, there will be errors and issues arising from the extra data, and settings wrong in the newly copied sprites.

I think the time you guys are thinking will be 10 fold because of people not knowing why things aren't working. And when you go to edit the new sprite, it will not correct itself by using the description drop down boxes above. The only way to repair the new sprite is to know the correct data and exactly what nybbles it uses. This excludes 90% of people that will use the editor. Even the experienced ones.

For instance, and this is only one of the big issues, when one sprite uses a 2 nybble value. The data gets transferred to a sprite that uses only 1 nybble. You cannot use the drop down boxes to repair it. The boxes can change only one nybble.

It would be a lot more confusing not knowing why your sprite doesn't work, IMO. And makes no sense to be copying to another sprite with incompatible data.

You will know right away that you changed sprites and the data is new...You may never know the data copied and pasted was wrong. Or why the sprite doesn't work. You can't look to the descriptions...how will they know?

Thats the thing though. You wouldn't be erasing data. There is no reason to copy from one sprite and then change to another unless you just need a new sprite. The data does not match between them. This is a bad practice in the first place. The switching to another sprite and then back again wouldn't happen unless you go back and forth between the sprite menu. At this point why bother copy and pasting? There is no time savings there and perpetuates a bad practice that shouldn't be done.

It doesn't make sense at all to keep the data unless you are duplicating another one of the same sprite. They don't match.

And in your example you can see the expalantion of the data in the sprite boxes. You will see nothing is selected. But you cannot see copying to another sprite and its data.

With all the new data I and others have added recently here...I still say check one of your old hacks or current whatever. And look to see how big of a problem this is. Also copy and paste sprites that are different with nybble pairs. They really get screwed up in the copying. I'm telling...just look at the older hack before this data was known.

Well its your call, I can show you more detail of what happens and the negative effects if need be. Otherwise, I guess people will have to compensate other ways...

Yea, but I'm saying, what if the user accidentaly changes the sprite number, and then changes it back?
The sprite data will be gone. Without the user knowing.

Please don't let the Sprite Data go, when changing the Sprite.
This would just be plain awful.

They would know, because this is what should happen by default. This doesn't make sense. Why copy and paste incompatible data? It takes two seconds to look back at the data and re-enter if this rare situation happens. But, with the current copy and paste, users are guaranteed to have bad data 90% of the time that can corrupt sprites, make things not work properly etc.

You cannot fix this wrong data. The description boxes will not fix it or see it at all. The only way to know it is wrong, or why your sprite didn't work right, or if there are conflicts is to go through the sprite database to compare all of the data between the sprite you had at first, and then the new one. Remember the descriptions don't say which nybble is which, or which is 1 or 2 nybble.

This is a HUGE editor flaw...I know you guys don't see it yet because you haven't looked with all the new data. That is all I have been doing the last few weeks. I am telling you it is very common, and a major problem. I can give many examples where this corrupts things...Input IDs, start stops, etc, etc. Lengths.

Here is another major problem...If you try and correct the data in the description it changes to an even worse situation because of the above mentioned.

Lui, and Dirbaio, I encourage you to look back at your hacks...See for yourself all the incorrect and unecessary data that is there.

Maybe you add a checkbox to enable copying data...not as default, with a big warning saying this can corrupt your sprites and levels.



Please, explain because I do not see the counter argument here....You select one sprite, want to copy to a different sprite...Where the data does not match??? Then you have to repair the new sprite you picked with the hex edit, not the descriptions...and go to the database to make sure there is no additional data that did not get fixed.

If you guys want to check it on the IRC, I can walk you through a lot of situations where the current system is VERY bad.

Once you actually see in effect what I am talking about, you are going to do a complete 180°.

Look I know how to fix the data..now after editing so much of the database. But no new users will be able to figure this out, and nobody that has been using the editor has up to now, or else you all would be chiming in about what a big problem this is.

This bug will always corrupt data for one of the biggest features of the game. The sprite system. I think this is one big reason why a lot of the activator data I found was found, because I did it with manual (correct) hex edit. If it were for the current copy and paste, the data may never have been found.

No.

The problem is that users won't know the sprite data has been changed. Users expect that selecting a new sprite number from the sprite list will just change the sprite number, and nothing else.

Erasing the sprite data is a destructive change.

Destructive changes shouldn't be performed in one of these situations:
1: The user doesn't get warned BEFORE the action that the destruction is going to happen
2: The user doesn't notice the destruction is done after triggering it.

This feature would break BOTH RULES.
It'd be really confusing.

It's not that difficult to type all 0's in the sprite data raw box.
And if it is, then the user will still see the fields for the new sprite with weird data, and he can correct it.

For these reasons, this is not going to be implemented.
And enough discussion out of this.