(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
05-04-24 11:30 PM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - A little problem with Metedit... New poll | |
Pages: 1 2 3Add to favorites | Next newer thread | Next older thread
User Post
AlexAR

Ninji


 





Since: 02-27-06
From: TX

Last post: 6287 days
Last view: 6285 days
Posted on 03-18-06 11:31 PM Link | Quote
Originally posted by NetSplit
I don't know much about the items, but regarding your scroll question, there are 2 types of doors. One type will alternate between the two scroll types (horizontal -> vertical, vertical -> horizontal) while the other type will cause horizontal scrolling, regardless of the previous type of scrolling. Thus, it's not Chozo rooms that cause this to happen, but rather the kind of door that leads to them. : )


Hmm, I see. I was getting the scrolling to work, even though I didnt know why it was working. What you said now makes sense. Weird how the help file in Metedit clearly states that its rooms with Chozo statues that effect the scrolling...

Now if I can get a fix on that bomb power problem Im having, I can get to work.
Thanks NetSplit.


(edited by AlexAR on 03-18-06 10:32 PM)
Kirk Bradford Myers

Shyguy








Since: 01-23-06
From: Baltimore, Maryland

Last post: 6580 days
Last view: 6580 days
Posted on 03-20-06 05:40 AM Link | Quote
Originally posted by AlexAR

Why wont the Bomb power up show up in my hack? Its tied to the Y-Map coordinate of another item correct? Of the long beam correct? I moved the long beam down 10 rooms and to the right 5 rooms..the bomb power up should have moved 10 rooms down but kept its original X coordinate correct? I have no other power ups on the same Y line, I can see and collect the long beam but not the bomb power up.



Technically, you are right on the money with everything. I checked that out for you and it does appear that the long beam and the bombs share the same line. Moving the long beam should make the bombs appear where you say they are supposed to. Hmmm...

Can you possibly display a screenshot of the room the bombs are supposed to be appearing in, with an indication of where you want them to appear in that room? I'm thinking it might have something to do with the actual XY coordinate of the item in the room itself. If that's the case, I have a simple fix for it...

As for the door problem, NetSplit pretty much hit it on the head.


(edited by Kirk Bradford Myers on 03-20-06 05:00 AM)
AlexAR

Ninji


 





Since: 02-27-06
From: TX

Last post: 6287 days
Last view: 6285 days
Posted on 03-20-06 07:14 PM Link | Quote
Originally posted by Kirk Bradford Myers

Technically, you are right on the money with everything. I checked that out for you and it does appear that the long beam and the bombs share the same line. Moving the long beam should make the bombs appear where you say they are supposed to. Hmmm...

Can you possibly display a screenshot of the room the bombs are supposed to be appearing in, with an indication of where you want them to appear in that room? I'm thinking it might have something to do with the actual XY coordinate of the item in the room itself. If that's the case, I have a simple fix for it...

As for the door problem, NetSplit pretty much hit it on the head.


Thanks for the reply Kirk. I got the bombs to show up now. I believe the problem was that I was placing the long beam to the right of the bombs. I fixed it in Metedit, no hex editing. Ive been getting some help from Dude Man on the subject as well. In summary he told me that to move items thru hex editing, I should search for a 3 byte string ...

X coordinate on Map of item - item ID - YX coordinate on screen

On an unmodified Metroid Rom, the Morph Ball, the string would be..
02 04 96 Yet Windhex cannot find it. Can your "Simple Fix" help me?
I just want to see if I can move the bomb power down on the screen a bit and see if its possible to "separate" the long beam and bomb power ups and give them their own location data.
Kirk Bradford Myers

Shyguy








Since: 01-23-06
From: Baltimore, Maryland

Last post: 6580 days
Last view: 6580 days
Posted on 03-21-06 07:13 AM Link | Quote
I did a little bit of researching into this for ya...

After pouring over the original Metroid's Brinstar item data, I've determined that giving the long beam and the bombs their own individual line is a quite tall order. Whie it is certainly possible, it would require a complete rewrite/hex editing of the existing weapons data to the point where a sacrifice or two may have to be made. This is because of the fact that the item data is compressed and nicely so into a certain amount of space. In order to give the long beam and bombs their own line without losing anything in the process, we'd have to expand the area alotted for item data...not possible with my level of know-how. Rewriting the item data would also render the editor in MetEdit worthless since it relies on changing specific addresses to do it's little tricks. A bit impractical.

I have, for the most part, decoded the format in which the item data is stored. I plan to put my findings up at Datacrystal.org when I've figured out a few more necessary things. The explanation of how everything works is a bit long winded, though, and beyond the scope of this post...

However, there are a few things I feel that you can do within the limitation presented to you, that being that the long beam and bombs must exist on the same horizontal line. Here are a few options available to you, with necessary addresses that can be edited via a hex editor...

==========

LONG BEAM / BOMBS MAP COORDINATES

6403 = Y coordinate for both the Long Beam and the Bombs
6406 = X coordinate for the Long Beam
640C = X coordinate for the Bombs

You can determine where exactly on Metroid's 32x32 map area these items will appear by changing these bytes. While the first two are editable with MetEdit, the third one determining the separate X coordinate for the bombs is not. You may now use this information above to move both the long beam and the bombs anywhere within the horizontal line they must sit in, the location of which is determined by 6403.

LONG BEAM / BOMBS ROOM COORDINATES

640A = Long Beam YX screen coordinates
6410 = Bombs YX screen coordinates

While the previous information indicates where these items will appear within the game's map, this information above will determine exactly where these items will appear within the rooms they are located in. The first number of the byte indicates the Y coordinate (0-E) and the second number indicates the X coordinate (0-F). For example, you mentioned that the byte that determines the Morph Ball's location in it's room has a value of 96. This means that the Morph Ball is located at screen position 06,09. If I wanted to throw the Morph Ball into the very bottom right hand corner at screen coordinates 0F,0E, I would set the byte that determined it's location to a value of EF. Simple. The same can be applied to the locations above to place these objects anywhere you would like within the rooms they are in.

CHANGING THE ITEMS THEMSELVES

6409 = Long Beam
640F = Bombs

Now, here are two rather interesting little bytes. These bytes are what tell the long beam and the bombs to BE the long beam and the bombs! Interestingly enough, we can tell these items to be any item in the game that we want them to be simply by changing the value of the above bytes. Currently the value of these bytes are 02 (Long Beam) and 00 (Bombs) respectively. Here are the values below to change to...

00- Bombs
01- High Jump Boots
02- Long Beam
03- Screw Attack
04- Maru Mari (Morph Ball)
05- Varia Suit
06- Wave Beam
07- Ice Beam
08- Energy Tank
09- Missiles

Suggest not using any values except for the ones above, as values above 09 shall cause....strange things....to happen...

==========

I know that this information only begins to scratch the surface, but I sincerely hope that you find some of it useful. Take care and good luck on your hack, it looks rather unique!
AlexAR

Ninji


 





Since: 02-27-06
From: TX

Last post: 6287 days
Last view: 6285 days
Posted on 03-21-06 07:17 PM Link | Quote
Now THAT was some extremely useful, well written info my good man Kirk. I read your post, went to my editors, found the offsets, changed em... boom.. instant results with no head-scratching.. A rare occurrence unfortunately. I believe I'm good to go now and should have this hack done real soon. I thank you Kirk and Dude Man. Oh, and it would be great if you could submit whatever information you derive from Metroid to http://romhacking.deadbeat-inc.com/. We could use dedicated people like yourself to register and peruse the forums there as well.
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 03-21-06 09:59 PM Link | Quote
Here is an old doc I made describing the item data format:

http://pages.infinit.net/voxel/MetroidItemData.txt

Preliminary doc about item position data in Metroid.
Version 1.0 2004 By VL-Tone
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

The address offsets for the item data in the RAM and ROM
are: RAM - ROM
A3D6 - 63E6 BRINSTAR ITEMS
A2D9 - A2E9 NORFAIR ITEMS
A26D -1227D KRAID ITEMS
A20D -1621D RIDLEY ITEMS
A83B - E84B TOURIAN ITEMS

To Decode the data:
First read 3 bytes: Y and a 16 bit pointer (lobyte and
hibyte) to the next line data.
The format of the first 3 bytes of each line are:
**[y,lobyte,hibyte]

Then, read sequentially every variable sized item field on
the same horizontal line at Y until skipbyte=FF (check the
tables at the end of the doc for the formats and the
deconstruction of the Brinstar data)



So just after reading 3 bytes for the y position and next
line address pointer:

For each line, scan for each item field on a horizontal line
until the skipbyte=FF then you read the next 3 bytes until
you get to the end of data which looks somethings like
12FFFF where 12 is the last y line position which is not
used and can be any number higher than the last item y line.

So as you scan the lines, each item field has a variable
length and a different format depending on the itemtype as
the table below shows.

This format was probably created so the game didn't waste
too much cpu cycles checking if an item is in a room it
just loaded. This branching scheme only check if the y line
is equal to Samus y map pos. If we found a way to add many
items maybe it could end up slowing the game, by causing
pauses each time a new room is drawn/loaded, I'm not sure
about that since I mostly decoded the data without having a
way to edit it, for use in Metroid Cubed.

Anyway here are the tables:

--itemtype = 02 = power-ups
item field
format=[x,skipbyte,itemtype,powertype,locinroom,00]
powertypes can be:
00-bombs
01-boots
02-long shot
03-screw
04-maru mari
05-varia
06-wave beam
07-ice beam
08-energy tank
09-missiles
0A-glowing lava ball
0B-arrow

--itemtype = 03 = memus (swarming enemies) item field
format=[x,skipbyte,itemtype,00]

--itemtype = 04 = elevators
item field format=[x,skipbyte,itemtype,destination] if the
destination byte highest bit then direction is up.

--itemtype = 0A = palette switch
item field format=[x,skipbyte,itemtype,00]

Here is the Brinstar data grouped in **[line headers] and
[item fields]. The bytes are in the same sequence as in the
raw data, just grouped.

The raw data for Brinstar from A3D6:

02 E4 A3 03 05 04 03 00 0F FF 02 05 37 00 03 F3 A3 18 06 02
09 67 00 1B FF 02 08 87 00 05 02 A4 07 06 02 02 37 00 19 FF
02 00 37 00 07 0F A4 0C 04 0A 00 19 FF 02 08 87 00 09 1C A4
13 06 02 07 37 00 15 FF 03 00 0B 2A A4 12 06 02 09 67 00 16
FF 04 01 00 0E 39 A4 02 06 02 04 96 00 09 FF 02 08 12 00 12
FF FF


Annotated and Deconstructed Brinstar item data from A3D6:

**[02,E4,A3]
[03,05,04,03,00]----[0F,FF,02,05,37,00]
elevator/tourian varia

**[03,F3,A3]
[18,06,02,09,67,00]----[1B,FF,02,08,87,00]
missile energy tank

**[05,02,A4]
[07,06,02,02,37,00]----[19,FF,02,00,37,00]
long shot bombs

**[07,0F,A4]
[0C,04,0A,00]----[19,FF,02,08,87,00]
palette switch energy tank

**[09,1C,A4]
[13,06,02,07,37,00]----[15,FF,03,00]
ice beam memus

**[0B,2A,A4]
[12,06,02,09,67,00]----[16,FF,04,01,00]
missile elevator/norfair

**[0E,39,A4]
[02,06,02,04,96,00]----[09,FF,02,08,12,00]
maru mari energy tank

**[12,FF,FF] <-- End of item data


There maybe some particularities not listed here but I
can't find what.

Also the wavebeam and icebeam could be reversed in meaning, I'm too lazy to check

Anyhow, have fun



(edited by VL-Tone on 03-21-06 09:08 PM)
Kirk Bradford Myers

Shyguy








Since: 01-23-06
From: Baltimore, Maryland

Last post: 6580 days
Last view: 6580 days
Posted on 03-22-06 05:51 AM Link | Quote
VL-Tone...good God! Thanks a million! My biggest question was what those two bytes between the y-coordinate and the first x-coordinate were supposed to point to...you've pretty much answered that question. Hat's off to you!

While we are on the subject of items, I have a couple of questions myself...

I've noticed that the Ice Beam, Wave Beam, and Long Beam items in the game of Metroid can be taken again and again, as they will re-appear when you leave the room. This was probably so the Ice Beam and Wave Beam can be taken whenever one wants and the player will not deadlock themselves by not having the beam they need when they need it. Clever.

Here's my question....what causes this to happen? What makes those three items different from all the others in that they can be taken again and again? The reason I'm asking is because I would really like to set the game so that the Long Beam can only be taken once and then never again. There is really no need for this item to re-appear, as once you have it it is yours for the duration thereafter.

Also, I've noticed that when you move an object in Metroid to a different room on the game's map, the password system seems to no longer be able to read it. This not only includes checking to see if items have been taken, but also works with all other things the password system reads, such as checking to see if doors have beem opened, whether or not Kraid and Ridley have been killed, whether their statues have been hit, etc. I was wondering how this can be fixed so that the password system can check the items and read the other things in the rooms that you select.

For the record, the password system works perfectly in my upcoming hack Metroid Begins only because the new maps were cleverly designed around the doors and items and other things that were already there without actually moving any of these things from their original place. The only thing that I moved was the Ice Beam in Brinstar, because the password system does not read this...it doesn't need to since it is one of the recurring items in the game. The original passage leading to this item is still there, but serves a different purpose entirely...

Any help with the above issues from anyone in the know would be greatly appreciated, and would pave the way for future Metroid hacks...
AlexAR

Ninji


 





Since: 02-27-06
From: TX

Last post: 6287 days
Last view: 6285 days
Posted on 03-22-06 06:41 PM Link | Quote
Ive noticed this issue as well. I have no problem with my hack letting you get the beams more than once, but I do have a problem with the missles. I moved a set of missles to a different room. If the player dies and restarts, the player can collect those same missles over and over. Hopefully, there is a fix available before Im done with level building.
AlexAR

Ninji


 





Since: 02-27-06
From: TX

Last post: 6287 days
Last view: 6285 days
Posted on 03-25-06 05:30 PM Link | Quote
Ive been having alot of difficulties with elevator placement. Is there a way to change "Area" without having to go thru an elevator shaft? What makes the elevator special? Is it possible to change area by just going thru a door?
Dragonsbrethren

440








Since: 12-01-05
From: New Jersey

Last post: 6472 days
Last view: 6472 days
Posted on 03-25-06 06:07 PM Link | Quote
The elevators, as far as I know, are the only time the game loads new graphics and room data. It should be posible to change which area's graphics and rooms an elevator loads.
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 03-25-06 10:30 PM Link | Quote
Originally posted by AlexAR
What makes the elevator special?


That's a quick but very interesting question, here is the very long and boring answer.

This is some theory I made up sometime ago, some of it may actually make sense:




The Japanese version of Metroid was on the Famicom Disk System. Originally Metroid was set to be a game that would utilize the FDS to its maximum and aimed at improving the slowing down sales of the not that popular disk system in its later days.

With 64k on each side it provided a whopping 128k of space that could be used to build a huge world. The writable aspect meant that they could store many details of a game progress, like the status of every red doors in the game.

But, somewhere along the project, Nintendo realized that RAM prices had dropped to the point they could begin to sell 128k cartridges. And just about the same time, they developed a chip, the MMC that allowed the NES to use more than 16k of PRG data in a cart.

So with that in mind, the team/management decided to build the game both for the Japanese and US market. The funny thing is that they ended up trying to sell the Japanese version as a way to sell more FDS, and the Japanese public didn't appreciate that, especially those that found about the US release on a cart.

To use 128k on the FDS, the game would require to flip the disk in the middle of the game to access each 64k side, so the world had to be split in two and swapping had to be minimal. But with the MMC chip, they had another problem, the chips enables switching between 16k chips, but doing this would result in some glitching and flickering. The also ended up fitting all FDS writable data in a password. The FDS version didn't need a password and had better music and sound fx, but that's about it.

The 128k NES cart contained 8x16k chips. They decided to use 3 for the main program and 5 to build separate areas with each their tiles, structures, rooms layouts and music. So Brinstar, Norfair, Kraid, Ridley and Tourian are each contained in one chip on the motherboard of the game. The elevator was chosen as a way to switch areas without to much flicker and problems. On the FDS, there was 3 areas on one side, and 2 (and probably 3, one being repeated) areas on the other side.

One could say that Samus travels from chip to chip on the cart? And to go further in this crazy theory, maybe motherboard+cpu=motherbrain?

As far as I know, the name of the areas and enemies were translated by someone in the Japanese team, not by Nintendo of America. Just read the story in the title screen! Some of the names seems to be clever play on words, something Japanese like to do more than the NOA early translation team. It was stated that the Metroid team was at least in part influenced by the movie Alien, with Ridley Scott being the Director.

If you rearrange the letters from Metroid, you can get ROM EDIT. Since it's the name for the ROM EDITion of the japanese game originally destined only for a disk, and that the game was (almost) secretly constructed with that in mind, so they could also release the NES version, I think this coincidence fits nicely. I suspect that Hirokazu "Hip" Tanaka is behind these names




So, that's what's making elevators so special in Metroid. The same concept was used in Metroid Prime, to reduce disk access, that's why some GC froze in the elevators, since a defective drive was more likely to fail at that point.

Some of what I wrote is not all factual, and some is made from assumptions. But many facts could back up at least some parts of this theory.
AlexAR

Ninji


 





Since: 02-27-06
From: TX

Last post: 6287 days
Last view: 6285 days
Posted on 03-26-06 03:48 AM Link | Quote
.....well I guess I cant argue with that.

Of course I was hoping for something along the lines of..., "Just change offset 0046B1 to 54." But your logic is undeniable so I will just move along.

Thanks.
Kirk Bradford Myers

Shyguy








Since: 01-23-06
From: Baltimore, Maryland

Last post: 6580 days
Last view: 6580 days
Posted on 03-26-06 06:57 AM Link | Quote
Metroid was designed the way it was with it's system of elevators and doors for a reason...because these are good excuses for the game to seamlessly change certain properties about itself.

Metroid cannot scroll in both horizontal and vertical directions at the same time as Super Metroid does, and uses the doors as an excuse to change the prominent scrolling direction.

Likewise with elevators...the game uses these as an excuse to change out banks of music and graphics data since the NES has a limited RAM to work with. In fact, the map data in the Metroid ROM itself makes no indication of the five areas of the game, only room numbers. The job of changing areas lies solely with the elevators. I have used this to my advantage in Metroid Begins to cleverly create a few places where one area with a horizontal passage will intersect through another area's vertical passage successfully by utilizing strategically placed like room numbers!

On an off-note...

I said somewhere in an earlier thread that one day I was going to tackle Metroid's music, something seemingly as of yet untouched by most ROM hackers. As I am a musician at my heart, this was inevitable. Since I at least knew where the data for the title screen theme was located, I decided to see if I could make heads or tails of it. I was pleasantly surprised to see that, despite the fact that the music is somewhat compressed, that the format that it was written in was a breeze to figure out, and that editing it would be no harder than creating new room data from scratch! I'll put it to you this way...I've beem playing keyboards and piano for almost twenty years now, and I had a harder time programming the sequencer on a Korg 01/Wrd synthesizer to play an original piece of music that I wrote than I had reprogramming Metroid's title theme to play "The Devil Went Down To Georgia"...

As it stands, I have been mucking around experimenting with things for the past couple of days to the point where I could practically write new and original music for the game. Of course, there are still a few things to figure out, but believe you me, I'm digging!

I am doubtful that any music will be hacked for Metroid Begins due to time constraints on the expected August 6th release date and the fact that Metroid Begins is pretty much a Metroid 1 remake and I can't therefore justify mucking around with one of the only things in that game that Nintendo did right. As they say, if it ain't broke, don't fix it! However, I will continue my research into this, and once I get the format completely figured out I'll try to post my findings in a separate thread. Stay tuned...


(edited by Kirk Bradford Myers on 03-26-06 05:05 AM)
Dragonsbrethren

440








Since: 12-01-05
From: New Jersey

Last post: 6472 days
Last view: 6472 days
Posted on 03-26-06 07:41 AM Link | Quote
Originally posted by Kirk Bradford Myers
I have used this to my advantage in Metroid Begins to cleverly create a few places where one area with a horizontal passage will intersect through another area's vertical passage successfully by utilizing strategically placed like room numbers!


Heh, that's clever, I was considering making all the rooms of the same number similar in my hack, incase someone felt the need to go "secret world" hunting in it, I never even considered making the areas intersect like that.
VL-Tone

Paratroopa








Since: 11-18-05

Last post: 6475 days
Last view: 6475 days
Posted on 03-27-06 12:04 AM Link | Quote
Here is my very old online Shockwave demo of a Metroid Music editor that was never released.

http://pages.infinit.net/voxel/metroidmusiceditor.htm

It was based on Acmlm's (himself) findings, though I had to figure out some stuff he didn't. I'll try to dig the old text file and post it here.

The demo is a little unstable, buggy and unfinished, and it doesn't actually edit the ROM data, but rather some included copy of the music data (not 100% ethical, but whatever, I'm sure Tanaka doesn't mind... I could ask him, I know how to contact him.).

Even in its current state, the editor could still be very useful to you to help you figure out the format. You can hold the ctrl key to get the hex value for each commands.

I'm sure you would want me to publish the finished editor so it could help you meet the deadline, but I have other projects that I have to work on, like the SM64 editor... Maybe I'll have time this summer.


(edited by VL-Tone on 03-26-06 10:05 PM)
Kirk Bradford Myers

Shyguy








Since: 01-23-06
From: Baltimore, Maryland

Last post: 6580 days
Last view: 6580 days
Posted on 03-28-06 04:38 PM Link | Quote
Vl-Tone, is there any thing you can't do to a Metroid ROM?!?

Your little music creation thing there is limited in it's scope, agreed....but it's going to be a big help in editing Metroid's music for future hacks. My biggest problem wasn't figuring out the format...at this point, I pretty much had that nailed. The problem was finding the data for all twelve songs in the ROM. As it is now, all I need to do is copy the hex equivalents and pretty much perform string searches in XV132 to find this stuff. Thanks a million for your help.

The only problem I have left to figure out is how to change the sonic "properties" of the NES's four voices. For instance, the main lead instrument in the title theme has a tendency to reverberate, and sounds like a piano in an echo chamber. But in Ridley's music, the main lead sound has a "backwards" thing going on with it, slow on the attack and quick to cut off. Yet in Kraid's lair, the lead instrument is pretty much solid on/off notes with no embellishments...

I ned to find out what is setting the "properties" of these four instruments, so some REAL music editing can take place, stuff that would sound much different from what was originally there..
AlexAR

Ninji


 





Since: 02-27-06
From: TX

Last post: 6287 days
Last view: 6285 days
Posted on 03-30-06 02:38 AM Link | Quote
Originally posted by Kirk Bradford Myers
Vl-Tone, is there any thing you can't do to a Metroid ROM?!?



No kidding, Vl-Tone, you are a beast. My Metroid hack is now gonna take even longer to release since I now want to change up the music with the help of that shockwave.

Anyways, I am fairly confident Kirk or Vl-Tone should be able to help me out here. I start playing my hack..go down the elevator to Kraid's Lair...I then die and respawn in a garbage room. In the original, Samus respawns at the elevator. Apparently the respawn point is not tied to the elevators, so is there an offset defining where Samus's respawn point is? There would be five such offsets for each of the Zones?
Dragonsbrethren

440








Since: 12-01-05
From: New Jersey

Last post: 6472 days
Last view: 6472 days
Posted on 03-30-06 03:02 AM Link | Quote
In MetEdit shift-left click any room in that area on the map to set it as the starting point.

Edit: A little late, but it's actually Shift, not Ctrl.


(edited by Dragonsbrethren on 04-06-06 07:54 PM)
Mega-Dog



 





Since: 11-19-05
From: Minnesota

Last post: 6306 days
Last view: 6288 days
Posted on 03-30-06 07:12 PM Link | Quote
Originally posted by Dragonsbrethren
In MetEdit ctrl-left click any room in that area on the map to set it as the starting point.


Make sure you are in the correct area you want to make it also...cause if you are setting it for Nofair and you are editing in Brinstar I belive it doesn't work.

Also there is a way to move Samus beam down spot for starting...I did it in Metroid M2 but it has been awhile since I did it...I can look into it if anyone is interested.
AlexAR

Ninji


 





Since: 02-27-06
From: TX

Last post: 6287 days
Last view: 6285 days
Posted on 04-05-06 09:57 PM Link | Quote
Hello again. Guess what...I have another problem, but that's what these forums are for right?....I greatly appreciate all your help guys, you've answered every one of my questions and I'm ending up with one kick -ass Metroid hack because of it.

I'm sure at least one of you guys (Kirk, VL-Tone, Mega-Dog, Dragonsbrethren) has had to move the High Jump boots location for your respective hacks. So far, with all the info you guys have given, Ive been able to move most items along with their respective same line items thru hex editing. But not the damn boots. They are tied to a palette switch room in Norfair, at least that's what it seems like.

In Brinstar, the code for its palette room item and energy tank that's on the same line reads...

07 0F A4 0C 04 0A 00 19 FF 02 08 87 00

nice and simple to understand
I was able to move the energy tank several screens to the right by changing 19 to 0F
no problem

In Norfair its palette room item and boots code reads...

11 6D A3 16 04 0A 00 18 09 31 0B E9 41 02 9A 00 19 09 21 8B E9 51 02 9A 00 1B 06

02 01 37 00

01 is the boots right? why is there so much more crap in this?
1B is the X coordinate on the map right? I changed it to 19...it didn't move the boots...

How did you guys move the boots?
Pages: 1 2 3Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - A little problem with Metedit... |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.023 seconds; used 480.42 kB (max 617.09 kB)