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

Pages: [1] 2 3 4 5 6 ... 9
Support / Re: Zack BCX support...
« on: 2024-06-21 05:27:36 »
Sounds like AI hallucination to me. I'm not sure a file with that name even exists.
This is way outside of my knowledge base, but I believe Zack is just an NPC without a dedicated file.
In the PS1 version, NPC models are stored per location, not separately. So you need to decompress and open up a BSX file for a field location where he appears. And figure out which model entry in the file corresponds to him and where the data is in the BSX file.

Announcements and site development / Re: We were hacked.
« on: 2021-07-23 20:30:49 »
You can have up to 500 of them on a free Yahoo account. It's pretty insane. If for some ungodly reason you manage to come up with more than 500 different email addresses, just make a second Yahoo account and you've got 1000.
I tried, and it looks like your information is out-of-date. At some point it became a Yahoo-Plus-only thing, at least the massive number part (my settings menu says 3 for free). People who were already using the feature may have got to keep it. I haven't found too much information on the change yet.

WIP / Re: Recreating Project: Final Fantasy VIII
« on: 2021-02-07 19:56:57 »
I'm sure they were talking about the backgrounds, not the character model.

Is your analysis so far any different than this one from last year?
ff8 battle file animation format

Been a long time, but I think you divide it by 4096 to get the percentage of a full revolution, then convert it to whatever angular measure unit you're using. But the MCH models in main_chr.fs (like d024.mch you're viewing) don't use that packed system I described. They use simple 16-bit (2-byte) integers. All the real animations anyway aren't in those model files, but part of the files in the archives for each field.

I put them all along one axis (Z in my case). The "rest pose" is just an animation itself, and has no impact on other animations.

I did briefly mention back then that I don't load them in XYZ order. As I said there, I read them in ZXY, and used YXZ as the rotation mode. I don't think I've tried things with direct vector rotations in a long time; I've been using poses. I'm not sure how much will be directly applicable since I did things in my script like swap around the axes for the vertex coordinates to YXZ so I wouldn't have to rotate the model and to get left-right correct instead of being mirrored.

Code: [Select]
mdlPoseBones['Bone.%02d' % (rNum + 1)].rotation_mode = 'YXZ'
mdlPoseBones['Bone.%02d' % (rNum + 1)].rotation_euler = (-rots[1] * math.pi / 2048, -rots[2] * math.pi / 2048, rots[0] * math.pi / 2048)

Scripting and Reverse Engineering / Re: [FF9]2016 release
« on: 2016-04-21 06:01:40 »
I think it was that they accidentally left their source code in. Amazing mistake, right?
I'm not actually sure whether it was actual code or not. .NET might just leave in lots of info. Didn't remember exactly what the opening post originally said.

The wiki also mentions Playstation version when mentioning the compression. As in, only the Playstation version. You don't need to decompress further in the PC version.

I briefly wrote about that before. That type of has a a footer (I mean a structure at the end of the file), much like the regular header, but with the order of the entries reversed, where the final 4 bytes of the file are the model count, the 4 bytes before that are the first model's first texture offset, and so on. Also, no EE EE EE EE separator.

I'm not sure whether you're already aware of this (especially since I don't know exactly how you're using the textures after loading them), but you have to be careful with UV calculation. I believe the UVs are given for the texture pages, rather than the individual textures, and not all textures have coordinates perfectly aligned at the corners of the texture pages. When working with an extracted texture, you have to account for that difference.

I was the one who made that video. I have a Blender script for importing the .mch models, and another script for reconstructing a .mch (mostly, I have to add the texture section manually) from the imported model. After importing, I delete the mesh, then make a new mesh using the same names as the old mesh (the export script refers to things by the names assigned by the import script), keeping only the skeleton and any animations that were loaded.

Graphical / Re: [FF8-steam] Character texture replacement
« on: 2014-11-23 20:34:34 »
I just stumbled accross something interesting minutes ago: you can replace lowpoly models with highpoly models thanks to Deling . I replaced lowpoly squall with highpoly squall in main_chr.fs.
I don't think that's safe. When I was doing some high-texture model tests last year, I found that too many model textures can cause graphical glitches. The cube model I showed in that thread was an extreme case of extra textures, but just a few can glitch up cutscenes sometimes. For example, Edea's scene in the Timber studio, and the scene after the prison.

First four bytes of what?  The *.ARC header?
First 4 bytes of the first subfile, what you called "pointer of the last, missing file on it.", 86 A5 03 00. These bytes are the LZS header.

I don't specify the compressed size because I understood that I didn't have to if I was just using the whole sub-file.
By specifying the compressed size, I'm talking about the LZS header. When working in validate header mode (the default), myst6re's tool demands that the remaining file length after the header matches the value of the header exactly. Otherwise it'll throw up that "Invalid LZS header" error message.

And the subfile's size as derived from the ARC header does exactly that.
According to the LZS header, the compressed data is 0x3A586 (238982) bytes long. Adding the 4 bytes taken up by the header, the LZS file would be 238986 bytes long. But a length of 238988 bytes, the subfile length you got from the ARC header, is 2 bytes more than that. See my point just above.

The last two bytes of the *.ARC header, the last two bytes of which specific subfile, or the last two bytes of the whole ARC file?
Last two bytes of the first subfile. I don't know why they're there, but they don't seem to be used. I tried setting a breakpoint while entering battle and they didn't get read.

1. Extract the subfiles from BATTLE.ARC
2. Using a hex editor, delete the final two bytes, F1 D2, from the first subfile.
3. Run unlzs on the first subfile.
4. If all went well, you should have a decompressed file with a length of 516688 bytes. It should be identical down to the last byte to BATTLE.OUT.

Sorry for missing your report until now.

Those first 4 bytes? Either keep them on or use the "no-header" option. Those bytes are the header (compressed size). Also, the decompressed output should be completely identical to BATTLE.OUT. So, actually, you should be able to skip decompressing the data and go straight to editing and recompressing.
Looks like when working with a header, myst6re's unlzs is extremely picky. If there are any extra bytes beyond the specified compressed size, it complains. And the subfile's size as derived from the ARC header does exactly that. Delete the last two bytes (F1 D2).

There's no installer, so nothing can be bundled, if that's what you're referring to. It's just an archive file containing the precompiled binaries and required dlls.

Troubleshooting / Re: Garden and field files
« on: 2014-05-04 19:18:40 »
The import/export tab only allows importing/exporting from the currently open archive. In the case of field.fs, that's mostly the individual field archives. Vgr, you probably have a different idea of what "field files" are. I believe Shard wants the ability to extract files from every field location at once.

Keep in mind, the PC version was developed by Eidos back in 1998; their native language is English.
The PC version wasn't developed by Eidos, it was done by SquareSoft Inc. That's the North American subsidiary, though, so the native language would still (mostly) be English. Looking at the credits, there were at least one Japanese programmer from Square's other games.

Troubleshooting / Re: FF VIII World.fs
« on: 2014-03-15 06:09:09 »
The in world.fs is an older type of They were used in the PS1's FF8 demo and sometimes appear in the old, unlinked field archives, but the one in world.fs appears to be the only actual use of the old format in the final version.
Some details about the format. I don't know if this is the right term, but there's a "footer". To read it, you have to work backwards from the end of the file. Unlike the headers in standard files, all offsets are absolute, not relative.

Code: [Select]
import struct
import os.path
from os import mkdir

class genericEntry:
    def __init__(self):
        self.location = 0
        self.size = 0
        self.isNPC = False
        self.MCHNumber = -1
        self.TIMlocations = []
        self.modelLoc = 0
        self.sizeBeforeAnims = 0
        self.anims = []

def unread(src):
    loc = src.tell()
    curResult = struct.unpack("<I",[0] - 4)
    return curResult

name = raw_input('File name:')
src = open(name, 'rb')

charaEnd = struct.unpack("<I",[0] - 4)

totalModels = unread(src)

models = []

for i in range(totalModels):
    mdl = genericEntry()
    firstNum = unread(src)
    if (firstNum & 0xD0000000) == 0xD0000000:
        mdl.MCHNumber = firstNum & 0xFFFF
        mdl.location = unread(src)
        mdl.isNPC = True
        loc = unread(src)
        while loc != 0xFFFFFFFF:
            loc = unread(src)
        mdl.modelLoc = unread(src)
        mdl.location = firstNum & 0xFFFFFF

fillerplace = genericEntry()
fillerplace.location = src.tell() + 4

if not os.path.exists("%s_extract" % (name)):
    mkdir("%s_extract" % (name))

for i in range(totalModels):[i].location)
    curmdl = models[i]
    rawdata =[i + 1].location - models[i].location)
    if curmdl.isNPC == True:
        outmdl = open('%s_extract\\mdl%02d.mch' % (name, i), 'wb')
        for offs in curmdl.TIMlocations:
            outmdl.write(struct.pack("I", offs + 0x100 - curmdl.location))
        outmdl.write(struct.pack("I", 0xFFFFFFFF))
        outmdl.write(struct.pack("I", curmdl.modelLoc + 0x100 - curmdl.location))
        while outmdl.tell() < 0x100:
        outmdl = open('%s_extract\\d%03d_anim.bin' % (name, curmdl.MCHNumber), 'wb')


    Alexander: At 0x8138 in mag203_b.01 (Sorry, didn't have it listed correctly in my big list.)
    Brothers: 0x31E0 in mag204_b.00, and 0xE0 in mag204_b.03.

    Grim Reaper:
    According to the models I manually extracted a while ago, there are multiple copies.
    One can be found at 0x122C95C.

    There were so many models that I don't think I got them all, but in FF8.exe, I've found:
    • Gilgamesh's swords (multiple copies, I think)
    • Various Angelo models, and Angelo's bone
    • Rinoa's wings?
    • A cherub (angel)? 0x11786D4
    • Boko models, Cactuar, and Moomba

While their textures are in the archives, those summons' models are in FF8.exe.
For the English 1.2, both non-Geforce and Geforce:
  • Phoenix: 0xDB537C
  • MiniMog: 0x112BC04
  • Carbuncle: 0xCB6F94
  • Tonberry: 0x1147514
These are "normal" GF models.

I mean that Quetzacoatl model uses 3 material/maps but the info of the third one is missing and ther is no unwrap for that part of the model.
You may need to increase imageCount in the script in order to have all the UVs preserved.

If you've located the beginning of the model, then it should be simple. The first 4 bytes of the alternate header are the length of the model, in little-endian (take the bytes and reverse the order to get the value).

Good night.

The alternate-format models are not at the beginning of the file, which is why the script fails. Unfortunately, I don't know enough to automatically locate where they are in the file. I used a hex editor to find the alternate-format models and to copy their data out into new files. That isn't an optimal solution.

For example, open up mag005_b.05 in a hex editor and copy out the data from 0xD4-C643 into a new file.
In its file, Eden is at 0x5A54-134FF.

I don't know yet if you've gotten the alternate-format models out of the files yet (though I'm assuming you have), but it requires a slightly different script for conversion.

Code: [Select]
modelData = - offsets[0])with
Code: [Select]
modelData = replace all occurrences of "0x1C" in the script with "0x18".

Oh, and I slipped up when I was updating my list to post. There's another Leviathan model in mag005_b.02.

Since GF textures are separate from the model, they are not easily merged into the newly created model. It can only directly provide the model.
The script creates placeholder textures for the purpose of being manually replaced or maybe to make textures behave correctly when exported. You can adjust how many placeholders are created by changing the value of imageCount.

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