The "sanity check" meant that I don't think either number is right, at first blush. Not that I think rowing your boat where you want to go is crazy, it's my style, too.
Testing measurements against expected values is one protection against propagating errors. I know this isn't rocket science or DNA sleuthing, but it is complicated.
Trying to puzzle through what you are seeing. Joints have a rotation value which means the direction of X, Y and Z are not necessarily aligned with the world axes. When you have three position values, they are relative to the rotation value for the parent joint.
So a set of position values like 0.1, 0.1, 0.1 mean move +0.1 along all three world axes, starting from the parent world position, but then you rotate that result position around the world position of the parent by the parent rotation value (which has been modified from the world orientation by the rotation of its parents, all the way to the root). I am thinking that this is where your variations come from. Many of the older game engines required zero rotation for joints, but that is not true for Sims 2 or Sims 3.
One frustrating issue with MilkShape is that if you are building a skeleton and adding joints, MilkShape will alter the rotation values, often of multiple joints at once... the joint stays at the same spot, but it is not the same. I used the Ascii file method I talked about a few posts ago to make the skeleton be exactly what I wanted it to be. I was getting the values from the Granny Viewer, and converting the quaternions they display to euler angles.
You could probably replicate a skeleton that way in Maya using the attribute editor. Both MilkShape and Maya (by default) use Y-up. Transferring a mesh with skin weights into Maya is no small feat, but getting the basic mesh and a skeleton into it is not hard, after that a smooth bind would get you a rough skin weighting. I've never used any version of Maya prior to 6.5, but most of the basics were there, Sims 2 was built with Maya 6.5, likely started on an older version.

Having been sent into the wilderness by the Wise One, cmo returns; battered, weary, a trail of bear and wolf carcasses in his wake...

I remembered you and Ciexari discussing bones in his script thread, and I edited the SKINs before I exported the MLOD. That added the joint and I was able to assign it. It still isn't working quite right, but I think changing my _RIG and doing the Ascii thing may solve it.

Cmo, I believe if you succeed, you should write a step-by-step and put it on the wiki.

I know what ingredients are in the soup, but I don't know the whole recipe. I think you have all of the ingredients, though.

The game still isn't recognizing the assignments of the new bone. Maybe because I need to change something in the VRTF or something?

I saw you changed the SKIN value.
But I am pretty sure that the compiler does not write any of the skin values that are in the .s3ascg files. It uses the values in the SKIN block to obtain the joint hash value (essentially its name) and from the list order determines the index value to use (this is paired with the vertices into the VBUF block). I would believe that your assigned index values are getting into the compiled file (with two bones that should be 0 and 1) but that the SKIN portion of the MLOD/MODL file still has a single joint in it. You might do a clean decompile and look at the .s3ascg files to verify that.

Why is it that you can't just decompile the dresser, strip the mesh out and put your window mesh into it?

Dressers generally only have one or two group ands windows generally have many groups.

I'm using the SingleDoorModern now. It has the same amount of groups, and it already has the extra bone, glass, and wallmasks. Looking at how the door SKINs are setup, I think I saw what I was doing wrong. But I'm pretty sure the door is going to work because the closet door I made works.

Enlighten me after you get done doing your victory dance in the end-zone. I am curious now as to what went awry.

<* Wes *>

I had added the new bone to all the SKINs but one. In the door, some have the root bone, some have the moving bone, and some have both. That might not have been the problem, but it wasn't right.

I had to use the glass door so I could have a moving glass part. I also used the doors animations(sounds work, too).
Now only if the animations were non-default...

WesHowe ducks... allowing that grenade to pass harmlessly over his head.

EDIT: I also meant to say that it looks good, and is a clever bit of work, even if you don't have the non-default part solved, yet. Solutions such as this have a value for machinima even if they are not fully independent works. Good job, sir.

Thanks, Wes. I going to do something simpler and document the process. It would be easier if we could assign new bones to the mesh. This is the edited SKIN:I did this before I exported out of s3pe. Once decompiled and in MS, the bones were there and in the correct locations. I assigned vertices to them, and exported and recompiled. Then I decompiled it again and put in back in MS. All was as it should be. But not in game. The root bone moved with the interaction, and everything(including what was supposed to be assigned to the new bone) moved with it. :P

On the non-default animations front, I don't know what else to try. You would think that changing the instance number(64), and referencing that number in the jazz script(32) would work, but its like the animation doesn't exist anymore. Another thing that is strange is that when I put the door animations in the dresser, there was no sound. But in the window, it has the sound. And it's using a window script class. So I guess the windows and doors share the same sound reference or something?

Fantastic!
So can you make custom animations .. and add them to the game ..? Using custom interactions Like [ Choas paining ] ? !
Thanks :D

I have no source to the game, and I believe that the relevant game code is in the core, not the scripts. However, based on my reading of the feature specs for granny, I don't think that the data exposed in the SKIN section is relevant to the animation, other than providing the link between the vertices and the joint.

I think the data that governs the actual joints as used at runtime is in each of the grannyrig files. I think the SKIN part provides a reference so that a joint (by hashed name) has a position on the list, an index starting at zero. Each vertex has one or more assignments, again an index, and a weighting, essentially a percentage. The game engine would link the vertices to the bone by looking for all the assignments to a particular index value.

I think the position data in the SKIN block is for reference value, because I never detected any result from poking it. What is used at runtime appears to be the values in the grannyrig file. Since I never decoded enough of those to know what values to poke, that part remains untested by me, but there is a post about car making somewhere on MTS where someone made a tweak to one to alter car wheels. That seemed to prove the point, although they did not do it right (based on an incomplete understanding of quaternions) they did move the wheel rotation point.

I don't know where it is, but there has to be a reference somewhere that matches the grannyrig to the object. While we can't readily edit those rigs, we can potentially redeploy them.

For rotations, the position of the joint is critical, because it is the center of the rotation. But for translations, it is not so important. While we see and think of joints being in the middle of our meshes, the game engine will do translations just fine, even if the joint was underneath the root, or out in front somewhere.

I only take the time to type out this lecture because I think, while you have done so much, you are stuck looking at the wrong place in great depth. I think that what you need is to get a SKIN with the right location data to MATCH the grannyrig, so that the rotations you create in MilkShape will match what the game engine does with them. Other than the hash for the joint, and the index position, I think the rest of the data (the matrices) is unused at runtime, instead the grannyrig (which uses position and quaternion rotations rather than matrices) is the reference point for the playback.

Anyway, you have made some exciting progress nonetheless, work you can be proud of.

<* Wes *>

Oh, and the sounds and some of the other aspects you notice are embedded in the CLIP file in a section that the AnimTool merely copies over. When I explained earlier that the frames are 'inserted' into the original, what really happens is that a new file is made, because the format has a table of offsets, a size item, and you have to adjust all of those to maintain overall integrity. But one of the sections is just copied from the original, and that contains the data that specifies sounds, effects and targets. It would not be that major of a project for someone to write an editor for that section, but I don't see that someone being me, at least not in the immediate future. Mainly, you would have just put the beginning and the end of the original file before and after the edited block, and alter a couple of offsets and change the overall filesize field. Most of the block is editable text, but with 0x7f padding, you can see it by loading one into an editor.

Wow, great work, Cmo!

I've also been trying to hash the animation name and call custom animations, but to no avail. Hopefully one of you two will figure it out lol

Hello all,

I'm currently working on a mod wich adds lots of new interactions for our sims. But without custom animations those interactions are simply useless. The AnimTool seems really promising (thanks Wes), but unfortunatly I'm not able to use it correctly for now.
The first thing I've tried was to convert a CLIP (a_idle_neutral_loop_1) to SMD and convert it back to CLIP without modifying it. Used in game with my mod, the "new" CLIP is working well but I noticed that the new file is about 50% bigger than the original one. Using the 'Clip Info' boutton of AnimTool give very different results between the old one and the new one. Is it expected ? Do I miss something ?
The second step was to modify the original CLIP with Milkshape (I've just animated the two arms of the sim). Used in game, the new CLIP doesn't work well. Only one of the two arm is animated. The second one seems to have keeped his old keyframes.
I've tried to use the rigfile provided by Mesher, but with this rigfile the moded anim shows exactly as the original one in game and using 'Clip Info' give an error: "Err: jtCount is 322 max is 256" or something like that (I'm not at home right now and can't verify, sorry).

Any help would be more than welcome.

Thanks,
Gwenh

PS: Sorry for my crappy english.

I've written some s3pi wrappers for a few resources including the ClipResource. This should let you edit the event sections, and all other sections except frame data, in the S3PE grid view.

http://code.google.com/p/s3pi-wrappers/

Thanks atavera! This is great!

Well I figured what was missing from the process when I was trying to add bones. I did add the bone to the grannyrig file, and I did change the SKIN to reference the new bone. What I didn't do was change the group's joint reference. I was able to see this with atavera's s3pi wrappers. I added a bone and a group to the club light and made a (ugly) ceiling fan. You can see the video here. The quality is crappy, but you'll get the idea.


eta: Wes, I have to edit the .smd in notepad before running it back through the animtool. For example, for the fan I had to swap the y and z rotations. Also, I did the same animation in Blender and got it to work by swapping the x and y rotations.

Good luck for the project, being able to do custom animations would be the ultimate milestone for TS3.
With ambitions and custom interactions there'd be no limits to the number of "custom jobs" the modders can make. (some of them already exist in the careers mod by Twallan, using default animations\interactions)
And that's just the first thing.
IF possible at the end, I sincerely think it would attract most of the people\modders still active on TS2 only.
So kudos to you all, I'll follow your steps closely.

I think the issue there is probably the orientation of the root joint. Or lack of one. The SMD format is Z-up, while most of the modeling tools that are not named 3DS Max default to Y-up.

The converter solves this by swapping Y and Z positions and rotating -90X (for export), but it only does that on joints that are unparented. So if the fan rotation was parented to the root, then the root would be the only joint that is altered. If both joints are unparented, then they both get adjusted.

I cannot be sure with more info which case applies, and explaining rotations with words alone is difficult, but there should be a way to simplify the process either by parenting the joints or by rotating the entire object prior to export.

<* Wes *>

In the case of the fan, I only included one joint in the rigtext, and it was unparented. It was also unparented in the grannyrig. I've tried it parented to the root also, but I still have to swap axes.

And you don't have to explain rotations, I'm still trying to wrap my mind around things you've explained before. I've been using Notepad++ to edit the .smd, so it's it's pretty simple (because you can move columns). I'm glad Blender can be used for this. Sill no advancement on the non-default front. I've tried everything but the right thing. slides grenade back under Wes's chair. Any suggestions?

Wes rolls chair to other side of room, dons firesuit, inserts earplugs and adjusts goggles.

It has to be something simple, but perhaps overlooked. We know we can make animations that the game will accept, so just like meshes there has to be something that makes them unique. Unlike mesh objects, that have a cataloging process on startup, I suspect the animations are embedded in game code. So something in the game play scripts triggers a JAZZ script, and the JAZZ script calls whatever animations are needed to be played.

So either an existing JAZZ needs to be overwritten, or some game code written that calls a new JAZZ script. Of course, you know about the special bits used in the hashed animation names. I am sorry, I cannot allow myself to be sidetracked very far right now, I have another objective I set for myself that needs lots more attention...

Sudden blast erupts, smoke is too thick to ascertain fate of Wes.

OK, I wrote a tutorial on how to create an object with custom animations for The Sims 3. Personally, I believe that it is a very thorough tutorial, and nobody should have any trouble following it. The tutorial is here.

Finally! A custom animation tutorial! But I guess I'll have to read some modding tutorials on MTS, becuase I'm completely new to coding XD...