 |
I. Advice for editting techniques
Testing
SMILE doesn't always work exactly as you may think it does or want it do. I encourage extensive testing of rooms while/after you're building them using a savestate with most suit upgrades collected so its easier to test. When in doubt about something, always try to test it. You don't want to spend a large amount of time building a room only to find that it doesn't work because of some minor glitch that could've been avoided.
Backups
Random (or not-so-random) errors can sometimes creep up on you while editting in SMILE. Even during normal level editting and not just while making risky edits, you should be backing up every time you accomplish something you deem significant. During what can be deemed risky editting, such as room expansion, where you know errors are likely to occur, it's best to be making even more frequent backups of your work. Also keep a few backups for long term archival purposes in case you run into an error you missed a few days ago and it's such a critical error that you can't work around it.
Obviously, the easiest way to backup your work is just to make a copy of the ROM after you've saved your changes. SMILE also has a backup system, but it has its own quirks for you to learn. If you haven't figured out how it works, it's best to rely on manual backups, which are more simple to understand, although they take up more space.
This entire FAQ should be viewed in the context of this advice. Before changing anything that seems risky or changing anything for the first time, always make a backup so your work is not lost.
Specific help
Jathys' IRC channel (#jzd on irc.esper.net) has quite a few SM hacking experts hanging around most of the time. If you have a particularly puzzling question that isn't covered in this FAQ, it's possible one of them knows the answer.
II. Door-related editting
How to edit doors
Shift+Rightclick on the back of "Door A" and select clone door (or hit hotkey C when moused over a door), then enter a name. Then go find whatever door you want to link it to, for example "Door B", clone that door, then go back to Door A and shift+rightclick it again and select "Edit door." Select whatever you named the clone of Door B and then click 'transfer properties' and 'remember'. Then save the room you did this in. Then go to Door B and repeat that process only give it Door A's information. Then save that room as well.
Important: If your door is going to transverse areas, like from Crateria to Brinstar, you need to manually set the "bitflag" to 40. If you don't do this, the map will get screwed up. Leave the mouse over the second "field" in the door editor and you'll see that field is the bitflag. It's usually 00.
Important: Doors are tied to a specific door # in the door editor. If you delete a door with a harder to find #, you may run into problems. Don't delete doors carelessly.
You don't have to worry about the color of doors - as the portion of the door that gives it its color is merely a door cap - a PLM that can be easily dragged and placed on different doors to your liking, as long as the room has PLMs in it.
Some rooms will not accept ceiling or floor doors. These are typically rooms with no scroll blocks. There is also a difference between green and blue scroll blocks with regard to how they interact with ceiling or floor doors. If you're getting an error while going through one, try changing the scroll near it from green or blue or visa versa. Floordoors seem to have an affinity for blue scroll areas and ceilingdoors have an affinity for green. However, this is not always the case, in some rooms its reversed or they won't work at all. Don't plan out door positions without testing to see if they work with regards to ceiling or floor doors, as they are more finicky than left/right doors.
Also, while elevators work similar to door transitions and some people have taken the time to figure out how to edit them correctly previously, it's not recommended that you try to edit them in SMILE yet. Even Jathys notes that elevator editting is pretty buggy and doesn't always work as you think it should.
How to add doors to a room (for SMILE 1.23 but will work with 1.32 with one caveat)
Warning: This is sort of advanced, since you'll need to use a hex editor and have some knowledge of hex to do it. If you don't, it's best you not attempt this until you learn more, as editting raw code in the game can cause big problems. Always make backups if you're unsure of what you're doing.
First copy/paste the code for a full, working door from the $83 bank. (example: 19 DC 00 04 01 06 00 00 00 80 00 00). Go to the end of the $83 bank where there's some free space. Copypaste the full, working door code X times into the free space (perhaps each on a different line for comprehensibility purposes), where X is how many doors you want to add to said room. Note where each iteration of the door code begins, reverse the addresses and write the addresses down without the 83 part - it's assumed by the game when dealing with doors. Each address should look something like this: AA 20. (Note that this would actually be read as the address 83 20 AA, but as I mentioned, the 83 is assumed and thus removed, and it's reversed to become AA 20.) You should have one of these addresses for each door you copy pasted into the code. Then go to the end of bank $8F where there's more free space. Put each address in that free space - all in the same line. So they'll look something like this: AA 20 AA 30 AA 40 AA 50. That's, for example, if you have 4 doors. Now add some garbage data (try simply 01 01) after those numbers so SMILE recognizes that the door data ends there. Now note the address where this group of pointers begin, without the 8F indicating the bank; the game assumes this as well. It should be something like this: E0 FF. Now open SMILE and go to Edit > Pointers for the room you want these doors to be located in. For the doorout pointer, enter the address where those pointers began (my example was E0 FF). SMILE will probably crash. Now, reopen it and go to that room again and check the doorout pointer. It should still be what you changed it to. Now check the door editor; there should be as many doors recognized there by SMILE as you copypasted in.
Another thing you should do for the first few times you complete this process is, after you've altered the base door data for that room using SMILE to your liking (through cloning and connecting them to where you want them to go and such), reopen the location the data is stored at in bank 83 in the hex editor and make sure that the data has been changed accordingly for that room. This helps you to confirm that SMILE really is saving the data where you want it to and not somewhere else in the rom as a result of incorrect or unreversed door data pointers. If you note that this data has changed since you copy/pasted it in, then you'll be able to be fairly certain that SMILE is saving the data there and not somewhere else.
Edit: This can be done in a few less steps in SMILE 1.32, but the basic process is the same. One major difference is that SMILE will no longer crash when changing the door out pointer. Also, the one caveat is that now SMILE will ask you whether you want to clear out old data and move that data to the new doorout pointer location. To be safe, select "no" when adding doors this way.
The screenshot below should help visualize what this data should look like when finished. The door data itself resides in bank 83 in the top screenshot (each in a new row), and the pointers leading to that data reside in bank 8F which is shown in the bottom screenshot. The doorout pointer then points to these pointers in bank 8F. The doorout pointer for the set of doors emphasized in this screenshot would be E9D0. Note that the way both the door and pointer data is organized in the screenshots is how I recommend doing it. Putting each in a new row makes it easier to understand the data if you need to come back to it later and there's plenty of empty space at the end of the 83 and 8F banks for a format like this despite the fact that it uses up a bit more space than a compact format like the one the game uses.
III. PLM-related editting
How to put an item in a specific room
Any item such as a missile, a super missile, etc. can be turned into any other item by rightclicking on it, selecting type and then changing the values in the lefthand box (you'll see the item pic change.) One thing though: The index is important for the game to remember which items you've picked up, so the index number needs to be unique.
In fact, all items are classified as "PLMs" in SM. Thus, changing PLMs is the same, and you can change anything else classified as a PLM into an item and vise versa.
PLMs are basically items, gates, doorcaps, and other little weird things hanging around in Super Metroid. Rightclick on a PLM and scroll through the list of numbers to change one PLM to another. Like even the "S" Icons and "Arrow" PLMs can be changed into a Charge Beam or something. You just need a unique Index number for items and doors. Try to find an item in a different room you know you won't use, move it out of reach, and use its index for your new item. Door caps and items use different indexes though, so a door cap with say, index "03" can't be removed to allow you to add an item with the index "03."
Scroll PLMs (the "S" icons you see in levels)
These
load extra scroll data that allows you to activate scrolling within
SOME red scroll blocks when Samus touches the "S" icon. However,
without messing with some hex and such, its basically only the red
blocks that you see them sitting around in the regular game. The
"arrows" extending off from the "S" icons merely extend that icon's
reach to any of the arrows. As mentioned earlier, these are PLMs and
can be transformed into items and other stuff you might need.
Gates
Gates
are those little one-way (or multiple way if they're Blue and you have
the wavebeam) pillars that obstruct your way occasionally. They're
composed of 2 PLMs. The pillar itself - which has an index of 00 and an
unknown of 80 - and the shotbubble, whose unknown is 00 and its index
is a bit more variable depending on what color you want it. For
example, a green left-facing shotbubble has an index of 08. Blue
shotbubbles are either 00 or 02 depending on which way you want them to
face. There are a couple different gate options which you can grab from
gates sitting around within the original game.
IV. Specific SMILE functions
How to alter when a room goes into another state (Edit>State Properties)
You can change under what conditions a room goes into another state. When you're in the second state (or third/fourth state depending on which you want to alter the conditions for), go to state properties. There will be a drop down box with many different options, such as "zebes alive," etc. Using these, you can alter what conditions will cause that state to load. If you go to that option while the default state is up though, it'll just say there are no values to alter.
How to move rooms on the map (Tools>Map Editor)
In SMILE v.1.23 and below, 'Move Room X/Y' moves the location of the room. In SMILE v1.32 and above, you have to use the hotkey "m" to move rooms to the position on the map that your cursor is currently over. You can copypaste the tiles SMILE shows below the map picture around to design the map.
Edit>FX1
This can change whether theres water, acid, lava, etc. in the room. (You have to experiment with the "surface numbers" under it to get it to whatever level you want.) The A/B section under that has a lot of stuff on animating spike tiles, changing bg effects like the waterfall effects in Maridia, etc. Warning: If the boxes are red, don't edit this, as it's disabled in that room, because the game doesn't have space for it.
Preferences>View>Options>Show Scroll Areas
This allows you to see the scroll blocks. You should have this on most of the time. (The default is off I think, and I don't get why as this is important.)
View>Tile Size>8x8 Scroll Editor
This lets you edit scroll info. Blue has basically full scroll capability, green has full scroll capability, and a red block means the "camera" will not scroll within that block. (Thus you dont want to have the player move through these red blocks. They're mostly for hiding stuff.) Green and blue scrolls will react differently to floor doors/ceiling doors and green scrolls tend to show tiles all the way to the "bottom" and "top" of the room, while blue ones tend to hide the bottom 2 lines of tiles in a room.
How to Edit Layer2 Backgrounds (Preferences>View>Layer 1)
Hitting this button will turn off the Layer 1 (foreground data) in SMILE and thus allow you to edit the layer 2 data beneath it. Useful for editting those pesky Maridian rooms.
Edit>Room Properties
The height and width will change the height and width of the room.
Warning: Changing width (expanding horizontally) will screw up the current tile configuration of the room and you'll have to redo it. Changing the height will only add a bunch of garbage below the normal room though, so you can clear that space out and use it.
Warning: When expanding rooms horizontally, you will find that it kills some of the tile formations you may need. For example, since the only way to get doors of specific numbers is to copypaste other doors of the same number, you may screw up your room if you destroy the doors in it. Thus, what you should do is to copypaste every door in your room near each other into a small clump (but keep them fully formed and normal) so they're next to each other, then copy this and keep it in SMILE's memory while you do the expansion. Then you can expand the room horizontally and after that, copypaste the doors back in and place them back where you need them.
If the room has scroll blocks, you have to use the Scroll editor to assign the space you just added green, red, or blue blocks.
Warning: There are limits to how big you can make a room. Namely, the tile data limit for that specific room and the scroll data limit. If you try to make it too much bigger than normal, you can cause errors, so don't push it. Especially with the scroll data (through the scroll editor). If you add too many scroll blocks, you may get rooms after the one you're editting being "eaten" and thus totally destroyed, which you definitely don't want. Thus, don't expand rooms too much beyond their normal capacity unless you know what you're doing. Especially important is backing up the game before expanding rooms too much - to test how large you can safely get them.
One saving grace about the SM engine is, it interprets no scrolls on a particular block as a green scroll - so you can have rooms that have no scroll blocks through part of them and still have the room work in most cases.
Edit>Special>Layer 2>Add
You can add a layer 2 background to a room that doesn't currently have one using this function. Note that most rooms that use layer 2 backgrounds don't have a BG_Data pointer - and you'll want to remove that pointer if there currently is BG data assigned to that room since it will conflict with the new layer 2 background you added. Other things to check are the layer1_2 pointer (this sometimes conflicts with the type of tiles you're using for the layer2 bg; if you run into any problems, try to find a layer1_2 pointer from a room with the same tileset as the one you're currently making), the FX2 pointer (should be 0000 unless the room has special effects), and the layer2scroll (c1c1 is a safe bet for looking good).
Edit>Special>Layer 2>Remove
Some rooms have "built in" Layer 2 backgrounds, most notably a lot of Maridian rooms. You can remove these by using this function, but backup before doing so in case it turns out you didn't want to remove it.
Edit>Special>Game Behavior
You can change some random stuff here, from the Ceres Timer to how heavy Samus is in water, lava and such. A note: watch out for the "Red Powerbomb" checkbox. It will cause palette errors when loading from a save and with Ceres Ridley's room.
Edit>Special>Enemy/PLM +/-
You can add PLMs and enemies to rooms using this script if you absolutely have to, but I wouldn't use this function unless absolutely needed. It seems very buggy, and it can erase portions of surrounding data in order to make room for its additions. This is because it sometimes changes PLMs and enemies in surrounding rooms to make space. If you do use it, extensive testing and looking around for errors in surrounding rooms is recommended. You're better off using already existing PLMs and changing them to suit what you need unless you really know what you're doing.
Warning:
This script assumes that when you're adding enemies/PLMs with it,
you're repointing your PLM/Enemy data to have free space after those
entries. Do not add enemies/PLMs unless you've repointed the Enemy/PLM
pointers.
When adding enemies, you need to repoint the enemy population and enemy set pointers for the room to free space at the end of the enemy bank before you use this or it will end up overwriting data nearby in the rom. When adding PLMs, you need to move the PLM pointer for the room to free space at the end of its respective bank (8F in this case). Even doing this, you're limited by how much free space you've alotted yourself. Watch the positions in a hex editor and see when you're close to adding too much, because SMILE can and WILL overwrite other data with you use this feature.
Edit>Pointers
Important for an extensive hack.
Level Data - expand the rom, and repoint this to free space and edit the level_entries.txt file with the start and end point of the level data for a room and you can greatly increase your tiledata allowance. Note that if you repoint this, SMILE will save over WHATEVER data is in the space you point it to with the level data, so make sure it is indeed free space.
FX1 - See FX1 editting for what this does. You can repoint it to a new position to let a room that has a red FX1 use another room's or even create your own.
Enemy Population & Enemy Set - These control the enemies allowed and their placement in the room.
Scroll - The scroll pointers for a room. Since you can use the scroll editor, you don't need to change this unless you know what you're doing.
FX2 - You almost never needed to change this, most rooms just use 0000; it factors into the landing site areas in Crateria, escape rooms and a few other rooms.
PLM - Determines what PLMs are in a room. You probably shouldn't need to change this too often unless you really need a lot more PLMs in a room, since you can edit PLMs by rightclicking on them and changing them into other items.
BG_Data - changing this will change the background configuration. Go find a room you like the background of, check out its number, for example, B920 or whatever, and you can go to a different room, enter it as that rooms BG_Data and use it in that room. If the BG_Data of a room is 0000, then the Layer2 bg is being used instead of the BG_Data pointer.
Layer1_2 - Affects segments of the backgrounds in specific rooms but it seems to be a major focus in parts of the backgrounds of Maridian rooms and the "landing site" areas in Crateria.
Door Out - As mentioned in the door editting section, you can change this to change the location of the pointers that lead to the door data for the current room.
V. Non-menu based SMILE functions
BTS (Right next to the clipboard)
The
"little green formations" that are hanging around some slopes and
ledges in the game. You can make tiles more than just squares by
dragging these over the tile you want them to work on. Don't ask me
what those little red circles are for. I'm too scared to find out.
Other>Layer 2 Scroll (Right next to BTS)
If
you change the BG_Data of a room and you start getting odd errors, this
might be the cause. Check another room with a similar BG and change the
Layer 2 Scroll to that value. C1C1 is sort of the "normal" status of
this, but a lot of different rooms use different configurations
depending on where they draw their backgrounds from. More info on this
is contained in the help files that come with SMILE.
Graphic Set (Under the Clipboard, and BTS stuff)
Changes
what tileset is used for the room you're currently editting. Keep in
mind you have to change the background of the room to one that
naturally draws its tiles from the new graphic set to make the room
look right.
VI. Miscellaneous techniques and concerns
How to create white-outlined/blue-outlined 2x1 or 1x2 vertical/horizontal and 2x2 BTS combined shotblocks and bomb blocks
This
is excessively complicated and very obscure, so I'll describe an
example of it and you can mess with it to get the type you want.
Example
- Look for the BTS dropdown list in the BTS segment of the editor.
Under that, you'll see the large group of green/yellow/red BTS icons that are
normally used for creating slopes and such. As an example, drag the BTS
that's a tiny green box in the lower righthand corner of the tile over
a tile in the room. Now, In the scroll box that usually says "Air,"
"Shot block" or things like that, adjust it to be a shotblock or a bomb
block. The white outline should appear with the block you dragged the
BTS over as the focal point. You can now add other blocks around that
one as horizontal blocks or vertical blocks coming off that one (check
out how it should look by looking at one that's already constructed in
the game, and then mimic it with your block; only now you can now use
different tiles and such for it)
Note: you can get different
types of these combination blocks by dragging different BTS formations
over to the tile. The whole top row of said BTS formations will yeild
different types of combination blocks. You can even get blue outlined
tiles which will not regenerate when bombed/shot.
Enemies
Basically any enemy can be changed into any other with the right configurations. When in doubt, look for a sample enemy thats placed in the original game and works there. Then copy its data and enter that data into your own enemy in a different room. Be sure to copy every value, because although some variables have a range within which you can alter the enemy's behavior, some enemies just won't work if you leave the Graphic Unknown 00 or such. (For example, Space Pirates.)
Whenever you're altering which enemies are in specific rooms, be sure to remove enemies you won't be putting in a room from the "allowed" list and adding the enemies which you will be using to the list as well.
As you alter more enemies you'll run into specific quirks that are unique to specific enemies - like Metroids have to be in slot 001 to work and they don't always make the correct sound effects - or the fact that Covens don't seem to work outside the Wrecked Ship. The slots seem to be specifically for graphics. If you have two different enemies in slot 007 for example, the enemy earlier on the list in slot 007 will take on the pallette of the later enemy in slot 007. You can use this to your advantage to get some bizarre color combos, like purple Rios using Zoomers and many other interesting palette shifts.
Much more info about enemies and their configuration is contained in the help files that come with SMILE.
How to Fix Loading from the Ship
If you change Crateria Mainstreet so that it no longer connects to the landing site room by changing door data, loads from the ship will cease to function normally. Here is how to fix this in SMILE 1.32 (it's a slightly different process in 1.23 and below because there's no shortcuts for getting the door data and room ID so you have to get them manually). Go to a room that leads to the landing site room. Put your mouse cursor over the specific door that leads to the landing site room and hit L. Next, stay in that room, and go to Edit>Area load stations in SMILE. In there, go to Crateria 00. There should be a Room ID button and a Door Data button under that. Hit the Room ID button and click "Use current room for this load point." Then go to Door Data button and click the option "From the last door tile you pressed 'L' over." Then click Save. This should fix it so that you can load from the ship again.
Altering Tiles and Palettes
The Graphics Editor under Tools will be your main help if you want to alter or redraw some tiles. However, the redrawing itself can't really be done in SMILE. However, you can use the Graphics Editor to export tile data from any graphic set to a file format that can be understood by a tile editting program such as Tile Layer Pro. Once you've opened the file in TLP or a similar program, you can edit them, save the file and then import them back into the game with SMILE.
Palettes can be editted within SMILE itself in the graphics editor - although they can also be exported as well. Backups are strongly suggested during the palette editting process however. This is because the game only has room for a certain level of palette complexity and going over this limit will result in some data after the palette being overwritten. SMILE warns you before this happens so you can elect not to save the changes. However, there have been rare instances where I've noted errors occuring when the palette data was only very close or exactly at the limit, so backups are always a good idea.
Altering the Acquired items screen (Start+R)
You can alter this screen by opening the game in a program like Tile Layer Pro and searching through it. Eventually you'll be able to find the tiles that make up this screen. You can also find some other interesting graphics by doing this.
Swapping Pointers
A very useful technique for altering specific rooms to your liking. For example, say you want to have FX1 effects for a room that has a red FX1. Find a room that has a white FX1 and plug in its pointer number (Edit>Pointers) over the FX1 pointer of the room that has a red FX1. Both of those rooms will now be drawing from the same FX1, but it will now effect both rooms.
Helpful Pointers to have
A semi-decently compatable scrolling sky background configuration
BG_Data: b80a
FX2: c11b
Layer1_2: 91ce
A full Tourian Metroid-room background (as opposed to the half-formed ones)
BG_Data: e3e8
Layer1_2: c91e
Landing site's configuration
BG_Data: b76a
FX2: c116
Layer1_2: 91c9
Exploding landing site's configuration
BG_Data: b76a
FX2: c120
Layer1_2: 91b
When in doubt, go to a room that you want to cull the background from
and look at its BG_Data, Layer1_2 and FX2. Copy these to a new room and
it will assume that specific background. Be sure to change the
Layer2scroll to be compatable with that particular background (usually
C1C1), change/remove the layer 2 itself if there is one, and make sure
that room is using the same tileset that the background draws from.
Interesting related tidbit: Note that it is the FX2 of the escape rooms
that cause the explosions that go off all around the screen.
Rooms that have effects that don't work in every area
For one, FX1s are set depending on which area the room is in, so they will change if you move a room to a new area. This means that certain FX1 effects are only achievable within the specific area they're allocated to.
Secondly, most bosses will not work outside their specific area, although there are some exceptions which you can find through experimentation. Torizo will become a Gold Torizo if placed in Norfair and Gold Torizo will become regular Torizo if placed in Crateria. Spore Spawn may work in Crateria if I recall. In other cases, you have to use a workaround to have the effect of it being in another area. To do this, keep the boss room in the area it's supposed to be in and move the boss room to the exact x/y location on the map that you want it with the map editor, then go on with connecting the doors to other rooms as normal. However, do not insert the bitflag of 40 that you typically do when doors are transitioning areas. The only downside to this is that if the player pauses in the room, the map will show up as garbage data within the area the room really is in. Once they leave, the map will be fine though.
Thirdly, active Chozo statues - the one that walks in the Wrecked Ship and the one that lowers the acid in Lower Norfair - will not perform their functions if they are moved out of said areas. These can also use the same boss room workaround to appear to be in other areas.
Best possible workaround of the scrolling sky error in a new room
Currently, there is no way to get a completely errorless "scrolling" sky in a new room within SMILE itself. The
best workaround is, however, perfect besides the fact that it removes
the scrolling and takes up a lot of tile data space because it relies
on using layer2 backgrounds. Here it is:
Go to a room that has
the sky, say the landing site. Go to Preferences>View>Layer 1 and
uncheck it. This'll let you view the layer2 bg directly and edit/copy
it. Copy the sky one 'screen' (the space within a scroll block) at a
time. Then go to the room you want to put the sky in, go to
Edit>Special>Layer2>Add. Also, check the pointers on this room
you want to have the sky bg. Change the layer1_2 pointer to 91D3 or 91CE (try 91D3 first, if that doesn't work then go to 91CE), the
BG_data to 0000 and the FX2 to 0000. Also go to Other>Layer2scroll
and set it to 0181. Now take what you've copied and throw it into the
layer2 bg of this room, then save the room and repeat. You'll have to
keep copying the already existing sky tile formations from the landing
site to that room. If you want a large room and you want the bg to look
just like the landing site's sky - then that's a lot of copying, but
it'll work.
Hex editor fix for the scrolling sky error courtesy of Rakki
Note that before trying to put this fix to use, you need to understand how to add and/or edit doors, and about editing pointers for a room. You WILL need a Hex editor for this.
Modifying the pointers contained within the BG_Data for a room containing a scrolling sky background is the key to fixing, or should I say avoiding, the scrolling sky error. The following is a snippet of the BG_Data pointers in the Landing Site of a clean ROM.
0E 00 6A 89 80 D1 8A 00 48 00 08
The first two bytes (0E 00) denote that this room needs to determine which part of the background to load based on the door you enter the room from. This is where the second two bytes (6A 89) come into play. The second two bytes are a pointer to the address of the door that leads to a room with a scrolling sky background. In this example, $896A is the ROM location of the door leading FROM the first indoor room of Zebes (leading to Morph Ball and Bombs) TO the Landing Site. Hence, this part of BG_Data tells the Landing Site how to load the background for when you enter the Landing Site from the first indoor room of Zebes.
The next three bytes are the location in the ROM at which the background is stored. The first byte (80) and third byte (8A) are consistant for the BG_Data for any scrolling sky room. The important byte is the second one (D1). It determines what height of the scrolling sky background to load based on the Y position of the screen at which you enter the scrolling sky room. The following bytes correlate to the following room heights.
Byte B1: Screen Y 00
Byte B9: Screen Y 01
Byte C1: Screen Y 02
Byte C9: Screen Y 03
Byte D1: Screen Y 04
Byte D9: Screen Y 05
The next two bytes (00 48) tell the system where to store the background at in RAM. A value of 00 48 seems to work in-general, although Super Metroid also uses values of 00 40 and 00 4C. The best thing you can do is just to start with the same value every time, test the added/edited doors, and then change the value if any graphical glitches occur. For the record, one graphical glitch I got while testing was that my entire HUD blacked out and glitched up.
The last two bytes (00 08) denote the size of the background, in bytes. For scrolling sky rooms, this should just be left as 00 08.
One last note: If you plan on editing the Landing Site's doors, make sure you include the following two sections of data in the BG_Data for the room.
0E 00 6A 89 80 D1 8A 00 48 00 08 - Used to set the background off of an SRAM load.
0E 00 FE 88 80 B1 8A 00 48 00 08 - Used when the ship is landing.
The second snippet can be omitted if you choose to disable the intro sequence in SMILE. Also, the pointers contained in BG_Data must be terminated by two trailing bytes of 00 00.
There's room for 6 lengths of pointers in BG_Data for both the Landing Site and the Lake. This means 4 or 5 doors for the Landing Site, depending on if they double-up one of the pointers (the one used by the ship when loading, can also be used by a door connecting to the room) and 6 doors for the lake. Any more than 6 lengths of pointers for either one of those rooms, and the whole BG_Data needs relocated.
How to prevent the walking Chozo in the Wrecked Ship from changing room scrolls after its walk
This is a lot easier to change in SMILE 1.32, now that you can make your own scroll PLMs, but here's the legacy version of the fix anyway:
This is a rather obscure problem but a problem nonetheless. It can be solved with a hex change.
First, check to see that both states of the Walking Chozo room have the same scroll data (the
state the chozo walks in is state 2). Then check state 2 to look for
random scroll plms lying around. There are some after a
certain point in the lower segment that screw up the camera's ability
to go further.
After all that, in order to get past the point
that'd normally end at the reserve tank and get back down into the area
where the Chozo once sat, you'd need to make a hex
change.
These are notes from a trace performed while the walking chozo is changing the scrolls:
$AA/E6FA 8F 26 CD 7E STA $7ECD26[$7E:CD26] A:0000 X:0000 Y:E57D P:envmxdiZc
Open a hex editor, go to the location AAE6FA in the rom and change the 8F you find there to 8E. This should prevent the Chozo from changing the room scrolls.
Also,
there may be some problems with the tiles that the walking chozo comes
out of when it goes down to the bottom level.
I would recommend if you change this
value that you make a backup, make the change, test it to see how and if it works
with what your intentions are for the room. If it does, then go back to
the backup and proceed creating the game. When you get to the very last
days of the process, you can make this hex change last and keep a
backup from before the time you did it in case any problems come up in playtesting. This method worked in SM: Golden Dawn.
VII. Random problems you'll encounter while editting Super Metroid
- Scrolling sky background errors temporarily after changing doors that connect to the landing site rooms with the scrolling sky background
This one's a killer. It happens any time you alter a door's properties
in one of the three huge scrolling sky rooms. There's a lot of
workarounds for it but none are really perfect. My recommendation would
be to not change the doors in these rooms and don't change the doors in
rooms that connect to these rooms and just use the ability to change
the room properties of the surrounding rooms (size and such) to make
them taller and change them to your needs. You can also turn a lot of
red scroll areas to green to get different sized rooms. On another
note, I remember DrewSeph saying he removed the scroll from his sky to
fix this problem in SMRedesign but I have no idea how he did that. I
assume it is beyond the scope of SMILE itself.
See the subject "Best possible workaround of the scrolling sky error in a new room" higher up in this document. It won't completely fix the problem, but it's an acceptable workaround and you can use it to make the scrolling sky a static sky background (no scrolling) and avoid the error. This works even in the already existing landing site rooms, but you have to make sure you remove all remnants of the scrolling data (FX2, Layer1_2, BG_Data) and replace them with what the workaround segment tells you to replace them with. Also note that the landing site rooms already have the sky tile data stored in a layer2 background, so there shouldn't be any need to copy in or remove any data within the layer2 bg itself to make this change. Under that there's a segment that explains the origins of the problem and how to use a somewhat extensive hex editting process to avoid it in the landing site.
- Ridley, Kraid, or Draygon don't seem to be in their rooms!
This one had me for awhile. Go to Help>Offscreen Enemies to 0,0 in SMILE. Kraid's ancillary parts are in the room but his actual HP value is stored in an enemy offscreen.
- Draygon's room doesn't always seem to show changes you're making to it - specifically around the edges it seems - which makes it difficult to edit it extensively.
Actually this is the result of Draygon's room being entirely stored as
a layer2 background. Remove the layer2 and then you can begin editting
it fully.
- Certain rooms have some issues when editting them.
These include 79C5E (Brinstar fireflies), 7A293 (Brinstar fireflies 2), 7B6EE (Lower Norfair Demon/firefly Room), 7DEDE (Large Room in the Tourian Escape). Removing the Layer2 of the first two of these should fix your problems with them. The latter two don't seem to be savable at first glance. SMILE thinks they have negative space available. However, this is just a result of faulty tile data guessing on the part of SMILE. According to PJBoy, the Lower Norfair Demon/firefly room should have 5196 bytes of usable tile data space, and the Large room in the Tourian escape should have 3727 bytes of usable space. Don't go too close to these limits while editting and there's still a chance these numbers are off as they haven't been tested, so make a lot of backups during the editting process if you intend to edit them.
Certain rooms have errored graphic sets and thus you can't see what you're editting when you edit their tiles so I recommend not doing so in these rooms, but in the case of Kraid's room and some rooms like this, you can still edit the doors inside it. However, I wouldn't recommend trying to edit the tiles in said rooms unless you really know what you're doing. Future versions of SMILE may be able to make viewing and edit these rooms easier eventually.
These rooms include 7A59F (Kraid's room), 7DF45 (Ceres elevator room), 7E0B5 (Ceres Ridleyfight).
VIII. Weird Crap
- Some rooms in SMILE will show more max allowable tiledata than logically makes sense. For example, the second state of the Maridia noob tube room has supposedly a max of nearly 700,000. According to PJBoy, this state of the noob tube room actually only has 1413 bytes of space available. Most of these are errors or misinterpretations by SMILE. While I've never run into a problem with these rooms yet while editting, I'd stay conservative with how complex your tile formations within them get and, as always, backup frequently. Or you can make a backup of your work up to that point, attempt to go mad, making the room very complex/large, and see what the real cap on its tile data is before it starts eating the rooms after it. Then you can restore to your backed up data with the knowledge of the real limit.
- There are a few rooms in SMILE (particularly in the Wrecked Ship; there are at least 3 or so there) that allow you to change the tile data seperately for each state. In some cases (most notably the Wrecked Ship 'mainstreet,' the tile data limit will actually be HALF of what SMILE says it is for rooms like this. For example, the approximate limit for the tile data of the Wrecked Ship mainstreet room according to SMILE is 10,000 bytes. However, this is divided up between approximately 5000 for the regular state and another 5000 for the second state. If you go over the limit for the first state, the second will be destroyed and SMILE will not warn you when this happens, so be cautious and only use around 5000 bytes for each state of that room.
|
