having an issue with making a hack for Metroid,

I've tried to make a simple "column" where samus will fall downward for a few screens however, when I try to do so, the floor (despite having no objects there) functions as if it is lava (ie samus' falling speed decreases, damage is incurred) and she falls back to the top of the screen.

Looked through the MetEdit/Editroid help, did a quick Google search, and one of this forum, to no avail.

Editroid seems to make the rooms default horizontal scrolling...ie invisible infinite death floor.

ahhhhh I'm sorry, in the exuberance of receiving a response I thought it meant something totally different, but what you said works.

I did a few more tests with Editroid and it seems that by default when you add a room to the map the room number it is given is "FF" which is out of the range of possible rooms for each area (0 to 2d) and when you get to the "ceiling"/"floor" of one of these rooms (ie that room is next if you are falling downward or climbing upward respectively) then the scrolling stops.

thanks again!

sorry for my incompetence

I'll be able to verify this soon once I go into the ASM that SnowBro "reassembled". It doesn't seem to matter where the items are, at least to Editroid, if you have a room with a right door and one with a left door or vice versa then when you go to the next room the scrolling has switched.

I'm going to venture a guess that it is in the subroutine that scrolls the screen over to the next room when you enter a door changes whatever flag that controls which way the scrolling goes. I'm guessing this because your locked in the corridor from door to door so the computer has time to do something quick like that. if you test out the impractical case where there is a right door and no left door on the other side you'll notice that you can shoot and enter the door and the scrolling stays the same (and you are trapped in said room  :banghead:)
There's probably some subroutines somewhere that do this: Where is samus at? >>  If she's at an opened door then make sure there's another on the other side >> if there is then move the screen into it >> change scrolling direction while the user has no time to move and see us do this secret magic >> done

Not sure if you mean a preset amount of rooms as in each area has different "compositions" that is limited to using, or the whole game...but regardless, it just means that you have to add bullshit doors sometimes to suit your designs.

This is kind of related, but a really interesting youtube video about "glitch worlds" you access by going through doors incorrectly...

http://www.youtube.com/watch?v=Oq5pRsdq_eE

I think most people know about this in Metroid or have at least heard of it (I took the game out to beat it a year or two ago and couldn't get this to work, I'd already spent so many hours of my life trying to re-charge my life meter that it just got so tedious)...but anyway around 5:13 he finds "lava that doesn't do anything to you" because of how the scrolling didn't switch. A really good video anyway.

(also sorry for whatever reason, the verbosity switch gets turned on for me when I don't sleep)

With regards to the precise design of such a hack, I assume some sort of "check value at location $(ABCD), y" would come into play during the bubble-door routine. The question is, how should such an offset table be designed?

Metroid's geographical layout consists of a 32x32 room grid (including the empty "pictureframe" around it). To assign a special bit to each room would require 1024 bits, which is 128 bytes. I could not find a section of empty space (all $FF's) during my scan of the Metroid ROM. The best I could come up with was a 48-byte snippet at $19980.

It might be more efficient to somehow encode the H/V scrolling status into the screen type byte itself. Screens seem to be defined by values in the range of $[00-2D]. This means at least six of the eight bits are utilized in determining screen layout itself.

As a lark, I redefined the byte which assigns layout to the first screen in the game (where Samus teleports in, just next to the MaruMari). The screen's original ID is $09; using our two potentially-free bits, I assigned values of $49 and $89 to this spot. Neither crashed the game, but it was the latter that resulted in no observable difference in gameplay. ($49 resulted in a screen of near-nothingness, save a small partial platform at the top of the screen and a pool of invisible lava at the bottom.)

More research will be required to make sure that Bit 7 of the Screen Type bytes isn't already utilized for something, but I think something along those lines will be the most efficient way of bringing about selective scroll-control.

The actual ASM routine would be rather simple:

[Samus enters a bubble door; the game starts going through it's usual routine; at the point where scrolling is affected, we insert something like this:]

LDA_zp: $GH        (I'm assuming there's a zero-page location for "screen type we're going to".)
AND_imm: $80
BNE: $07              (Let's assume a set 7th bit denotes vertical scrolling.)
LDA_imm: $00
STA_zp: $JK         (This will be the byte the original game uses to determine scrolling. Again, I'm assuming a $00 results in horizontal.)
JMP_abs: $LMNP   (Whatever routine the original game goes to after determining scrolling.)
LDA_imm: $01      (We wind up here if the logic gate yielded a non-zero result.)
STA_zp: $JK         (Let's make the next screen scroll vertically!)
JMP_abs: $LMNP

The beauty of this is that it would come into play ONLY during a bubble-door transition, allowing for "more clever/experienced hackers" to create intersecting maps. (A screen which scrolls vertically when entered via Brinstar, but horizontally when entered via Norfair.) I must admit to being rather n00bish in my knowledge of Metroid from a hacking standpoint. I *do* fully intend to create a full-fledged rewrite sometime prior to 2015, and something like this routine will be a veritable certainty. That said, I'd love to hear from a veteran Metroid hacker on this topic. 

If not, one could always create such a value at an unutilized location in RAM (zero page, if possible).

You know how mathematicians assign names like "x" and "y" to unknown values? I didn't want to do that, since it might create confusion with the x and y registers. So I used letters of the alphabet not associated with registers or hex numbers A-F. Starting at G and omitting vowels, I got about halfway thru the alphabet.