Conn wrote:I got a hack request by Spane for "Prophet of Chaos" to get the pots destroyed also with Sword L2-L4, so I decided to open a single hack collection thread similar to the encyclopedia, where people can post their (credit)free single hacks they find nifty, so that other can merge them with their own work. But be careful that these hacks don't overwrite your own code.

Legend:

Hack: Name of the hack hereAuthor(s): People who made the hackInformation: The type of hack, basic informationRom: which rom they work withCode Addresses: pc address without header where the code is locatedScreenshots: Self-ExplanatoryLatest version: Complete, demo or N/AIPS URL: Where to get it / website URL

This is great! I've hex decoded this (as usual). Now everyone can implement it via hex. All addresses are for No header. If you have a header, just go 32 lines down from the given address. This is 512 bytes in dec or 200 in hex.

Potentialing wrote:This is very cool, though can't you distribute the .asm file instead? I think that would be a lot better.

If not, then can you please explain what you mean by "$00/DABD" and "$07/7B70 - 07/7B9B"? I understand they're offsets, though the / is what confuses me.

You don't rally need Asm or Ips here, since the changes are not that big. Bringing in the actual code is the matter of copy and paste in hex (this is just my way of doing it, since this is the "actual" thing the way the machine understands it). But some actually prefer IPS, while others ASM. So this is just a matter of style.

Regarding your question. I think the hex analysis actually answers it. $00/DABD is where the pointers have changed. I usually write this as 0xDABD, or simply DABD. The actual new code is at $07/7B70 or 0x77B70 or 77B70.

But you know Conn is a coder. Every coder will write an address in way, so that the first global bank is separated. So 77B70 is actually first global bank 07, and then offset 7B70 in the bank. The machine sees it this way to. It defines the global bank first (and the global bank has 8000 bytes). Then it searches for the offset in the bank.

This is incredible, I have no idea how you found those values to hijack, because they seriously confuse me. (Very curious how you got tile interaction to work, I'd love to make the ice rod attack interact with the swimming tiles to overwrite them to ice blocks.)

If you could share how you found those values, that'd be awesome, but regardless, thank you for the patch!

Thanks a lot Well, let me explain that by my history: I never learned programming but was forced to develop AST and bszelda due to the absense of professional hackers. So I teached me coding through learning by doing.So my approach to find addresses is rather intuitive and creative than professional. In this special case, I was making some trace logs with geiger and looked first for the sfx (when destroying a pot to have a first address to start searching; STA $2142).Then I made some more trace logs when interacting with pots - this is hammer use and pick up. Then I found that there is a cmp with $70 which is when you are in front of a pot. The rest was easy, was looking which value is affected when sword is used and this was a 27 at 7E/0354.

I do not know which swimming tiles you mean, but if there is an interaction with other items, there's a good chance to get your desired patch work.I also have the suspection that opening the entrance of Skull Forest with the fire rod has a similar asm background.

Knowing this we can actually do ASM by using hex. Interesting isn't it. Of course this process is done by assembler, like xkas, when we "apply" the Asm patch. Understanding the above, we can see, that it is really not applying, more like converting into the language, for the CPU to read. This is why I use hex, since the code is actually in its final state. Of course having ASM is also vital, if someone want to examine and understand the code as it was originally written.---------------------------------

Regarding the ice rod freezing water. This is probably much more difficult to do, since in the braking pots code, the new code is somehow refering to the same effect on the pot as the hammer would have it. But freezing water is something brand new.

Plus, if the ice should be slippery to walk on is also hard to achieve, since these tiles is more for indoor ice floor. No idea, how SePH managed to make slippery ice on the overworld in PW. I guess this is, where we should start. Make a water region, with the ice blocks first and then find a way, how to make a special tile to be able to "switch" between the two.

ah, now I understand what is meant by swimming tiles. This is indeed much harder...If it is possible to get the tiles on the overworld, I would start tracing with zora's flippers: which values are affected that Link can swim when touching water. Then I would check what happens when icing a tile like a monster (but background tiles are better suitable than sprites, but I'd not remember right now a bg tile that can be iced).

Update: It appears that the 'i' tiles aren't actually .... ice? If they are used for something else, or at all, we'll have to find that out eventually.

^Ice tile interactions, and:

Code:

CODE_07D7B0: 9C 48 03 STZ $0348 ; |

^The moment when the rom clears all ice tile interactions every frame, which can be hijacked to avoid the condition.

So I at least found out how to make Link slip even though he's not truly on ice. I've also found that I can find if the Ice Rod Shot exists on the screen by looking for #$0B in the first $0A bytes from $0C4A (The 10 "special" sprites in the memory bank)... as for singling out the one that's hovering over water, I don't think there's any flag for checking that. Even if I found that, I still need to find out how to replace the tile itself....

On an un-related note, I'm planning on hi-jacking Link's movement behavior under specific conditions (I'm specifically going to prevent him from using the ladder while using the Roc's Feather I'm coding), and I found Link's movement code in wii's disassembly:

Hopefully this isn't getting too off-topic, but I'll be sure to post some actual, useable codes after I make enough discoveries to get stuff done. (Actually, at this point I think I can fix up 80% of the problems I had with my Roc's Feather. https://www.youtube.com/watch?v=K2LUg2sYXfc

EDIT: [quote="Conn"]I also have the suspection that opening the entrance of Skull Forest with the fire rod has a similar asm background.That is... actually a very good idea! I'm going to look into that.. though I am probably going to have a very struggling time looking for a way to replace the drawn tiles on the screen (temporarily until Link moves off-screen, even). If I could get assistance with that, that would be very much appreciated.. but I'll try regardless. Thank you for the advice, by the way!

EDIT2:

Code:

$0333[0x01] - Stores the tile type that the lantern fire or fire rod shot is currently interacting with.

^I just memory watched this value using the Fire Rod and found that:Shallow water = #$09Deep Water = #$08Ice tiles (in-dungeon) = #$0FBush Tiles = #$50 (Actually, maybe I should make a patch that burns bush tiles whenever it passes by one)

Yes, it is going a bit off-topic. Maybe SePH can split this topic so that, as initially thought, people can share their hacks here.

Your progress with the rock's feather looks amazing, this opens many options to built in further riddles

I wonder whether I can help you with the ice layer request... best were if you have a rom with a pool half of water, half of ice layers. As these tiles are so far only indoor tiles I cannot make such a rom myself. Or maybe PW helps since it is already implemented in this rom? But if I can hack it in PW it won't help you I guess.

$03E8 is the Ice Rod version of $0333.

Great finding, it's not hard to get your code I think. Just need to hack a code to lda $03e8 cmp #$08 and if yes, swap bg tile... similar to the pots that change when destroyed.

Potentialing wrote:Bush Tiles = #$50 (Actually, maybe I should make a patch that burns bush tiles with the fire rod whenever it passes by one.

I think everyone would very much appreciate this. It's a fine idea, can easily be spoted as a mod, (since we know you can not do this in Alttp), and it is hopefully not that difficult to achieve.

If you need a specific tile value, you can actually use SNES9X (I'm using rerecording v1.51 v6 svn113)

Regarding drawing tiles, I just asked Math on IRC (Me: "By the way, if you happen to know how to draw/replace tiles in-game, that'd be awesome to know how to do."), and they claimed this:

MathOnNapkins wrote: You do that by writing to the arrays at $7e2000 and $7e4000 (for bg1) and updating the tile attributes too $7f2000-3000 That's for indoors That's not enough though, you have schedule a dma transfer to do the actual change in vram during NMI I have a system that I worked on that can do that sort of thing, but it still needs work (e.g. for making a chest appear, or a block ,etc) What I was really trying to do was rewrite the object system from scratch The ones used in dungeon rooms To make it all flexible and stuff

I'm going to have some serious headaches to identify which tiles I'm supposed to replace. I think I know how now, but it's still very mind-boggling. (Find the right room the player is on, find the X/Y position of the Ice Rod Shot to calculate which tile to replace, find the tile on the table so it can be restored off-screen... ugh)

I do understand what Math is meaning. You know the graphics are displayed usually in a 2 way system: (1) load tiles from rom into ram, (2) load tiles from ram into vram with dma.So you'd need to transfer the ice tiles, when the ice rod touches water into ram and then make then a vram transfer to display them.

Conn wrote:I do understand what Math is meaning. You know the graphics are displayed usually in a 2 way system: (1) load tiles from rom into ram, (2) load tiles from ram into vram with dma.So you'd need to transfer the ice tiles, when the ice rod touches water into ram and then make then a vram transfer to display them.

The thing is, I need to find a/the system that loads up the correct values of that table, then find an automated way to replace it on the fly whenever the ice rod touches a water tile.

Don't worry, it should be doable. The coordinates are somewhere (the game must know the coordinates when $03E8 get'sa 08). With these coordinates it is possible to replace the tile correctly in ram. And a vram transfer (if it isn't done automatically yet, can be coded as well.

How about doing it without the vram transfer first. For instance use the ice rod on a water tile, to simply change its atributes as MoN said. Then you could "walk on water", just to test how this part is done.

Puzzledude wrote:How about doing it without the vram transfer first. For instance use the ice rod on a water tile, to simply change its atributes as MoN said. Then you could "walk on water", just to test how this part is done.

That's the problem I'm having though, I don't know how to find out which tile I'm supposed to update, and I can't seem to find the table in wii's dissembly, either.

I think first the new ice tile must be transferred into vram (so that it also available on the overworld). This is maybe most difficult since I do not know which tile can be replaced. Then it is needed to understand what must be done to change bg tiles. I assume a simple map change. This can be traced by watching what happens when you destroy a pot, both the pot, as well as the removed pot are bg.

I'm not sure whether it is needed to hack a "walk on water". When the correct bg tile is replaced (which you can normally also walk on) it is possible that the attributes do not change then. E.g. you cannot walk on a pot, but as soon it is replaced, the new tile allows to walk on it.If this won't work, I remember that I once changed the tiles attributes in AST. The torches were in front of sprites or so. So it is possible to hack directly into tiles' attributes as well.

I propose immediately after the first post, because it pretty much got off-topic after that. This is a wonderful discussion for ASM help, though.

Math wrote: The ice shot has: jsr $8981 in its code It is that routine (the one at $40981) that does the collision check and writes to $03e8 ($03e4, x) right around the line.... jsr Entity_GetTileAttr in that routine right after that is where it writes to $03e4, x

I'm gonna investigate this. If I find out how to do this, I think I have enough information to put this hack into play.

I propose immediately after the first post, because it pretty much got off-topic after that.

I don't know about this, since the hex decoding is still a part of pot braking directly. And that post is number 4. So this is not connected with the Ice rod topic.

I think it would be best to split after number 8. Then a new topic would start with Conn's post about the swimming tiles, this is post 9, while post 10 is clearly a separate issue. Post 4 is on topic, 5 is connected with 4, so is 6 and 7. In the 8th I still had the pot-breaking in mind, when traversing from Asm to Hex.

So braking the pot topic and all comments connected with it are roughly to post 8, later on it is the Ice rod topic (parts of it are still in previous posts though!).

It is really hard to say where the actual line is. First post only would be possible if all of those patches would be gathered together as one posts only, with no comments.

I've created a general ASM topic with the split and edited Potentialing first post to include Conn's original post! That way well keep the other thread for the asm/hex hacks database! Please keep the same posting format as Conn for the other thread and it should be all good!

You see at the start of above code:$00/884A BF 00 20 7E LDA $7E2000,x[$7E:2AAA]Here the tile for the bg is loaded which results in a water tile 08 to be stored at $08:03E8 at the end of above code!If I manipulate this by cheating with e.g. 7E2AAA 0B you get this:

you can walk on that tile! So if you change this to an ice tile you'll walk on that, too

Unfortunately this takes only effect when leaving and reenter the screen, so a re-enabling of the dma transfer that displays the background when entering the screen must be implemented when using the icerod (usually a simple jsl to the dma routine will do the job).

But first you need to get the ice tile to the overworld so it can be accessed by LDA $7E2000,x

So the code will look like:start here: $08/8A5D 9D E4 03 STA $03E4,x[$08:03E8] then hack: cmp #$08if yes:write a code to get again the x value so that in this case the new ice layer is stored to ,x[$7E:2AAA]reenable the dma transfer... and that's it