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.
I had issues with touphscript and hack7, but this is probably my own fault. Loveless opened flevel.lgp just fine. Can anyone point me to a field that is known to have a typo or other obvious translation goof in it so I can see if they fixed it?I remember a minor typo (well, a commonly confused word error) in one of the PC version lines: "It's you're fault for running around like that!" in Junon.
I'm looking at the FIELD\*.DAT files, which are less than 100KB each. Within an editor like Makou Reactor or Hack7, you can observe blocks of data labeled 'AKAO', but these are only a few bytes in size.Are you talking about the script opcodes? If you are, then we're talking about different things. I'm talking about the text 'AKAO' actually appearing in field files as viewed by a hex editor. If you look at the "tutorials/sounds" section in Makou Reactor, the entries marked "Sound" are the AKAO blocks.
I've read that elsewhere as well, and I don't doubt it...but I'd imagine someone has done more digging than that. AKAO itself seems to only precede 'Play music #x', but from what I can see, AKAO sections simply aren't large enough to contain the entire songs themselves - where is the actual music data stored? If I knew that, I could figure out how it's being referenced, and modify that...or at the very least, replace entire songs with other songs where desired.AKAO blocks aren't large enough? How large are the AKAO blocks you're looking at? What makes you think they aren't large enough?
I don't suppose you mean that the field model files themselves are contained within the .DAT files (.DAT files are quite small), so I assume you mean that the file names are explicitly mentioned...or do you mean that their LBAs are mentioned, in hex? If so, I assume these .DAT files are little-endian, like the various .BIN files FF7 uses? I'll do some digging with a hex editor later today.luksy's mistaken. That's only true in the PC version. In the PSX version, NPC models are stored in the BSX files. I don't understand the documents about their structure well enough to explain how they work.
The first 4 byte of field.bin is the uncompressed size, the gzip header is at offset 8.Compare that with the standard format. ff7dec probably fails because it wasn't designed to handle this situation.
DWORD gpu_opcode
BYTE unk[4]
SHORT unkTransp //if this AND's with 0x04, sets semitransparency
BYTE unk2[2]
SHORT vertices[4]
SHORT vertices2[4]
DWORD Vertex_colors[4]
BYTE u1
BYTE v1
BYTE u2
BYTE v2
BYTE u3
BYTE v3
BYTE u4
BYTE v4
SHORT unused1?
SHORT textureNum
SHORT unused2?
SHORT unused3
SHORT unused4
SHORT unused5?short vertexNum?
?short numOfVertices?
?short bone-index?
?short unknown?Offset Length Description
0x1C 0x02 Triangle count
0x1E 0x02 Quad count
struct
{
byte unknown
byte total_textures?
byte unknown
byte uSize
byte vSize
byte replacement_section_count
UV_pair original_area_coords
byte unknown[2]
UV_pair replacement_coords[replacement_section_count]
}Offset Length Description
0x08 0x02 When bit 0x04 set, face has semi-transparency
0x36 0x02 Texture index
struct
{
uint16 start_skinobject_index
uint16 skinobject_count
byte unknown[12]
uint16 start_triangle_index
uint16 triangle_count
uint16 start_quad_index
uint16 quad_count
byte unknown2[8]
}Scan data files for tables that include sector numbers for files of a given format.(I'm not supporting virtual file systems)But, uh, aren't those what most or all of the Square PSX games worked on here use?
the problem with remodeling things in ff8 is that they use weighted models, and thus the rigging process would need a fancy shmancy tool to get done... otherwise the characters wouldnt animate.I'm not very savvy with 3D modeling, but there doesn't seem to be specific weights for each vertex group. The unknowns in vertex data and vertex tend to be 0 all the time. As far as I can tell, all that matters is which bone the vertices are assigned to. If rigging the models is so important, what would improper rigging do?
struct texAnim
{
uint8 textureNum;
uint8 originalUCoord; //All UV coords here are for the upper left corner
uint8 originalVCoord;
uint8 regionUSize;
uint8 regionVSize;
uint8 copiedRegionCount; //1 less than the actual number
uint8 unknown1;
uint8 unknown2;
//Insert remaining UV coords here
};I always have to double the "U" part of the UV coords and region-size to get a reasonable U coord/size. Maybe it has something to do with how the TIM format works?
I finally came to that conclusion : If someone (a programmer, of course...) could take RINOA's source code and make another program to view/extract/convert mch files, I would be really glad.Koral never released the source code for RINOA, so that's not possible. Any program for that will have to be coded from scratch.
For example, to look at the ff8 model at one screen and point by point recreate them on another would result in something that looks like an exact copy yet it is not if you actually created it yourself. Thats what I was asking.Well, apz was accused of stealing for his model because part of the texture was clearly taken from Dissidia or something like that. I suppose if by looking at the data and texture that one can tell it wasn't created by a converter, then it's OK.
Anyone have the Japanese text of that line? She might be saying "the guy upstairs FROM the weapon's store" or some other odd grammatical construction.
<Tifa>As I think I say in many places, I don't really know Japanese. Anyway, that "２階" means "second floor" (in the sense of counting the ground floor as floor 1). A lot of online examples use "２階" as "upstairs", but that's a bad assumption to make without context.
「<Cloud>！
武器屋２階のおじさんから伝言よ」