Old SMILE Help Thread

[UltimaOUlaw]

I'm working on a full length hack but I need to know what Address the animations for items/pick ups and Beam Animations can be found in TLP. All help is appreciated  :^_^:

[Scyzer]

I'm working on a full length hack but I need to know what Address the animations for items/pick ups and Beam Animations can be found in TLP. All help is appreciated  :^_^:

Items are at $48000, animations for beams/explosions are at $D5600. The grapple beam animations are at $D0200.

[Sperry]

Has anyone else edited a room, only to find out much later that by doing so he screwed up the colour palette of another older room? Well, that's my problem now. Can anyone please tell me how to fix this?

[Crashtour99]

THe bosses work by boss bits. If you beat a boss, a bit is set, then when you go back into that room, that bit is read, and comes up positive, so the room changes and you won't fight the boss.

Is there an easy way to make it so that bosses and/or minibosses don't set bits?

[MetroidMst]

You would probably have to do some research and get rid of the bit-flag in a Hex Editor. I think that would be the least laborious process.

[personitis]

Has anyone else edited a room, only to find out much later that by doing so he screwed up the colour palette of another older room? Well, that's my problem now. Can anyone please tell me how to fix this?

Watch your room size. Every time you save a room in SMILE, in the top left most of the window you'll see something like 759/1053 (random digits). If the left digit is higher than the right, then you've overwritten data, but SMILE will generally warn you about this. Hit NO and work within the parameters you have (or if you're really smart, you can repoint data).

[JAM]

Is there an easy way to make it so that bosses and/or minibosses don't set bits?

It's possible. But then, the gray doors wouln't open after killing the boss. For example, if make bomb Torizo to not set the bit, then you can't exit from his room. Even grey door with "Open after cleaning the room" with "enemies to clear the room" set to 01 still would not opens as long as Torizo wouldn't count as killed enemy.

I think, the best solution is JSR that will set different bits depending on Room index, for example.

I have another question about bosses. Is it true that the every big boss (such as Kraid) will only work if the boss room is placed in specified coordinates at the map? Is it hardcoded in initiation AI of each boss?

[Scyzer]

THe bosses work by boss bits. If you beat a boss, a bit is set, then when you go back into that room, that bit is read, and comes up positive, so the room changes and you won't fight the boss.

Is there an easy way to make it so that bosses and/or minibosses don't set bits?

Well, actually. There is. Contrary to what other people have said, there is a simple way to reset a boss bit. Simply use the layer1_2 data pointer for the room with the boss in it. The ASM would constantly check the boss bit that the current boss will set when killed. If the bit becomes set, then the ASM branches to clear that bit pretty much straight away, after a delay (to allow the door to open).

That way means the boss will be there everytime you enter the room, though, you won't have to fight it cause the grey door willl be gone (unless you have the high bit set)

[MultiK1llZ]

does any one have a good clean rom, cause i have a super metroi (J) that is very glitchy and another super metroid that doesnt allow me to quick edit the level.

[personitis]

Google is your friend. Though I wonder if patches are in the question here... <_< >_>

[Crashtour99]

Simply use the layer1_2 data pointer for the room with the boss in it. The ASM would constantly check the boss bit that the current boss will set when killed. If the bit becomes set, then the ASM branches to clear that bit pretty much straight away, after a delay (to allow the door to open).

That way means the boss will be there everytime you enter the room, though, you won't have to fight it cause the grey door willl be gone (unless you have the high bit set)

Thanks man, this actually helps a lot.   :grin:
I'm going to be doing some unusual stuffs with doors, so that's not a problem.

[Scyzer]

Simply use the layer1_2 data pointer for the room with the boss in it. The ASM would constantly check the boss bit that the current boss will set when killed. If the bit becomes set, then the ASM branches to clear that bit pretty much straight away, after a delay (to allow the door to open).

That way means the boss will be there everytime you enter the room, though, you won't have to fight it cause the grey door willl be gone (unless you have the high bit set)

Thanks man, this actually helps a lot.   :grin:
I'm going to be doing some unusual stuffs with doors, so that's not a problem.

Disregard EVERYTHING I said before. I know a way to have 2 bosses in each area. The door ASM pointer. Just have code run whenever you enter one of the boss rooms. This code will check the boss bit to see if it has been set, and another bit that determines which boss(es) has been killed (just an unused bit in RAM). If the boss bit comes up as false, RTS without changing anything, and you get to fight the boss. If the bit comes up positive, then it will read the other bit. If the bit has been set to 1, then boss A has been defeated. Assuming you are entering boss A's door, the code will do nothing, and leave the boss bit set, meaning you won't fight it. If you weren't entering boss A's door, the bit will be reset, meaning that when you enter boss B's room he'll be there waiting for you. If the other bit came up as 3, then both bosses have been killed, and the code doesn't change anything.

For the other bits (not boss bits), you would have a code run upon LEAVING the boss rooms, that sets either bit 1 or 2, meaning you've beaten that boss.

So simple and easy ASM too. It'd probably only take up about 50 bytes

[Sperry]

Has anyone else edited a room, only to find out much later that by doing so he screwed up the colour palette of another older room? Well, that's my problem now. Can anyone please tell me how to fix this?

Watch your room size. Every time you save a room in SMILE, in the top left most of the window you'll see something like 759/1053 (random digits). If the left digit is higher than the right, then you've overwritten data, but SMILE will generally warn you about this. Hit NO and work within the parameters you have (or if you're really smart, you can repoint data).

Thanks, but I think I'm still ok with room size. The digits that appear at the top left when I save are 3840/5165. What else might I have done wrong?


edit: Also, ever since I've added the 'Super Metroid Scrolling Sky Fix Patch', created by P.JBoy, the landing site doesn't load any more when I open my rom. What have I done this time?  :cry:

[zephyrtronium]

It sounds to me like you applied a patch intended for an unheadered ROM to a headered one.

[Sperry]

Ok, so I've gone back to a pre-patched version. I'll deal with the lading-site sky later. Right now, I have to learn how to fix this palette problem.

When I press E in Smile in an adjacent room, things start out ok. But when I enter the landing site, the game freezes and this is what I get:


When I press E in Smile in the landing site itself, I can't play at all, and this is what I get:


Finally, when I open my emulator and load super metroid, I can play, but the colours are all messed up, but I can still play. The only thing that works here is the blue suit: that's intentional, because [spoiler]in this mod you don't play as Samus Aran, but as Armstrong Houston[/spoiler]. This is what I get when the game starts at the landing site:


So all of this said, I'm sure there's an easy solution to this. It seems the colours are just messed up. Right? I'm hoping it's as simple as that.

[personitis]

1.) What's up with all the "Do fish get thirsty" under your pics?
2.) Again, you didn't apply a headered patch to an unheadered ROM did you?
3.) And if all else fails, there's a way to completly kill the BG glitch in the landing site (or any scrolling sky BG at that).

Considering if you've done any actual level work or not, Id would start over really. =\

[squishy_ichigo]

Those kinds of errors tend to happen with to many enemies in the room.  A normal room can only have 4 types of enemies, but iirc, the landing site's cap is lower.

Try removing any extra enemies from the allowed list and see if that changes anything.

If thats not the problem, then you might be overwriting important data in the ROM.  What all have you edited?

[Zhs2]

1.) What's up with all the "Do fish get thirsty" under your pics?

lol Imageshack

[JAM]

I have a little problem...

I have located an array of addresses of messages which displayed when you get an item and expanded it by relocated the array after that with correct pointer to it. In second array there are buttons in messages coded (when you see press "X" or "B" button in messages).

New values in messages from 1E to 25 are worked fine, but 26 and above that are very glitched. Sometimes message is displayed but the whole layer 1 turns black, sometimes all graphic is corrupted and I fall about 20 screens through the floor.

Values in array are alright. Message is correct too. Even the same values that using Energy Tank and others are not working under message 26.

Any ideas why it happened?

[Sperry]

1.) What's up with all the "Do fish get thirsty" under your pics?

Photoshack, like Zhs2 said.

2.) Again, you didn't apply a headered patch to an unheadered ROM did you?

I don't think so. I still don't quite understand the difference between headered and unheadered ROMs, but I haven't really modified anything else than terrain and doors...

3.) And if all else fails, there's a way to completly kill the BG glitch in the landing site (or any scrolling sky BG at that).

That's good to know. How can I do this? Does this imply deactivating scrolling skies?

Considering if you've done any actual level work or not, Id would start over really. =\

Well that's what I might do finally. I've found an earlier version without any bugs, and I think I'll just continue from there. However, I remember reading somewhere that it was possible to import rooms from other files. If this is true, what's the easiest way to import a room from one of my glitched versions to the ones that work.

Those kinds of errors tend to happen with to many enemies in the room.  A normal room can only have 4 types of enemies, but iirc, the landing site's cap is lower. Try removing any extra enemies from the allowed list and see if that changes anything.

Yes I've noticed that. The ship alone counts as two, and I only added two other different types. However, the problem unfortunately doesn't go away when I remove them.

If thats not the problem, then you might be overwriting important data in the ROM.  What all have you edited?

Well, I've basically only edited terrain and enemies in two rooms, but I've also messed a lot with door before figuring out how they work. Would this somehow be the cause to my problem?

[Crashtour99]

The difference between headered and unheadered ROMs is 200 bytes at the very beginning of the ROM (headered has them, unheadered doesn't).

If you apply a patch for an unheadered ROM to a headered ROM (or vice versa) then it will write data in the wrong place and cause all kinds of problems (either the data won't be readable or it will overwrite other important data).

[personitis]

@Sperry: Yes, unfortunatly it requires that you take off the scrolling sky. But for future refernce (and to correct an above post =P) switch the BG to "Use Custom BG" in the Background Editor and in the pointers window switch FX2 to 0000 and Layer1_2 to 91D3. Then you can use\make any BG you want.

[Sperry]

The difference between headered and unheadered ROMs is 200 bytes at the very beginning of the ROM (headered has them, unheadered doesn't).

If you apply a patch for an unheadered ROM to a headered ROM (or vice versa) then it will write data in the wrong place and cause all kinds of problems (either the data won't be readable or it will overwrite other important data).

Ok thanks... I must have missed that. How do I know if my ROM is headered or not? Do I open it in a hex editor or what? And should my ROM be headered or not? What's better?

[JAM]

Sperry
Size of headered ROM is 3146240 bytes and size of unheadered is 3145728. If you have just downloaded ROM, most likely, it will be headered.

Headers are evil

When you read in Hex Tweaks "change vaule at 81110", this is true for unheadered ROM. For headered one, you'll need to add 200 bytes to get a correct address (81310). Searching for values is easier with unheadered ROM because something points to 81110 will do so in a headered ROM too, but to get there you will need to add 200 (hex) bytes. If you want to use hex editor or apply patches then you better remove a header. Most patched are for unheadered ROMs.

Header can be added with SMILE in anytime if you want so.

[Sperry]

Ok, got it. Headers are evil. Thanks so much :D

I've noticed there are quite a lot of smile tutorials on youtube. Is there one with step by step instructions on how to properly set up a ROM (unheadering it, etc...)? The uttermost basic stuff for noobs?

Also, I'm still looking for a way to copy rooms from my old glitchy versions to a new cleaner one. Is this possible or do I have to redo everything manually?