[SM] Cloned room cannot be tested?

[stevem512]

Hi all (first time posting),

I started using SMILE 2.5 a few days ago, and I have (as far as I know) gotten to grips with the basics, along with the more intermediate steps e.g. using a hex editor to repoint PLMs, enemies, etc.

I made a few working rooms in SMILE by modifying existing rooms in Super Metroid, but my aim is to make my own Super Metroid hack so I need more rooms than the game provides (plus, some of the original rooms I only want to slightly modify, at least for a first run).

After reading the Moonedit SMILE FAQ about Making New Rooms (here for ease of access: http://forum.metroidconstruction.com/index.php/topic,300.0.html), I managed to copy an existing room (I copied the header for an existing room in HxD, and modified it to my liking), and I repointed the level data, enemies allowed/ population, enemy set, PLM, door out etc. I've modified the doors via door cloning such that I can transition between this room and a (working) room within SMILE. However, when I run the game, I just get a black screen if I test the cloned room. Also, I cannot move into that room from the working room it is connected to (when the door opens, I enter it, but there is no transition between the rooms; I cannot progress through the door). This is probably a longshot, but has anyone else come across this? Am I missing something obvious?

Of course, moving EXISTING rooms and editing those works fine, but cloning an existing room and editing that doesn't work for me.

Steve

[begrimed]

First make a copy of your broken ROM. Now, on a working ROM (preferably a working back-up of your hack right before you attempted the room cloning), clone the room and everything about it, make sure that works, then start changing/testing the different pointers one by one until it's completely detached. After that, you can compare it with your broken ROM (using File Compare if necessary) and see what exactly went wrong the first time you attempted it.

There's also this work-in-progress guide for SMILE RF.

[stevem512]

Hi Grime,

Nice to actually speak to the person whose guides I've been reading the last few days :p So I tried something similar this morning as a matter of fact; I copied a room I know works (different from the one I copied and modified for this post) and used door cloning to link it up where my (currently non-working) room should connect. I get the same effect (i.e. can't enter the room, can't test the room). In this case, I did exactly what you said; I just cloned the room, but left all the pointers the same. I can try what you suggested, but I feel like I've tried that already :/ I presume I'm not cloning the room properly?

For the record, the steps I take for room cloning are:
1) find the room header I want to clone in HxD, and paste-write the data to a free part of the rom
2) edit mdb with the start location of the copied room header
3) room can then be selected in SMILE

The only thing I can think of as to why it's not working is because I might be copying the header to a free part of the rom NOT for headers (if memory serves, the header is at offset 77XXX). Does the free space start from 78XXX for room headers?

Steve

[begrimed]

As long as the copied header is pasted somewhere in bank $8F (which is everything between offsets 78000-7FFFF), everything should work fine.

Does the room that you copied have any extra room states, or just E5E6 = Standard1? For copied room headers with extra states, there's a pointer that needs to be updated for each state.

[stevem512]

Hi Grime,

I moved the offset for the troublesome room to beyond 78XXX, and it works :D (well, doors, enemies etc.) I'm not as stupid as I first thought! However, now I'm getting another issue; a messed up layer 2. Any idea what might cause this? Is it a dodgy background pointer? The room I copied to make this room wouldn't let me edit the background (it's one of the tall shafts in Norfair that I copied and moved to Brinstar), so I deleted the layer 2 information, added it again, and made the background. Would this have had an effect at all?

Enclosed are what the room looks like in SMILE (before - https://www.dropbox.com/s/o120ee8itx2mdv3/Before.jpg?dl=0) and while testing (after - https://www.dropbox.com/s/xuns97krw7x96jv/After.jpg?dl=0). At least the room can actually be tested...

And to answer your question, no it's just the standard room state. Making rooms with multiple room states is a job for another time!

Steve

[begrimed]

Layer 2 issues are an easy fix. In SMILE 2.5, there's the "Tools > Background Editor > BG / Layer 2 SCROLLING" - select whether you wanna use a BG_Data pointer or Layer2 BG from that top drop-down menu. If you're using a layer 2 background, then the BG_Data pointer also needs to be changed to 0000.

Good catch with the 77XXX address, that would've taken awhile to diagnose over the forum like this.

Multi-state rooms are almost just as easy to work with as single-state rooms, so it won't be a huge step up when you decide to. :D All room states are, are extra sets of room pointers that are loaded after an event is triggered (such as Shaktool's room remaining cleared-out after Samus gets the spring ball).

[stevem512]

Hi Grime,

If you're using a layer 2 background, then the BG_Data pointer also needs to be changed to 0000.

That was exactly my problem! I was using a layer 2 background, but the pointer wasn't 0000 for some reason. It was an easy fix, thanks :p

Good catch with the 77XXX address, that would've taken awhile to diagnose over the forum like this.

Haha, like I said, when I suggested the problem, it was a longshot as to whether anyone knew what directly caused the issue! I remember reading something about certain pointers requiring addresses > X8XXX

All room states are, are extra sets of room pointers that are loaded after an event is triggered (such as Shaktool's room remaining cleared-out after Samus gets the spring ball).

Ah nice, that makes sense. I presume the total size of the room multiplies with the number of states i.e 2 state room ~ 2x larger than single-state room?

Finally one more question; I'm getting to grips with understanding the right special, speed, and orientation values of enemies, but I've come across an issue with Hachi enemies; I add in both the Hachi and its wings (and edited the parameters from what I've seen elsewhere in the game). However, the enemy glitched (no wing animation), and when Hachi approached Samus, the game froze. I changed the Hachi + wings to two Zeelas (and made sure I had enough space for the enemy population and enemy set), and it works fine. Any idea what I may have messed up? I assume it's either space in bank or parameters for enemy motion, but I'm not sure. Also, should the wings of Hachi be added to the list of allowed enemies in a room?

I think those are all the questions I have for now :p Thanks again for your help!

Steve

[begrimed]

Hachi's wings don't go on the allowed list, and they aren't needed for the enemy to work either. Make sure the enemy indexes aren't switched up, which is their actual number order in the room (you can see the index by setting your mouse on an enemy or PLM and looking at the number in the yellow pop-up box). Hachi's wings must be the index number immediately following the Hachi itself. If it's the other way around, I could see a crash happening from that.

Also, in SMILE's description, it says Hachi sometimes uses speed for unknown reasons, but I believe this is an HP value that adjusts when (or if) the Hachi's wings will break off before it dies, if it has them.

[stevem512]

Hachi's wings must be the index number immediately following the Hachi itself. If it's the other way around, I could see a crash happening from that.

Ah yeah of course, I forgot it says that in the details for the wings :/ I'm almost certain that's why I had the crash.

Hachi sometimes uses speed for unknown reasons, but I believe this is an HP value that adjusts when (or if) the Hachi's wings will break off before it dies, if it has them.

I thought this was the case for the wings themselves, not Hachi? So what happens if you set Hachi speed = 50 (the "rarely used speed") and the wing speed = 20 (for example)?

I will start remembering all these tidbits of information at some point!

Steve

EDIT: Yes, you're perfectly right. Altering which enemies are Hachi/ wings works perfectly with no freezing :D

[begrimed]

Oops, yeah, you're right about the speed 0050 thing, my mistake. If a Hachi uses 8000+ as its speed, it starts with no wings, even if it has the wings attached, so my guess is that the 0050s were mistakenly meant as damage values for the wings or something, and don't actually have a purpose being set to 0050 (unless someone wiser than I knows better and wants to correct this).

[stevem512]

Ooh ok, that's good to know. I've not played around with speeds yet, but that's something to watch out for!

This is now off topic from the original post, but it's an interesting issue; in my hack, there are two missile upgrades (one in each room). When you pick one of them up, the other one disappears. Any idea why this happens? Is there something to do with the index of the missiles that I'm missing?

Steve

[begrimed]

Items causing other items to disappear happens when their "Low" value is the same for both in the PLM Editor. If you're adding new items, or just wanna re-assign some for convenience as you go, unused Low values for items are 51-7F and 9B-FF. For all of the non-blue door caps, it's 61-7F and AD-FF.

[stevem512]

Ah, yes that makes sense. Again, I misread what SMILE was saying about the Low index. I figured the same issue would be for doors as well. So I guess if two pink door caps have the same index, then opening one will open the other?

Thanks for all your help. Now I feel like I know what I'm doing :p

Steve

[begrimed]

Somewhat. Opening one door that shares a low index with another door in the same room won't cause the other door to immediately open or vanish, but if you left and re-entered the room, then it would be gone.

Any time! You've already gotten past the stuff that stops most hacks before they really begin, so it's mostly just details now.

[stevem512]

Opening one door that shares a low index with another door in the same room won't cause the other door to immediately open or vanish, but if you left and re-entered the room, then it would be gone.

Ok, so I assume this behaviour is consistent if the two pink door caps with same indexes are in different rooms i.e. open door cap in room A automatically opens door cap in room B?

Thanks for the kind words! It's mostly details AND having time to do it. Back to work on Monday means I can't spend all day learning/ doing things anymore :(

[sm cory]

hey I found an easy way to copy a room in smile! pull up the existing hack with that room then go to file> open rom> select the new rom to past it to but after that don't click shit lol just press save room and bam room is pasted  :heheh:

[Quietus]

Indeedy-do. This has been known for a long time, and is also a handy backup for if you screw up a room and need to revert, as you can open an unmodified ROM, then your own, and save it. :^_^: