Messages

1

Releases / Re: [REL] Final Fantasy VII - Retranslation Project With Documentation

« on: 2012-09-24 11:45:17 »

There's usually a simpler explanation to these issues: plot ≠ gameplay.

2

Scripting and Reverse Engineering / Re: FIELD.BIN (exploration) thread

« on: 2012-07-26 02:28:30 »

Grab the command line gzip and make sure to use the proper options (should be a couple flags, IIRC) to exclude unwanted stuff from the header.

3

FF7 Tools / Re: [WIP/RELEASE] Final Fantasy VII International all-in-one translation package

« on: 2012-07-25 19:17:06 »

That would need at least a few changes to the poor sources, which I have no idea where the hell I have them (if they still exist somewhere on my disks). Plus it's no complicated tool, anybody can reprogram it with better results, hence why I never bothered releasing it in the first place.

4

FF7 Tools / Re: [WIP/RELEASE] Final Fantasy VII International all-in-one translation package

« on: 2012-07-25 17:55:06 »

Careful how you use isocpy, all it does is injecting a file into the ISO without expanding anything: it doesn't update TOC information nor it considers if the file is larger than the original entry (i.e. corruption of the next file in the ISO might happen). The program is not meat to be used by newbies, which is why I never released it to the public other than for this project (and with MNU files you can't possibly screw).

5

Scripting and Reverse Engineering / Re: FIELD.BIN (exploration) thread

« on: 2012-07-24 00:43:10 »

Negative; rather than choosing Save after making modifications, I chose Save As, and created a new image.

You don't need to use Save, changes are instantly applied no matter what command you use after import. With Save As all you do is creating yet another identical copy of the ISO.

Actually, not quite - LBA values are always 150 lower than the corresponding sector IDs, because the first 150 sectors of a PSX disc are used for license data. That means if you're hunting look ups, you have to account for the numeric difference.

There's no difference to be taken into account, you were probably mislead by CDMage's sector scroller (in which sector 150=LBA 0=beginning of the ISO). Let's go by examples: LBA=0 means something is located at sector 0, byte 0; LBA=23 means the sector you need to seek to is the 23rd, byte 54188 (23*2352=54096, where 2352 is the size in bytes of each sector). Licensing data is much smaller than 150 sectors.

6

Scripting and Reverse Engineering / Re: FIELD.BIN (exploration) thread

« on: 2012-07-23 01:03:50 »

What do you mean by same position? If they are the same size as they originally were, if they have the original name, and if they are in the original directory?

No, I mean they must share the same LBA and size on all three disks. There's no point in retaining the original size (and whatever other crap) if you're planning on regenerating an expanded ISO.

Probably due to different gzip implementations, my file was 2 KB smaller than the original

Check if the gzip signature is correct and if the header contains any extra information like time stamps and file names (FFVII doesn't like 'em), just in case.

It successfully imported the file (to the same LBA/sector as the original), and I saved the new image as a new file (in the same format I loaded it as, Mode 2/2352-byte image;

You don't save a new image after injecting a file, it's unnecessary. The ISO is already changed as soon as you confirm the injection.

7

Scripting and Reverse Engineering / Re: FF7 PSX: SAVEMENU.MNU's NEW GAME feature

« on: 2012-07-22 07:43:51 »

Still, I think Hack7 should be able to open the files, and complain about issues afterward if desired...

Or Makou could regenerate jumps automatically. I'm not sure why it's still working internally with byte positions:
1) it's error prone like hell, using labels instead of addresses would void the problem in an instant;
2) makes editing unnecessarily complicated, especially if there are several jump opcodes in a function.

8

General Discussion / Re: Final Fantasy Versus 13 Cancelled

« on: 2012-07-22 03:32:14 »

X was a great game and last great FF.... after that with FFX-2 (the first main cash in), it was over.  It has never recovered.

Dull cast, embarrassing story, incredibly boring battle system based on a growth system that simply doesn't exist and ends up making your characters identical in pretty much every aspect (with the exception of Yuna, she has the Summon command after all ;O ). And Nomura, oh for the love of god, NOMURA ALL OVER THE PLACE. FFX killed the series for me: so many terrible choices for just one game. No wonder the same team created XIII, another gigantic pile of flaming sh*t.

9

General Discussion / Re: Final Fantasy Versus 13 Cancelled

« on: 2012-07-21 19:46:58 »

Final Fantasy series Died with Final Fantasy 10.

Fixed.

10

General Discussion / Re: Final Fantasy Versus 13 Cancelled

« on: 2012-07-21 01:15:40 »

Couldn't care less about this last piece of crap by Square Enix. Bye bye, Sasuke lookalike.

11

Scripting and Reverse Engineering / Re: FIELD.BIN (exploration) thread

« on: 2012-07-20 14:43:06 »

Delete=physically removing them from the file, so you'd obtain the old file size -8. What you've probably done is replacing the first 8 bytes with zeros, which definitively doesn't help in making any codec recognize the gzip signature. Delete those extra bytes, that's all you gotta do.

12

Scripting and Reverse Engineering / Re: FF7 PSX: SAVEMENU.MNU's NEW GAME feature

« on: 2012-07-20 02:01:36 »

Exactly, what's this corruption issue you guys are talking about?

13

Scripting and Reverse Engineering / Re: [FF7, Field, DAT] Strips of background tiles

« on: 2012-07-20 00:18:47 »

The PSX had no direct access to VRAM and the transfer is slow.

DMA transfers from/to VRAM are actually fast, very fast, way faster than regular RAM access from the cpu.

14

Scripting and Reverse Engineering / Re: FIELD.BIN (exploration) thread

« on: 2012-07-19 23:55:05 »

That's pretty much the procedure: delete 8 bytes, rename to FIELD.gz, use any decompression program capable of detecting gzip files and you're done.

15

General Discussion / Re: Final Fantasy VII Rerelease thread

« on: 2012-07-05 19:33:47 »

Like Covarr said, it is HD the very moment it runs at 720p or 1080p, which FFX HD edition does. So it's HD, even if it still uses PS2 era assets and looks like ass. Doesn't matter what people would expect when you talk about HD as the technical definition always applies no matter what the general public says.

16

Releases / Re: [REL] Menu Overhaul Project

« on: 2012-06-29 18:10:44 »

I'm afraid increasing chocobo name length would be rather trivial as it would need an extreme reconfiguration of memory pointers assigned for those. I tried doing that once and it turned out as a nightmare.

17

Releases / Re: [REL] Final Fantasy VII - Retranslation Project With Documentation

« on: 2012-06-16 17:25:51 »

I bothered to check it.     The same as "Glass hairpin" is made clear in Ultimania.  These things are intended by the designers.  A way around this is for me to do both.  I can call it Omamori and in description "An amulet"  but this may just be silly.  Either way I am keeping Omamori because Ultimania and the bonus disk make it clear that is what it is.  An Omamori is an amulet, but an amulet is not always an Omamori.

Ultimania and the bonus disk were not created by the team that worked on FFVII, it was outsourced and most assets were created for just the purpose defined by said disk (notice the models for the Buggy and the Highwind, definitively not coming from game assets). In other words, it's not exactly something you'd want to refer to as accurate information as it's probably something coming from Famitsu or whoever took care of assembling all the data to create the guide and the disk. The original designers, programmers, producers, etc. had barely any role in the material you're basing your nomenclature off. Fun fact: I've never seen a sketch of the regular items coming from Nomura of whoever was assigned to additional designs.

18

Releases / Re: [REL] Final Fantasy VII - Retranslation Project With Documentation

« on: 2012-06-14 17:28:29 »

Says here they are specifically a certain culture/religion.  They are certainly not regular western items. Using "Amulet" or something else completely destroys the connection to Buddhism and Shinto. Edit.  I understand the Japanese translates as "Amulet"  but Ultimania makes it clear that Omamori is intended.

The ones in FFVII aren't Shintoist or Buddhist amulets, considering they aren't based on either religion (neither exists in the FFVII world, after all). Not to mention using "omamori" is totally clueless to the player; there isn't a thing lost when you translate it to amulet, as there aren't real pictures in game other than an extra disk nobody ever bothered to check (and even in that case people would still understand it's a japanese amulet, it's not rocket science). Leaving omamori is just like leaving Barret's "Cloud-san!", no more no less. Plus, they're usually called amulets anyways and the reference would still make sense with a non japophile term.

19

Releases / Re: [REL] Final Fantasy VII - Retranslation Project With Documentation

« on: 2012-06-11 19:01:10 »

I would only agree with the criticism on omamori. Leaving it as omamori just looks plain stupid as they clearly aren't japanese items but rather simple amulets you'd see any day.

20

Releases / Re: [REL] Final Fantasy VII - Retranslation Project With Documentation

« on: 2012-05-29 11:32:44 »

Giving colors to items, places, and whatnot doesn't seem like a correction you should make, since you're adding something that wasn't there in the first place (and that's the main reason why you are retranslating: preserve the original material and providing better options when it's necessary). The original has other manners for making key words stick out.

As for the "Obtained X" string, I would go and fix the articles whenever necessary. "Obtained the Masamune" sounds more natural and that's what you'd usually find.

21

Scripting and Reverse Engineering / Re: Problem with window.bin

« on: 2012-05-28 13:11:10 »

Do yourself a favor: download this program, go under the Tools menu and select "Manage window.bin".

22

Scripting and Reverse Engineering / Re: Problem with window.bin

« on: 2012-05-28 09:02:11 »

Think about it. If the executable listed filenames, the console would have to seek the file every time a resource was called. On a CD-ROM, that would be immensely slow. Direct block addresses are much faster.

That's quite far for the real reason why some games don't use TOC filenames (libraries would still cache TOC data in order to locate files in an efficient manner, so it's not a matter of speed). PlayStation games do so because libcd is bugged and cannot access directory records longer than one sector, causing all the data in the extended sectors to be totally invisible to the system. With direct LBA+size references you can overcome this limitation and access very large directory records.

23

General Discussion / Re: PSX mods working on PS machine

« on: 2012-05-15 11:13:04 »

Why would a kernel cause memory alignment issues?

Because of the 16 bit pointers in each text section.

Does the game require uncompressed kernel data to include alignment padding?

Yes, it's gonna make the hardware crash otherwise.

24

General Discussion / Re: PSX mods working on PS machine

« on: 2012-05-14 15:40:37 »

Or you're just doing illegal stuff to the processor. In most cases it's a matter of memory alignment, like those old broken kernel tools creating incompatible KERNEL.BIN files.

25

General Discussion / Re: PSX mods working on PS machine

« on: 2012-05-14 02:01:10 »

Broken mod = broken tools. All the stuff I did on FFVII so far worked like a charm on real hardware, even in cases where the changes were pretty extensive and involved code rewrites.