Modding Expeditions (KF)

[Holy_Diver]

I think the collision meshes are just simplified versions of the tiles, it's just it can reference different tiles to use as the mesh. Such as the bumpy ice or rock in some areas, which just uses regular wall collisions. Either that, or some of the duplicate tiles may have been collision meshes for them.

Yes, still important data.

Ah, I think there has been a misunderstanding about the tile data; the entire top section of the files (10 * 16384 bytes) is made up of actual grid data of the map.  It just points to the meshes and draws them according to a 2D array. This is why the light data can be different for each tile.

So you just figured this out? Sounds like good news.


About the MO file. I can tell you that the parts you have in violet and magenta begin with 4 bytes, part of which is probably a bit array of flags of some meaning. The remaining parts are 16-bit indices into the orange offset array. And those go into the white. Which you have highlighted 16A to 16E mistakenly.

It's safe to document this much. The flags may include information like, to apply the deltas in reverse, since the indices cannot possibly encode this. Assuming that it's reversible.

I need to print out the TMD at the back of the file to see if anything about it lines up with the deltas data block. I will do that when I have time to look at your utilities.


EDITED. If that's true, is the grid 128x128? If so there should be a lot of blanks; or do you think there are layers? Is "Height" elevation then?

[Holy_Diver]

More or MO

The deltas begin with a 16-bit figure that is proportional to the number of bytes pointed to by the orange offset table. As the sizes grow large the ratio grows slightly.

The next 16 bits seems to be a 16-bit signed value. The value –32768 (i.e. smallest possible) looks special, like a reset code, that is followed by another 16 bit number. I think this hops around the vertex data, basically resetting a pointer. If the block's second value is not -32768 (0x8000) then my guess is the deltas begin at vertex #0.

Strikeout: see my next reply/edit.

What is weird, is the 8-bit deltas always fall on odd numbered bytes. It follows the deltas are not variable length encoded, like MDL's. There's no way to be sure about data like this other than to render the animation. Typically then you can tweak the algorithm until a picture emerges. You're utility is in a better position to do that.

[Holy_Diver]

I noticed about "–32768" that the sequence also often happens at the very end. This suggests it's not moving around vertex data. My first instinct the tail end markers were so the deltas could be walked in reverse. However that doesn't look feasible to me. I also noticed the number following the marker tends to be small, and my instinct is it is a 16-bit index back into the orange offset table.

Strikeout: I found an index that is 23, so can't be the orange table. I've also noticed the interleaved bytes are always even on the non-delta side (unless a special index.)

It seems bizarre, but the only explanation I can think of is that a delta block that looks small, can actually include other delta blocks inside itself, basically stringing deltas together. This seems somewhat preposterous. However it's not unlike a general purpose compression algorithm. If this is all true, you might say that this form of animation compression is closer to an off the shelf file compression codec SOM's animation format.

These may not be deltas at all in fact. They could be compression codes. And only after the data is decompressed might it then be interpreted. On the other hand, they don't look like efficient compression, and nothing else is compressed. Hopefully there is not any obfuscation, but I stand by these findings. I just don't see a lot to go on. Could you do more tests modifying the memory in the game? Or coach me?

EDITED: For the record, I edited the last paragraph significantly. Several minutes later

[Holy_Diver]

What about Psycpros binaries? I don't want to be needy, but Game Maker is a bit exotic for me. (I stopped myself to see if it was part of Visual Studio 2017, which has some game stuff built-in.)

I'm not sure what I need to build binaries. I think probably it's better to download.

P.S. Your TScan is not so user-friendly. It asks Yes or No, and I'm not sure what it wants from me. Then it turns unresponsive when I close it. Does it just extract TIMs? C# is probably a better vehicle for a Psycpros, not being a game after all?

EDITED: I found this (https://github.com/TheStolenBattenberg/Psycpros/blob/master/Tools/Psycpros_0.01d.zip) poking around. Unfortunately it spins the GPU out of control, and sends my workstations fan into a tizzy like it was playing a game unlike anything I've ever tried on it. TScan doesn't do this when idling. I don't have any advice but to open Task Manager on Windows and see if it shows the GPU at 100%... as for TScan, I cannot find instructions. Does it use T files? I have to try to mount the bin/cue files I have. I'm probably going to make an ISO of my KF2 discs this weekend while in town.

[TheStolenBattenberg]

What about Psycpros binaries? I don't want to be needy, but Game Maker is a bit exotic for me. (I stopped myself to see if it was part of Visual Studio 2017, which has some game stuff built-in.)

I'm not sure what I need to build binaries. I think probably it's better to download.

P.S. Your TScan is not so user-friendly. It asks Yes or No, and I'm not sure what it wants from me. Then it turns unresponsive when I close it. Does it just extract TIMs? C# is probably a better vehicle for a Psycpros, not being a game after all?

I like to prototype a lot of code in Game Maker, since its scripting language is essentially very watered down C, but I've currently been  porting it over to C# because its becoming a mess very quickly, and I miss object orientation (which is something I thought I'd never say when I first began programming). I'm unfortunately not familiar with C#, though learning quickly as it seems pretty alike to Java. TScan should not be bothered with, it's old code that doesn't actually read the T Header at all, it just searches for KF2 textures.

Unfortunately it spins the GPU out of control, and sends my workstations fan into a tizzy like it was playing a game unlike anything I've ever tried on it.

Game Maker doesn't come with a GUI library, and the code I'm using for the widgets I wrote near enough 5 years ago, so it is very optimized. Another reason for the C# port, as well as it being a more accessible language.

[Holy_Diver]

Unfortunately it spins the GPU out of control, and sends my workstations fan into a tizzy like it was playing a game unlike anything I've ever tried on it.

Game Maker doesn't come with a GUI library, and the code I'm using for the widgets I wrote near enough 5 years ago, so it is very optimized. Another reason for the C# port, as well as it being a more accessible language.

I take it there is a missing NOT in what you said (in bold)? This has to be fixed. My guess it's rendering at a constant million frames per second I would've thought if anything a Game Maker would not allow this to be.  In any event, SOM is the only "game maker" that has install space on my workstation! I don't know C# myself, but I'm thinking about using it for  a new tool/arm of SOM to be called Exselector. It is more portable than C++, and I don't know if it has a portable GUI, but C++ definitely doesn't. I would think that a portable GUI would be part of its value, but I don't know for certain if it has one. (Quick search: http://www.mono-project.com/docs/gui/winforms/ suggests Windows Forms can work with Mono by some subsystem. Source: http://www.mono-project.com/docs/gui/)


P.S. For me personally, I would be most comfortable with C++, however I am fine with anything that works with Visual Studio out of the box.


EDITED: Here (https://stackoverflow.com/questions/18294332/why-is-winforms-in-mono-not-opening-any-window) is suggestion that Mono emulates WinForm's off Windows (e.g. I was uncertain if it was only compatible with Windows environments.)

[Holy_Diver]

FYI: I was semi-successful copying the files off my discs yesterday. The NTSC-J disc seemed to copy everything cleanly, and I made an ISO also; which mounts. However it doesn't play in the ePsxe I have (with Japan bios) and has considerably fewer files in its OP folder than the NTSC-U/C disc does... or did. (It has ED.D, ED.S, OP.D, and OP.S... so I wonder if something did not copy, even though no errors arose.)

As for the U/C disc, it had errors, mainly in its OP folder, possibly entirely limited to it. So I felt like I did not get a full copy of that disc. I have working BIN/CUE files (downloaded) for this game, but I couldn't mount them, so couldn't see the files on the disc.  (Edited: for the record, I've never had problems playing this disc on various PlayStations. But I suppose an error in the disc could pop up anywhere.)

I think I have all of the data files intact. I don't know if errors can be because of copy-a protection scheme. In which case, special software might be required.

FDAT.T
ITEM.T
MO.T
RTIM.T
RTMD.T
TALK.T
VAB.T

These names appear pretty straightforward, but can you (TSB) write down your understanding of each file? Or point to documentation where you have done so? At this time. Thanks. Let's crack this nut

[Holy_Diver]

I have ePSXe 1.9.25 set up. I'm disappointed your KF2US.CT attachment doesn't have item locations, as your screen shot does.

Needless to say, main points of interests are world coordinates for each and every entity within the game. Please don't hold back findings.

I would like to start getting hard documentation, one way or another. I want to know where to find everything myself. I'm a little dismayed that for all of our talk there are not hard addresses or anything, yet.

[Holy_Diver]

The MO data remains elusive to me. I wanted to try a theory. I found an 0x8000 marker/index that wouldn't fit into the "orange" index. It is 23. This means either it's not expanding these indexes, or it's doing so by another mechanism. What has up to 23 elements?

I'm unsure how best to approach this, other than staring it up and down. Another thing I've noticed is in the two byte pairs, where the high byte is a delta... the low byte is always even. It could be that it is shifted left by 1. It looks like a bit mask, but this rules out the possibility that it's 8 bits per vertex component (why not use the last bit if so?) My impression is that this value can be negative, however 0x80 is a common value, which looks more like a bit mask than a negative figure.

This is perplexing. I wonder if the 0x8000 indexes could be TMD primitive groups. Still the low-order bytes repeat, so it's hard to imagine them as direct references to the vertex component to adjust according to the delta. Nevertheless I remain convinced the idea is to apply these deltas directly to individual vertex components.

[TheStolenBattenberg]

FDAT.T
ITEM.T
MO.T
RTIM.T
RTMD.T
TALK.T
VAB.T

These names appear pretty straightforward, but can you (TSB) write down your understanding of each file? Or point to documentation

Main T File documentation: https://github.com/TheStolenBattenberg/Psycpros/blob/master/Documents/File%20Formats/T.h

FDAT.T:
Holds general game data, Maps, Item tables and event data. Also includes some texture pages for items etc.

ITEM.T:
Has some regular TIM files for item description text.

MO.T:
Animated TMDs. (https://github.com/TheStolenBattenberg/Psycpros/blob/master/Documents/File%20Formats/MO.h)

RTIM.T:
Modified TIM style texture pages.

RTMD.T:
Modified TMD tilesets for levels.

TALK.T:
Standard tim files, for NPC dialogue.

VAB.T:
VH / VB VAG Sample bank files, SEQ Sequence data files for music.

I have ePSXe 1.9.25 set up. I'm disappointed your KF2US.CT attachment doesn't have item locations, as your screen shot does.

Needless to say, main points of interests are world coordinates for each and every entity within the game. Please don't hold back findings.

I would like to start getting hard documentation, one way or another. I want to know where to find everything myself. I'm a little dismayed that for all of our talk there are not hard addresses or anything, yet.

I totally forgot about posting the updated .CT, I've attached it to this post. :) This one contains some offsets, to the start and end of certain data tables, some I'm not even sure of yet.