(Sorry for noob-ness) FFVII: mods for psx version only

[Covarr]

You arent calling Avalanche organized are you? LOL

Not in the slightest, but have you seen the place where pretty much all N64 retextures hail from? It's loaded with unnecessary dupe topics that should have been updates to previous topics, generally redundant projects (roughly ten Mario Kart texture packs that all serve the same purpose), and outdated stickies. Not to mention, the first posts in about half the threads pretty much never get updated, so to find the latest release of a texture pack you have to browse through sometimes dozens of pages of post after post of "whens the new version of ur textur pack comin out! weve been waiting too long".

 

[titeguy3]

I've actually found that Qhimm is a lot more organized than most modding community forum boards. It's just easier to find stuff.

 

[sl1982]

Hmm maybe ill shall clean up my little corner of the forum one of these days

 

[Gemini]

The problem is that we can't have models with bigger file sizes than the original.

Data can be relocated around the disk, models included. You don't even need to rebuild the whole ISO, but just move a file in an empty region of the image (i.e. end of disk). In other words, the only actual limit is the hardware.

 

[Bosola]

As far as I know, that isn't true. The issue is not the limitations of the disc, but to do with the fact that -

a) Bits of the executable don't look for files, but go to particular sectors and tracks expecting data, so we'd have to disassemble parts of the executable and change these locations, and
b) We can't create PSOne data lookup-tables / filesystem data from scratch.

If you know differently, though, I'd be very interested to hear how I could exceed the limits of the KERNEL.BIN. I *have* heard about attempts in the past to get PSOne homebrew up and running without the Net Yaroze framework - presumably, *someone* must be able to author  bootable Playstation discs.

 

[Gemini]

a) Bits of the executable don't look for files, but go to particular sectors and tracks expecting data, so we'd have to disassemble parts of the executable and change these locations, and
b) We can't create PSOne data lookup-tables / filesystem data from scratch.

a) Those allocation tables are incredibly easy to locate, some even stored in the most obvious locations (FIELD.BIN contains the whole thing for the FIELD folder, just like ENEMY1-6 indexes are stored inside BATTLE.X). Most of them, if not all, use a simple lba+size (sometimes padded to sector) format.
b) It's really possible to, but not necessary. I've expanded the hell out of some overlays and data files, and guess what? The game doesn't refuse to work with them. Models follow the same procedure.

If you know differently, though, I'd be very interested to hear how I could exceed the limits of the KERNEL.BIN.

You mean the RAM limits or size on disk? I haven't analysed the first case (even though it should be a static array, meaning it's pretty hard to expand), but the second is very possible to do and my personal tools already take care of it.

 

[Bosola]

That's excellent, and makes things very different for my mod project. As for the KERNEL, I meant the space on disc. One issue, though - how would I go about importing a file larger than the original onto the ISO? Is this something your tools can handle?

I know one thing: I'm going to take a look at your tools NOW!

 

[Gemini]

One issue, though - how would I go about importing a file larger than the original onto the ISO? Is this something your tools can handle?

My tools inject KERNEL.BIN somewhere else in the ISO (forgot exactly where, but it's an unused area so who cares) and update the index/size values for it inside INIT\YAMADA.BIN, which also contains several other initialization index/size pairs. The same procedure was used for other files that grew bigger, like FIELD.BIN and BATTLE.X.

 

[Bosola]

Amazing! You really are the Playstation Guru!

 

[Solidsnake777]

I saw this post and was wondering if you still have that tool.