I am using Milkshape 1.8.0 and attempting to do some UV work within the tool.  I feel like I'm performing brain surgery with a fishing pole.

I am trying to create a new UV texture group (but do not desire a separate mesh group).  For example, the arms of the standard body mesh are broken into 4 distinct UV groups...left front, right front, left back, right back...the textures of which are placed at different locations in the skin texture.  Physically, the arms are all part of the same "body" group in the mesh, however.  But for texturing purposes, they are divorced from it.

I want to take a part of the existing mesh - like a hand for example, and map JUST the hand by itself to another location in the texture.  However, I cannot figure out how to accomplish this simple task in Milkshape because the UV nodes in the hands are "tethered" with the rest of the arm.  I want to separate the hand from the rest of the arm for texturing purposes only in the same way the arms are separated from the trunk of the body.

OmG, lIkE hEeEeeLlpPpp!!!1111

J

http://thesims2.ea.com/update/getpatch.php?appVersion=1.10&languageCode=

Major performance fix + a handful of the more serious bugs.  Vacation lots are almost playable now.

http://thesims2.ea.com/update/getpatch.php?appVersion=1.7&variation=cd&languageCode=

InTeenimater users are advised to remove InTeen before applying the patch or defer installing the patch until compatibility has been confirmed (or a compatible update to the InTeenimater has been released).

Objects in 3D games are comprised of "geometry" (or "models") and textures - two dimensional pictures or images that are applied to the surface of that geometry to give it a particular look.  In 3D games, object geometry is actually made up of tiny triangles "glued" together to make a single contiguous surface.  This is traditionally called a "mesh" - a latticework of triangles that make up 3D geometry:



If we solidify this "mesh" we get our mannequin that Simmie spoke of:



We can then apply a texture (clothing, in this case) to our model to give it a more appealing look than dull gray



The 2D texture is stretched across the surface of the geometry, producing the end product:



As SimmeCal mentions you might download one mesh, and then multiple textures (or skins) which are applied to that mesh to create many different looks.

In short:

A mesh defines shape

A texture defines style

You need both to see anything in the game.  Many (if not most) custom clothing or content just uses the mesh files that are already in the game.  But if you want a differently shaped object - one not present in the game by default - then you need a custom mesh for that object as well.  Many custom body styles, hair, and clothing require the use of such meshes.

J

It has been a long held belief that files in the downloads folder are opened in alphabetical order, folders coming before files in the same folder. Once a resource is loaded once, it's not loaded again.

Indeed this is something that has long been accepted as truth (indeed I was one of the first people asserting this observation as fact), and most of the modding community now accepts the "alphabetical load ordering" theory as fact.  However, something recently surfaced during the InTeenimater OFB beta that made me dig a little bit deeper into this and now leads me to believe this is not universally true and is potentially the source of many headaches for many people who may have hundreds - even thousands - of mods in their game.

After careful analysis using a number of file IO tools, I discovered that the game loads package files in the same sequence as the underlying file system sees them.  On Windows XP or Windows 2000 running an NTFS file system, files are always indexed alphabetically with subfolders appearing after (not before).  In essence it is "breadth-first" traversal of the directory structure and then alphabetical by file.  Indeed this is exactly the same order that we have all come to expect with respect to package load ordering.  I would say, that this holds for the large majority of Sims 2 players (fortunately!)

However, one of my beta testers experienced a phenomenon that nobody else on the test team could replicate: their InTeenimater flavor paks were being loaded BEFORE the core InTeenimater packages (flavor paks are add-ons/extensions to InTeen that are designed to augment the base feature set and intended to load after the core package files).  This is despite the fact that the flavor paks follow alphabetically AFTER the core packages.  Naturally, I assumed this would be sufficient.  Indeed many authors assume this, as there are a whole host of mods that start with 'z' in their name to ensure late loading.

I wrote a little program (attached), which enumerates the directory structure in the same order that the game "sees" the files.  What I observed may surprise you:

With the exception of the one beta tester I mention, everyone (including myself) experienced identical alphabetical ordering:

ME_MindControlMirror.package
InSIMenator (UV) v2.3 DEST Edition.package
InTeenimater_A.package
InTeenimater_B.package
InTeenimater_C.package
InTeenimater_D.package
InTeenimater_E.package
InTeenimater_F.package
InTeenimater_FlavorPak_BackToSchool.package
InTeenimater_FlavorPak_CollegeAdmissions.package
InTeenimater_FlavorPak_NoAgeOfConsent.package
InTeenimater_FlavorPak_NoCommittedRelationships.package
InTeenimater_FlavorPak_NoFailBirthControl.package
InTeenimater_FlavorPak_NoMiscarriage.package
InTeenimater_FlavorPak_ResidentialGraduates.package
InTeenimater_FlavorPak_SameSexPregnancy.package

Not surprisingly, each one of these testers have an NTFS file system running on Windows XP.  NTFS is the default file system for all new Windows XP installations.

However, the one beta tester I mentioned, running a FAT32 file system, experienced this ordering:

InSIMenator (UV) v2.3 DEST Edition.package
ME_MindControlMirror.package
InTeenimater_FlavorPak_SameSexPregnancy.package
InTeenimater_FlavorPak_BackToSchool.package
InTeenimater_FlavorPak_CollegeAdmissions.package
InTeenimater_FlavorPak_NoAdultTeens.package
InTeenimater_FlavorPak_NoAgeOfConsent.package
InTeenimater_FlavorPak_NoCommittedRelationships.package
InTeenimater_FlavorPak_NoFailBirthControl.package
InTeenimater_FlavorPak_NoMiscarriage.package
InTeenimater_FlavorPak_ResidentialGraduates.package
InTeenimater_F.package
InTeenimater_A.package
InTeenimater_B.package
InTeenimater_C.package
InTeenimater_D.package
InTeenimater_E.package

Indeed, this is the EXACT sequence in which the files were physically written to the hard disk.  As you can see, the files are "almost" alphabetical within their respective groups (the core InTeenimater files are mostly sorted, for instance, with the exception of the F package)...but the flavor paks PRECEDE the core InTeenimater files.  As it turns out, InTeenimater_F happens to be the first file in the ZIP file that I distributed to the beta testers, hence the reason it appears first in this list as well.  This user installed Merola's Mind Control mirror AFTER the InSIMenator, placing it 2nd instead of first in this listing.

Only FAT32 systems exhibit this phenomenon.  For my InTeenimater users this is not likely a huge issue, since most people will install the flavor paks AFTER the core program.  But if someone unpacks them in the opposite order, they will have HUGE problems (jump bugs, crashes, missing menu options, etc.)

As an additional test, I had this person delete the flavor paks and then recopy them back into their Downloads folder and run the utility.  This is the order that those files then appeared:

InSIMenator (UV) v2.3 DEST Edition.package
ME_MindControlMirror.package
InTeenimater_F.package
InTeenimater_A.package
InTeenimater_B.package
InTeenimater_C.package
InTeenimater_D.package
InTeenimater_E.package
InTeenimater_FlavorPak_BackToSchool.package
InTeenimater_FlavorPak_CollegeAdmissions.package
InTeenimater_FlavorPak_NoAgeOfConsent.package
InTeenimater_FlavorPak_NoCommittedRelationships.package
InTeenimater_FlavorPak_NoFailBirthControl.package
InTeenimater_FlavorPak_NoMiscarriage.package
InTeenimater_FlavorPak_ResidentialGraduates.package
InTeenimater_FlavorPak_SameSexPregnancy.package

In this configuration, the user no longer experienced crashes or jump bugs, and it was evident that the InTeenimater was functioning normally again.

Placing the flavor paks in a subfolder also proved to be an effective means of ensuring that they loaded after the files in the root, again suggesting that sub folders are processed *after* the files in the current directory.

This news throws an obvious wrinkle into the equation for those of us with inter-dependent mods that require correct load ordering in order to function properly.  We should have a care that those users who are running Win98/ME and those upgrading from 98 to XP, are likely to have FAT32 file systems and that we cannot rely on alphabetical package naming to ensure proper load ordering on these systems!

J

This is the first release of SimPE that is fully certified for use with Nightlife.  Major improvements on all fronts!  If you were previously using 0.48, you should upgrade immediately.

http://sims.ambertation.de

I have a question for anyone in the know (since my copy of NL has yet to arrive).  How do the object.package files differ between someone who has installed NL on top of TS2 versus someone who has installed NL on top of University (if at all)?  Just wondering if modders must support both upgrade paths or just one?