News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - puzzledude

Pages: 1 2 3 [4] 5 6 7 8 9 ... 14
ROM Hacking Discussion / Re: Need help for Z3 hack stuff
« on: March 20, 2015, 03:20:53 pm »
1) There's a saying in the latin language (spoken by ancient Romans): if you change a little, everything will be changed. It basically means if you go for crystals in light world, it will cause a chain reaction. This was solved in Goddess of Wisdom like so: Master sword was stolen (and was put in a chest). But there was a level-3 sword in a chest, defined as Master sword (actual level-2 sword was skipped, since if you put it into the chest and open it, the game will freeze).

Level-2 sword can still be put in a chest (but this will need the ASM fix - code already written by Conn).

This brings up another question: what to do with the Meadow. It is basically your choice how to fix/solve all of that.

2) Normal gfx edit. But title screen is considered a bit advanced, due to buggy HM title-screen editor and multiple repetitions of the same elements. HM also tends to destroy the rom sometimes, if the title screen is edited.

3) You can put heart pieces and containers anywhere you like.

4) 1 chest means one item. Rare chests are coded to also have an alternative (like Lamp/5 ruppes, so if you have the Lamp, the code jumps to 5 rupees). The chests in a minigame are completely different. These are a different object, which will react on the Shopman sprite.

5) Where all the texts are, under Monologues. You just need to find it, which can be difficult.

6) Usually you do the game yourself and ask for guidelines.

7) This code was written by Conn. Can't remember where it is exactly and what to change.

ROM Hacking Discussion / Re: Need help for Z3 hack stuff
« on: March 20, 2015, 12:01:51 pm »
Wait, you mean there is no pendant in Light World while I change 02 to 03? If does, then I need remove this to test the rom for ice cave bug. But you said you already test it my hack, right?
Yes, if you change the 02 to 03, you will collect crystals only and there are no pendants(the game will think you are already past the pendants). You can force them out though. So you can still collect them, but there would be no place to display them in the MENU, which is set to crystals. The crystals can then be collected in light or dark world, but they will not display on the map in light world.

ROM Hacking Discussion / Re: Need help for Z3 hack stuff
« on: March 20, 2015, 09:08:36 am »
And how can I remove pendant in Light World?
Open the rom in HM, go to World maps/ Normal World, press the drop-down arrow, select Pendants, press the Move button, select the purple dot, right-click the purple dot, select Remove icon.

But there's no need to do that. The game knows it is in part2 and should thus not load pendants, even on the map.

You are unfortunately out of luck with the Crystals displaying on the map correctly, unless you choose that your first dungeon is the Dark palace and that the Helmasaur is the first boss to defeat.

This crystal is separate from the drop down menu: under First Crystal. The rest will display after this dungeon is done: under All crystals. This is the only thing you need to edit (all the crystals).

But... the crystals will display in dark world. Haven't tested if it is even possible to display them in light world. This is not documented and will probably need ASM (the editor doesn't seem to respond if you click on Normal or Dark world under World maps; it displays all icons regardless). So there is something else telling the game to display them in dark world only.

Editing the icons on the map also tends to bug the rom and will surely display a false dark-world-whirl simbol on the map.

ROM Hacking Discussion / Re: Need help for Z3 hack stuff
« on: March 14, 2015, 09:53:40 am »
No, the addresses are separated, the 03 comes at 2EDE0

Ice rod cave (bug fix)

Collect crystals in light world (ie jump to part2 after talking to the uncle)

ROM Hacking Discussion / Re: General Leo Hack issues
« on: March 12, 2015, 05:06:35 pm »
Something is finally matching:

the rom
Final Fantasy III (U) (V1.1) [!] CRC32-C0FA0464 unheadered
+ your patch makes it a 84A1F38E.

PS (this matches the last line in my list):
Code: [Select]
Final Fantasy III (U) (V1.0) [!]         CRC32-1E5FF73D unheade. (WORKS)
Final Fantasy III (U) (V1.0) [T-Spa][a1] CRC32-C42B9546 unheade. (WORKS)
Final Fantasy III (U) (V1.1) [!]         CRC32-84A1F38E unheade. (WORKS)

However we still don't know, how such files will behave, since they they all seem to work and yet they are different (and nothing matches the hashes of the Rom/Iso info given).

ROM Hacking Discussion / Re: General Leo Hack issues
« on: March 12, 2015, 11:57:50 am »
Further testing:
Code: [Select]
CRC32 for Original roms:
Final Fantasy III (U) (V1.0) [!]         CRC32-85967AA9 headered (WORKS)
Final Fantasy III (U) (V1.0) [T-Spa][a1] CRC32-98F42AF5 headered (WORKS)
Final Fantasy III (U) (V1.0) [!]         CRC32-A27F1C7A unheade. (Doesn't work)
Final Fantasy III (U) (V1.0) [T-Spa][a1] CRC32-BF1D4C26 unheade. (Doesn't work)
Final Fantasy III (U) (V1.1) [!]         CRC32-E71362B7 headered (WORKS)
Final Fantasy III (U) (V1.1) [!]         CRC32-C0FA0464 unheade. (Doesn't work)

CRC-32 when the original roms are patched (patch applied):
Final Fantasy III (U) (V1.0) [!]         CRC32-39B691EE headered (WORKS)
Final Fantasy III (U) (V1.0) [T-Spa][a1] CRC32-E3C2F395 headered (WORKS)
Final Fantasy III (U) (V1.0) [!]         CRC32-703A3517 unheade. (Doesn't work)
Final Fantasy III (U) (V1.0) [T-Spa][a1] CRC32-5BAD9A3A unheade. (Doesn't work)
Final Fantasy III (U) (V1.1) [!]         CRC32-A348955D headered (WORKS)
Final Fantasy III (U) (V1.1) [!]         CRC32-9591F794 unheade. (Doesn't work)

CRC-32 when the the header is removed from the working patched roms:
Final Fantasy III (U) (V1.0) [!]         CRC32-1E5FF73D unheade. (WORKS)
Final Fantasy III (U) (V1.0) [T-Spa][a1] CRC32-C42B9546 unheade. (WORKS)
Final Fantasy III (U) (V1.1) [!]         CRC32-84A1F38E unheade. (WORKS)

Nothing matches the ROM/ISO info
Unmodified ROM CRC32: D184D919
Patch Applied  CRC32: 6DA4325E
Unmodified ROM CRC32: 326CF6A2
Patch Applied  CRC32: 76370148

It is because of the above confusion (3 different files work/load the game, but non of them matches the original CRC, that we should go for the UPS format, where such confusion is not possible.

With this example you can clearly see the major fault of the IPS patch format, since all the above 3 patched games, which seem to work might crash sumwhere during gameplay, since they don't match with the given hashes.

It is also altogether odd that the standard FF3 file was not used to make the Ips.

This should be 85967AA9 headered and when patch applied 39B691EE headered (this file works by the way).
I would take my chances and use this file to play.

Your other option is to further search until you find the rare rom with the actual original header (which does not contain only 00 bytes). Then the hashes might match up.

ROM Hacking Discussion / Re: General Leo Hack issues
« on: March 12, 2015, 09:07:36 am »
Would it be okay to request someone to patch it for me and send me the working file?

Unfortunatelly no. Since then you would be asking for a rom. I, however, tested this out:

This is the ROM info:

Only HEADERED version will work!
Unmodified ROM CRC32: D184D919
Patch Applied CRC32: 6DA4325E
Final Fantasy 3 (V1.1) (U) [!]
Only HEADERED version will work!
Unmodified ROM CRC32: 326CF6A2
Patch Applied CRC32: 76370148

Very well described, But... all Final_Fantasy_III_(U)_(V1.0)_[!] seem to be without the header by default.

Standard FF3 file:
Final Fantasy III (U) (V1.0) [!]
with no header, CRC-32 is A27F1C7A.   

Added the header with Tush:
File CRC32    85967AA9   (added header with Tush)                             
ROM CRC32     A27F1C7A   (original non headered file)

But the hashes are not matching, even if headered. This is so because the original header does Not conaint only 00 bytes, that Tush has added to a non-headered file.

Similar here:
Final Fantasy III (U) (V1.1) [!]

File CRC32    E71362B7    (added header with Tush)                           
ROM CRC32     C0FA0464    (original non headered file)
Hashes are again not matching.

If you already patched the upper two files and don't work, you can try and ask the author where he got the original headered rom, or what's the CRC-32 of the original file without the header, ie ROM CRC as opposed to file CRC, which he submited under "Unmodified ROM CRC32: D184D919".

You see, this headered file: D184D919 should be A27F1C7A, if the header is removed, so:
D184D919 base + original header
85967AA9 base + manually added header (00 bytes)
A27F1C7A base only (actual rom)
(if the above is not true, than the author used a third party original file; or the D184D919 refers to base only).

Your goal is to get this headered file with the CRC D184D919. If you patch this you should get 6DA4325E and this file should work.

I hate the headers. Imagine the Ips would be made out of the non-headered file (which is easy to do). You would immediately know, where you're at.

ROM Hacking Discussion / Re: Need help for Z3 hack stuff
« on: March 11, 2015, 06:33:49 am »
You're better off removing the header with something like Tush and only adding a header back when using outdated tools that require a header. Most shouldn't (as headers of this sort are completely unnecessary in this century) and the vast majority of the codes, patches and documentation that people share with you will be with an unheadered ROM in mind. If you use an unheadered ROM you won't have to make adjustments to all of your offsets, thereby giving yourself one less chance to make a mistake somewhere along the way.
Exactly. The address is usually given, if there's no header mainly because this is the "actual" address. It is interesting that Euclid, the author of Parallel Worlds, made a document a while back with lots of useful hex fixes (addresses) and they were all based on the headered rom. So if you have a non headered rom, you simply go 32 rows in hex back (-200) or add a header to match the addresses, in the upper case (address given if no header, but you have a headered rom) you simply go 32 rows forward in hex (+200) or remove the header to match the addresses.

So in the upper case the 2EDE0 (if unheadered) is actually 2EFE0 (if headered).
Or $02/EDE0 --> $02/EFE0 (if you prefer the "ASM" terminology of writing addresses). The $ means the address is in hex, the 02 refers to the "global" bank (since the game is constructed in "banks" of 8000 bytes (in hex), and the EDE0 is the "local" address/offset.

ROM Hacking Discussion / Re: Legend of Zelda: Ganon in Light World
« on: March 10, 2015, 05:26:03 pm »
Well problem is I use header rom. I didnt use unheader rom.
Nothing really problematic here. If headered, then:
2EDE0 becomes 2EFE0 (for the crystals in the light world)
02 --> 03

15720 becomes 15920 (for the Ice cave bug fix)
12 02 FF FF 16 ---> 12 02 02 02 16

The address is then basically shifted by +200 bytes.

Normally when hex editing you always remove the header, since the pointers will then point "falsly" and can confuse. For instance the pointer 00 80 0A (reversed SNES address) leads to 50000 (hex address). In any headered Lorom, the same pointer leads to 50200, which at first glance seems like a paradox, but the game knows to "skip" those 200 bytes.

Code: [Select]
header           00200
actual address   2EDE0
sum              2EFE0

ROM Hacking Discussion / Re: Legend of Zelda: Ganon in Light World
« on: March 06, 2015, 06:02:39 am »
In the spirit of the "hand of peace" which bradzx accepted from me, I asked Conn if this is fixable. And Conn! found it using his ASM skills.

This bug was made by Hyrule Magic program (false scroll values for room 288).

If the file has no header, open it in a hex editor and go to hex address 15720. There is a code there 12 02 FF FF 16.
Change this to 12 02 02 02 16.

So both FF bytes are false and should both be 02, and the scrolling in the cave will be back to normal (tested).

I can also send you the ips with Ganon in light world, which also has all those fixes in it (ice cave bug fix and collecting crystals in light world feature).

ROM Hacking Discussion / Re: Need help for Z3 hack stuff
« on: March 06, 2015, 05:51:43 am »
In the spirit of the "hand of peace" which bradzx accepted from me, here's how to achieve that. It was traced by Conn! and incredibly, there's only one byte to change.

If the rom has no header, use the hex editor and go to hex address 2EDE0. There should be a byte 02 there (jump to part1). Change this byte to 03 (jump to part2) and you will have crystals in light world.

This is the same in Goddess of Wisdom. When you rescue Zelda to the church and talk to the priest, the game will thus jump from the beginning mode directly to the second part mode (skipping the part1= collect pendants).

This is altogether incredibly useful, since the game can now have a different global strategy of having one overworld and 7 crystal dungeons; similar to Link's Awakening for GB. So it skips the 3 pendant dungeons, Agahnim's dungeon and fight with Agahnim, which forces you to the dark world. But the strategy can still be adopted: you can namely collect crystals in light and dark world, so you can have both worlds as well.

It was translated to something that the hardware understands. If you don't mind, in what other situations would such a translation be necessary when hacking this game? I guess any pointers that we input manually but what else?
Basically everything, since the pointers are all over the place. Imagine you have lots of (different) data, so you obviously need to know when to "go" to specific "data blocks". For instance the hurting pits are just 114 bytes, out of 1MB (million bytes). So that needs one pointer.

Each data for any of the 295 rooms needs one pointer (1 for each room). Ironically all such pointers again need a primary pointer. So the authors decided to tell the "machine" to first go to the area for all the room pointers and then "jump" to each individual room (data only). Similar for header, items, sprites data etc etc.

Same for overworld areas etc etc. This is basically mandatory to know/learn, specially if you write ASM, where you also need to know where to jump to your new code. Usually all addresses in ASM are Snes addresses (only this time you actually write them out, they go to little endian after the assembly with xkas).

To save space, the pointers are sometimes 2byte only, since they are all in the same 8000 bank (and the 3rd value of the 3byte pointer would be identical, so it is loaded only once). Sometimes the 2byte pointer refers to the ofset from 1 address (to save space again).

You will need the Snestuf program to calculate this:

Set addressing mode to LoROM (Type1), since that's what Alttp is by default; uncheck the "include header" and "format results".

At PC address type in 150000 (location you want the data to be at), and at SNES address the automatic output will be 2A8000.

Reverse that and group it by bytes into 00 80 2A. So this is actually the Snes address reversed, since the CPU of the Snes sees addresses in little endian (reversed).

So basically what we (the humans, lol) see as 150000, the Snes "machine" will se as 00 80 2A. Reminds me of Matrix for some reason.

Original values (pointer) were 0C 99 00. So input 00990C into the Snes address field, and you'll get 00190C. So at this address you can see the Alttp list of all rooms with hurting pits: first value of the code is 72 00, which is 0072hex is 114 dec. In Hyrule magic go to room 114, and you'll see if you fall down here, you will not be teleported (but respawned to the door).

Regarding the pit damage: I believe Conn already found the byte which controls this - in the Conker hack, when you fall down no heart is subtracted, so this address was found by him. This should be 1 or 2 bytes, with the value 01 (default), which should be changed (in Conker to 00= no damage) in your case to 20 in dec= full damage (but you need to write it in hex, so 14).

Here the info on pits from my document:

*Couldnt find any pointers here

*Data at 190C (block is fixed to 72)

72 in hex is 114 in dec :2 = 57 rooms with pits are possible.

2 bytes for a pit definition.

72 00 = room 114

New data found by XaserLe on expansion

Pointer at 394AB, pointer is 0C 99 00, leads to 00190C.
Data length at 394A6, 70 00 (+02 is 72 00 is 72 in hex is 114 in dec :2 =57 rooms with pits.
This can now be expanded to 320. 320 rooms x2 = 640, is 280in hex= 80 02= (-2) = 7E 02.
change 70 00 into 7E 02 to be able to have all 320 rooms with hurt pits.

So what you basically need to do is to change the pointer at 394AB, to not lead to 00190C, but rather somewhere else with more room, for instance 150000 (if the rom is expanded to 2MB). New pointer is then 00 80 2A. And at 394A6 you define the length of the data block. For instance if there are 100 rooms with hurt-pits, you need 200 bytes (2 per room), is C8 in hex. But for some reason you need to reduce it by 2. So new value is C6 00 (100 rooms), old value was 70 00 (57 rooms). Max is 7E 02 (320 rooms).

Damage holes to all rooms with 20 hearts of damage would keep original intentions of game (but there are a couple rooms that still do need the pit teleports so will have to redesign or figure out how to keep them working), i did start doing that (with mathnonapkins hex notes it was easy) and bumping up enemies stats with the stat editor which was also easy.....not sure i can find and dig out my notes though was along time ago.

That's actually not a problem. The pits are teleports by default, and the default value for it is room 0= Ganon room. With that new hex code you simply need to enter all the numbers of rooms (in hex, 2 byte each) which will have hurting pits. Original game allows 57 rooms, this code allows 320 rooms (max). So if you wish the teleporting pits in a room, you simply don't define that room in the list. So basically all you need is a list of all rooms with hurting pits.

Just an idea for the bug pits:
-first use the new hex code, which we decoded a while back, to be able to extend the number of "hearting" holes to all rooms, so when you fall down a hole, you will be respawned to the entrance, but...

-in the ASM code, find the "subtract" 1 heart when falling down a pit and then change this to 20 hearts.

Result: when you fall down a pit, that's supposed to take you to bug world, choose the "pit that hurts the player". Once you fall in such a pit, you will respawn at the entrance that you entered the room, and then be dead (since it will substract all your health). So then it actually will be the "game over" pit.

Problem-1: the new extended hurting pit code is not compatible with Hyrule Magic, so it needs to be inserted via hex at the end.

Problem-2: everytime you fall down any hurting pit will result in sudden death (but I believe you want the game to not be to easy).

You again need to remember that you and KGP are the authors and you can do things the way you want. (It is for that reason that some hackers actually don't post their progress to much, since they have their own idea for their game and might not agree with other ideas).

Personal Projects / Re: Update: Bruce Campbell vs Ganon, it's on.
« on: March 05, 2015, 03:56:55 am »
1) What did you like?
2) What did you dislike?
3) What would you like to see improved?
4) What would you like to see removed?
5) Did you finish the game? If not, why? And how far did you make it before you chickened out? LOL

I finished Zelda3 Bruce Campbel vs Ganon.
1) I liked the new feel (remodeled overworlds and dungeon as well as the "bad dead" feel of it. The game has potential. You can clearly see, that this is much better that just a "masterquest".

2) Bug pits and other various bugs. The house in the Zora's domain and the watefall paradox drawing in the dark world. Also some dialogs are based on too much swearing. Like this one: "The lake of [censored] fluids."

3) Mainly to debug all the remaining bugs (bug pits, false overworld drawings, false house exits). Also some dungeons could be more remodeled, specially the first dungeon of the dark world (pretty much similar to original).

4) Pretty much the same as 2) and 3)

5) Yes, I finished the game. I don't quit that easily. But I know a lot of players did not finish it, because of the bug pits and maybe the sword-1 comes too late, so you can get defeated a lot and have to view that message with the "dildo" maybe too many times.

So the combination of bug world and the "dildo" message in the early stage of the game might bring players down (in into quiting early). The game is thus much more appealing later on.

Also the Triforce dialog is very cool.

Great that this is on, and that KGP has contacted you back.

Newcomer's Board / Re: Correspondence between ZST and SRM?
« on: February 18, 2015, 06:30:34 am »
What's the correspondence between save states and saveram? Are the addresses the same? If I discover an address in a save state for, say, a character's name (presuming it's immutable and not player-changable), could I crack open the saveram, go to the same address, and alter that character's name? Or is a save state (I use ZSNES as is the standard) a subset of the saveram? Or is there no general, reliable relationship between the two at all?
Long story short: there is no correspondence. ZST is a savestate of the ZSNES emulator and is completely specific and emulator based. The savestate of other emus, such as Snes9x, have again their specific savestate file, in this case with the .000 extension. SRM however is save ram made by original game and is compatible with all emus and real hardware.

The difference between the two is great and there is no connection whatsoever. If you want to edit the save of the game, it is best to analyze the SRM itself. But again even if you would "hack" it, like Math On Napkins did with the Alttp SRM, the changes are not that easy.

SRM usually has an internal checksum validation, so if you edit anything (giving yourself better equipment) you need to manually change the checksum for the file to be valid. This however is somewhat difficult. In Alttp it is even/odd byte dependent. If the address to be changed is even, and gets a +1, then the even byte of the 2byte checksum needs -1. If the changes are bigger it is sometimes impossible to see, how to change the checksum without somesort of a calculator, specially because of the "looping", since 00 byte -1 is then FF.

ROM Hacking Discussion / Re: Zelda III hacking *sigh*
« on: February 17, 2015, 08:11:20 am »
Yeah. It just seems insane though, that the only editor available is completely broken yet we're all still "negotiating" with it anyway. To call it "usable" would be an outright lie. One wrong click will permanently destroy your ROM. And you can't just learn how to use Hyrule Magic, you also have to learn to fix all of the things that it breaks inadvertently. Which basicially means you have to learn EVERYTHING about the game, how it's data is structured and how it's data is used.

With all of the data that has been mined for this game it seems like it would be easy (relatively speaking, of course) to program an editor for it that actually works. Too bad there isn't anyone with the appropriate skills that's interested in doing this. Therefore, the only people willing to hack this game have to be some sort of masochists (or insane like me). Makes me wonder how many hacks of this game have been started but never finished.
Welcome to the club. It is a fact that 80 percent of all people, who have attempted on an Alttp hack, have quit, due to their file getting severely bugged, while 10 percent have produced a final product, which is also quite bugged (similar to what you see in Bruce Campbel, where practically all pits lead to the "bug world/dimension").

You can clearly see, how difficult the process is, since some Master hacks of this game have practically nothing changed, but have quite some bugs (again).

The main problem is not just Hyrule Magic, but also Alttp as such. This game is like a closet, which has shelves, and on it books, but placed in such a way, that there is no emtpy space or very little of it.

So when you try to edit it (meaning changing and adding some books) you will eventually drop a book or have to force something to be falsly "stuffed in".

If you try to start from scratch and empty all of it, the shelf would drop out of frame, when you would remove the books from it.

That's basically what Hyrule Magic is doing (failing) when you use it on the entire filled up Alttp rom.

Luckily Math On Napkins decided to write a new editor for this game a while back, called Black Magic. If this is ever to be finished, it would radically improve the process and bring in lots and lots of new complete hacks of this game.

Unfortunately it is difficult to expect for one person to code all that, since the standard set for this editor was incredibly high (almost to much). And the author of Hyrule Magic asked MoN to not release the source code for HM, or the edited version of it (hyper irony, since the author produced a bugged program and "doesn't want" it to be fixed).

We now have enough knowledge to come up with the perfect non-bugged indoor (dungeon) editor, since I decoded every possible indoor info in hex and know how the game writes/stores the data for it (including pointers and all). It would look similar as the HM dungeon editor and would do similar tasks, but would never bug out, since it would have fixed pointers to precalculated addresses, with so much ofsets between room-codes to always have enogh space (so called maximum space possible would be reserved for the desired code). And the game would still not come pass 2MB.

But we would certainly need a help of someone, who is capable of writing a program, since this really is "the next level" of coding. We can do gfx, ASM etc etc, but currently I know no person to be able to write such an editor and we really can not ask MoN to be involved with 2 editors or to change his style/work, set for Black Magic.

Pages: 1 2 3 [4] 5 6 7 8 9 ... 14