Indoor pushable blocks

I was just thinking if it is possible to make those indoor pushable blocks to be pushed multiple times. With this some nice puzzles can be made.
 
I don't know why Nintendo decided to go with the one push only, since this is not so usefull. The good thing about these blocks is, that they are automatically pushed by one unit and reset to their original position after leaving the global room (HM room).

I think in principle it is similar to the icerod code. The moved block must be stored into the map at 7e/2000 overworld or at  7f/2000 (bg1), respectively 7f/3000 (bg2) in dungeons.
Prior to this, after the move it must be saved to ram that the block is moved and can't be moved anymore. This is your desired code you need to know. But there are other things with similar effects (statues e.g.) which you can move as many times as you wish...

Statues have lots of other problems. Two statues at once will bug out the player, since they can not collide. They can not be pushed by one unit (but rather freely, which is no good). They can also be pulled by default (this can be changed though), the blocks can not be pulled.
 
Also, I don't think pushable blocks can exist in the overworld. I also hope it is easier than the Icerod, since the block can move already by default. I guess the part where it stores to ram, that it has already moved needs to be checked.

I found one involved address:

$01/D966 A9 27 27    LDA #$2727      
pc: 00/d966 if you change this to a9 70 70 one block of the water dungeon overworld can be moved further (left one). This has however some bugs, if you push on the right one, the left will be moved as well.

This was only a short trace of involved address. The problem you will encounter is that each block has a default number beginning by 70.
Block 1: 70 70, Block 2: 71 71, block 3: 72 72.

If you move a block the number will simply replaced with 27 27, which means unmoveable block and is the same for each moved block.

What needed to be coded is not that easy:

First the address from which you move the block away gets a 00 00, so for example you move block 2 the 71 71 gets a 00 00.
Here you'd need to know what the native value is (70, 71, 72...)

The code is this:
$01/D87D A5 00       LDA $00    
$01/D87F 9F 00 20 7F STA $7F2000,x[$7F:2C9D]
$01/D883 9F 40 20 7F STA $7F2040,x[$7F:2CDD]
You need to hack before this execution, means before it gets rewritten to 00 00 an intermediate store of the native value is needed (whether it is 70, 71, 72...):
01/D87x LDA, $7F2000,x
01/D87x STA $7Exxxx (store the value (70, 71, 72 or whatever) to unused space in ram)
then the native code needs to be executed:
$01/D87D A5 00       LDA $00    
$01/D87F 9F 00 20 7F STA $7F2000,x[$7F:2C9D]
$01/D883 9F 40 20 7F STA $7F2040,x[$7F:2CDD]

In the next step you need to prevent that the new block value gets rewritten by 27 27
instead of:
$01/D966 A9 27 27    LDA #$2727              
$01/D969 4C 7F D8    JMP $D87F  [$01:D87F]  
$01/D87F 9F 00 20 7F STA $7F2000,x[$7F:2C9B] A:2727 X:0C9B

You need to hack
01/d966 LDA 7Exxxx (load intermediate store e.g., 70, 71 72)
and then again run the native code
$01/D969 4C 7F D8    JMP $D87F  [$01:D87F]  
$01/D87F 9F 00 20 7F STA $7F2000,x[$7F:2C9B] A:2727 X:0C9B

I hacked this, this is way complicated since the same address is used to store a 00 or the 27 to the address...

Download the patch here:

http://bszelda.zeldalegends.net/stuff/Con/moveblock.zip

Here's what I did:

Code:


org $01d87d
NOP
NOP
JSL $0EFE00 ; (below the icerod code to not overwrite it)

org $0efe00
CMP #$2727     ;check if block is already moved
BEQ $0F           ; if yes branch to after first RTL
LDA $7F2000,x ; load block value (e.g., 70, 71, 72...)
STA $7ED010   ; store to intermediate (unused) 7E/D000 is icerod
LDA $00           ; set old block value to 00 to indicate that it is moved
STA $7F2000,x
RTL                  
LDA $7ED010 ; branch here if 27 - load intermediate value
STA $7F2000,x  ; store intermediate instead of 27
RTL                  


I do not know if it contains bugs... e.g. pots use also a 70 70... also check some more dungeons. I only tested for water dungeon, light world (where you pull the lever to flood)
Edit: tested slightly, seems to work correctly (no pots involved) and works also at other places (e.g. blind's hideout, overworld). You can check at other places and look for any bugs

Beautifull. . Going onto the testing. I've also found out how the values are assigned.

at 271DE (block is 80+80+80+0C) = 18C = 396 in dec :4 = 99 pushable blocks.

*Code (4bytes for one block)
0B 01 3A 19 (no ending value! FF), room values are mixed!, so the space must be hardcoded, that the game knows where to stop reading values.

0B01 is room 267 = light world water chamber where you flood the water. So the left block is number1 is 7070. And so on for all 99 blocks. The middle one is block number2, but the right one is number19.

Cool!
I was able to push all blocks in any room I tested with above patch... I also edited the post and gave the asm here.

Let me know what results you get from playtesting

Tested. All blocks I came accross worked fine. Even made some mods with HM to make custom rooms, with blocks on new positions (locations) and it also works. 
 
You know, I wanted to have this feature since when I moved the first block. And was surprized it only moved once in the original Alttp.
 
I've also learned that the floor underneath the block gets reloaded, when you are pushing the block, which is intersting. This basically means some minor display fault, if the block is pushed to the very edge of the room (but I can fix this in HM directly). The block must also be on even x and y to prevent it from being pushed (with half body) into the wall (I can also fix this easily).
 
Did you know, you can also push the block into the pit, and it will arrive in lower level (so now there are a lot of new puzzles possible).
 
Also tested the collision between the blocks, which is fine, if it is pushable on shallow water (and it is) and even the sprite interaction. Everithing is ok, and a lot better than the statue sprite, since block is always pushed by one unit. Also checked the pots and there's no change.
 
Altogether a very recommended feature  . I'm also having a hard time understanding, how you managed this, since if all blocks get rewritten to 27 27, it can be a problem. Also, how did you find free ram.
 
PS
I've also decoded the pointers and the block data in hex, so I can have 128 blocks in the game instead of Nintendo's 99 block limit. Didn't test this in a combination with the new code though.

Meanwhile I did the comparisment in hex. So this is how the Asm looks like in Hex. This is how I see new data.
 
MULTIPUSHABLE BLOCKS, in HEX
  
at D87D (new pointer)
A5 00 9F 00 20 7F --> EA EA 22 00 FE 0E
   
MAIN CODE
at 77E00 (old values were FF)
C9 27 27 F0 0F BF 00 20 7F 8F 10 D0 7E A5 00 9F 00 20 7F 6B AF 10 D0 7E 9F 00 20 7F 6B

At first I thought Asm is impossible, since you would basically need an entire RAM map of the whole game. So obviously Asm is connected to Ram and to tracing (nice word), to actually trace the code, and realize where the Ram addresses are.
 
I was also astonished, that this actually works (since I wanted this feature like forever, and didn't know it was possible to do after the first analysis).
 
Quote
I'll probably implement this in the hack, so feel free to experiement or create puzzles with this while you create your six dungeons!
 
Exactly. At first I wanted to put the speed of pulling the statue to zero, to able to only push it, but now we have this. Since I always wanted to do that puzzle with the block being near the wall and close to the switch, but since it can not be pulled, a nice alternative (smart) road needs to be taken.

At first I thought Asm is impossible, since you would basically need an entire RAM map of the whole game. So obviously Asm is connected to Ram and to tracing (nice word), to actually trace the code, and realize where the Ram addresses are.

You need to realize that the game is played in ram! The game loads only data from rom into ram, like which palette is given to which tile and so forth. graphics are in vram and music in aram, progress stored into sram. But everything is ram actually.

I'm also having a hard time understanding, how you managed this, since if all blocks get rewritten to 27 27, it can be a problem. Also, how did you find free ram.

oh with my code no block gets written to 27... I disabled this and get it's value out of the intermediate ram instead (which is block specific 70, 71, ...)
There's plenty of free ram. I just watched with geiger... it's a good guess in the end but out of my experience, the address I use won't make problems.

Okay, I haven't downloaded this yet, but did you guys REALLY just make the pushable block to be made to be pushed twice!!!???

If so, that is OUTSTANDING!

What about making it pushable 3 times or 4 times or n times?

Or what about being able to push it an infinite amount of times?

I was thinking.... if there are two pushable blocks that the player can view and if the player pushes one of them one time then how would the player know which one they pushed and which one they haven't pushed if they forgot.

So what if you count the number of pushed by the color of the block. A dark block means it hasn't been pushed at all and then change the color of the block after its been pushed so that you know that its been pushed.

If you have a really complicated block puzzle with lots of blocks then the player could easily get confused on which blocks were only pushed once or twice or none so a color system or something like that could be helpful.

By the way this is awesome work.

The blocks that can be pushed are pushable infinite times ... or at least until you push them into a corner. I posted it here:
http://zeldix.forumotion.com/t129-zelda-3-single-hacks-collection

As for the color; maybe you can address a different color via HM?

Erockbrox wrote:Okay, I haven't downloaded this yet, but did you guys REALLY just make the pushable block to be made to be pushed twice!!!???

If so, that is OUTSTANDING!

What about making it pushable 3 times or 4 times or n times?

Or what about being able to push it an infinite amount of times?

I was thinking.... if there are two pushable blocks that the player can view and if the player pushes one of them one time then how would the player know which one they pushed and which one they haven't pushed if they forgot.

So what if you count the number of pushed by the color of the block. A dark block means it hasn't been pushed at all and then change the color of the block after its been pushed so that you know that its been pushed.

If you have a really complicated block puzzle with lots of blocks then the player could easily get confused on which blocks were only pushed once or twice or none so a color system or something like that could be helpful.

By the way this is awesome work.  

Any block can be pushed infinite times with this code (you would realize that, when looking at the code - it never gets a value 27 27 which is unmovable). So if it is pushable infinite times, you really don't need colours.

The only visual problem is that the ground in which the block stands will be auto reloaded under the block when pushed, which can cause visual minor problems. The other thing is that if the block is not on even x and y (with the wall or any other object in the room) it can be pushed into it with half body (and reload the ground, to half erase the object). But all of this can be solved in HM by carefully designing the pushable area.

I would like to know. Is it possible to have regular pushable blocks (1 push) AND these infinitely many pushable blocks in the same room? Could you have both types of blocks in a single rom? Or is it just one or the other?

Let's stick to one or the other mode. Otherwise it gets complicated...

It is possible to make exceptions like that block 70 gets stabled to 27 and further don't but then you have:
one block can always only be moved one time, all other infinite times.

Looking at the code closely, you'll see that all blocks are one and the same type. So the entire game can have one-push blocks only, or infinite-push blocks only.

Entirely new code would be needed to address each and every block, but the problem is that once pushed, the new value is by default written to the same place. This is wisely solved in the current code to go back to its original value (which is pushable, regardless of the block number).

Could it be possible to remake the blocks such that they are sprites instead? Then I think it would be possible to have both types of blocks in the SAME game!

I think this idea isn't bad at all. You'd need to alter the behaviour of a sprite that way that it moves when touched instead hurting you. But I'm not experienced how to archieve this. To not rennounce on a sprite you'd need to create a complete one. And this is beyond my skills.
Easier might be to substitute a background tile to behave the way you want. Bushes, pots, walls, everything interact with the sprites (cannot walk through wall bg, can walk on ground bg, can lift pots, move blocks)...
This behaviour is coded somewhere, so take an unused bg tile (maybe one is available that you can even already move or lift, like a plant or pot), give it the gfx of a block and then start coding

Right now I'm unfortunately a bit too exhausted to start over something new like this, but maybe you find out something awesome yourself

Also if the blocks were to be turned into sprites then I wonder how it would work when you push a sprite off an edge and down onto a lower level?

Is it possible to send one sprite to another screen what it was not originally on before?

And how they would reset back to their original positions after being moved?

Yes, these are all those good questions why I'd leave it either move all blocks either one time or all blocks infinitive times...

This is why it is not a sprite. Sprites can not leave the screen. You can not make the sprite go into the other HM room. For instance sprite in room 97 must remain there. It will respawn however, but surely such blocks would not make it into lower level.
 
Also boxes right now are not sprites, but special objects. So basically you would be doing a brand new sprite similar to the Statue sprite. But obviosuly Alttp authors had problems here and decided to make a brand new object (similar to lightable torches). These torches are also not sprites.

the floor reload side effect (e.g. pushing a block on a spiked floor causes it to disappear), is that too difficult to fix?