Search results

To play around with stuff and things in Unity and WebGL. Seems like a huge amount of work to try and write tools and proprietary formats into a client whose code base can't be changed.

Generally the focus is on extraction, not really interested in putting things back.

For PRS i found this python implementation that works pretty well. Not exactly perfect, but I was able to port it to Node and extracted each file from a bml, decompress it and write it to the file system, though I haven't done any extensive testing. Is PRC a variation on the PRS decompression...

I definitely want to leave a paper trail for anyone else that might be interested in stuff like this. Also it helps me a lot to write everything out and be able to refer back to it without having to remember everything. Also Tofu, I might have to bother you about PRC decompression sometime down...

Some of these are turning out better than others. I think I just need to figure out how to handle rotation and scale, and we should be in business.

Haven't looked at textures yet, but stuff is starting to fall into place. Sword exported from psobb's Item_Model.afs file.

NJTL headers are pretty simple. Header is NJTL followed by a pointer to the end of the section. This offsets the pointers in the entry by 8 bytes. Header in blue is: So 3 textures and it points down to 0x08 (+0x08 for offset) right below the header. The NJS_TEXNAME entry is right below...

Exported from xj file.

Ran into you today, was nice to meet you.

XJ File type So that's everything I have so far for the .nj filetype. Aside from the missing mesh information, assuming that's what it is, it's mostly self contained at pretty simple. That's for a single node, but even multiple nodes simply follow the same structure and it's just a matter of...

I've been looking into xj models and comparing them with nj models to see if there is a way to export xj models into a more readable format. I'm going to write what I've found so far here to clear my mind and hopefully someone else can provide incite. My priority right now is mostly on...

A bunch of Pso dev tools are listed here: http://psodev.free.fr/

There are still a lot of issues to work on, but I managed to port Schthack's map viewer source from Delphi/Pascal to a Nodejs script which outputs an .obj file. Textures seem to be in the right place for the most part, but the UV's are wrong. All of models in the map can be exported, but the...

Okay a few hours and 128 lines of code later, I think I have a episode 2 .njm to episode 1 .njm converter that mostly works (not garanteed). Usage: node script.js <file.njm> Still in debug mode, so it just exports to output.njm.

Okay, i think i see what's going on. Let's see how many people get this one. If you need a hint, watch this explanation. https://www.youtube.com/watch?v=dQw4w9WgXcQ

To continue the conversation (with myself), why do i think episode 1 .njm's and episode 2 .njm's are actually the same file? For starters, episode 1 animations work on episode 2 models just fine. If there was something inherently different about them, this probably wouldn't be the case...

Starting to look at the episode 2 njm files. It looks like they are the exact same file, just in a slightly different formation. The dreamcast .njm files have NMDM on the front and then a pointer to the end of the file. This does not seem to be part of the actual file definition and as such...

kk managed to extract all 341 player animations from Pso PC Version 2. 1. Use tofu's tool to extract PlyMotionData.pr2 to PlyMotionDataPr2.bin PRCTool.exe /D PlyMotionData.pr2 PlyMotionDataPr2.bin 2. Copy PlyMotionDataPr2.bin into a folder somewhere 3. Make a folder named "output" inside that...

Okay, I have a better idea of the .njm file structure. I'll try to write it up when I get home. Also I managed to find the pointers to the animations in the plymotiondata.pr2 file to preview it as an njm file. Still have a lot more tinkering to do though.

Found some more information on .njm First 4 bytes are NMDM Second 4 bytes is a null pointer to P0F0 - 8 Third 4 bytes is a pointer to the motion list Fourth four bytes is the number of frames The problem is in the documentation there doesn't seem to be a decent description of what void *p[1]...