Super Metroid/SMILE Help Thread

2009-04-01 07:24:06 am

Samus...? Is that you?

Quote from Obsy:

Because noone awnsered, how do you create new enermies/plms.
not nessasaraly from scratch.

DSO gave you a good one to copy enemies, but this is easier way, you don't even need a hex editor:
Go to SMILE's enemy list, go to the enemy you want to copy, click Copy xxxx DNA, then go to another enemy you're not using, and click Paste xxxx DNA. But if you want to copy to freespace, then go the end of SMILE's enemy list, and you see a few random things. (2 T's in blue box and a bridge-like thing)
Paste the DNA over them.
For PLMs, i don't know, but i know atleast that it requires hex editor.
But if you want to actually create new enemy/PLM, then you need ASM.

Quietus

2009-04-01 07:38:28 am

Super Secret Area - Dead Ahead!

Another newbie question. The option in SMILE to add/remove PLMs works fine, but them the game often crashes. I presume this is to do with the repointing that everybody keeps on about, so that'll require hex editing, but where would one start?

Shadow34370

2009-04-01 10:22:33 am

Quote from Quietus:

Another newbie question. The option in SMILE to add/remove PLMs works fine, but them the game often crashes. I presume this is to do with the repointing that everybody keeps on about, so that'll require hex editing, but where would one start?

Adding PLMs/Enemies will require hex to work correctly/safely, but there is an easy way around it. If you need more enemies or PLMs in a room just switch the pointers for the enemy population/set or PLM data with another room that has the amount of enemies/PLMs you need. If you want to get started with hex editing, though, I would start playing with adding doors, than adding new rooms or something. That way you can get a feel for what it is like. IIRC the bank that enemy population/PLMs is located at is very full and there really isn't much room to repoint to, so you might not even be able to add PLMs/enemies safely anyway. aiwebs_027

UltimateAvenger

2009-04-01 03:57:24 pm

LOL

Quote from Shadow34370:

Quote from UltimateAvenger:

quick question, is it possible to edit the beams as in how they look? If so, how? Eh?

Yes, you can change what the beams look like easily using TLP, but you can change the way the animation is used. Beam sprites are about 1/3 of the way down in the ROM if you look for it in TLP. I just posted a video here that has a different beam sprite if you want to take a look.

Ok I have searched tlp and still no sign of the beam sprites. Do you know exactly what offset it is on?

Shadow34370

2009-04-01 04:35:32 pm

I made a video showing where and how to edit the beam sprites. Hopefully it helps! aiwebs_011

(Video was still processing, so quality might be bad.)

UltimateAvenger

2009-04-01 06:42:58 pm

LOL

thanks shadow!

Sadiztik Fish

2009-04-02 02:49:51 am

OMG FLAN!!!!!!!

Quote from Shadow34370:

If you want to get started with hex editing, though, I would start playing with adding doors, than adding new rooms or something. That way you can get a feel for what it is like. IIRC the bank that enemy population/PLMs is located at is very full and there really isn't much room to repoint to, so you might not even be able to add PLMs/enemies safely anyway. aiwebs_027

I'm not sure about the enemy banks, but there's actually a ton of space at the end of bank 8F, which is used for PLMs, Scrolls, etc. There's easily enough space to repoint most rooms' PLM pointers to free space. I think there's about $2000 bytes free space there (it starts about 7EA00, goes till 7FFFF).

Also, I would say that simply repointing to free space is far easier than trying to copy data such as adding new doors or rooms.

Best thing to do is swap pointers though, like shadow said. It saves heaps of space in the long run. I've never copied a new room or changed a pointer to free space. What I do for rooms level_data, is find the room right after in the level_data pointer, and change the pointer so any free data I have left is taken away to the start of the room, and can be used in the previous room. (if I have used 100/150, i change the pointer so it starts 50 bytes later, thus meaning I've actually used 100/100, and the other 50 goes to the room before that one).

Pretty much means that my Level_Entries.txt only really works for my hack... good thing I keep backups grin new

[quote="Shadow34370"]
If you want to get started with hex editing, though, I would start playing with adding doors, than adding new rooms or something. That way you can get a feel for what it is like.  IIRC the bank that enemy population/PLMs is located at is very full and there really isn't much room to repoint to, so you might not even be able to add PLMs/enemies safely anyway.  [aiwebs_027]
[/quote]

I'm not sure about the enemy banks, but there's actually a ton of space at the end of bank 8F, which is used for PLMs, Scrolls, etc. There's easily enough space to repoint most rooms' PLM pointers to free space. I think there's about $2000 bytes free space there (it starts about 7EA00, goes till 7FFFF).

Also, I would say that simply repointing to free space is far easier than trying to copy data such as adding new doors or rooms.

Best thing to do is swap pointers though, like shadow said. It saves heaps of space in the long run. I've never copied a new room or changed a pointer to free space. What I do for rooms level_data, is find the room right after in the level_data pointer, and change the pointer so any free data I have left is taken away to the start of the room, and can be used in the previous room. (if I have used 100/150, i change the pointer so it starts 50 bytes later, thus meaning I've actually used 100/100, and the other 50 goes to the room before that one).

Pretty much means that my Level_Entries.txt only really works for my hack... good thing I keep backups :grinnew:

DMantra

(user is banned)

2009-04-02 02:41:25 pm

Breathe in the Future, Breathe out the Past

So I ran out of elevators, and need to make some new ones.
I noticed that the door under the species is always 0000 f8 07 00 03 00 00 0004 8000,
and the species going up or down is slightly different, so that much I understand and can copy.
However they still just don't want to work. Samus goes to the next room, but she's just stuck at the bottom/top.
Is there something else I need to do? Perhaps in the pointer section?

squishy_ichigo

2009-04-02 05:09:59 pm

. . .

DMan: I've made a new elevator from scratch, so I might be able to help!

Elevators are made up of two doors... one for the elevator part, and one for the room transition

Room#going to - Bitflag (I used E0 and F0) - 03 00 00 00 00 0000 0000 <-- AREA TRANSITION DOOR
0000 F8 07 00 03 00 00 0004 0000 <-- ELEVATOR DOOR

AND if you want your elevator to come at a different X position, you just have to change the 5th value (its labeled X, not to hard to understand eh?) to whatever screen # you want the elevator to appear at. (ex. first screen from the left = 00, second = 01, etc.)

And make sure the elevator enemy is set up correctly to!

D73F (it's an elevator*)
[Special] = 2C00
[Speed] = 0000/0001 for down/up
[Speed 2] = Y position to make the elevator first appear when entering the room on an elevator. 0018 is a common value for elevators going down into a room. 0Z40 works quite well for elevators going up into a room, where Z is the screen just below where you emerge from.

*Do not include this in the Enemy Allowed list or it will crash your room.
**Door tiles with a RoomID of 0000 must be directly underneath the elevator, or you won't be able to stand on and use it.
***Elevators need 2 door in their path to function correctly. More information on this is included with the door editor.

That SHOULD work...

DMan: I've made a new elevator from scratch, so I might be able to help!

[spoiler="squishy_ichigo's stupid little ELEVATOR guide!  That probably sucks!"]Elevators are made up of two doors... one for the elevator part, and one for the room transition

Room#going to - Bitflag (I used E0 and F0) - 03 00 00 00 00 0000 0000 <-- AREA TRANSITION DOOR
0000 F8 07 00 03 00 00 0004 0000 <-- ELEVATOR DOOR

AND if you want your elevator to come at a different X position, you just have to change the 5th value (its labeled X, not to hard to understand eh?) to whatever screen # you want the elevator to appear at. (ex. first screen from the left = 00, second = 01, etc.)

And make sure the elevator enemy is set up correctly to!

D73F (it's an elevator*)
[Special] = 2C00
[Speed] = 0000/0001 for down/up
[Speed 2] = Y position to make the elevator first appear when entering the room on an elevator. 0018 is a common value for elevators going down into a room.  0Z40 works quite well for elevators going up into a room, where Z is the screen just below where you emerge from.

*Do not include this in the Enemy Allowed list or it will crash your room.
**Door tiles with a RoomID of 0000 must be directly underneath the elevator, or you won't be able to stand on and use it.
***Elevators need 2 door in their path to function correctly.  More information on this is included with the door editor.[/spoiler]

That SHOULD work...

Phazar

2009-04-02 07:45:48 pm

...

I'm actually working on making some elevators as well, and they can be somewhat confusing. Most have a certain scroll pointer in their data, and the Tourian elevator seems to use the exact same bitflag at the top and bottom. However, 0004 seems to be the default "Distance From Door" pointer for elevator transitions.

DMantra

(user is banned)

2009-04-02 10:28:36 pm

Breathe in the Future, Breathe out the Past

Thanks squishy. Turns out I had the direction pointers mixed up. I swapped 02 and 03 and everything is fine now.

tbolt76

2009-04-04 04:49:06 pm

hi i was wondernig and im sorry if this has been asked before but i need to change the color of a block how do i do that without affecting other tiles?

MoogleEmperor

2009-04-04 05:05:37 pm

If you change one color, it will always affect any other tile that uses the same palette. 8 palettes of 16 colors each (technically 15 because the first is always transparent) is the limit for level tiles. You'll need to work around this.

Tyjet66

Edit history:

Tyjet66: 2009-04-05 04:18:03 am

2009-04-05 02:29:43 am

What'd you say?

EDIT: Thanks for the help.

attachments:

2009-04-05 03:30:37 am

Room 2:

Find a door that's already in the direction you want and then copy that. You'll notice it has different BTS tile values, which is why just flipping the door as you did doesn't work.

Room 1 is the scrolling sky error. PJBoy made a patch that fixes it, which I just attached to this post because I don't remember the link.

attachment:

Super Metroid Scrolling Sky Fix Patch.ips

Sadiztik Fish

2009-04-05 03:42:55 am

OMG FLAN!!!!!!!

Several things:

1. The background messes up because you've changed some of the door withing a scrolling sky background. I don't know why this actually happens (I'm not sure if anyone else does either), but this is easily fixed with a simple patch. It was attached to a post in this thread a few pages back, I think, or someone may provide it (I don't have it cause I use a different way of fixing it).

2. The door opens backwards because it was naturally for a door going the other way. Just copy a door facing the same direction, or draw your own from the tiletable. (if you draw your own, top is shotblock BTS 00, next 3 are verticals, BTS of FF, FE, FD respectively).

3. Giving a room a scrolling sky background is easy with a few pointers, but there are some limitations with it. It may be easier to just draw the sky in Layer_2, though the clouds will not scroll.
If you want a scrolling BG, then use C116 OR C11B in the FX2, B76A in the BG_data, and 91C9 for Layer1_2. The biggest problem with this is that the room draws the BG from the top screen in the room. Meaning if your room is 1 block high, you CANNOT get mountains in the BG, only clouds, because the mountains are actually being drawn 5 screens lower. If you want the mountains scrolling BG (which I'm assuming you do), you need to first expand the room vertically so it is 5 screens high. Next you need to repoint the scroll pointer to free space (as there won't be any for the extra scrolls), and make all the first four layers of scroll blocks red, last layer green/blue. You also need to move the enemies so they appear in the part of the room you'll be in. Then the background will start displaying from the top screen, but you'll only see what is five screens down; the mountains.
It's pretty complicated at first, but that's how it's done. If you need more help just PM me.

Several things:

1. The background messes up because you've changed some of the door withing a scrolling sky background. I don't know why this actually happens (I'm not sure if anyone else does either), but this is easily fixed with a simple patch. It was attached to a post in this thread a few pages back, I think, or someone may provide it (I don't have it cause I use a different way of fixing it).

2. The door opens backwards because it was naturally for a door going the other way. Just copy a door facing the same direction, or draw your own from the tiletable. (if you draw your own, top is shotblock BTS 00, next 3 are verticals, BTS of FF, FE, FD respectively).

3. Giving a room a scrolling sky background is easy with a few pointers, but there are some limitations with it. It may be easier to just draw the sky in Layer_2, though the clouds will not scroll. 
If you want a scrolling BG, then use C116 OR C11B in the FX2, B76A in the BG_data, and 91C9 for Layer1_2. The biggest problem with this is that the room draws the BG from the top screen in the room. Meaning if your room is 1 block high, you CANNOT get mountains in the BG, only clouds, because the mountains are actually being drawn 5 screens lower. If you want the mountains scrolling BG (which I'm assuming you do), you need to first expand the room vertically so it is 5 screens high. Next you need to repoint the scroll pointer to free space (as there won't be any for the extra scrolls), and make all the first four layers of scroll blocks red, last layer green/blue. You also need to move the enemies so they appear in the part of the room you'll be in. Then the background will start displaying from the top screen, but you'll only see what is five screens down; the mountains.
It's pretty complicated at first, but that's how it's done. If you need more help just PM me.

Tyjet66

2009-04-05 05:06:07 am

What'd you say?

Alright, here's another one that has me stumped. The picture's pretty much explain my problem.
Picture a: Room in-game
Picture b: room in SMILE

Any ideas on how to fix this?

attachments:

a.bmp

b.bmp

Shadow34370

2009-04-05 08:08:41 am

Possibly a different state? Make sure that there is no other alternate states in the room. Otherwise I am not sure. Embarassed

Quietus

2009-04-05 08:28:42 am

Super Secret Area - Dead Ahead!

This may sound obvious, too, but have you disabled the layer?
Try pressing keys 1-5, and check they all say 'enabled'.

Tyjet66

2009-04-05 09:20:20 am

What'd you say?

Quote from Shadow34370:

Possibly a different state? Make sure that there is no other alternate states in the room. Otherwise I am not sure. Embarassed

Why didn't I think of that before? Embarassed

That fixed the problem, all I had to do was go to the different states and change the pointers. Thank you.

tbolt76

2009-04-05 02:50:03 pm

In certain rooms on smile i keep geting a runtime error 9 subscript out of range how do i fix this int in the same room all the time and it just wont work

Jathys

2009-04-05 06:31:49 pm

Quote from tbolt76:

In certain rooms on smile i keep geting a runtime error 9 subscript out of range how do i fix this int in the same room all the time and it just wont work

Most likely it means that some data from the room before has been expanded in such a way that it overwrites the start of the room . . . This can be any of a number of things, but is *usually* related to increasing the size of a room and saving extra scrolls or simply making a room too large (so it starts overwriting the header/data of the next room). If you've done graphic changes, that's a possibility as well (and easy to check simply by trying to open a different room that uses the same graphic sheet as the room that crashes.

As for fixing, a few possible ways:
1) Open the room in a good rom, then open the bad rom (but don't re-open the room). Save the good room from the good rom into the bad rom . . . Side effect = fixes your bad room, but overwrites the end of the room before it.
2) If you can figure out *what* did the overwriting, you can repoint it in the good rom, THEN do the #1 fix (this way, you get the good rom, but it'll save itself to the new location, thus not overwriting the prior room.
3) If you don't need the room that's crashing, you could simply adjust your mdb list to point to the corrected starting point of the room, then manually (hex) put a dummy room header in that spot so it won't crash smile... Then edit as normal.

Sorry #2 and #3 are both pointer/data adjustments, but it's just the way it is. I should make smile be able to start an mdb list from scratch, ignoring all existing rooms. For most people, this would suck. For everyone else, it would mean the ability to have smile auto-change pointers/data as needed so the headers don't get overwritten. (Can't do this with the original mdb list, as moving the data around would overwrite stuff at the end).

[quote="tbolt76"]
In certain rooms  on smile i keep geting a runtime error 9 subscript out of range  how do i fix this  int in the same room all the time and it just wont work
[/quote]Most likely it means that some data from the room before has been expanded in such a way that it overwrites the start of the room . . . This can be any of a number of things, but is *usually* related to increasing the size of a room and saving extra scrolls or simply making a room too large (so it starts overwriting the header/data of the next room).  If you've done graphic changes, that's a possibility as well (and easy to check simply by trying to open a different room that uses the same graphic sheet as the room that crashes.

As for fixing, a few possible ways:
1) Open the room in a good rom, then open the bad rom (but don't re-open the room).  Save the good room from the good rom into the bad rom . . . Side effect = fixes your bad room, but overwrites the end of the room before it.
2) If you can figure out *what* did the overwriting, you can repoint it in the good rom, THEN do the #1 fix (this way, you get the good rom, but it'll save itself to the new location, thus not overwriting the prior room.
3) If you don't need the room that's crashing, you could simply adjust your mdb list to point to the corrected starting point of the room, then manually (hex) put a dummy room header in that spot so it won't crash smile... Then edit as normal.

Sorry #2 and #3 are both pointer/data adjustments, but it's just the way it is.  I should make smile be able to start an mdb list from scratch, ignoring all existing rooms.  For most people, this would suck.  For everyone else, it would mean the ability to have smile auto-change pointers/data as needed so the headers don't get overwritten.  (Can't do this with the original mdb list, as moving the data around would overwrite stuff at the end).

tbolt76

2009-04-05 08:17:41 pm

well sounds like taking rooms and switching them to other areas is a bad idea time for a change of tactics

UltimateAvenger

2009-04-05 08:32:46 pm

LOL

I wonder...What program would I use if I wanted to change Samus' Animations...Does anyone know? Eh?

tbolt76

2009-04-05 08:40:12 pm

What I orginally wanted to do was take the rooms from tourian that were no longer being used and use them in brinstar to recreate the old areas im guessing that what caussed the runtime errors if theres any way around this let me know