ATTN: SMILE 2.5, SMILE Fork Projects

[Kazuto]

I've been away from the scene for awhile, so since I'm not sure how many people are working on their own forks of SMILE, I thought I'd post this as a general mention.

There's a few errors in SMILE's default level_entries.txt file that can corrupt, at best, two major rooms in the game, and at worst, literally dozens of other rooms.  They also prevent editing a large-sized, but not necessarily important, room in Norfair.  Because of the erroneous entries, it's possible for a user to corrupt rooms through normal usage of SMILE.  I verified this in SMILE 2.5, but I also saw the error in level_entries.txt for the latest SMILE RF, at the least.

The error lies in the fact that SMILE uses the next level entry data as sizing information for the current room.  So, let's take a look at the level_entries.txt file.  If you scroll down a bit, you'll see the following lines:

Code Select Expand

24C30D
24C428
24C706
220322
221D2E
221EAE
222720
2229AC
225187
2253EE
225883
22614E
22658C
2266A5
22694E
226A8F
2270A1
24DB52
24E6AE
24E809

Notice how the entry numbers jumped from 24C706 to 220322?  This is the first error.  Because of this, room 7B6EE, the giant stone head in Norfair, displays a negative number for its available size, preventing you from editing it.  Further below, it jumps from 2270A1 to 24DB52, incorrectly reporting 158385 bytes available for room 7CE40, the Gravity Suit room.

Further up in level_entries.txt exists the other overflow error, which looks harmless enough in its normal context: 220232 followed by 2271CE.  This incorrectly reports 28572 bytes available for room 79A90, the Chozo statue with the Missile expansion in Crateria with the weird eye scanner in its default state.

Both of these rooms are small rooms, but these errors allow them to be resized to be enormous.  An unwary user could easily corrupt a large portion of their game and have no idea what happened.

Fortunately, there's an easy fix to make SMILE correctly recognize the room sizes.  Simply cut the section starting at 220322 and ending at 2270A1, and paste it between the entries 220232 and 2271CE.  You'll notice the entries are now in correct sequential order, as they should be.  The three rooms reporting erroneous byte sizes will now display their correct sizes.

Edit: I wasn't allowed to post Code in my first post.  Hmm...

[JAM]

This patch will help you. Started by Scyzer, finished by me.