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 - FCandChill

Pages: [1] 2 3 4 5 6 ... 20
1
Are any of them too large to add?  CD game patches can easily run into that issue.

If it's a space issue, the staff let's you host patches on external sites, like here...
https://www.romhacking.net/translations/2795/

Additionally, a script could be made to insert the dialogue, insert the patches, etc. but it's a little to late to do that...

As for the file host, Mediafire, you can do worse, but you could do better. I suggest archive.org.

2
Been wondering that myself. They seem good enough.
Me too. What romsets the disk images came from would help as well, as it's apparent a lot of people are having trouble tracking down the right disk images.

3
Yikes, it sounds like you're manually inserting dialogue into a hex editor:

The Newbie Package of REQUIRED Material

ROMHacking.net FAQ: You ask, we answer!
ROMHacking.net Getting Started Section: Newbies Go HERE!
ROMHacking.net Documents Section!
How to ask questions the smart way.
On the Essence of ROM Hacking
Talk with experienced people in our IRC chat and ask specific questions there.

For script dumping and insertion (use these instead of manually inserting):
* https://www.romhacking.net/utilities/224/ - Atlas
* https://www.romhacking.net/utilities/647/ - Cartographer

Debugger -
* https://www.romhacking.net/utilities/689/ - FCEUX

So the thought of learning how to deal with rom expansion along with basic changes seemed daunting.  The second issue is that I can easily write to a cartridge that is configured for UxROM mapper 2 (the format Zoids BotCC uses) and I decided that for this project a primary goal would be to have an end product that was faithful to the translation while at the same time could be played on the same hardware the game was initially designed for.

Players won't notice the mapper is different unless they check the file size. I would strongly suggest you expand the rom so the translation isn't compromised. If you have the ability to have more space, take advantage of it. You'll have a better translation as a result.

4
I did some preliminary research into the menu. Here's my notes:

Code: [Select]
***DAT***
Loading places from RAM differ. I suggest breakpointing at a controller register after a button input first and making a savestate, to make debugging easier.

PPU Write Breakpoint
 07:C138: BD 00 07  LDA $0700,X @ $0799 = #$0D
>07:C13B: 8D 07 20  STA PPU_DATA = #$00

 07:C138: BD 00 07  LDA $0700,X @ $07A2 = #$0A
>07:C13B: 8D 07 20  STA PPU_DATA = #$00

 07:C138: BD 00 07  LDA $0700,X @ $07A3 = #$1D
>07:C13B: 8D 07 20  STA PPU_DATA = #$00



=========
RAM write

 07:CC75: A1 1E     LDA ($1E,X) @ $B85D = #$0D
>07:CC77: 99 00 07  STA $0700,Y @ $0799 = #$7E

 07:CC75: A1 1E     LDA ($1E,X) @ $B860 = #$0A
>07:CC77: 99 00 07  STA $0700,Y @ $07A2 = #$02

 07:CC75: A1 1E     LDA ($1E,X) @ $B861 = #$1D
>07:CC77: 99 00 07  STA $0700,Y @ $07A3 = #$7E

ROM Address of "DAT":
0x1b86d

=========
Pointer calculations


 07:D829: B1 53     LDA ($53),Y @ $9B2A = #$B7
 07:D82B: 18        CLC
 07:D82C: 65 1C     ADC $1C = #$A6
 07:D82E: 85 1E     STA $1E = #$5D

 07:D800: 65 1F     ADC $1F = #$B8
 07:D802: 85 1F     STA $1F = #$B8
 
 07:CC87: A9 20     LDA #$20
 07:CC89: 18        CLC
 07:CC8A: 65 1C     ADC $1C = #$86
 07:CC8C: 85 1C     STA $1C = #$A6
 
 
Termination for pointer?
>07:CCAF: C6 1A     DEC $1A = #$02
 07:CCB1: D0 AA     BNE $CC5D
 
 ;load as a constant. Not sure how "LOOK" is handled.
 07:D804: A9 02     LDA #$02
 07:D806: 85 1B     STA $1B = #$02
 07:D808: 85 1A     STA $1A = #$02

Takeaways:
* Pointers are programmatically generated.
* Length of string probably loaded into A from "LDA #$02". Not sure how "LOOK" is handled.

With this, I'll say expanding the menu will be a pain in the butt. The code is kind of hard to follow too. Doesn't help that each menu entry's pointer is programmatically calculated.

I suggest just removing the dakuten support. This will prevent you from having to move stuff around.

Also, I would suggest expanding the rom instead of sacrificing the script. How are you inserting the script? Can you provide the Japanese and English table files?

5
Depends on who you ask, but Totally Rad's localization made the game into a funny surfer dude parody.

6
Okay, I thought it might be something like that but I tried adding a header to my ROM using Tush but it still didn't seem to work.

Use Tokimeki Memorial - Densetsu no Ki no Shita de (J) (V1.0)[!].smc. With the header, this is the sha1:
6d6c021023873e5651817f4603435eabbc8297f5

Not that it matters. The translation isn't very good.

7
May I suggest creating a submission?
I don't think it's worth it. Some menus were updated, but that's about it. It's more of a graphics hack than an actual translation. It's easy to dump the game's script but hard to insert due to how the game is programmed. The hacker decided to edit the font to translate some stuff without inserting any dialogue data, is my first impression.

As the patch was freshly created just now, the patch will be for whatever version TokimemoFan happened to have.

It requires a 200 byte header.

8
Use the following patcher:
https://www.romhacking.net/utilities/893/

As for translating the game, many people have tried, many people have failed. Why? I assume it's because of the game's funky dialogue storage system. The guy who made the patch even said they had trouble locating the pointers...

9
Programming / Re: Building Leaked Source Code?
« on: September 07, 2020, 11:36:29 am »

10
Newcomer's Board / Re: WORD WITHOUT POINTER (ASSEMBLY)
« on: August 09, 2020, 12:24:07 pm »
Your friend is correct about it being hardcoded, but not the location... The location is actually 0x6112 in the rom. It's hardcoded like so.

Code: [Select]
00e112 lda #$49               A:0054 X:007f Y:0000 S:1e38 D:0000 DB:00 nvMxdizc V:191 H:155 F:11
00e114 sta $7e245e   [7e245e] A:0049 X:007f Y:0000 S:1e38 D:0000 DB:00 nvMxdizc V:191 H:159 F:11
00e118 lda #$4d               A:0049 X:007f Y:0000 S:1e38 D:0000 DB:00 nvMxdizc V:191 H:169 F:11
00e11a sta $7e2460   [7e2460] A:004d X:007f Y:0000 S:1e38 D:0000 DB:00 nvMxdizc V:191 H:173 F:11
00e11e lda #$45               A:004d X:007f Y:0000 S:1e38 D:0000 DB:00 nvMxdizc V:191 H:183 F:11
00e120 sta $7e2462   [7e2462] A:0045 X:007f Y:0000 S:1e38 D:0000 DB:00 nvMxdizc V:191 H:187 F:11

#$49 is T for example. What you want to do is JMP to somewhere else, add an extra LDA, and JMP back. This is a good guide to learn assembly...

https://skilldrick.github.io/easy6502/

6502 is similar enough to 65C816. As for how I found the correct location, I used the BSNES+ debugging emulator.

12
Use HTTPS Everywhere:
https://en.wikipedia.org/wiki/HTTPS_Everywhere

It has to be configured on a per-site basis, since not all websites use SSL.

As for RHDN redirecting to the HTTPS version, there's ways to do it in PHP, however, it may have been a deliberate decision to support legacy browsers.

13
Are there any advantages/disadvantages to using one vs. the other? I ask this as a complete noob.

I haven't used Atlas or Cartographer much, but here it goes.

Python script
* Seems rather primitive.
* I couldn't get it to compile.

Atlas / Cartographer
* Widely used. More or less a standard
* Kind of a pain to work with flat files. As in, you're working with plain txt files.
* I looked at Cartographer's source code and couldn't really follow it.
* You have a decent amount of examples and source at your disposal.
* The developer of Altas is fairly active.
* There's a steep difficulty curve.

Cypro Ace and Spiro
* Currently, behind closed doors because I still add features from time to time, so I will have to set up the environment for you.
* It's been awhile since I did benchmarking, but the script dumping and insertion is faster than Atlas and Cartographer.
* I think the source code is good.
* The utility supports autolinebreaking. It's incredibly tedious to add line breaks manually to every dialogue line.
* The utility allows writing your script to multiple regions. I've heard Atlas is really limited to where it can write to the rom.
* It doesn't support writing to multiple files like Atlas. I just never found the need to program it in, since I never needed to.
* The preview option makes it easier to edit scripts that are heavy with control codes.

July 09, 2020, 05:17:33 am - (Auto Merged - Double Posts are not allowed before 7 days.)
I may be able to help. I have a decent disassembly of the game, and it shouldn't be too hard.

I looked at the python script dumper and got a script dump.

https://mega.nz/file/5jABmQRR#CGyV_RVe4goONxCeOskFTPlAb6q_iV31QYQpINdwr7s

So the game uses 4 byte pointers which point to "RIFF" "files". The RIFF files contain "src code" "jump" and script data. Quite an interesting format. It's no wonder the game was never fan translated...

In any case, the src code junk is not a big deal, however, I need some more info on the "jump" data. I tried No$GBA's debugger, and ARM7 is much different to 6502. It's more similar to Intel processors which I don't have much experience with. I hypothesize that data after "JUMP" contains embedded pointer data. I know for a fact the game uses embedded reads, but I need some more info on it.

Hi! Years ago I translate this game to Portuguese.

By the way, your tool doesn't dump / insert all dialogue in the game.

14
Just to be clear, I'm following up on this thread and am still 100% committed to making a Spanish translation. I haven't answered these lasts posts mainly because FCandChill has beaten me to the punch with the corresponding relevant questions. :P

I decided to take it upon myself and sign up. Here's a mirror of the download:

https://mega.nz/file/c25WlCYY#dcmbJqR6jFYm1xpifcjGU7zAEeStfuB-bVNdmIQF840

I renamed the archive from "Files.7z" to "Harvest Moon Script Dumper and Inserter.7z". Other than that, everything else was untouched.

As for the code itself, it's very small and compact. All the dumping and insertion data is in a.py. __main.py handles all the dumping and insertion. Two archives called "Dumped" and "Insert" store the script. The code is in English and the comments are in Portuguese.

It's up to you if you want to use this utility or not. I would recommend using the romhacking standard utilities like Cartographer and Atlas or you can have me adjust my utilities for you, if you want to work in a GUI.


15
Hi! Years ago I translate this game to Portuguese. You can find a text dumper/inserter here: https://www.romhacking.net.br/index.php?topic=1521.0
You just need to adapt the tool for your project.

The huge problem is the title screen. It requires a lot of asm knowledge.

Sorry for any english mistakes. I'm not a fluent speaker.

Do you find a way to edit the title screen? It's the only thing I didn't edit in my translation.

I would assume we'd have to register on the forum to download it, no? I can't seem to find the download link. Can you provide a download link here instead?

16
Pointers are specifically the part that eludes me. Appreciate you sharing those docs. I will definitely take a look at them.

Any help would be greatly appreciated! Right now the main issue is text length and how to extend that (where possible) without breaking the game.

Pointers specify where dialogue is located. When you repoint, you relocate where the dialogue is located. You also control how long the dialogue line is. Repointing is the solution to your issue. As for danke helping you out, you're in good hands. As for the partial disassembly of Harvest Moon: Friends of Mineral Town, I'd love to see it, danke!

18
ROM Hacking Discussion / Re: Kickle Cubicle Level Editing
« on: June 20, 2020, 11:51:44 pm »
I loved this game when I was a teenager, I never coulda beat the extra levels after I beat this game. I'm glad this game is getting the love it deserves. :D

Yeah, it's really good game. I'm a fan of hard as nails puzzle games.

Project is now public on github here: https://github.com/the60ftatomicman/KickleCubicleLevelEditor
At the moment the instructions are a bit bland (I apologize) however I'll get things up and running

It took some time to extract (90% correct) the level data and enemy data from the documents.
I need to add more tile icons
I need to add more enemy icons (only a few are in there)
after this we'll be v0.10

I'll get a timeline up on what I would like to improve (alot) soon! I was just excited to get the little I have done out the door for now to generate some interest.

If you're code savvy and can develop in angular by all means I could use the help!

I find the choice of JavaScript interesting. Unfortunately, I don't have experience with level editors to help out currently and have my hands full with other project. I would suggest finding pre-existing utilities that are out in the wild and seeing how they tick. Thing is, most aren't in JavaScript...

I looked at the code for a bit. If it were me, I would have done a few things differently: I wouldn't have used Powershell (just a preference, it has its limitations), and I would have read the graphics straight from the rom instead of storing them as PNGs. Just some preferences though. Still a pretty cool utility you have going on.

19
In the credits, it says "Ale'ssandro Verrecchia (Faggot)" .. second line from the top. Is it supposed to say that? I checked to see if an obscure instrument had that name, but couldn't find anything.



It should be spelled "fagott" or "fagotto"... "Faggot" is simply a homophobic slur. But if it were me, I would use the more innocuous name for the instrument, the "bassoon"... https://en.wikipedia.org/wiki/Bassoon

20
I stick by what I said about Quest64. It's a boring collect a thon where you walk  around empty crappy rendered environments and hope for some kind of encounter. It made me wish I was playing any rpg with an encounter rate of every two steps. (And i hate those :P)
I've beaten Quest64 legitimately. Quest64 isn't the worst RPG, but it definitely is an unfinished game that should have never been released in its current state. The Japanese version is actually a more finished game (it even has a proper ending), but still lacks standard RPG elements like money, armor, and more than one party member... Also, the graphics are pretty good (in my opinion), it even has an impressive draw distance for the N64. While the innovative gameplay enticed me for a bit, the gameplay can be completely broken by abusing water and rock spells and then using a spell that blocks magic ... all enemies attack via magic...

Fun fact: The Quest 64 battle theme steals some riffs from the Final Fantasy VII battle theme.

Pages: [1] 2 3 4 5 6 ... 20