Posted by CyclopsCaveman

---

I'm sorry, but it's very hard for anybody to even make out anything from your posts, would you mind repeating the question with clearer English? Pardon me if English isn't your first language.

---

Posted by Insectduel

---

Then it must be the first door you wanted. You basically click "Use Current Screen" where you put the door screen at in your editor.

If these options don't work use the following ROM offsets. Correct me if I'm wrong.

Graphic Sets

$1D06E The first set of doors. (First 6 levels only)
$1D07D The second set of doors (Indexed by each stage ID)
$1D088 The boss set of doors (Indexed by each stage ID)

Door Opening Sets

SecondDoorLocations ;at $19F07
.byte $16,$16,$FF,$12,$FF,$11
.byte $FF,$FF,$FF,$22,$20
FirstDoorLocations ;at $19F12
.byte $13,$13,$13,$0F,$13,$0E
.byte $FF,$FF,$FF,$FF,$FF

---

Posted by brawlman9876

---

alright new problem, when i put the conveyor belt sprite from Guts mans stage where the conveyor belt line is, it makes a noise but the sprite doesn't show up, why dose it do this?

---

Posted by NetSplit

---

This is incorrect; it's possible that your sprites are out of order, but that's unlikely (you'd probably have to have your sprites set up pretty weird for that). Sprite ordering is one of the potential triggers for what is probably causing the bug, though, which is that moving platforms each look for sprite #$2C in a specific sprite slot. Basically, when the game comes across #$2C, it will activate the moving platforms that are associated with that by going through a moving platform list and comparing for equality the #$2C's sprite slot to the sprite slot value for each platform in the list. If equal, it activates that platform.

Your problem sounds like two things. Firstly, you think that #$2F is the sprite for moving platforms, but it's not; it's just for the sound effect. #$2C is the moving platform initializer sprite. Secondly, for the Guts stage moving platforms, #$2C needs to be in sprite slot 0; that is, it needs to be the very first sprite on the first screen. I don't remember if its vertical position matters or not, but it might. Its usual vertical position is #$FF (the very bottom of the screen). If it winds up mattering and you can't set that in Rock and Roll (if you can, I don't know how or I have an outdated version), go to $1A4C6, reverse those two bytes (in the original game, they are 41A8, so you'd get A841), add 10010 to it (in this case, A841+10010 = 1A851), and go to that address. That's the location of the start of Guts Man's sprite data (sprite slot 0). That is the one that needs to be that #$2C sprite. First byte is the screen number (should probably be #$00), second is the x coordinate (#$80, by default. I highly doubt it matters), third is the y coordinate (#$FF by default. I don't know if it matters, but I'd keep it #$FF just in case), and fourth is sprite ID (#$2C). So, in the original, slot 0 would be 0080FF2C. Set it up like that and it should work fine.

You will almost certainly run into trouble if your moving platforms aren't in the first scroll area of the stage (the first corridor) and you have sprites before then. I'm pretty sure the #$2C sprite must be on the first screen of the scroll area that has the moving platforms (although I might be wrong. The original game definitely sticks to this reasoning, though). So, if the scroll area starts on screens 1 or 2, then change the screen number of that #$2C sprite accordingly. Having sprites beforehand would mean you'd have to change the sprite slot for the platforms you want to appear.


Also, assuming you don't know much about sprite slots: The sprite slot is determined by the ordering of sprites in ROM, not based on the apparent ordering in-game or in the editor. You can put sprites in any order in the ROM, but that can have undesired effects. Basically, when the game is going through the list of sprites to place them in the game, it goes through them in order, expecting that the next sprite it places is the next one Mega Man will come across. That means that if it isn't, then sprites that should be the next one Mega Man comes across (based on how it looks in the editor) won't be placed because the game will be waiting for the later sprite before placing the earlier ones. When it does get to that sprite, it will then see that it should have placed the others, so they'll appear on the screen at their proper locations at the same time (read: enemies will probably appear out of nowhere in the middle of the screen). As far as I know, Rock and Roll doesn't support automatic sprite ordering (meaning you need to be mindful of the ordering of these things yourself), though it probably should; it's the most common problem I see in Mega Man hacks because no one cares enough about fixing it. Fx3's Mega Man 1 and 2 editor, visine, supports automatic sprite ordering as an option when saving (as it should); out of order sprites can be a useful advanced feature if you know what you're doing. The drawbacks of visine are that it's DOS and that it might be a tiny bit buggy or, at least, intolerant of extensive changes to the game (beyond just straight data changes, so you're probably fine). For the most part, though, it's a good editor that I recommend in addition to Rock and Roll.


I hope that all helps.


Edit: Also, it sounds like you might not know much about hex editors.. Basically, all files on your computer are made up of bits (0's and 1's - binary) that encode everything, where most things are some number of bytes (1 byte = 8 bits). They mean different things in different places, and what matters is how they're interpreted. A hex editor lets you open up a file and view the binary that makes up file, viewed primarily in two-digit hexadecimal (hex) numbers instead of binary (so base 16 instead of base 2. That's 0-F (0-9 followed by A-F) instead of 0-1), since it's easier for people to deal with a lot of this stuff in two digit hex numbers than it is in 8 digit binary ones. In short: they let you view and edit the data in a file as hex numbers.

Each byte in a file has an address associated with it. So when we give you an address, we're telling you which byte you can change to change some aspect of the game. Rock and Roll does all of this under the hood; when you change something, it's really making one of these changes that you can do on your own with a hex editor. It's just making your life easier by making it visual and giving you an interface that's usually better than just changing numbers in a hex editor.

If you don't have one already, you should go grab a hex editor so you can fiddle with the bytes in your ROM (though make sure to make a backup before doing this, especially if you're inexperienced. It's easy to mess something up if you don't know what you're doing, but don't let that deter you). I use Hex Workshop, but I'm sure there are good free solutions available; you'll have to try some out for yourself or ask around. You can find a lot of them at this page on romhacking.net. You might want to check out WindHex32 or Thingy32 first.

---