Erock's Version Conker 1.2.7

Also I think I've noticed in the newer versions that the stairs in the SM64 castle interiors areas seem to not have any effect on conker at all. I believe that the stairs used to slow down conkers speed, but now it seems as if that reduction in walking speed is gone. I'm I correct on this?

Erockbrox wrote:Also I think I've noticed in the newer versions that the stairs in the SM64 castle interiors areas seem to not have any effect on conker at all. I believe that the stairs used to slow down conkers speed, but now it seems as if that reduction in walking speed is gone. I'm I correct on this?

Yes, I made this when debugging. This is the side effect of debugging the hammer-splash bug. Otherwise I would need a lot more free tiles to be able to also include slow walking on stairs. This is just a different tile-type. I used regular floor for stairs. You can also revert this to slow walking, but if you hammer such tiles with hammer, the water will splash on them. So it's your call on this: walk slower and hammer splash bug, or no hammer splash bug and walk normally (current).

Erockbrox wrote:Okay now that I'm using the correct version do I need to do anything special in this version like the move pointer headers thing?

Now, I'm stuck on this part. In this room there is a block, but the chest always appears even if the block isn't moved.

I'm assuming that seph originally wanted the chest to appear once you move the block and I selected to move this block as a special setting, but it doesn't seem to work.

I'm guessing that because there is another tag that says "chest appears if enemies are killed" and once you get to this room the enemies are killed so the chest just spawns regardless if the block is pushed or not.

Now that you have a proper Hyrule Magic, you don't need to move heaers as they are already moved and you already have unlimited (maximum) space for room-headers. All you need to do is change tag2 to "Nothing". Then it will work: you will have to push the movable block for the chest to appear.

Current situation is this: chest will spawn in all cases due to tag2: defeat enemies to spawn, yet there are no enemies, thus spawn. Move block tag is irrelevant due to tag2. If tag2 is nothing, then tag1 works normally and the pushable block is in the room.

Do note: tag1 and no chest in the room, or tag1 and no pushable block in the room: can result in a game crash.

^ So now I think I understand. Seph wanted the chest to appear if you push the block, but see in this same room you designed a warp tile puzzle which if you kill all of the enemies then a chest spawns. So basically you cannot have both options here at the same time.

I will just leave it the way it is because nothing really can be done.

Now that I'm thinking about this, I think that you can have both, but for the kill all enemies for chest make that the "other" room that you warp to with those warp tiles.

I might test it out and see if it works, but really its not a big deal here to change anything.


Also I would say that the Erock version should be close to being complete. Most of the major modifications are already done, just wrapping up a few details. Waiting on the new graphics and might need help with some monologue edits.

Erockbrox wrote:^ So now I think I understand. Seph wanted the chest to appear if you push the block, but see in this same room you designed a warp tile puzzle which if you kill all of the enemies then a chest spawns. So basically you cannot have both options here at the same time.

I will just leave it the way it is because nothing really can be done.

Now that I'm thinking about this, I think that you can have both, but for the kill all enemies for chest make that the "other" room that you warp to with those warp tiles.

I might test it out and see if it works, but really its not a big deal here to change anything.


Also I would say that the Erock version should be close to being complete. Most of the major modifications are already done, just wrapping up a few details. Waiting on the new graphics and might need help with some monologue edits.

LoL, this room is actually shared with another room with warps. In this case you need to do this: tag1: SE (sutheast) Move block for chest, and tag2: W (west) defeat all enemies for chest.

But SE (sutheast) Move block for chest tag doesn't exist. This is why originally the door was a shutter door, so it was SE (sutheast) Move block to open. Chest is permanent.

The choice is yours what to do here.

Conker 126 has:
SW move block to open, and
clear room for chest (but there are 2 chests).

Both tags are wrong, however I believe there are no paradoxes or crash bugs, so nice to see, this is still working:
SW move block to open is obsolete, and you reach left areas first and are required to get the chest I believe, not knowing you actually are spawning 2 chests. If you were to change floor levels (ie go on the starcase) the righ chest should become invisible, since this tag always need only 1 chest in the room. You can see this in PD's quest hack, where you spawn 2 chests and one then still spawns, but is not seen, since you "reseted" the room.

Okay, new graphics have come in.

While I am doing my own version I will not exclude you guys from inserting the new graphics into the older version if you decide to. Hopefully in the end you except my version as the official version anyway.  



I didn't like the blood splatter looked in the game so I got them redrawn.

I didn't like how the big cannon ball graphic was like a hollow ring and didn't match that of the smaller cannon ball graphic in the clock tower (gear dungeon)

The witch was turned into a fountain, and although I admire Conn's attempt at the graphics, I think this new fountain actually looks like a fountain.

Conn, I didn't tell the artist that the fountain is animated because I felt it was too complicated to give all that info to him at once, however now that the graphics are drawn we can then talk about if we want to add in some animation to it, but I would need all the details.

If the witches stick (which stirs the pot) can be made back into a circular motion like in the original then we might be able to add some pixels to it and make the coke in the coke fountain sparkle or bubble or look more like a liquid.

Also I didn't like the floor tile in the sony dungeon so this new graphic might actually do.

The interesting thing about this game is that because there are so many different skill sets involved in the process of making this thing, the game is really bigger than all of us. This is because no single person here could create this game all on their own. It literally is a team effort.

I admit your guy has talent
I see what I can do with that - I take only care of the witch, then I retire completely on the game.

ok erock, apply below patch on your rom. It should also fix the monologue to kick the deku seed (all are in the expanded area, which you cannot reach in HM, so this oatch is safe to apply)

1.2.7 is released:
https://www.zeldix.net/t1337-conker-s-high-rule-tail-v1-2-7#19689

Patch Release v1.2.7 ~ December 4th, 2017
--------------------------------------
- inserted Erock's Interpretation of Koka Kola fountain
- Added some crucial hint to kick Deku Seed in monologue
- added hard puzzle solution to spoiler section

Now keep in mind Conn that the version that I'm using was the version right before you added those monologue changes about dash and kick.

So im trying logically to figure out how this patch is supposed to work.

So the logic went like this.

- I downloaded your version right before the text changes (seed, dash)
- Then I edited my own version with objects and sprites
- Then you fixed the witch and gave me a patch

So what is my original version to compare to when applying the patch? And if I apply the patch then I believe that all my dungeon edits will be reverted? So I'm a little confused.

I think if you just want to add your new changes to mine the patch is supposed to be an asm file.

Erock, you can trust my words when I say it's safe to apply this patch, I know what I'm doing.
The kick monologues are in the expanded area which cannot be edited by you, and is unaffected by hm. Means applying this patch makes harm to anything you did.
Make a security copy, apply the patch, test.

It changes the main entrance pw ruins monologue to kick deku seeds and the erock folder monologue to dash invisible.
Other than that it changes the fountain. That's it.

And... how would you think an asm file to change gfx could work?

Ah well. It's up to you to apply it or not, it's your project

But if I patch this what do I use for my original rom?

Like with Lunar IPS you need the modified rom and then you need the original rom.

So I don't know if I know how to apply your patch.


I know what you mean though, the changes you made are irreverent to HM, so it doesn't matter. Something like that.

You don't tell me now that you do not know how to apply a shitty ips patch, do you?
Just apply the patch on your current rom. That's it

If you are afraid that my patch does some side effects, make a security copy, like your rom name is erock_conker.sfc
copy it, rename to erock_conn.sfc, apply the patch with lunar ips, test if the well is included, test the monologues, test your modifications. If you notice all is alright, keep on working with the patched rom.

So what is my original version to compare to when applying the patch? And if I apply the patch then I believe that all my dungeon edits will be reverted? So I'm a little confused.

You don't tell me now that you do not know how to apply a shitty ips patch, do you?
Just apply the patch on your current rom. That's it.

I think he had a problem in understanding if the IPS is applied to original ALTTP rom or something else. But I can see it is 12 KB only, so logically it should then be applied to version 1.26 to thus gain version 1.27. And if this changes the monologues in the expanded space and the gfx pointers+ code, then it is compatible with v1.26 with or without additional dungeon edits. But obviously the further gfx edits (cannon ball etc) should be done last (after the patching). I hope this explains it for all involved.

Everything worked just fine and I patched it just fine. I'm just always used to patching to the original unmodified rom.

But now my version was the "original unmodified"

Yes, I understand graphics go after patching. If fact since conn inserted witch now I have to extract the graphics instead of just inserting them.

All is okay!

Ah, now I understand what the problem was.
Your version is now up to date with 1.2.7 (changed kick monologue, inserted new witch well). Your additional changes are not affected, since I neither made any changes in zcompress nor HM.
All changes are in the expanded area of either uncompressed graphics (witch well), which isn't recognized by zcompressed or the shifted monologues that are not recognized by HM.
Means your altered rom (previous work) is not affected in any means by applying this patch!
I didn't inserted the canon ball, as this would have affected zcompress stuff, and doing so might have corrupted your rom (I'm sure you can do that yourself however). I am also happy with SePH's graphic, so this will not be updated by me in the "official" Conker.

Much luck  

Okay noticed some things....

So I'm working on the Erock version and I came across somethings.

1) I edited some graphics on the overworld, yet after reinserting them with zcompress the new updated graphics didn't show up in HM. HM still had the old graphics. (edit) It seems to be displaying the correct graphics now in HM... strange.

2) I noticed that there is one tile with hammer that is incorrect. It's when Conker is facing left or right and swings the hammer. On the hammers first pose that graphic is wrong. It needs to be like the hammer slam on the ground but only up in the air. Trust me. But when I fixed the graphics I never saw the update. I wonder if the hammer graphics are only loaded once you get the hammer and then that's it. I can tell you which tile it is if you want.

3) Remember how you guys debuged the splash on the fence in the SM64 indoor area. Well you know that sometimes when you fix one bug you just create another.

Now because of this debug when you are in the dessert area (palm trees area) if you hit the sand with hammer then a water splash effect happens.

I honestly liked it better before it was "debugged". splashing on the fence in the castle is pretty rare and I like the idea of slowing down when you run up and down the stairs. So I would like to change this back.

Just remember that if you change the tile properties to give me a patch too or just tell me how to do it.

4) When putting in some of the new graphics, I used zsnes and yychr with a save state in the area in the game from zsnes and yychr to load that save state to get the color pallets for certain tiles.

I noticed that for some unknown reason that yychr I could not see the actual in-game color pallets. For example the blood on the overworld in the black/white/gray scale area. I could never see those two colors of red in yychr as options to pick from when coloring the tiles in yychr.

I'm also seeing this same effect in the subway tile area. For example I don't know exactly how many colors I have to choose from with the subway tile and I don't know which color pallet row the game is using for that tile.

I then did an experiment. I colored the tile in yychr with one of every color from a certain row (see the very bottom row of the tile). Then I tested in-game. To my surprise I see in the tile two row sets of blue colors, yet in yychr you never see any pallet row which contains two sets of blue colors.

So my conclusion is that something is not displaying correctly in yychr or something. See image.

1. Happens to me sometimes as well, it seems a bug with the emu. I guess the ram on your computer isn't cleared, and is reused in some cases (having the unaltered rom still inside). I help myself by renaming the rom. E.g. conker_127_v1 -> conker_127_v2 and so on

2. Hammer tiles start at 11/c000 - help yourself, they are uncompressed. If you post the tile to change (index starting at 11/c000) and the new gfx I may change it in official 1.2.7b (along with below splash bug.

3. Try this: change
0d/f1a0: 01 -> 09 (will make splash in shallow water then)
0d/f3d8: 09 -> 01 (won't make splash on dry land then)
~Note! Before we permanent change it to rom, we should agian check other tiles, hyrule castle and such

4. That's normal and correct if I understand you correctly. One sprite or tile can only use 8 colors (only exception is Link's sprite). So divide the palette in the middle. E.g., enemies always use the left 8 colors, while items always use the right 8 colors. Seems like your floor uses 8 colors to the left only

Remember how you guys debuged the splash on the fence in the SM64 indoor area. Well you know that sometimes when you fix one bug you just create another.

Now because of this debug when you are in the desert area (palm trees area) if you hit the sand with hammer then a water splash effect happens.

I honestly liked it better before it was "debugged". splashing on the fence in the castle is pretty rare and I like the idea of slowing down when you run up and down the stairs. So I would like to change this back.

LoL man, you think my debug (without quotes) has anything to do with a completely separete problem of the yet another splash bug in the desert. The desert was hammer-bugged all along, just no one apparently noticed this. When you hammer the sand, it splashes, but when you hammer shallow water, it doesn't (when it should). It's the same problem as before. SePH didn't assume you can not use any middle tiles for anything, so he used sand on false middle tiles and shallow water also on false middle tiles.

Shallow water tiles should be where ALTTP has put shallow water tiles, and sand should be where ALTTP has put non shallow water tiles. This was not made in Conker, since it can easily be overlooked due to people not hammering all the ground all the time. That's why this bug was overlooked.

Well you know that sometimes when you fix one bug you just create another.

Which is not the case here. Same problem is in version 1.25 before Mario castle debug, in version 1.24, 1.23, 1.22, even 1.2 beta. The sand will always hammer-splash - this was so from the beginning this overworld was made.

Just remember that if you change the tile properties to give me a patch too or just tell me how to do it.

Like said, no tile property was changed. This was middle tiles editing.

I noticed that for some unknown reason that yychr I could not see the actual in-game color pallets.

You should always get the correct pals for sprites, not sure if this is possible for all objects on screen.

3. Try this: change
0d/f1a0: 01 -> 09 (will make splash in shallow water then)
0d/f3d8: 09 -> 01 (won't make splash on dry land then)

Thank god. This is for desert only. This table actually controls the tile properties. If you do this, that sand is ok (basically you tell that tile to now be normal ground, and the other is for shallow water to actually splash). However I believe this is actually for the smallest tiles (and not middle ones)?  If this is true, it can have side effects. Basically if you change the tile proeprties, you will change them for the location and not fot the gfx set. If multiple gfx sets are loaded onto the same space, it will change them also. That's why I solved the Mario Castle splashing in another way.

Of course you have free hands Erock and can revert the Mario Castle debug (you can take version 1.24 or 1.23 ir 1.22 to see how SePH made, and what I did, to revert this, with middle tiles editing). In this case, it will just splash anywhere again: in Castle and in the desert. Water splash curse, that's what this is.

I also wondered how your small fix bytes (I checked your code if you remember) potentially could cause such a glitch. Good to know it wasn't yours
If it isn't demanded too much, could you briefly check the byte changed having side effects, you know HM best and probably have the best idea where to hammer.

But I will also test it in some areas. If all is good, and Erock sends the hammer tile, I'll update the hopefully last time with a 127b. Also I should stop looking into this thread, as it obviously reveals more bugs, and I want to leave the game behind at one point.

If it isn't demanded too much, could you briefly check the byte changed having side effects.

0d/f1a0: 01 -> 09 (will make splash in shallow water then)
0d/f3d8: 09 -> 01 (won't make splash on dry land then)

Jackpot, or maybe it is bingo.

I tested this out, the upper edit does Not change the tile properties of the smallest gfx tiles (so no side effects possible). Before and after edit this is the situation:
SAND layer 1= middle tile 712, made out of small tile 12 (type0), 13 (with type0), 28 (with type0) and 29 (with type0).
SAND layer 2= middle tile 52, made out of 4 small tiles 157 (type72)

Shallow water layer 1= middle tile 144, made out of 4 small tiles 446 (type9)
layer2= same as sand layer 2.

So before and after the edit, this remains the same. So no small tile type was changed.

Now if you calculate the length between both addresses= DF1A0+x= DF3D8, x= 238 (hex)= 568 dec.

Rings a bell? Middle tile 712 minus middle tile 144= 568.

Thus these are the never before found tile types of Middle sized tiles (which HM can Not edit, this is why we thought them to be hardcoded).

So now indeed we can find the start of this table with tile 0 to tile 3759= all middle tiles types.

This is what needs to be changed. You see, Middle tile 712 is hardcoded to be shallow water because 0d/f3d8 = byte 09. No matter if you then fill this with small tiles, this middle tile insits being type 09 at least for the hammer (not the person though).

Same is valid for lifting bushes etc etc. All these tiles were until now "hardcoded". But actually there is Type Table which controls these middle tile types.

Although the smallest tiles have correct types, we also need to adopt the tiles types of the middle sized tiles. Now the Mario Castle splashing is easy fixable with the same method, which then makes my debug obsolete.

So that debug can just be hex-reverted, and then fixed via this new method, by locating the middle tiles to be changed on this table which Conn found, also from byte 09 to 01 for the middle tiles in question. It's just 3 or 4 of them (vertical fence etc). However the stairs must go to walkable-stairs-type, so this is not 01 but another type, which needs to be checked via smallest tiles - this must match, I think it's type 08).


Thus a hammer-splashing bug was a result of 2 things not matching: the tile types of the smallest tiles, ie GFX, ie 8x8 pixels-- in concordance with the middle tile types. This however reacts only to hammer, since the smallest tiles prevented the Link's main sprite to interact with water, however the hammer reacts to both, and they both must be type 01, ie no shallow water and no hammer-splash.

A great paradox can come from more complex middle tile types, such as liftable bush. Fill this tile with gfx of a rock, and you will be able to pick this rock up, since the middle tile type is still liftable bush. And there is apparently the third table too, to then load new gfx (what's under bush) to this location. So this is even more complex. This is why you never change the complex midle tiles: bush and rock etc usually remain on place in hacks. For instance: bush is middle block/tile 54, you just don't change that to any other middle tile number.

Uh wow, didn't expect I dig up gold

The table starts at 0d/f110:

Code:

$05/FABE BF 00 20 7E LDA $7E2000,x[$7E:2694] A:0694 X:0694 Y:000A
$05/FAC2 AA          TAX                     A:02C8 X:0694 Y:000A
$05/FAC3 BF 10 F1 1B LDA $1BF110,x[$1B:F3D8] A:02C8 X:02C8 Y:000A

So if 3759 tiles are addressed, this is hex $eaf, so the table should end at 0d/f110+eaf=0d/ffbf
(looks like I calculated correct when looking at the hex patern in the rom)

I guess you can do something awesome with it
For myself only important is for now that the addresses given work bugfree. So I'll wait for Erock's new hammer, maybe include that new bubble in that go, and release 1.2.7b.
Do you remember which bytes I changed for castle fences? If yes, can you give me the bytes to revert? I forgot and didn't document...

And then... yeah spoke too often about retirement, I'm still working on that as well

Conn wrote:Uh wow, didn't expect I dig up gold

The table starts at 0d/f110:

Code:

$05/FABE BF 00 20 7E LDA $7E2000,x[$7E:2694] A:0694 X:0694 Y:000A
$05/FAC2 AA          TAX                     A:02C8 X:0694 Y:000A
$05/FAC3 BF 10 F1 1B LDA $1BF110,x[$1B:F3D8] A:02C8 X:02C8 Y:000A

So if 3759 tiles are addressed, this is hex $eaf, so the table should end at 0d/f110+eaf=0d/ffbf
(looks like I calculated correct when looking at the hex patern in the rom)

I guess you can do something awesome with it
For myself only important is for now that the addresses given work bugfree. So I'll wait for Erock's new hammer, maybe include that new bubble in that go, and release 1.2.7b.
Do you remember which bytes I changed for castle fences? If yes, can you give me the bytes to revert? I forgot and didn't document...

And then... yeah spoke too often about retirement, I'm still working on that as well

Yes, this bank than ends with some empty space, ie FF bytes, so it end on 0DFFFF, and then 0E0000 is start of monologues.

Here the REvert and the INvert IPS for Mario 64 castle splash fix.

REvert Mario 64 castle hammer splash fix and turned off slow walk on stairs
http://acmlm.kafuka.org/uploader/get.php?id=5257

INvert Mario 64 castle hammer splash fix and turned off slow walk on stairs (obsolete)
http://acmlm.kafuka.org/uploader/get.php?id=5258

Thanks
Unfortunately, the reversion reverts also the gribble on tree stump fix at Ganonagain. So I leave your original solution for the castle fence (which does work bugfree anyways).

So, I will only alter those 2 bytes for the beach in 1.2.7b. When I am on it, I consider changing the bubble, Erock posted with the witch (and that hammer tile). For the bubble, does anybody know where that tile is located in zcompress (I compare sprite by sprite usually to find it, so if anybody has a faster solution...)