 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by beneficii |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
| User | Post | ||
beneficii Lakitu Level: 36 Posts: 101/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by Sion I don't think that he thought he was introducing a new technique.... |
|||
|
beneficii Lakitu Level: 36 Posts: 102/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| geter, Hey, you need to change your background picture. I can't read your message without selecting it. EDIT: Read the FAQ btw. EDIT 2: Welcome to the board, btw. (edited by beneficii on 06-03-05 11:12 AM) (edited by beneficii on 06-03-05 11:18 AM) |
|||
|
beneficii Lakitu Level: 36 Posts: 103/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| You may want to familiarize yourself with asm. Also, you don't know which of those bytes caused a change and the data could be in chunks, so experiment with different things. Try to find the first byte of a stage too. | |||
|
beneficii Lakitu Level: 36 Posts: 104/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| Hmmm, I remember my EarthBound game deleting on its own if I didn't play it for a few days. I don't know if it still does that now. | |||
|
beneficii Lakitu Level: 36 Posts: 105/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by paraplayer Does free will equal randomness? |
|||
|
beneficii Lakitu Level: 36 Posts: 106/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| I found a chunk of code that I believe is related to the locks in SMB3. I'm trying to find the code that goes before this code, and I'm trying to find the later ASM that uses the values stored by this one. Note that the bank of code starting at the Rom's 14010 and lasting 2000 bytes is stored at bank C000. To convert an address found here to the ROM address. In the comments, all numbers mentioned are in hexadecimal unless otherwise specified. But here goes: This code starts at 148DD in the ROM, C8CD in the game's memory: DEC $0745 LDA #$80 STA $04F2 LDY $0727 LDA $C898,Y //These values seem to increment by four lasting 10 bytes. CLC ADC $0745 TAY LDA $C878,Y //These values seem to affect what happens down the code more--keep an eye out for where the value here is kept stored for the whole code from here: $0745 STA $0745 LDA #$01 STA $20 //This'll come up shortly LDY $0300 LDX $0745 // I'm guessing that this is the current lock number, but I'm not entirely confident in this LDA $C7BD,X //Change the value of the first one (which seems to affect the first lock) and there are weird effects on the first lock when it is unlocked; changing it seems to change wildly the position of graphical change STA $0A STA $0301,Y INY LDA $C7CE,X //The arbitrary values here affect the position where the new tiles will replace the old ones; I was able to get this to actually replace a lock in a different position from the original, but I couldn't make the graphical change stick after Mario entered another stage; there is obviously another piece of data missing STA $0B STA $0301,Y INY LDA #$02 STA $0301,Y INY LDA $0745 ASL ASL TAX LDA $C801,X //C801 seems to be the 4 8x8 tiles that replace the lock (try modifying them--you'll notice that it does change the graphics that replace the lock), with the first byte being the upper left, then upper right, then lower left, then lower right; it has been somewhat interesting trying to change the values of these; set them to 0 and you get weird dancing hills; STA $0301,Y INX INY LDA $C801,X STA $0301,Y INX INY LDA $0B CLC ADC #$20 STA $0B LDA $0A ADC #$00 STA $0A STA $0301,Y INY LDA $0B STA $0301,Y INY LDA #$02 STA $0301,Y INY LDA $C801,X STA $0301,Y INY INX LDA $C801,X STA $0301,Y INY LDA #$00 STA $0301,Y STY $0300 LDA $0745 ASL TAY LDA $C7DF,Y //Try changing these values; they have interesting effects actually; STA $0A INY LDA $C7DF,Y STA $0B LDY $0A LDA $7D00,Y //I believe that if C878 were set to 0 (as it seems to be for most locks), then it loads from $7D06 to be exact; of course, what this piece of code does is a bit confusing, so it might be helpful to try to find what stores to this address; but I find using nnesterj that during most gameplay, this is zero; after finishing the first fortress and as the code changed, 7D06 changed to 8 then finished at 18 and stayed that way AND $0B BNE SAFETY //I'm not sure what this about, but it is dependent on C7DF + 1 + (current lock number?) and the value at 7D00 + )value of C7DF+ (current lock number?)); if any of their bits match up, then you ride the BNE to the next desitnation and skip the whole next piece of code; LDA $7D00,Y ORA $0B STA $7D00,Y LDA $7D40,Y ORA $0B STA $7D40,Y LDX $0745 //Keep an eye on X LDA $C856,X //The screen data at the low nibble? AND #$0F ASL //This doubles the screen data value TAY //and transfers it to Y LDA $8000,Y //I think checking the second-to-last-bank of this PRG-ROM could be helpful; I noticed in the RESET routine of the ROM that the two last 8k banks of the PRG-ROM are hardwired to 8000 and E000; apparently, the screen data is important to this, but the values are woefully random and are hard to make any meaning of CLC ADC #$F0 STA $0E LDA $8001,Y //Another interesting set ADC #$00 STA $0F LDA $C856,X //X data as posted by Dahrk Daiz, but does not affect graphical change LSR LSR LSR LSR ORA $C845,X //Y data as posted by Dahrk Daiz, but does not affect graphical change TAY LDA $C867,X //Tile data as posted by Dahrk Daiz; this does not seem to change the graphic, it only changes the passability to the matching map tile STA ($0E),Y //Y data affects where exactly this is stored; it seems an address was stored here; all addresses you access seem to be on the SaveRAM; LDA $15 AND #$03 BNE SAFETY2 //I'm not sure what address 15 is about, but if it's 3, then you get to skip the BNE; INC $20 LDA $20 CMP #$07 BEQ SAFETY SAFETY2: LDY $0745 LDA $C845,Y STA $00 LDA $C856,Y AND #$F0 STA $01 LDY $20 JSR $ABCF //I'm not sure which bank is currently attached to A000, but I'm guessing the one before this (I'm not entirely sure how PRG-ROM is attached, if both both 8k banks have to be consecutive); unfortunately I've not ventured down this line of code yet; JMP $CF29 SAFETY: LDA #$00 STA $0745 STA $20 INC $0729 JMP $CF29 //Meaningful lock code seems to end here; I'm not sure what the other stuff below this line is for LDA $0711 AND #$04 LSR LSR ORA #$18 STA $16 DEC $0711 RTS These are my observations thus far. It'll be interesting to hear the inputs of others. Solving the locks mystery will be difficult, I think. EDIT: I've done some more experimentation as regards locks in SMB3. Observe the photo:  There is a lock two spaces below where it normally is, while where it normally is is replaced with sand. The first level has been replaced by a fortress.  After completing one fortress, you can see a little green glitch southeast of that fortress. This is the graphic that was supposed to be changed into. I deliberately messed up the position where it was going to be. The lock remains and the sand dune remains.  See? You can pass the lock, because that position was not messed up.  This was after dying once, which unfortunately made the lock unpassable again and got rid of the green glitch. Interestingly, it did not change the sand to a road (or anything else), which confuses me. I would think the sand would be replaced with a road (or the green glitch), because I thought the game does that every time the world map is reloaded. As you know, I thought the issue was that it was simply redrawing the road to where the lock originally was (and redrawing everything to their original spaces), but that does not seem to be the case. Do you guys know what I'm saying? What is going on? (edited by beneficii on 06-07-05 01:32 PM) (edited by beneficii on 06-07-05 01:33 PM) |
|||
|
beneficii Lakitu Level: 36 Posts: 107/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| Emperor Ziffantine, Uh, the U.S. is doing far better than Europe (though not as well as China). Though the U.S. has a burdensome system too and has issues with budget deficits, the E.U. government is far more burdensome on the economy, and many European countries are having problems experiencing growth. I think German unemployment is now up to 5 million. (edited by beneficii on 06-07-05 09:38 AM) |
|||
|
beneficii Lakitu Level: 36 Posts: 108/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| Emperor Ziffantine, I'm just waiting for the Europeans to figure out that you don't need a giant bureaucracy to have free trade. Unfortunately, many elsewhere also seem to be forgetting that lesson. I'm glad that the world has followed a more decentralizing pattern lately, with business networks becoming more prolific (and top-down hierarchies in business becoming less and less common), and with the decline and fall of superstates like the Soviet Union (and possibly the European Union, and even possibly the United States). I think the central governments of both the E.U. and the U.S. are in decline. The E.U. government is a huge, dysfunctional morass separated from its citizenry, while the U.S. government is a bit closer to its citizenry, but still a huge, dysfunctional morass deep in debt. I think we're going to be entering into an era, in which the international system is more like the 19th century than the 20th. (edited by beneficii on 06-07-05 10:18 AM) (edited by beneficii on 06-07-05 10:19 AM) |
|||
|
beneficii Lakitu Level: 36 Posts: 109/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by Jigglysaint What a pain, LOL. As of late, my leads have been getting worse and worse. I know that World 1 at least in RAM is stored at 6100 (and that its location is stored at 8000, which in the ROM file is 3C010, in two bytes as 6000 and that the location is copied--often with slight alteration--to 63). When I beat the fortress, the corresponding tile there changes, but when I die and come back to the map, the old tile (the one I wanted changed) comes back in the memory. A pain. But I'm trying to figure it out. (edited by beneficii on 06-07-05 05:12 PM) (edited by beneficii on 06-07-05 05:15 PM) |
|||
|
beneficii Lakitu Level: 36 Posts: 110/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by Emperor Ziffatine The 20th century was the one with all that, and the 19th century was relatively peaceful, especially in Europe, which was decentralized then. I think the 20th century was so violent because of ideologies that favored extensive power in central governments in order to attempt to force unwilling societies to conform to the ideologues' desired mold. (edited by beneficii on 06-07-05 05:53 PM) (edited by beneficii on 06-07-05 05:56 PM) |
|||
|
beneficii Lakitu Level: 36 Posts: 111/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by Smallhacker As regards this, I've always wondered about the nature of the user. You know how you are viewing things and can control them; you are receiving information from the outside and sending information out. I've always wondered about the user. Some may say it's an illusion to fool you that you are a user somehow separate from your body, but I say if there's no user to fool, then why bother? The fact that you are seeing all this shows that you as a user exist, and you're not necessarily tied to your current body. |
|||
|
beneficii Lakitu Level: 36 Posts: 112/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by Emperor ZiffatineOriginally posted by beneficiiOriginally posted by Emperor Ziffatine The twentieth century was far worse: World Wars I, II, the various Cold War conflicts, several mass slaughters of people by their own governments, and various ethnic cleansing conflicts between peoples occured because of increasingly centralized control. Take the ethnic cleansing, in the 19th century European governments came to Africa and drew irrational boundaries, forcing different ethnic groups under a single system, while even splitting ethnic groups among boundaries. The Europeans could keep peace for a while, but their rule caused increasing tension amongst the peoples living in their colonies and you can't keep the peace forever. Eventually their control snapped and the tension was released. The same happened in Yugoslavia, as various different ethnic groups were forced under a single regime, with tension growing between them. When Yugoslavia could no longer stand, that tension was released, and you have the brutality that occured in the 1990s. |
|||
|
beneficii Lakitu Level: 36 Posts: 113/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| EDIT: I have updated the hack. Some pretty embarrasing mess-ups on the airship have been fixed. I also changed the airship retreat points so the thing doesn't fly off and become inaccessible. I have solved a problem that I believe no other SMB3 hacker has solved and the solution has been implemented in this hack! The Hammer Bros challenge you! "Chousen!" they say. Go to Level 3 to answer. Now for some screenshots followed by the link:      http://www.freewebs.com/beneficii/uba.ips "I wonder where the newspaper boy is. I was hoping he'd come and bring me some good news." (edited by beneficii on 06-11-05 04:07 AM) |
|||
|
beneficii Lakitu Level: 36 Posts: 114/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by Heian-794 Indeed it is. There are actually three kanji spelled in coins: 決闘状 【けっとうじょう】 kettoujou "dueling challenge" Play through and you'll find it. BTW, the second kanji is very detailed and was hard to write in coins. Check to see how I did.  |
|||
|
beneficii Lakitu Level: 36 Posts: 115/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| EDIT: Looking back over this, I see it was poorly written. Let me edit it a bit. EDIT 2: It's not confirmed yet, but it looks like there is a fixed number of locks per world: World 1--1 lock 2--1 3--2 4--2 5--2 6--3 7--2 8--4 Because of this, don't go over the number of locks for each world. ------ Okay guys. I'll come out and say it. If you want to change a lock's position in the game SMB3 for the NES and have its being cleared stick, here's what you do. Note that, unless otherwise mentioned, all numbers mentioned are in hexadecimal. First, note that lock type A is for vertical roads, and lock type B is for horizontal roads. Second, here are the addresses of particular tables in the ROM. There are 10 different lock positions in the game (so there are 10 chunks per table). The first lock is broken when you finish the first fortress (wherever that may be), the second the second fortress and on the same map and (presumably) same screen as the fortress you finish, so you may want to make sure players can only complete fortresses in the order you want. I think it would be instructive to find out how the game deals with a warp whistle, because fortresses and locks are skipped when you use it, so I wonder how the game skips over them, if there is a fixed number of locks per world (which would be a problem) or if the game simply counts the number of fortresses, etc., actually present in each world it skips (which would simplify things). Third, I have not experimented with breaking a lock on a different screen. I'm going to do that next. Also, a vertical river (like those in Worlds 4 and 5) can be used instead of a lock. I believe other types of tiles may be used. I sorta know where to find them out. Since I gotta leave in about 10 minutes, I'll check that out later. Basically, you use clearable tiles, tiles that change after you "clear" them. Here are the starting addreses in the ROM for each of the tables: 147CD, each chunk lasts 1 byte and represents the high byte of the address to the name table where you'll draw the graphics that replace the lock: By the way the world map is drawn, the value here must be either 28, 29, or 2A. Anything else'll just not work. To find the exact value of both bytes of where to put in the name table, open up the Discombobulator or Workshop, get the x and y values of where you want to draw to replace the lock, and use the result from this formula: A = 2880 + 40 * y + 2 * x The A value is what you want to use. 147DE, 1 byte each, represents the low byte for the address to the name table, gotten from the formula above. Put the low (less significant) byte in. 147EF, 2 bytes each, setting the "cleared" tiles. This is the one that everyone missed. This maintains the lock has "cleared" (i.e. replaced with a road), "cleared" like a level is cleared, after you enter another level. Each chunk has 2 bytes. The first byte of a chunk is as follows: ssss xxxx s=screen number x=x position The second byte depends on your y value. Depending on your y value in Discombobulator or Workshop, here's what you put for the second byte: y= 0--you put 80 1--40 2--20 3--10 4--08 5--04 6--02 7 or 8--01 And that's it. 14811, 4 bytes each, 8x8 tiles to put to name table. The first byte is upper left, next upper right, next lower left, and last lower right. There is a variety of values, but here are some preset ones you'll find useful: FEC0FEC0 vertical road FEFEE1E1 horizontal road D4D6D5D7 horizontal bridge 14855, 1 byte each, y position to put explosion and same passability as new tile. The byte works like this: yyyy 0000 y = y position in Discombobulator or Workshop + 2 14866, 1 byte each, x position'. The byte works like this: xxxx ssss x = x position of lock s = screen number of where the lock is 14877, 1 byte each, tile number to imitate passability of after clearing the lock. There are some different ones you can use, along with the lock tile that when cleared switches to them: 45--horizontal road, used with tile 54 (lock A) 46--vertical road, used with tile 56 (lock B) B3--horizontal bridge, used with tile 9D (vertical river) DA--horizontal road, second palette, used with tile E4 (lock B, second palette) And that's it! I believe this works with every lock in the game (I've checked most of the chunks in the table--including the ones in World 8--and they match up!). Check it out for yourself! Oh, and editor makers, implement this! Remember, when a locked is cleared, there is a set tile that the lock (depending on its type) reverts to. Lock A always reverts to vertical road, lock B to horizontal road, The vertical river to horizontal bridge, etc. Now on to setting airship retreat positions and to finding out exactly how to work pipes! (edited by beneficii on 06-10-05 04:14 AM) (edited by beneficii on 06-11-05 12:34 AM) |
|||
|
beneficii Lakitu Level: 36 Posts: 116/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| Myster Mask and Kefka, I may throw in different sayings as I hack the game, and I may revise stuff. I'll probably end up making a complete hack, btw. Bascially, the problem that I solved was moving the lock. I believe this is the first SMB3 hack that actually moved the lock. Acmlm, It took me a little while, but I finally did find it out. Here is the path I took to finding it out: First, I started with the addresses Dahrk Daiz posted (I'm not sure if I could have done it without him. ), which set the position of the explosion and made the tile passable for one turn. I found the nametable data and the 8x8 tile replacing data. I looked to see where they were referenced and found the code not too far away. The code still wasn't helpful though, for there still was a piece of data missing. I did find the 148EF data, which proved to be what was missing, but I didn't understand its importance, or how to work it.I found that the world map data was stored at 6100, and I noticed that the tile that the lock was originally at was stored at 6144. I decided to find the piece of code that did the replacing. I finished the dungeon, then went to another stage and died. After I died, but right before the screen went black to reload the world map, I performed a trace using FCEUXD and saved it to a text file. I opened up the text file and hit Ctrl + F to find "@ $6144" (when Y or X is added to an accessed address, the address that was actually acced shows up as "@ address" in the traced ASM). I looked at the code around it, and I saw that another piece of SRAM was accessed, the 7D00 area. I noticed that 7D04 was accessed for purposes of the lock. I played the game, opened up the main memory viewer, looked for changes to the 7D00 area, and sure enough I found them. I saw that this is where the "stage cleared" information went, and I also saw that locks and fortresses cleared data went to the 7D40 row. The x value of the cleared tile determined 7D0X, where X is the x value of the cleared tile. The y values of the stage cleared was ORed to 7D0X. 80 was ored to it if y was 0, 40 if y was 1, 20 if y was 2, 10 if y was 3, 8 if y was 4, 4 if y was 5, 2 if y was 6, and 1 if y was 7 or 8. I noticed that the lock was referenced at 7D04 and 7D44 as the 10 bit. At that point I made the connection between the data at 148EF and this. I changed up the data there, put a Level 1 tile at the spot referenced by 148EF, finished the fortress, and sure enough it was "cleared." I then assembled a new hack, tested the lock like that, and it worked! I had found how it was done. |
|||
|
beneficii Lakitu Level: 36 Posts: 117/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| EDIT: BTW, the same position is often repeated many times throughout the level data. It's very redundant. NOTE: All numbers in hexadecimal unless otherwise mentioned! First thing, the airship start-off point is always at the castle and it's always sprite #2 in each world, even if that sprite is set to something other than the ship start-off point. Now, it seems quite random where the airship retreats to, and it is. But I think I found two sets of points right here: 1700E: Choice of y positions. There are 12 per world, and so this lasts 7E bytes (7 worlds each have an airship, not 8--remember). It's written like this: yyyy 0000 y = y position in Discombobulator or Workshop + 2 1709E: Choice x positions. Again, there are 12 per world, and so this lasts 7E bytes too. Here: xxxx ssss x = x position s = screen number I'm not sure if anybody had found this before, but here you go. Here are some of my thoughts on this: The two x and y positions always link up, for example if it chooses byte #5 in the y set, then it will choose byte #5 in the x set. If it reads 1701A in the y set, then it will read 170AA in the x set, etc. The aircraft will only retreat thrice, after which it holds its ground. When it picks, say byte #A, then byte #B will be its next choice, ending with byte #C. If it starts with byte #12, then it will probably go back around to byte #1 (i.e. the very first byte) next, then end at byte #2. Alright, tell me what you guys think. I hope this and the lock data are helpful. (edited by beneficii on 06-11-05 03:34 AM) |
|||
|
beneficii Lakitu Level: 36 Posts: 118/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by DurfarC Thanks! I'm glad to hear that my work is appreciated! I'm going to work on pipes next! |
|||
|
beneficii Lakitu Level: 36 Posts: 119/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
| NOTE: Remember, all numbers mentioned herein are in hexadecimal (base 16) unless otherwise mentioned! Alright, here's something I have just been working on: doing pipes in SMB3. I believe I have discovered enough to allow manipulation of pipe positions to one's heart's content. Here is the data: There are 18 bytes per table, and they each start at the named address. Essentially, each byte can be divided into two nibbles, the first which determines the left pipe's exit spot on the map and the second which determines the right pipe's exit spot on the map. 46AA, screen number. This is the screen number. The first nibble determines for when you enter the left pipe (in the pipe level) and the second nibble determines for when you enter the right pipe. 46C2, x position. First nibble determines for when you enter the left pipe, second nibble right pipe. 46DA, y position in Discombobulator or Workshop + 2. First nibble left pipe, second nibble right pipe. How does the game access this data, you might ask? Well, through the enemy data. The enemy data is different for each pipe level, as it determines the y position of a sprite (the only one in that level), whose tile number is 25, bank 1, and whose y position determines which byte in the table to use (from 0 to 17). You take the current enemy data address, add 3 to it, and there's your table number. Here's a list of the enermy data (using the starting value, so just add 3 to it to find the byte itself) and their corresponding table numbers: C103--0C C108--0D C10C--0E C111--0F C116--10 C11B--11 C120--05 C125--04 C12A--07 C12F--08 C134--06 C139--0B C13E--09 C144--0A C149--02 C14D--03 C153--01 C158--12 C15C--13 C162--14 C167--15 C16B--16 C171--17 C176--19 (out of range? unused?) Remember to add 3 to each of these. The number 0 is used for the sky tower, but note that the two nibbles are switched. Here are some of my thoughts on this: Like with the locks' 14888, these pipes seem to have an inexplicable table starting at 46F2. It's full of different values, and if you change them for the pipe number you want, it'll mess the pipe up. Still, leave them untouched, and it seems like you can still do anything with the pipes. Perhaps this is a mystery that does not need to be solved, because you can already set the screen number, x position, and y position? Anyway, tell me what you guys think. Tell me if you see any errors or problems with what I wrote or if you'd like anything clarified. EDIT: C171 is used! Thanks Kamek! (edited by beneficii on 06-13-05 05:16 PM) |
|||
|
beneficii Lakitu Level: 36 Posts: 120/567 EXP: 299656 For next: 8454 Since: 06-27-04 From: Cordova, TN, USA Since last post: 14 hours Last activity: 6 hours |
| ||
Originally posted by Acmlm Perhaps, now that I'm mostly done with the pipes. EDIT: BTW, hadn't you ever noticed that in a hack, sometimes the airship will retreat to somewhere inaccessible? EDIT 2: I found the x starting position. It's at 16258, but it's hardcoded in, and so changing it for one world will change it for all. Perhaps I can pull off an ASM hack somehow. That could work out. (edited by beneficii on 06-11-05 01:16 PM) (edited by beneficii on 06-11-05 05:22 PM) |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
| Acmlm's Board - I2 Archive - - Posts by beneficii |
If I get this to work, among with moving the lock blocks, I can design my world maps to look more different from the original ones. Two of the biggest mysteries in SMB3 seem to be solved. Thanks again!
