Try looking in C:{username}\AppData\Roaming\Spore Creature Creator\ (that's for Vista). In XP it should be something like Application Data, but I have no install here on XP at this time. By default, the app data folder is hidden in both XP and Vista (Microsoft calls it a system folder, and says you could damage your system).

The other directory in User Data, in Documents\My Spore Creations, just contains pictures and videos you make.

I have seen and accessed creatures from other users, so I know the process and have some of the files. I am of the belief the creature is downloaded separately after the picture is dropped on the application, but the data does compress well, WinRar got it down to 3K from 30K, so it could be incorporated in the PNG file. I don't have anything to parse a PNG file with here to separate the pixel data from any other.

Regardless of what is in the PNG file, after whatever download process the data is placed in .package files in your user directory. This is where I am viewing the data, and where the program accesses it from, after decompressing it.

Anyway, enjoy your morning, old grouchy-grouch.

I have been looking deeply into the very soul of these files.

I do not doubt that the program "phones home" when installed, that was foretold. I will trust others efforts to prove it was SecuRom that did it, that was foretold.

The creature data itself is inserted into .package files, in the new DBPF V2. The decompression code Dizzy wrote for the extract program (in the bowels), with minor modifications to the source, works on the compressed parts, although I have an all new parser for the V2 files. My thanks to Dizzy for the posting the source.

The main part of the creature data itself is an xml 1.0 file, uncompressed about 30K (my example critter). In the packages is/are sections(s) with the username and creature name, in unicode. While one user is hardly proof, the user name in there is the user name part of the account (sans the email domain) I made at the Spore site.

So I believe that when creatures are "published" the data uploaded includes the user name from the account, and the creature name, and that when the small PNG file is dropped onto the application by a different user, the data for the creature is downloaded and inserted into a package file, together with other creatures. That downloaded data includes the user name, compressed with the same 'QFS' method used on The Sims 2.

So I disagree with the "massive security leak" part. The rest of the issues about working with the program online and unblocked by a firewall are certainly valid points for people to watch, especially with installations that were not done with "gen-u-wine EA advantage" materials.

The PNG file is just a picture, so the CC has to be using the filename to trigger a download.

As for extracting things, I have enough information gathered to split the DBPF V2 package files into component parts with a commandline tool. Ugly but effective. I am trying to leverage the dead Dizzy's decompression code in the dead "simpemustbedestroyed" tools to complete my file splitter.

Then I can try to determine what these part pieces are used for (except the PNG parts, I already know what they are). My findings are posted at my place.

And no Spore Creature Creator programs have been, or need be, reverse engineered to determine the .package file layout.

Are you lobbing dud grenades again?
I see the username that was used on the spore site registration, which is about as secret and useful as "J. M. Pescado" is.
And encrypted is more correctly labelled compressed, with the same 0x10FB compression as used in The Sims 2 and the compressorizer.

Paranoia is a useful survival trait, but if you don't want to get bombarded with gamma rays, you can't lay out at the beach.

A fine sense of style there. "Yes, I'll take that shiny new laptop and the Windows XP upgrade package, please."

It appears, from my observations of the shelves at OfficeMax Circuit City, Best Buy and the like that the Windows XP upgrade is a top selling program. Microsloth has outdone themselves with a new business strategy for increasing revenues... sell everyone two OS packages.

sorchi:

You need to reset your view (look in the extra/preferences menu). The resource llist window has gotten undocked, so even when you open a package with an OBJD in it, you won't be able to select one to show up in plugin view.

I had that happen, only to rectify itself after a reboot.
Funny thing was, the audio worked in othe rapplications, while TS2 had no audio.
I chalked it up to one more example of why Microsoft doesn't write software to run the Space Shuttle with.

Who peed in Rohina's shampoo bottle?

Inge, for what little it may be worth, my opinion is that you (and especially Peter) have done a positive service for the community by taking the current work to the next stage.

<* Wes *>

The color binning problem could be addressed in SimPE. It came from Quaxi changing calls to some deprecated functions into errors. I believe Theo posted a query about why it didn't work, Quaxi provided an answer and now both of them have gone missing. Although since the site is down who can be sure.

I could never argue against such an authoritative source.
Still, the little details like the Maya default scale being 1.0 units = 1 Meter make me wonder.

In spite of the necromancy warning, wes_h says:

Christianlov popped out of the ether and posted a program he called CL tool, which is pretty much like SimPE was around version 0.12. It has some promise.

See his post at: http://www.modthesims2.com/showthread.php?t=257487

Seems we have had this discussion at regular intervals over the last three years, and have settled nothing fro certain.
But I am in agreement with Inge, although that proves nothing. It is a game, after all, and not a CAD program, so I presume the artists (not engineers) took some liberties with measurements when they built the game content.

I base my 1 meter on the sim height and the wall height.
Standard heght for doors in the US is 7 ft, or 84".
I doubt for every article that either of our ideas are correct, and I would bet that many items are not scaled realistically, but rather to fit the whims of the artists.

There is a MilkShape plugin in the package, and it is a sort of animation importer. It scans a .anmdat file (mainly ap01) and will attempt to convert some of that data into MilkShape animation format. It does not do a good job, because the arms do not always come out right, and because the vast majority of the game animations use IK animation for the arms and legs, and there is no support in MilkShape for IK.

Importing Object animations would be far easier, and I would like to see that worked on, too. The AniMax concept could help there, too.

<* Wes *>

I am sorry I cannot spend very much time until tomorrow evening explaining due to real life stuff.
But there are two different animation tools I have made.
AniMesh is a MilkShape plugin that converts skeletal animations (for body or object meshes) made with MilkShape directly into the TS2 binary format (tagged .5an). It is posted on MTS2.
Animax, which is posted here, is a two stage toolset that you launch via commandline or file association. Stage one converts the Maxis binary to a text script format that I dreamed up one day. The compiler converts that same format back to Maxis binary. If you change nothing between stage one and stage two, you should expect that the edited file performs the same as the original one, even if it is not a perfect binary copy.
The power comes from being able to cut, paste and modify the values between stage one and stage two, or to swap portions gathered from different disassemblies into a composite binary. This you do with Notepad or such. The changes one could make include being able to alter the values of the facial morphs, each of which form a part of an expression. The best documentation that exists unless someone else experiments and writes more is the material that Marvine wrote, which I copied into the second readme.
My general observation is that animations that are not defective in their binary format will not crash the game, even when the actions they dictate are grossly wrong. Remember, we started this with a conversation about plumbing the less dissected aspects of TS2, and so I made these tools available fro interested parties to use and learn with.
While I am definitely interested in suggestions for improvement, I can say I started working on animation stuff last year, although in fairness I will also say that some periods of time went by in which little progress was made. And despite my starting from a base of knowledge contributed by Miche, Atavera, DataFarmer and all the other early decoders, a lot of research and learning was necessary to get it this far.
So I am sorry if you expected a graphic design tool for the facial expressions, but that is a tool that is not easily possible to make at this time, although I have thought of cobbling one together using the likes of OGRE. In the meantime, the humble offering I have already made is all that I know of that is available.
<* Wes *>

It is interesting that the game engine supports IK in anim files. A lot of stuff converts the IK animation to FK keyframes for faster runtime operation. I have never attempted to match the disassembly with 3D coordinates on those IK movements, but I suspect there is likelyhood a close correlation. I believe you could copy the animation data for the arms from one animation, put them into a different one, and then alter the expressions, or take all the expression data from some animation you like and put it in one you don't.

It would be really nice of we had a nice 3D tool that you could do all of this in. Since we don't, I made do with what I could cobble together. One thing I learned in the process is that lots of maxis stuff was built bass-ackwards. The programming equivalent of baling wire and popsickle sticks.

In most animation files there is a faceblends section. Facial animations are morph type (vertex) animations. The disassembler will usually place these in a section with "-ap02" in the filename.

I attached a later version of the program notes here. There is some description of the facial blends and values, derived from work Marvine did.

Well, did anyone ever tell you to be careful what you wish for?

Seek, and ye shall find.

Here is an alpha-level program suite for editing animations.
The two main components are AnDis, an animation disassembler, and AniComp, an animation compiler.
For all practical purposes, you can take a game animation, use AnDis on it, the use AniComp on that and run it in the game. Some of the files reconstituted this way are not exact binary copies, usually the differences is floating point numbers out past six places or so. Well past the limits of the display.
I still have one unfixed bug that affects some fraction of one percent of the total animations that do not disassemble. I will fix this one day. While I do not have BV, someone that does reported that, except for the few oddballs, it handled all the BV animations also.
There is a set of program notesin the package, but they are not for the beginner or faint of heart. I use file associations so that I can just right-click in the explorer to disassemble or recompile things, and still double-click the file to edit it.
But you could just run them from the command line. They have no options, just the command and filename.

Well, what would you like to animate?

I have a reasonably well working animation exporter, released. Most of the material released that uses it is risque or p0rn.

I also have an unreleased  package that disassembles animations into an editable text format and will then recompile the files to game format. Someone who knew nothing about MilkShape or any other package could use this package and edit animations with just these two tools (AnDis and AniComp) and wordpad or notepad.

I made an attempt at importing the frames into MilkShape, but the Sims2 animations are not very useful to import because the IK animation data is in the animation files and the game engine, and most of the arms and legs action goes missing. I don't want to buy maya or something that expensive for a tool set.

We (testers and I) have modified facial expressions, and have inserted stuff from one file to another. It disassembles ANIM files that even SimPE chokes on.

If I knew someone that would actually do something with this, I'd give them the tools to use. They are relatively small command line things (plus one MilkShape plugin), although not as elegant as dizzy's work, reasonably bloat-free.

I tried to design the set so it was modular and I might be able to migrate other things in (such as BVH files) and later migrate animations out, possibly to Sims3. Right now, the wide variations in skeletal structure, and my thick cranial tissues, have hampered my efforts at transferring BVH files to the game.

I base my belief on the fact that the tiles are 1.0 mesh units on a side. My previous estimations of sims height, wall height and so on all point to a meter being the proper equivalent. A yard is close, but except for maybe fabric and carpet, no one uses yards as a regular measurement. So I believe the default mesh scale of 1.0 units/meter is what was used. Something had to be standard, because there is no way a whole fleet of artists got everything the proper relative size by comparing each other's work and eyeballing it.

It should round up all the parts for items that are linked using the three keys and an XTOL or XMOL, such as the collars, Non-replacement Pet coats, face templates and other CAS only items.

What Peter wrote is very powerful. However, we seem to have lost the most adventurous object modders in the last year, we are down to "New Mesh" as an advanced mod.

<* Wes *>

Tiles are one meter on a side, that's my story and I'm sticking to it.

On metrification, almost every metric equivalent to the common measurements is bigger. A meter is longer than a yard. A liter has more volume than a quart. A half-kilo is still heavier than a pound. Every US product that I know of carries the size expressed as common and metric both.

But the size units are in round common units, not even metric ones. With perhaps the exception of medicines (in milligrams) and the previously mentioned 2-liter soda bottles, manufacturers would have to commit to the expense of new packaging and then would have to raise prices because there would be more product using an even metric approximate-equivalent package.

I don't know of any marketing people that would like to be the first to unilaterally raise their product price. The soda size change happened as a result of a (successful) promotion to increase market share by giving a little more soda for the same money.

From my rememberance of when the 2 and 3 liter soda bottles began to appear, I don't think anyone would have trouble adjusting to the new size. I just think that too many people would not look at the size or price per unit, just whoever had the larger price sticker would have a sales disadvantage.