Mine was nothing like that - UVMapper even tells me if anything is off the edge. All my parts were on the map properly.

When i make a new object, in the game, the new mesh has all the patterns that were on the object i cloned from. What can i do to delete the old patterns (that were in the object i used to clone) from my new package?

Well, two weeks have gone by without any changes to the package. It was too good to be last, I updated the package today. However, there are not really any radical changes, except dropshadow meshes have been restored to the previous scaling in MilkShape, but is still saved to disk with the proper scaling values that game needs for them to work. Note that you will need to decompile your previous project again to see the scaling change. You should not use the new version with older intermediate files, but you can freshen these files by decompiling your old MODL/MLOD files, you should not need to remake them from scratch.

The MilkShape plugins have been moved to a separate package, and the licensing has been changed to a less restrictive license for the plugins. Additionally, the plugins now show the joint positions, should be especially useful for car meshers. The parts will animate, but the animation may not be as in the game on all objects, because the rigging is not included in the mesh files.

Am I missing something here? I updated the Tools and the plugin, and yes they are in the proper folders.

I created a new clone, opened it in s3pe, exported the MLOD and MODL files same as before, opened them in the new version 20 of the Object Tool but when I tried to import into MilkShape all the import plugin saw was the *.s3asc files and trying to import them throws an error, (ERR: Wrong file opened, use the "_filebase"), importing the *.mcfg throws the same error. The only way to find the *.mcfg file is by using the drop down for 'all files'. This was using version 1.8.5 of milkshape.

I went back to version 14 of the plug-in that looks for the mcfg file and it imported it without a problem. This is with version 1.8.4 of milkshape, I had version 14 in that folder so that's what I used to test it.

My OS is Vista Home Premium 64, all files up to date unless I missed something.

I see you updated the plugins. However, something is out of sync here. The new ObjTool will generate a file that ends in "_filebase.s3asc" and that is what you are supposed to load with MilkShape.

Both the V0.20 ObjTool and the V0.20 MilkShape plugins have the version either in the window title bar or right on the menu item. I am hoping this is what is wrong, if not I made a boo-boo, but it works here pretty reliably.

<* Wes *>

(ERR: Wrong file opened, use the "_filebase")

I just downloaded these for the first time, I had the same problem. I scratched them and tried again, same issue.

OK, I believe something is wrong. But I am missing something here, because I am not getting that error here.

When I decompile files, and open the V0.20 MilkShape plugin I see one (or more files) with names like this:

S3_01D10F34_00000000_7F76AE060BF7493A_MLOD_filebase.s3asc

And that is all I see without changing the "filter" on the dialog box from "Sims 3 Asc Files (*.s3asc)" to "All Files (*.*)". This matches what CT said.

So where is this going wrong?
Is there not a "somenameoranother_filebase.s3asc" file?
If you only decompile one file, is there more than one filename showing?
Or does just one exist and you get this error even when you select it?

There has to be something very simple I am missing here, because I don't think the old plugins (V0.14) will load the *.mcfg file from the new ObjTool without errors, because the mesh file names changed for the group mesh data.

<* Wes *>

"somenameoranother_filebase.s3asc"
That file does exist, but MS gives the error when you try to import it

I had this problem, but it was like you said, I was using the new ObjTool and the previous plugins. Once I installed the new plugins, it worked fine.

Found my problem, and it was my own fault for failing to remove the older version of the tool. When I chose to open the file it was already associated with the tool and I allowed to to open without browsing to the new version. I should have realized it when there was no *_filebase.s3asc file in the folder.

Thank you Wes, and feel free to use me as a training example of what not to do.

I am pleased it was a simple problem. I was really concerned because I tested and revised the file handling part that was not working a lot.

However, you need not shoulder the "blame". If I were a bigger shop, and had more any helpers, this would have an installer program, which would have made sure all of the steps like the file-association, desktop icons and the like were managed.

Thanks to all for their patience, and support.

<* Wes *>

I am getting the same error message that CTN got. I am not sure what tool to remove or where to remove it from. Sorry to be such a dunce but could you be more explicit about how to fix this problem?

OM

Just download the new S3ObjTool and the new MilkShape plugins. They are both marked V0.20, check that the proper version shows up when you run them.

I thought at first she downloaded only one, she did both, but inadvertently was using the old version (of the ObjTool) with the new plugins. The files changed some, and you cannot mix the older and newer versions.

An additional way to be sure is to open the .mcfg file with WordPad... the first line should look like this:


If it says an older version, the project files will be incompatible with the newer plugins. Decompiling with the newer version will fix that.

The MilkShape plugins have the version number right in the menu item.

I downloaded the tool and the plugins. For the plugins I just placed them in my MS folder after finding where it was by clicking on my desktop and choosing Properties. When I open the tool it says it is version VO.20 and that is the only version I have that isn't a ghost file. I would open the mcfg with WordPad but I don't know how to do that. I think everything should be right though as I have the new plugins in the right place and the new tool is the one I am using.

I'm sure I'm making some simple mistake somewhere but I cannot figure out what it could be. Do I need to remove something like CTN did? I can see the file that I want to open sitting in the folder I am directing Milkshape to look in but it keeps saying it can't open it.

edited to add: I downloaded two rars with plugins. One had 3 dlls and the other had 2. These were the 5 dlls that I put into my MS folder. Was that the right thing to do?

OM

Ok, now I feel like a complete idiot. I noticed that when I went to import my object in Milkshape the name of the import feature was still the name of the last version of the obj tool.

Even though the plugins are sitting in my MS file, for some reason, if I used the old desktop shortcut it would default to using the old obj tool to import with. If I open MS using the exe in the file instead of the shortcut it works just fine.

So I had to delete the desktop Milkshape shortcut I had and create a new one. That's all it took and now everything is going smoothly. I just thought I'd post though in case someone else is having the same issue. Next time I come asking for help be sure to remember to ask me if my computer is plugged in.

OM

I bet you have two versions of MilkShape installed. I always keep the previous version installed when I upgrade, I just carefully rename my old desktop icon so I know it is the older one.

If you are using my GEOM plugins, you would have installed 1.8.5 beta1, as they require thta. But these plugins will work on all versions back to 1.7.8, because the objects do not need a few features the body meshes do.

I am just glad that you got your problem straightened out... I know I have made a lot of versions in a short time, but I have been trying to get all of the tool issues resolved as quickly as I can, so that people can get their new creations made without worrying that some problem with the ObjTool or the plugins is going to bite them before they are finished.

<* Wes *>

You're right...I do have 2 versions of Milkshape installed...or rather, two instances of the same version...that was something else I discovered this morning when trying to figure all of this out. At first I thought that was my problem...that I had put the plugins into one but not the other and was using the one without the plugins. However, even after putting the plugins into both MS still reverted to the old Obj Tool until I got rid of the old desktop shortcut I was using. I have no idea how I ended up with two instances of the same version of MS going and I hesitate to admit this is only possible because I am running one off of my desktop.

I've got MS 1.7.9 in right now. I recently went through a complete computer update with new comp, new operating system, and new version of PSP among other new things required to get things running. Right about then I ditched Sims 2 and started trying to figure out how to mesh with Sims 3 with all the new tools and new versions of new tools that has required.

So I've been stumbling around trying to learn the new layout of my comp, the new idiosyncrasies of my OS, the new features of PSP, plus all the new tools that we need for Sims 3. I think if I had to update MS right now I might have a nervous breakdown...lol...I won't burden you with the details of the language that has occasionally slipped past my lips during this most frustrating time

Anyway, although it's occasionally frustrating it's fun to be learning this as it's being developed...I missed out on the development part of meshing for Sims 2. Dealing with new versions of tools coming out frequently is just part of the process and adds to the challenge of the whole thing. I'm just glad there are people working on all these tools and getting the whole ball rolling so fast...my Sims are a demanding lot and they want their bling

OM

I have to "recompile" a MLOD the error message:
UV Scalling overflow [0.000000:0.981817,0.000000:0,982249]. Export anyway?

What does the error message and what can I do?
In the MODL and the other 2 MLOD had been no error.
The UV map is 256 x 512 - is the matter?
Have the latest versions of programs.

translated with Google

You have UV Coordinates in that MLOD which are outside the footprint of the original UV mapping. The EA-made meshes have a scaling applied that expands the UV map to utilize the full map area. When UV coordinates are added beyond the right edge or below the bottom edge, these can become scaled beyond the boundaries.

The two solutions are to rework the UV coordinates so that all the points lie within the original boundaries, or to edit the mtlsrc files to change the UVScales value. The default value of 0.000030518 is appropriate for the second solution.

Thanks for the Help.
I did not understand how to modify the UV coordinates.

However, I found a solution. I have a different template from the game and taken it, I could then convert easily into my object.

Well, you are not alone in having issues dealing with the UVScales.
So the latest version (V1.00) modifies all of the UVScales values to the value I have been recommending all along. The new version is attached to the first message in this thread.

That is great news Wes, thank you so much. This means no more UVScale overflow messages!!
And easier building objects and UV-maps from scratch, right?

Thanks for the update Wes...so does this mean that we can now replace the EA maps with maps that are larger without having to edit the UV Scales by hand?

OM

This is an automation of going through all the .mtlsrc files and changing the values of all the UVScales, DiffuseUVSelector and SpecularUVSelector to 1/32767. While it is still possible to ruin a mesh, you should be able to UV map all the area between the top and bottom, left and right of the UV area (0.0 to 1.0).

It is possible to retain the original values by deleting the .mtlsrc files prior to recompiling the mesh, but I don't know of anyone except a science major who would want to do that. It just works.

Sweet! Thank you!

OM