Search results

In doing a table search it appears all the drunk references are still there. The animations may have all been un-preloaded though, so you may need to add them all back to anim_files.xtbl - preload True. You may also have to change the AnimSet reference on the character to Drunk.xtbl and add...

The animation table for that weapon is the Weap_RHammer.xtbl It appears there are only two Actions in that table. "Hammer Prep" and "Hammer Smash", the animations are "rhammer_prep.animx" and "rhammer_smash.animx". These action tags may also need to exist in the "anim_actions.xtbl" Just...

Usually, Black is what stays and White is what is knocked out. But you have to of course have the additional "A" channel for an RGBA image. I've never messed with the image options you have up there so I won't be any help there.

Sorry, not at the moment. All of these tools are in the works.

I'm not too familiar with whats in the actual crunched data but I would assume a crc should be in the STR2. I'll try to confirm.

I don't know 'all' of the proper crunched file specifics but what you have seems to be correct. The material of course has the referenced textures ( D, N, etc ) and assigned shader and the mesh components/draw calls are based off of unique materials. This may or may not be very helpful. LOD 0...

It is possible the animations aren't "preloaded" and they may be loaded in that mission container specifically. That's usually how we handle managing the memory for specific scenarios.

Hrmm, oh another thing as far as the "_high" matlib goes. The high file is found and loaded based on the character's name. So the mesh reference for "Zoey" in the character.xtbl. "zoey.cmeshx", code will look for "zoey" + "_body_high.matlib_pc".

Most all characters should be self-contained. There are of cases of other NPC's with direct texture sharing as we've seen earlier. Texture references for characters are only found in ccmesh and the "*_head"/ "*_high" matlibs outside of the associated pegs.

You should already be able to do that with the Table tools that were released.

The animations playing here appear to be the normal walking animations and the handprop locations aren't positioned for holding anything. Some conditions to be aware of only "civilians" will react to the rain. Character entries flagged as "heroic" will ignore the rain, as will scripted npcs's...

It appears that this is mostly a hard-coded scenario that occurs for the AI. The takeout animation that is played on an npc has prop triggers, found in the "anim_files.xtbl" to create the "umbrella" prop. When the animation_triggers process see the "umbrella" prop called specifically it...

If you look at entries for hair in the customization_items.xtbl you will see something like the below. If the hair isn't compatible with hats, too large, too tall or the like, it will have a wear option "Incompatible" that is flagged when a player is wearing a hat, "hat active". A separate wear...

All NPC facial animation is done with morphs or blendshapes. So what you have there is essentially the final rigged head. The only thing missing is the morph targets. If you can import and rebuild the morph_pc that should get you what you are looking for. At some point I will be working on...

The character_definitions table is essentially the same as SR3.

Ignore the morphkey file. Its an intermediate file used for mapping the mesh verts to the morph verts. My last thought here is that the animations in the "JOE" animation set are not marked as preloaded and are only loaded with the mission. If you are not preloading them the game will surely...

I would say it was likely added specifically for M02 or others that may use a similar override mechanic.

You are correct, that appears to be all there is available for this function.

It turns out, for whatever reason, the eyes in this rig and paul are indexed incorrectly in the middle of the rig. This throws off everything else of course, which is why you see the tearing you have there. I re-indexed the rig and cmesh, it may be of some help here, but will only help when...

Usually when a character tears apart like this the animations aren't indexed properly for the rig. It's possible the proper animation set isn't playing on this character or the character doesn't have the same bone hierarchy that most all characters have assigned. I would find that to be odd as...