Outfit7 starlite engine (pre-2023) 3d models (My Talking Tom 2/My Talking Angela 2 etc)

[scratchcat579]

moonlite supports extracting root.bundle (only post 2023 though and not encrypted version)🙂

https://github.com/nj-josh-man/MoonliteAgain

[scratchcat579]

and this is the ONLY good use case for the extracted files..

 

[yarcunham]

I analyzed all the asset files again and here are my findings:

If a vertex has more than 1 joint id associated with it, it always has joint weights too. So: rigid transformations where every vertex has a maximum of 1 joint don't use weights, which makes sense. The reverse is not true: All vertices might only have a single joint, but they also have a separate weight value. This also makes sense since you might have a rigid non-animated part with a smooth transition to an animated part.

The maximum number of joints in a single mesh file across all the assets was 57. All the joint indices in the vertex data are divisible by 3. Because they are divided by 3, the maximum number of joints you can reference is a single file is 255/3, or 85. 57 < 85, so it works out. (but why is the index multiplied by 3, why??)

 

11 hours ago, scratchcat579 said:

the 20 float bytes in the header are actually bounds.

Awesome, thank you.

[scratchcat579]

because of my extractor i was able to extract some textures. the game mostly uses KTX Basis Universal (KTX 11) for textures but also has a weird one.

I tried using PvrTexTool to load the texture but was unsuccessful:

I have attached some of these weird files.

Textures.zip

[yarcunham]

57 minutes ago, scratchcat579 said:

because of my extractor i was able to extract some textures. the game mostly uses KTX Basis Universal (KTX 11) for textures but also has a weird one.

I tried using PvrTexTool to load the texture but was unsuccessful:

I have attached some of these weird files.

Textures.zip 16.03 kB · 0 downloads

There are a lot of file names that end in _TEX_RGB_CRUNCH, so I suspect those use "crunch" compression. I looked into it at some point, but didn't get very far.

Here are all the different texture file name suffixes that I've seen:

_TEX_RGB, I think these are all KTX
_TEX_C, (speculation, i haven't been able to decode these) Looks like a KTX cube map maybe
_TEX_RGB_UC, UC = "uncompressed". Either a .png or a .jpg file. The jpg ones often look like loading screens or interstitials.
_MASK01, RGBA png file where each color channel has a different meaning. A: general texture visibility 0 = transparent, 1 = "use base color". R = "secondary color", G = shadows, B = highlights.
_MASK02, RGB png file with additional masks for different channels, these seem to depend on the application. sometimes it's just a tertiary color, sometimes it looks like an emission or a metalness mask
_TEX_RGB_CRUNCH, these I have not been able to decode, I assume they use "crunch" compression
_FX_TEX_A (speculation, i haven't been able to decode these either) alpha-only/BW texture for effect, particles etc

Anyway, a lot of props, furniture and such uses those _CRUNCH textures, so even if I have managed to decode the meshes, they remain untextured

 

[yarcunham]

(go to post https://reshax.com/topic/1418-outfit7-starlite-engine-pre-2023-3d-models-my-talking-tom-2my-talking-angela-2-etc/page/2/#findComment-8332 to dowload the latest scripts)
Here is the latest version of the mesh importer. It also has a bunch of my analysis code in it too.

If you give the "process_single" function only a single file, it will import just the mesh. If you give it 2 files, the second one is a skeleton and it will read joint names from the second file and  assign them as vertex groups in the mesh. Those vertex groups are then used for skeleton deformation when you select the mesh, then shift-select the skeleton and press Ctrl-P and select "Armature deform" Note: select "Armature deform" specifically, not any of the other options. Do not select "with empty groups", "with envelope weights" or "with automatic weights"

To import a skeleton, the skeleton import script in an older post should still work. I guess I should point out that as it is, the skeleton and the deforming model will not work with any animations. But you can use the skeleton to make your own animations. They just will not be compatible with the in-game animations if those ever get figured out

Edited February 28 by yarcunham
removed outdated script

[yarcunham]

This is so frustrating. I've tried some exporting some simple armatures from blender to fbx and to dae and then converting them with fbx2skel and dae2skel and then importing them back with the skeleton import script and this is the result. This is why the animations don't work. The bones point in the wrong direction:

I noticed an error in the annotation: the difference in the Y-axis rotation between the "Y" and the "root" bones should be 90 degrees. Anyway, the two imported bones have the same roll, which is incorrect anyway.

Edited February 13 by yarcunham
clarification

[scratchcat579]

20 hours ago, yarcunham said:

This is so frustrating. I've tried some exporting some simple armatures from blender to fbx and to dae and then converting them with fbx2skel and dae2skel and then importing them back with the skeleton import script and this is the result. This is why the animations don't work. The bones point in the wrong direction:

I noticed an error in the annotation: the difference in the Y-axis rotation between the "Y" and the "root" bones should be 90 degrees. Anyway, the two imported bones have the same roll, which is incorrect anyway.

this problem was also happening in my unity importer when importing bind poses. i fixed it by doing this to the position: rotation * position.

Edited February 14 by scratchcat579

[scratchcat579]

On 2/9/2025 at 7:18 PM, yarcunham said:

There are a lot of file names that end in _TEX_RGB_CRUNCH, so I suspect those use "crunch" compression. I looked into it at some point, but didn't get very far.

Here are all the different texture file name suffixes that I've seen:

_TEX_RGB, I think these are all KTX
_TEX_C, (speculation, i haven't been able to decode these) Looks like a KTX cube map maybe
_TEX_RGB_UC, UC = "uncompressed". Either a .png or a .jpg file. The jpg ones often look like loading screens or interstitials.
_MASK01, RGBA png file where each color channel has a different meaning. A: general texture visibility 0 = transparent, 1 = "use base color". R = "secondary color", G = shadows, B = highlights.
_MASK02, RGB png file with additional masks for different channels, these seem to depend on the application. sometimes it's just a tertiary color, sometimes it looks like an emission or a metalness mask
_TEX_RGB_CRUNCH, these I have not been able to decode, I assume they use "crunch" compression
_FX_TEX_A (speculation, i haven't been able to decode these either) alpha-only/BW texture for effect, particles etc

Anyway, a lot of props, furniture and such uses those _CRUNCH textures, so even if I have managed to decode the meshes, they remain untextured

 

i think the crunch textures use crnlib: https://github.com/BinomialLLC/crunch/

[scratchcat579]

On 2/6/2025 at 9:34 PM, yarcunham said:

The bind pose matrices are either the transformation matrix of the bone the vertices are supposed to be bound to, or more likely they're the inverse matrix because that is static and needed for animation: You multiply the vertex position with the inverse transformation matrix of the bone, then you multiply it with the transformation matrix of the bone at the current frame.

The mesh file also has some unknown data after the matrices, which I have just called "after matrix", and after that there are 64-bit joint ids, which correspond to the joint ids defined in the skeleton files (when you can find by searching for "ozz-skeleton" in the dumped asset files)

Here is an annotated picture of where the offsets and numbers are defined in the header:

edit:

For example, If I look at the entry number 17 in the joint id list, it's BE4303DC94F197F0, If I then search for it in the skeleton file, it's entry number 74. Because the root bone doesn't get its own entry, I look at entry number 75 in the skeleton joint name list and that is r_tibiaRibbonTweak_01_uJnt. So that is how you would bind any vertex that references bone BE4303DC94F197F0.

my format version has 4 bytes per id and the ids arent in the ozz for some reason 😠

TOMSKINADOOT.zip

[yarcunham]

4 hours ago, scratchcat579 said:

my format version has 4 bytes per id and the ids arent in the ozz for some reason 😠

Okay yeah, the skeleton file is in a different format, but the ozz-skeleton part seems to parse the same at offset  0x4C9.

I have been using ImHex to inspect these files and if you use this pattern in it, it will highlight the known data:

import std.string;
import std.mem;


namespace skeletonfile {
    struct NullStringBase<DataType> {
        DataType data[while(std::mem::read_unsigned($, sizeof(DataType)) != 0x00)];
        DataType null_terminator;
    } [[sealed, format("std::string::impl::format_string"), transform("std::string::impl::format_string")]];

    /**
        A null-terminated ASCII string.
    */
    using NullString = NullStringBase<char>;

    struct JointProperty {
        u16 parentIdx;
        u8 isLeaf;
    };

    struct SoaTranslate {
        float tx[4];
        float ty[4];
        float tz[4];
    };

    struct SoaRotate {
        float rx[4];
        float ry[4];
        float rz[4];
        float rw[4];
    };

    struct SoaScale {
        float sx[4];
        float sy[4];
        float sz[4];
    };

    struct SoaTransform {
        SoaTranslate translations;
        SoaRotate rotations;
        SoaScale scales;
    };

    struct ozzSkeleton {
        NullString magic;
        u32 version;
        u32 numJoints;
        u32 charsCount;
        NullString jointNames[numJoints];
        u32 jointPropertyVersion;

        JointProperty properties[numJoints];

        auto numSoaJoints = (numJoints + 3)/4;

        SoaTransform bindPose[numSoaJoints];
    };
    struct File {
        u8 version;
        u8 unknown[8];
        u8 numBones;
        u8 unused[15];
        u64 jointIds[numBones - 1];

        ozzSkeleton skeleton;
    };
}
//skeletonfile::File file @ 0;


skeletonfile::ozzSkeleton skeletonfile_ozzskeleton_at_0x4C9 @ 0x4C9;

 

[yarcunham]

On 2/9/2025 at 8:03 PM, scratchcat579 said:

because of my extractor i was able to extract some textures. the game mostly uses KTX Basis Universal (KTX 11) for textures but also has a weird one.

I tried using PvrTexTool to load the texture but was unsuccessful:

I have attached some of these weird files

I managed to decode the files: They have 4 extra bytes in the start of the file: the ktx texture (defaultPet_Body_RSCMask_TEX_BC_1705184) should start with «KTX 11», and the crunch textures (candyPet_Body_RSCMask_TEX_BC_2553344, fantasyPet_RSCMask_TEX_BC_3795744 and tropicPet_Body_RSCMask_TEX_BC_3509824) should start with Hx. The reference crunch.exe that is hosted on github did not work on the textures I tried it on. I investigated the files and they used a compression format "11", which the enum in the decompressor source names  cCRNFmtTotal and specifically checks that the format does not match it. Anyway, I was able to find an "enhanced" version of the tool on this page: https://neverwintervault.org/project/nwnee/other/tool/nwn-crunch-enhanced-edition and it was able to decode the files. It also worked on the textures you posted, at least after I removed the 4 extra bytes in front of the file and renamed the files with .crn and .ktx extensions. Here are the textures from your zip:

candyPet_Body_RSCMask_TEX_BC_2553344:

defaultPet_Body_RSCMask_TEX_BC_1705184: (this looks like one of those mask files I was talking about)

fantasyPet_RSCMask_TEX_BC_3795744:

tropicPet_Body_RSCMask_TEX_BC_3509824:


The command line I used was 
nwn_crunch.exe -file "tropicPet_Body_RSCMask_TEX_BC_3509824 - Copy.crn" -out "tropicPet_Body_RSCMask_TEX_BC_3509824 - Copy.png"

Edited February 16 by yarcunham
added command line

[yarcunham]

I finally relented and compared the matrices I get from the ozz animation file and the matrices in the mesh files and this is the result for the hip bone:

matrix from the skeleton:

Matrix(((-1.0, -0.0, 0.0, 0.0),
        (0.0, -1.0, 0.0, 0.6416075229644775),
        (0.0, 0.0, 1.0, -0.008603900671005249),
        (0.0, 0.0, 0.0, 1.0)))

(decomposed)
(Vector((0.0, 0.6416075229644775, -0.008603900671005249)), Quaternion((0.0, 0.0, 0.0, 1.0)), Vector((1.0, 1.0, 1.0)))

(rotation as euler)
Euler((0.0, -0.0, 3.141592502593994), 'XYZ')

matrix from the mesh:
<Matrix 4x4 ( 0.0000, -1.0000, 0.0000, 0.6416)
            ( 0.0000,  0.0000, 1.0000, 0.0086)
            (-1.0000, -0.0000, 0.0000, 0.0000)
            ( 0.0000,  0.0000, 0.0000, 1.0000)>
decomposed:
(Vector((0.6416075229644775, 0.008603900671005249, 0.0)), Quaternion((0.5, -0.5, 0.5, 0.5)), Vector((1.0, 1.0, 1.0)))
euler:
<Euler (x=-1.5708, y=1.5708, z=0.0000), order='XYZ'>

So, the position is different (0, 0.64, -0.09) vs (0.64, 0.09, 0.0) and the rotation is different (180 degrees around the Z axis vs -90 degrees around the X axis, then 90 degrees around the Y axis).

I guess now I have to figure out the correct space conversion then...

[yarcunham]

Further analysis: The basic body meshes all use the same bind pose matrices (i didn't check if they're literally the same bit-by-bit level, but the element-wise floating point values are closer than 1e-5 to each other). Some accessories (clothes, hair, etc) have significantly different matrices. There are some that are roated 90 degrees, which I suspect is some kind of an asset pipeline error. Then there are shoes: some shoes are high heels, and they systematically have a just-under-5cm (or 2 inch) offset. Makes sense: they're high heels.

Here is an example from the analysis output:

d64e8ca713d83fc1 (l_tibiaRibbon_01_uJnt):
in file "01843_a7494d1363ac7bd9.dat": basicHighHeels_SKINNEDMESH
<Matrix 4x4 ( 0.0000,  0.9998, 0.0216, -0.3501)
            (-1.0000,  0.0000, 0.0000, -0.0895)
            ( 0.0000, -0.0216, 0.9998,  0.0232)
            ( 0.0000,  0.0000, 0.0000,  1.0000)>
in file "01755_dc9ca21776a54c50.dat": drMartensBoots_SKINNEDMESH
<Matrix 4x4 ( 0.0000,  0.9998, 0.0216, -0.3023)
            (-1.0000,  0.0000, 0.0000, -0.0895)
            ( 0.0000, -0.0216, 0.9998,  0.0222)
            ( 0.0000,  0.0000, 0.0000,  1.0000)>

There you can see joint id, d64e8ca713d83fc1, named l_tibiaRibbon_01_uJnt which has a -0.3501 displacement on the X axis in one matrix defined in the "basicHighHeels" mesh and a -0.3023 displacement in the "drMartensBoots" mesh (4.78cm/1.95inch difference, assuming 1m = 1 world unit), . Also a 1mm difference in the Y-axis. All other elements are the same.

[yarcunham]

What the animation should look like:

https://imgur.com/2fotjqC

What it actually looks like:

https://imgur.com/hhPsGuN

LMAO

Edited February 22 by yarcunham

[yarcunham]

Okay, so my animations don't work, but if I trust the bone orientation I get from using the Inverse bind pose matrices in the mesh files, it looks like the joint's local X axis is the one that goes along a the torso, the legs and the arms and even the fingers of the model. The only exception is the tail where Z axis goes along the length of the tail and the X axis points left, toward the negative global X axis. I also added an empty in the scene to show the Blender native axes (X goes toward the top left, Y toward the bottom left and Z toward the top)

The mystery numbers "after the matrices" in the mesh file are floats and they seem to be some kind of a length value for the joints. Maybe It's actually the length of the bone. It could also be the radius of the bone, for physic collisions. In this image I plugged the number into the head_radius of the bones in blender and turned on "envelope" display mode. This is the "right orthographic" view in Blender, so X axis it "toward the camera", Z-axis is up and Y-axis is right

I'm pretty sure that is supposed to be the length of the bone. If it was supposed to be radius, the sphere at the base of the tail would probably be a lot smaller

Edited February 23 by yarcunham

[scratchcat579]

2 hours ago, yarcunham said:

Okay, so my animations don't work, but if I trust the bone orientation I get from using the Inverse bind pose matrices in the mesh files, it looks like the joint's local X axis is the one that goes along a the torso, the legs and the arms and even the fingers of the model. The only exception is the tail where Z axis goes along the length of the tail and the X axis points left, toward the negative global X axis. I also added an empty in the scene to show the Blender native axes (X goes toward the top left, Y toward the bottom left and Z toward the top)

The mystery numbers "after the matrices" in the mesh file are floats and they seem to be some kind of a length value for the joints. Maybe It's actually the length of the bone. It could also be the radius of the bone, for physic collisions. In this image I plugged the number into the head_radius of the bones in blender and turned on "envelope" display mode. This is the "right orthographic" view in Blender, so X axis it "toward the camera", Z-axis is up and Y-axis is right

I'm pretty sure that is supposed to be the length of the bone. If it was supposed to be radius, the sphere at the base of the tail would probably be a lot smaller

unity uses the same space as starlite (y up, x right, z forward)

that's probably why i don't have problems with rotations in my importer.

Edited February 23 by scratchcat579

[yarcunham]

10 hours ago, scratchcat579 said:

unity uses the same space as starlite (y up, x right, z forward)

that's probably why i don't have problems with rotations in my importer.

Do you also import the animations? Because the weird bone orientations are not a problem for posing the model. For that I only need the positions and the weights. I could even orient the bones by hand so that I the arms and legs have a consistent rotation axis (so for example having the knee and the elbow bend around the X axis). 

But if the bone orientations are not the same as they were when the animations were made, then you get the kind of thing I posted. And the animation I posted was the best result I have gotten so far.

[yarcunham]

Well, some kind of a success finally: https://imgur.com/aHXgpaf

The animation in the ozz-animation files are stored as absolute transformations, from the armature's origin. I'm sure I have tried this before, but apparently I haven't??

Anyway, this is what I did: I read the skeleton hierarchy just like before, and I apply the animation to the skeleton just like before. The I iterate over all the bones and set their matrix to the identity matrix.

So in edit mode my armature looks like this: All bones are at the origin. The armature itself has been rotated 90 degrees on the X axis and scaled by -1 on the local Z axis, to make the armature's local space match starlite/unity. The empty in the screenshot is again there to show the Blender native axes, you can see that the bone axes have their Z and Y axes flipped compared to the global axes.

Now you will notice that the animation above only shows the armature and not the mesh. That's because the model is bound in the "actual" bind pose, so after moving all the bones to the origin, the model becomes an eldrich horror. But I'm going to work on that now.

[yarcunham]

I got it working in an unsatisfying way by animating one armature as described, then making another armature where all the bones copy the location of the other armature:

https://imgur.com/D2hPq3h

Also now that I'm viewing that, I see that there are some occasional 1-frame glitches

That above animation is this  that I found in the outfit 7 blog: https://outfit7.com/blog/tech/outfit7s-art-pipeline

[yarcunham]

Theglitches are caused by quaternions having keyframes where the curves all cross the 0 line at the same time. And if you convert the animations to euler, then there are sometimes 180 degree jumps between keyframes, where for example the X rotation starts from 175 degrees and should go to 185 degrees, but because of how quaternions work, the keyframe is placed on 5 degrees instead. These could probably be filtered programmatically.

[yarcunham]

Okay, I could not reproduce the glitchiness today. I'd say the functionality is like 95% of what I was going for. The "unsatisfying" constraint trick works well enough for me, I can use it to bake the "actual" animation data if I want to. Just to see how it looks, I imported a bunch of assets and imported all the animations as actions. Then I used the NLA in blender to stitch a bunch of the dancing animations together (i had to cut it short due to imgur's 1 minute limit): https://imgur.com/gX8V9xJ

Things that I know don't work yet: Hats and hairs don't get skeletons. As far as I know, they don't use keyramed animation. Insted they use jiggle bones for physics simulation. For the video I linked, I just parented the hat mesh rigidly to the head bone.

Shoes: I tried using a pair of highheels on the animation, but they just look completely wrong (due to the foot offset issue i mentioned in a previous post). But then it looks like the boots I used in the animation actually have some kind of an offset too, which surprised me. The soles of the boots go through the floor mesh more than just the feet.

But other than those issues, the animations look perfect to my eye. Like I said, I didn't get any of the glitchiness today. Might have been a classic "turn it off and on again" type of problem.

[scratchcat579]

11 hours ago, yarcunham said:

Okay, I could not reproduce the glitchiness today. I'd say the functionality is like 95% of what I was going for. The "unsatisfying" constraint trick works well enough for me, I can use it to bake the "actual" animation data if I want to. Just to see how it looks, I imported a bunch of assets and imported all the animations as actions. Then I used the NLA in blender to stitch a bunch of the dancing animations together (i had to cut it short due to imgur's 1 minute limit): https://imgur.com/gX8V9xJ

Things that I know don't work yet: Hats and hairs don't get skeletons. As far as I know, they don't use keyramed animation. Insted they use jiggle bones for physics simulation. For the video I linked, I just parented the hat mesh rigidly to the head bone.

Shoes: I tried using a pair of highheels on the animation, but they just look completely wrong (due to the foot offset issue i mentioned in a previous post). But then it looks like the boots I used in the animation actually have some kind of an offset too, which surprised me. The soles of the boots go through the floor mesh more than just the feet.

But other than those issues, the animations look perfect to my eye. Like I said, I didn't get any of the glitchiness today. Might have been a classic "turn it off and on again" type of problem.

tf did i just watch... edit: you will need the prefab files if you want the rigs for the hats and hairs or anything that doesnt have an ozz skeleton

Edited February 26 by scratchcat579

[yarcunham]

11 hours ago, scratchcat579 said:

tf did i just watch... edit: you will need the prefab files if you want the rigs for the hats and hairs or anything that doesnt have an ozz skeleton

Yeah, I haven't looked too deep into them so far. Right now I'm trying to clean up and streamline the scripts I have. It will never "user friendly" as such, but at least I could make the model, skeleton and animation importing easy enough that anyone with any coding experience or at least experience with Blender and some willingness to try stuff out should be able to follow the instructions.

 

Also, going back to my animation woes: I'm not sure if it's even possible to import the animations without implementing the keyframe interpolation from scratch, so the method I'm using will have to do for now: I create 2 skeletons, a "reference" skeleton with all bones' bind pose set to identity matrix and another "deformer" skeleton with the bones' bind pose set as in the skeleton file. The deformer skeleton has a "copy transformation" constraint applied to every bone, where the constraint's target is the same bone in the reference skeleton. Any animations are applied to the reference skeleton, then the transformations are copied to the deformer skeleton, which then deforms the mesh.

The reason I can't think of a way of implementing the animation import directly is because the animation keyframes are independent timestamped values for translation, rotation and scale. So there might be a translation keyframes at times 0.25 and 0.5, and then rotation keyframes on times 0.33 and 0.66. In blender I can set the translation of a bone and then set a translation keyframe on frame (0.25 * fps) and so on.

I might be able to transform the keyframe data from pose (armature) space to (bone) local space, but so far I have not been able to wrap my head around the matrix math required for that. It sure seems like either the parent bones keyframes affect the results or doing piecewise transformations for translation and rotation matrices simply does not work.

So for now, I'm going to be content with using the copy transformations constraints. Later I might bake the visual transformation of the deformation skeleton just to get the converted animation data.

[yarcunham]

Here is the "user-friendly" version of the scripts (very heavy quotation marks on user-friendly):

If you have downloaded the MTA2-angela.7z in the earlier post, you have a bunch of meshes, a skeleton and a whole bunch of animation files.
For this tutorial, I'm going to assume that you unpacked the files in the directory C:\Users\SlimShady\Desktop\MTA2-angela

To import them into blender, follow these steps:

Download and unpack the blender-outfit7-import.7z somewhere, it contains 3 python files: blender-outfit7-animation-converter.py blender-outfit7-model-converter.py and blender-outfit7-skeleton-converter.py

Open each of those files in Blender's text editor, in the scripting tab.

Scroll all the way to the bottom blender-outfit7-model-converter.py and type in the absolute path to the skeleton file in the read_joint_parents_and_names function call.

For example:
read_joint_parents_and_names(r'C:\Users\SlimShady\Desktop\MTA2-angela\angela_SKELETON.dat')

Then add the path to the directory that contains all the meshes to the process_dir function call,
for example:
process_dir(r'C:\Users\SlimShady\Desktop\MTA2-angela\mesh')
Alternatively, if you only want to import just one of the meshes, type in process_single(r'C:\Users\SlimShady\Desktop\MTA2-angela\mesh\angela_bodyAngelaMTA2_MESH_SKINNEDMESH.dat')

Now you can run this file by clicking on the "play" button in the header. The meshes should pop into the 3D view within a few seconds.

Now scroll all the way to the bottom of blender-outfit7-skeleton-converter.py and type in the absolute path to the skeleton, again, to the process_single function call.
for example:
process_single(r'C:\Users\SlimShady\Desktop\MTA2-angela\angela_SKELETON.dat')

You can now press the play button in the header. This script creates 2 armatures, a "reference" armature and a "deform" armature. The reference armature is named "angela_SKELETON-reference" and the deform armature is named "angela_SKELETON".
Immediately after running the script, you will only see 2 very small bones on the X axis. The one that 2 units away from the origin is the reference armature. Select the reference armature.

Now, scroll down to the very bottom of the blender-outfit7-animation-converter.py file and type some animation file path in the process_single function call,
for example:
process_single(r'C:\Users\SlimShady\Desktop\MTA2-angela\anim\angela_stickerAlbumPoses_roomPose1.ozzanim')

Make sure that you have the reference armature selected, then click on the play button. The two armature should now "pop up" into existence.

Now select one of the meshes, then shift-click on "deformation armature", the one that is just named "angela_SKELETON", then press ctrl-p and select "Armature deform". Make sure that you select "Armature deform" specifically and not any of the other options.
Now click on the next mesh, shift-click on the deformation armature, press Ctrl-P, select "Armature deform". Do this until you have parented all of the meshes on the armature.

If the already-parented meshes are in the way, you can select the mesh and hide it by pressing H
Once you've parented all the meshes, you can unhide the hidden meshed by pressing Alt-H

That is the basic process.

 

Any animations you import will be added as an action with the same name. So If you you followed this post and open the action editor, you should find an action named "angela_stickerAlbumPoses_roomPose1-anim" in there. You can then add the actions in the NLA editor to make longer animations

blender-outfit7-import.7z