Mod The Sims - Adding Texture Options to Objects which have only one (Tech Discussion)

Numenor

21st Jan 2005, 01:53 PM

Actually I don't know if it is a "problem" having the family values all the same. As a matter of fact we only know that those values *must* be the same if the object is multi-state, because the game will identify the alternative state by its family number. But if the object isn't multi-state, the family value shouldn't matter...
In the in-game tests I've run so far, the recolours seem stable even if the MMATs have the same family value (I've tested it with the fireplace (The Gentrific "Flame-o-Rama", the most expensive), and the teddy bear. I haven't tested throughly the counters (for them, too, all the MMATs have the same family number).
BTW, I've tested that the teddy with only 1 MMAT is unstable, so it's good that OW pulls all the 10 MMATs for them.

Did you donwload the new CEP too?
Oh, is it ready? I didn't know! Thanks! *off to download*

EDIT:
I've created recolour packages for *all* the kitchen counters, and almost all of them are correctly made.
The only one that still has problems is the Club Room Countertop (counterClub): I can't understand why, but in the recolour package are included also the 8 MMATs for the Chiclettina Fjord (counterLoft)... :confused:

Numenor

21st Jan 2005, 05:58 PM

Oh! I've become an "Inventor"! LOL! :D Sounds like "Mad Scientist" doesn't it?
Delphy is great...

Numenor

21st Jan 2005, 10:50 PM

QUAXI:

I've found another "exceptional exception".
The "Independent Expressions, Inc., Big Entrance Shop Window" (windowcommercialplateglass_cres, GroupID 0x7F267FDF) has two subsets: the overlay (the glass) and the frame; the frame borrows the texture from the "main" window ("Independent Expressions Inc., Non-Reflective Window", doortwotilewidecommercialplateglass_cres, GroupID 0x7FB36DAE), while the overlay has its own textures.

If I create a recolour package for the frame, SimPE correctly pulls the MMAT from the "main" object.
But if I create a recolour for the overlay, in the resulting package there are 6 files: SimPE adds also the MMAT+MATD+TXTR from the main window, while they shouldn't be pulled because the overlay *doesn't* borrow the texture from it.

Quaxi

22nd Jan 2005, 02:04 AM

I didn't have the time to look at this tonight, but i have release the new SimPE anyway, so this will be the topic for the next Update.

jacktoon

22nd Jan 2005, 02:23 AM

Look everybody loves you, me included but nobody cares about freaking objects, OK? we want body meshes yes?...... I repeat love you

Numenor

22nd Jan 2005, 11:38 AM

JACKTOON:
I'm so glad that you love Quaxi, but don't you think it's a bit off topic here? There are numerous threads about mesh exporting/modifying/importing, and a lot af people are working on this. It doesn't seem to me that "nobody cares about freaking objects", OK?

QUAXI:
The new OW is *way* much faster! Great! :D

Quaxi

22nd Jan 2005, 01:26 PM

@jacktoon:
3 out of 6 major changes in the last Release were for the Meshes Team. It is not like I only work on one aspect of SimPE at a time. But Numenor is right, this IS the wrong Thread. And even with Meshes, recolors will still be a very Important Part!

@Numenor:
Thanks :D
I used it for one of the single Beds, which had some 20 Textures and 40 lifos in the Clone, and it took really long, s that is the tradeoff, it may be faster for most of the objects, but some get to take way longer than they did before :)

Numenor

22nd Jan 2005, 08:30 PM

I was trying and fix an issue with some counters that get the "white texture with red cross" when a sink is put on them.
The only way I could find has been adding the hash number in front of the texture references in the MATD; I knew that this would mean that the package couldn't be renamed any more.
But this is not true! I renamed the "hashed" packages, and the recolours still appear in the catalog!
So, why did we choose to remove the hash in the MATD references? If I remember well, Pinhead was the first to state that the packages with the hashed references couldn't be renamed...

Quaxi

22nd Jan 2005, 08:35 PM

Hm? I can't rename them when the Hash is in, but I can rename them without the Hash.
Btw. TSR had Problems too when they renamed the Recolors during upload. maybe it is only a problem, when you rename them BEFORE the game first read the package File?

But if there are Problems with Texture, the come back into the references. Cause the renaming Problem doesn't matter to most of the People :D

Numenor

22nd Jan 2005, 10:08 PM

I've renamed the package both before starting the game for the first time, and after having run the game once: I had no flashing blue textures, nor other issues. I've tried this with the Chez Moi counter and a coffee table...
I know that some users had problems renaming the packages, so should we think that some objects can't be renamed and other can? What objects have you tested?

Quaxi

22nd Jan 2005, 10:19 PM

The Daisy Painting, the Grandfather Clock (but this was a clone), Gothic Stair, the most Expensice Fireplace, the square table and one of the chairs. All turned out to be flashing blue after i changed the Names. But I allways tried this before loading them for the first time in the game.

Quaxi

22nd Jan 2005, 10:51 PM

Numenor

22nd Jan 2005, 11:38 PM

I think i found the issue with the counterloft Parts. SimPE did also allow Cres References in the MMAT Files, that belong to subsets the users did not select. the counterloft parts belong to the wallshadow stuff, so it was pulling the loft textures.

The attached OW will now only pull them if you selected wallshadow. And the Hashes are back :D

Oh! I'd never get to find it by myself...
Anyway, why on earth did they enabled Design Mode for the wallshadow?
And only for the Club and the Loft counters...!
Mmmmh... I wonder what would happen if I'd try and create a recolour package for the wallshadow...
Oh, I know... there are no MMATs for it, so the package would be empy, and anyway there would be no way to actually apply the recolour to the counter.

Oh, well... I'd better go and test the new OW, instead of asking myself silly questions! :)

EDIT:
I've created two recolours for the Daisy painting; I've renamed one of them before starting the game; both appear correctly in the game.
Then I've shut off the game and I've renamed the second package: both paintings are still correctly rendered.
Maybe the flashing blue texture was due to the hash *and* another cause that you have removed in one of the hundreds of updates...

Numenor

23rd Jan 2005, 09:52 AM

QUAXI:

Just a little info I gathered browsing the thumbnails packages...

Your "Picture Wrapper" currently handles only the FileType 0xAC2950C1 ("Thumbnail"), but it's perfect to decode the following filetypes as well:

0x4D533EDD Neighborhood objects (currently: "JPEG image")
0xAC2950C1 "Buy mode" Objects
0x2C30E040 Fence Arch
0x2C43CBD4 Foundations and pool
0x2C488BCA Dormers
0x8C31125E Walls
0x8C311262 Floors
0xCC30CDF8 Fences
0xCC44B5EC Modular Stairs
0xCC489E46 Roofs
0xCC48C51F Chimneys
0xAC2950C1 Ground coverings

Quaxi

24th Jan 2005, 12:45 PM

Thak you :) I will update this.

I just got an eMail about problems with recolors of trees. They sem to work in the Lot, but flash in the Neighborhood View. i didn't test this yet, but will do tonight.

Numenor

24th Jan 2005, 12:49 PM

No need to test that: it's a Known Issue, as clearly stated in the CEP front page.
When I'll find the time (and the inclination... :)) to study how the LOD works, I'll fix this.
Anyway, they shouldn't have emailed or PMed you about this. That's what the forums are made for! :)

Quaxi

24th Jan 2005, 01:37 PM

OMG, its in the CEP Thread? Shame on me!!!!

Numenor

24th Jan 2005, 02:21 PM

OMG, its in the CEP Thread? Shame on me!!!!

Oh, no, the critique wasn't addressed to you! The user that emailed you is to blame! Sorry if I wasn't clear enough :):):)

Numenor

27th Jan 2005, 09:59 AM

RGiles

27th Jan 2005, 10:01 AM

I blame numenor. He's always hated that toy oven and is out to get it.

Edit: Numenor, I made a tin roof to go with the trashed collection ;)

RG

Numenor

27th Jan 2005, 10:40 AM

Wonderful! I tried to do so, I extracted all the files and created the package... and then I gave up because I couldn't create a nice texture! My painting skills are at a Primary school level... :)

*off to download the trashed roof*

EDIT:
What have you done about the GUID in those roofs (rooves?), have you registered them as new object GUIDs? Are they a hash number?

RGiles

27th Jan 2005, 12:06 PM

They are a hash number. I tested with floors and walls... the do not use the same GUID set as objects. You can give them the same GUID as an existing object without conflict. I don't know what formula Maxis is using to get the Instance number for the XML file or the GUID. But in may case, both are simply based on the file name using the hash generator.

RG

Numenor

27th Jan 2005, 01:53 PM

Quaxi

28th Jan 2005, 01:13 AM

Quaxi, seems that the latest version (or versions?) of SimPE creates an empty package when recolouring the Rip. Co. Toy Oven (GroupID 7FF8BDC6).
I've checked, and there's nothing wrong with this object, there are no differences with the other recolourable objects, so I don't understand why this happens.

You did request that the Oven should never be recolorable with OW, so i respected that and excluded it. :D

No seriously. I found the Problem, and fixed it. The CRES name, stored in the Text list 0x85 already had the addition "_cres", which it usually does not have. So OW added it a second time and was unable to find MMATs referencing it.

Quaxi

1st Feb 2005, 08:39 PM

Do you think it would be helpfull if you were able to select the Color OW will pull when creating a Recolor?

WDS BriAnna

1st Feb 2005, 08:54 PM

Do you think it would be helpfull if you were able to select the Color OW will pull when creating a Recolor?

I doubt you're talking to me, but I'm going to pretend you are and say "Yes!!!!"

When recoloring it's easiest to work with something without a pattern on it, or something similar in brightness to what you want in the end, and I've had at least a dozen people ask me so far how to make OW pick a different Maxis texture to work from. I've had to point them to the pinhead tutorial so they can look through the lifos for the one they want. It's a pain. Being able to pick the texture pulled would be of HUGE benefit and all recolorers would love you forever. (Alright, we already do: but we'd love you more forever.) :D

Incidentally, while you're busy suggesting my number one most-wanted improvement, I'll mention my second: could the filepicker list for OW sort by the word after the guid and colon as an option? So, for example, Dynasty Dining Chair (7F9AEFDA: Chair_Dining_CentralAsian) would be with other chairs? Going in the game to see what Maxis called something is a step I'd rather skip, and scrolling one by one through the list to look at thumbnails is time-consuming as well. Someone made screenshots of what everything is called, but this would be better. :)

Quaxi

1st Feb 2005, 09:15 PM

You don't need Pinheads Tutorial to collect all available TXTR and LIFO Files for a Recolor.

Just create a Clone of the Object you want to recolor. It will contain the LIFO Files of all available Color Options for that Object. Just Export the one you want and edit it.
Now create the Recolor and import the Texture you previously edited.

So you see, it is not really complicated to get the diffrent color Options. The question is, is it worth the effort?

WDS BriAnna

1st Feb 2005, 09:22 PM

Your effort to add the choice functionality? I can't say. I don't know how hard that would be for you. I just know it would be extremely appreciated by many, many people. (Even the clone way is time consuming - you have to go back and delete your extra package file and all, best to have it built in.)

RGiles

1st Feb 2005, 10:07 PM

OK, thanks for the info.
BTW, in my tests, in the XML file I've used Hex values (with the 0x prefix), instead of decimal ones; and the roof still appears in the catalog and works fine.
It's much more readable this way, don't you think so?
It's much more readable, but may mot remain compatible for all we know. I don't think it's a very good idea to start changing this without Maxis doing it first. I'm also not convinced that the way I'm doing them right now is going to be compatible with University, so I'm not in a big hurry to make a tutorial.

RG

RGiles

1st Feb 2005, 10:08 PM

So you see, it is not really complicated to get the diffrent color Options. The question is, is it worth the effort?
I think that is would be worth it, considering how often I have answered this question.

RG

Numenor

1st Feb 2005, 11:35 PM

could the filepicker list for OW sort by the word after the guid and colon as an option? So, for example, Dynasty Dining Chair (7F9AEFDA: Chair_Dining_CentralAsian) would be with other chairs? Going in the game to see what Maxis called something is a step I'd rather skip, and scrolling one by one through the list to look at thumbnails is time-consuming as well. Someone made screenshots of what everything is called, but this would be better. :)

QUAXI:
I'd like this, too, as long as it's an option. Otherwise a million users would complaint about "OW not showing the objects any more".

Still about the OW listbox, I was wandering: is there a reason why typing in the search field the "space" isn't allowed at the end of the line? If I have to type "This and That" I have to type "Thisf", then go backwards with the cursor and insert a space. Anyway, if you implement the alternative sorting by Object_Name, this last problem is not important any more.

And if you could restore the default filetype to *.png in the texture import dialog, I'll be very grateful. But this is not very important, too.

The very important thing is the ##0x1C050000! thing... How's going about this?

RGiles

1st Feb 2005, 11:49 PM

I'd like this, too, as long as it's an option. Otherwise a million users would complaint about "OW not showing the objects any more".
Yes, agreed completely. I've often wished I could change the sort order on-the-fly.

As to the 0x1C500000 group... I'm very interested as well. We now know that many of the recolors available for download here and on other sites are going to break when university comes out. I'd very much like us to be able to make a post about making the recolors EP-safe.

RG

Quaxi

1st Feb 2005, 11:52 PM

Nothing so far. I was working on a new BHAH Plugin mostly. But i will setup SimPE to allways use that group for all Files in a clone/recolor.

I did change the png thing, and i will look at the sorting for the list, and i have to figure out the best way to implement the Color Selection.

EDIT:
Oh, and I fixed the Glass Problem, i think :D

Quaxi

2nd Feb 2005, 12:24 AM

Ok, here is what I did for Recolors:

TXMT and TXTR Files will use the Group ID 0x1c050000. And the forced Relocation ##0x1c050000! in the Filename.

The References in the TXMT will not use the forced Relocation Part.

The MMAT File will still have the private Group -1, and the name Reference will include the forced Relocation.

When cloning a new Object (which is the base for a remesh), I will use the Group ID 0x1c050000 for all RCOL based Files (Scenegraph?) and forced Relocations in all the Filenames. The References in SHPE, TXMT, TXTR... won't contain the forced Relocation.

All other Files will get the private Group -1

So let me know what you think about that.

Numenor

2nd Feb 2005, 12:38 AM

Everybody, come and see the new statue of Quaxi the Great! It's at the entrance of the new Quaxi Giant Stadium in Quaxiville! :D

I was exactly creating a test package like this. Have you seen the very last post by Tom? It should mean that the references into the MATD don't have to use the forced relocation, right?

Want to hear a funny thing? Tom made a typo in his post, stating that the new group is 0x1C500000, instead of the right one 0x1C050000.
I made the same mistake and created a recolor for the Goth stairs using the wrong group; but I inserted the forced relocation in all the MATD reference. The recolor worked, even when I renamed the package. But it shouldn't have worked: we should not be able to do a forced relocation on an arbitrary group... or not?

Numenor

2nd Feb 2005, 01:43 AM

QUAXI, I'm having a problem with SimPE. Since I don't know how to explain it, I'm attaching a test package (it's the cheap TV created by Todd). In its current state, it's completely functional: it can be bought in the catalog, has colour option enabled and is correctly rendered in game.

Open it in SimPE, go to the Resource Node, Reference tab. there are two references: a SHPE and a LGHT; the reference to the SHPE is correct and working.
Open the file selector and drag and drop the reference to the shape into the window (it will be the third reference in the list); now delete the shape reference from the first line.

The result should be almost identical to the original, right? The only difference is that the two lines are swapped, compared to the starting situation, but it should be irrelevant.

Now commit and save, and test the package: the TV still appears in the catalog, but it's invisible in the game. That's because the link from the CRES to the shape someway is lost. I can't understand why.

Mind that it's not a problem of position in the reference list: I tried to move the reference to the LGHT in the second line, and still the TV is invisible.

As a side note (just to let you know), the reference to the LGHT points to the local group 0xFFFFFFFF, though the LGHT file isn't included in the clone package. So, the correct reference shuld point to the 0x1C0532FA group, but since this is a hardcoded global group, the game finds the LGHT without problems.

RGiles

2nd Feb 2005, 03:44 AM

I made the same mistake and created a recolor for the Goth stairs using the wrong group; but I inserted the forced relocation in all the MATD reference. The recolor worked, even when I renamed the package. But it shouldn't have worked: we should not be able to do a forced relocation on an arbitrary group... or not?Yes, I think we should be able, which was why I disagreed with you when you commented on something needing to be hard-coded before we could start using the new group. I believe forced relocation would work for any group. What Tom's given us is Maxis' word that they'll leave a particular group entirely to fan-made content. But I believe with forced relocation, just any group will do the trick.

Quaxi,
As I mentioned earlier, many of the existing recolors are not going to work when University is installed. Would it be possible to write a plugin to SimPE that will do nothing more than convert a given recolor package's TGI and naming conventions to fit the new standard? The old packages will use several different schemes since first Pinhead's tutorial and later OW have gone through many changes.

RG

Numenor

2nd Feb 2005, 09:05 AM

RGiles, I think that we are confusing two different things:
1) the "forced relocation" means (I think) that the game will map that resource into its internal database not by its groupID (hash on the filename if the GroupID is -1), but in the group stated in the ##123! hash. The forced relocation is made by adding the ## thing in front of the filenames, not necessarily in front of the file references, too; adding the hash in front of the reference forces again the game to search for that resource into the forced group, and not into the ordinary "search path". I'm sure, by now, that the game, when searching for a resource, will look, in turn, into the following groups (in this order): "forced" group (if any), "hash" group (if any), object group (the groupID for original Maxis objects); global shenegraphic group (0x1C0532FA).

2) The "hardcoded" global groups are the ones included in the "search path" stated above; not every group can be a "hardcoded global" one.

So, you were right: the new 0x1C050000 group is already active as a hardcoded global group, but not the 0x1C050000: my staircase based on the wrong group worked fine only with the forced relocation in the references, too; while it's not needed when using the correct 0x1C050000 group.

EDIT:
The new 0x1C050000 group is definitely a hardcoded global one: the staircase works fine even if *no hashes at all* are used into filenames or references. With no other group then the standard 0x1C0532FA I could achieve such a result.
So, forcing relocation for files into the 0x1C050000 seems not necessary; Tom advised to do it to be absolutely sure that any possible conflict will be avoided. I agree with him: as long as we can rename our files, there's no reason to disattend such a directive.

Quaxi

2nd Feb 2005, 11:02 AM

Well, I think i already implemented the needed Algorithm for the Fix Thingy in when cloning an Object. So it should not be too hard to implement a Tool like that.

The biggest Problem is to confirm that those new Packages will work with the EP. Since the EP will be released 10 days latere here in germany (and i think in Italy too?), most of the initial Testing will be something the US Players have to make.

RGiles

2nd Feb 2005, 11:10 AM

So, you were right: the new 0x1C050000 group is already active as a hardcoded global group, but not the 0x1C050000: my staircase based on the wrong group worked fine only with the forced relocation in the references, too; while it's not needed when using the correct 0x1C050000 group.
Ah, I understand. I am a little unclear in that case why we need the forced relocation at all, but I will blindly trust that it's just for future compatibility. Where I did use the forced relocation ## in the references, it does work and the file can still be renamed. I am wondering which is preferred... with the hash in references, or without.

Quaxi, you can be sure that we will test it to pieces as soon as we're able. :D

RG

Quaxi

2nd Feb 2005, 11:14 AM

I was hoping to hear that :D

Numenor

2nd Feb 2005, 12:04 PM

RG, I think that the hashes in the references are read by the game only if there is some problem in locating files in the "search path"; so, I suppose that the game finds the files before having to rely on the hash. But if the package is incomplete, or has somo problem, that's when the hashed reference become important; so, I definitely suggest to adhere to Tom's suggestion and *put* the hash in the reference, too.

QUAXI: when you have a moment, would you please take a look at the problem I had while editing the Resource Node? (Read this post (http://forums.modthesims2.com/showthread.php?p=204486#post204486))

Quaxi

2nd Feb 2005, 02:49 PM

Sure! I will do it tonight :)

Numenor

2nd Feb 2005, 10:50 PM

Quaxi, another problem to report:
I have cloned the "Candy Coated Sofa" (GroupID 0x7F6ACBC2) and in the resulting package I've found, along with the right files, also all the files for the "Lap of Luxury Sofa" (GroupID 0x7F847023). This happens whether I check the "Use RCOL relations" or not (Hidden mode OFF).
Moreover, even if I uncheck the "Set Private GroupID" option, all the non-RCOL files still have groupID -1.

Quaxi

2nd Feb 2005, 11:14 PM

Firs things first. I tried to alter the Clone utility to use the Group 0x1c050000. And something goes wrong. I looked at it for some hours, so maybe some of you will find the Problem(s).

Quaxi

3rd Feb 2005, 01:28 AM

Ok, I traced the Problem down. I can change anything but the CRES Filename.

As soon as I change it from Paintingsquaredaisy_cres to quaxi_cres, the Object won't load in the Game.

I change the cres Reference in tne Text List 0x85 andd the Material Override. Did I miss a spot?

Numenor

3rd Feb 2005, 10:06 AM

No, I turned your package inside out and I've found only the problem about the CRES name in the cObject tab (and the "Description" in the MATDs, but this should be irrelevant).
The object doesn't appear in the game, no matter how hard I try. Maybe the 0x1C050000 group is not suitable for other RCOL files then MATD and TXTR? It sounds absurd...
Until now, I've tested the new group only with recolours (including the Goth stairs) and everything worked fine.

EDIT:
Oh, you have changed your original package; now only TXTR, MATD and CRES are in the new group...
But the reference inside the CRES still points to a SHPE in the 0x1c050000 group!

Quaxi

3rd Feb 2005, 11:36 AM

Yes, cause this is the way the Snowman works. The SHPE Files are in Group 0xffffffff, but the CRES still points to them with the Global Group 0x1C0532FA.

I think this is something to ask Tom :)

Numenor

3rd Feb 2005, 01:34 PM

I've found something important, maybe: try adding the ##0x1C050000! into the TextList 0x85.

EDIT:

OK, my test package will work fine (and can be renamed) when:

1) all the RCOL files are in group 0x1c050000, all the other files in group -1;
2) the forced relocation (##0x1c050000!) is used for:
--a) all the filenames of the RCOL files;
--b) all the references contained in non-RCOL files (Text List 0x85 and MMAT, both for the CRES and for the MATD reference)
--c) (optional) in the reference to the default MATD into the SHPE ("Parts" tab): this is not strictly necessary, because this "default" MATD are used only if any other texture reference is missing; but if something goes wrong (the tsDesignModeEnabled block isn't correct, the MMATs are all set to "False" or any other problem), the game won't find the default MATD and will show a flashing blue texture.

The forced relocation seems unnecessary into the texture reference of the MATDs (but anyway it doesn't prevent the package to be renamed).
It is not needed also [deleted] and in the "Filename" fields located in the cObjectGraphNode tabs (both for the CRES and the GMND).

All the rules above apply to the recolour packages, as well; but the relocation in the CRES reference ot the MMAT is not necessary (???).

Quaxi

3rd Feb 2005, 03:44 PM

I tried that before and it didn't work. There probably was a second error when i tried. Stupid Quaxi :D

Anyway, thanks Numenor for looking at it. I would never have tried that forced Relocation thing again in the Text Resource. :)

Numenor

3rd Feb 2005, 03:53 PM

QUAXI:
Correction: the relocation *is needed* into the "Item" tab of the SHPE (the reference to the GMND)

RGiles

3rd Feb 2005, 04:14 PM

And in short, best to leave the forced relocation on always. Files will always work with it on, but even those that currently work with it off may not in a later incarnation of the game core.

Agree?

RG

Numenor

3rd Feb 2005, 04:21 PM

Basically, yes. I don't know how difficult can be for Quaxi put it into the SHPE ("Parts" tab)

Quaxi

3rd Feb 2005, 06:44 PM

Hm, didn't Tom suggest to NOT use the forced Relocation in the reference? Which Object didn't work without relocation in the SHPE File?

Numenor

3rd Feb 2005, 06:54 PM

I've made my tests on a cloned and re-meshed sofa by Chriko: i used it because I know it very well and because I still couldn't manage to let "The Lone Quaxi" appear in the game with a not flashing texture :)
Anyway, in both the sofa and your clone, removing the relocation from the reference to the GMND into the SHPE ("Items" tab), caused the object to disappear.

EDIT:

I've read again Tom's post, and he simply says that
Just follow the golden rule and don't reference things using the hash of the filename anymore..
I couldn't find any warning about not using the forced relocation into the references.
My question is: WHY is it necessary to use the relocation in the references if the 0x1c050000 group is a hardcoded global group? The game should "map" all the RCOL files in that group by their filename, and when it finds a reference to an RCOL file, it should go and search it in all the global groups, including the new one.
Actually, the game does it, but (as far as I could see with my eyes) only for the texture references into the MATDs. My recolour for the Goth stairs worked well. Seems that the game's behaviour is different when dealing with other RCOL files...

Quaxi

3rd Feb 2005, 07:19 PM

Ok, here is the first version of the new OW. I just created a Daisy Painting and it did show up in the Game. Only had to get new GUID after the clone and that's it.

So could you please have a look at the OW and the resulting packages?

EDIT:
Ok, diffrent Version. You will notice that the "Fix Integrity" Option was moved to the Plugins menu. This Plugin should now "correct" old Packages.

EDIT2:
Ok, fixed some Bugs, not all yet, but some of them :D

Numenor

3rd Feb 2005, 10:05 PM

Man, you are fast! Let me finish testing the previous version, before releasing a new one! :D

Does the "Fix Integrity" do something new? Or it just fixes the TGI for all the RCOL files as before?

Quaxi

3rd Feb 2005, 10:12 PM

It does everything the Fix Options in the Clone Dialog do. Setting the Groups to 0xffffffff/0x1c050000, assigning a forced Relocation, changing the names (if wanted)...

Numenor

3rd Feb 2005, 10:22 PM

Oh! So I can try and "fix" some badly created re-meshed objects that I downloaded from the Beta forum...

EDIT:
What can I say... It's a dream come true!
Everything in the package is exactly how it should be... with just a couple of clicks! People will soon forget how much work there's behind such a well structured package...
But at least I will not find anymore on the forums packages so badly created that basically conflicted with every other object of the game :)

Just a little note about the "cleaning" function (since you were so kind to credit me for having suggested it, I'd like it to be perfect :D): I've cloned the Tulip Lamp (Group 0x7FE4CAFD), and there are many "useless" MMATs referring to MATD not included in the package (but the MATD references are relocated, so the game would never find them: I had to manually delete all those MMATs).

EDIT AGAIN:
Another little issue.
I've cloned a package, renaming all the RCOL files. Then I've selected "Fix Integrity and I've renamed a TXTR: the TXTR filename *wasn't* changed, while the reference into the related MATD was.
Moreover, if i call the Fix Integrity for a package that was already hashed, and in the rename listbox I click "Update", all the names in the list are badly renamed (something like "NewName_##0x1c050000!OldName_..."), but then the files aren't renamed, and the refences are in the form "OldName_##01c050000!OldName_...".

Quaxi

3rd Feb 2005, 11:30 PM

Well, you are not allowed to do manual change so far. At the moment i just "Replaces" names, it does NOT rebuild the Scenegraph Chain. It is only supposed to work for existing and working packages so far!

Anyway, the hash thing is a real Problem! I will fix that.

EDIT:
Sorry, i got your Post wrong, now I understand :D

Quaxi

4th Feb 2005, 12:38 AM

Please have a look at the above attachment again, it contains a new OW that should fix the Problems you described

Numenor

4th Feb 2005, 08:08 AM

QUAXI:
I'm sorry but I wasn't online when you posted the attachment (if you ever posted it... I see no attachments and your message wasn't edited).
Would you pleaase post it again?

EDIT:
I took a look at the packages that you posted on the development forum and I noticed that the SHPE has a strange name:
##0x1c050000!paintingsquaredaisy__(hash)_paintingsquaredaisy__(hash)_shpe

I checked: this happens in every clone package, either you choose a custom name for the RCOL files or leave the default one.
Obviously, this is harmless, since the SHPE filename is not used as a reference anywhere.

Quaxi

4th Feb 2005, 11:39 AM

The Attachment ist in Post 1119 :)

About the SHPE Name. The Renaming tool works quite simple, it just replaces the originla modelName (like paintingsquaredaisy) with the new name (which by default would be paintingsquaredaisy_hash).

Since the SHPE Files are build like modelname_modelname_shpe, the hash is put in twice. Which leads me to another point. The cShapeRefNode in the CRES File. Looks like the cObject GraphNode is allways set to the string between the first modelname and the _shpe Part, so maybe this needs to be changed too?

MaxoidTom

4th Feb 2005, 11:56 AM

You guys doing alright?

As I mentioned in my other posts, by default, if an external reference to a resource by name is not preceded by the ##group_id! prefix, then it automatically defaults to searching for the resource in the global scenegraph group id namespace. You guys should use ##0x1c050000!resource_name in these cases to put it in the global namespace we agreed upon. That way you are guaranteed not to conflict with any Maxis shipping content. We also avoid the nasty problem where we have group id collisions where the group id is based on the hash of the filename. Remember that all these references by name require that the names be unique within their group id namespace.

You should only really have to do this forced relocation for materials and textures--not shapes or geometry. That is because shapes can bind external materials to geometry subsets (design mode anyone?).

Numenor

4th Feb 2005, 12:49 PM

You should only really have to do this forced relocation for materials and textures--not shapes or geometry. That is because shapes can bind external materials to geometry subsets (design mode anyone?).

Yes, usually shapes refer to other materials then the "standard" visible ones: wall shadows, groud shadows, guob (can someone please explain me what a "guob" is? :)); currently, in our packages are included all of the above mentioned materials and textures, because we are trying to modify also the shadows cast by the new objects (actually, we couldn't do this, yet: the new objects still cast the original shadow...).
Therefore, all the materials referenced in the Shape should be included in the custom package, and relocated in the 0x1c050000 group.

But maybe I've misunderstood your post.
If you are referring to a custom object that "borrows" the materials and textures from an original Maxis object (i.e. has a tsMaterialsMeshName block in the Geometry Node), then should be simple: we don't use the ##0x1c050000! relocation prefix into that block, so that the game will search for the external materials in the global 0x1c0532fa group. I have successfully applied thins "linking" procedure to custom objects in the Local Group 0xFFFFFFFF, and it works.

For "normal" Design Mode, when no textures are "borrowed" from external objects, the situation is even simpler: all the materials and textures listed in the Shape are included in the package (since they are the "default" materials); any alternative colour is provided via additional "recolour packages", all relocated to the 0x1c050000 group.

We are trying to relocate all the shenegraphic files into the 0x1c050000 group, because we feel that this is the most "linear" way (we basically try to do what Maxis does); moreover, the forced relocation based on filename hash (using group 0xFFFFFFFF) prevent the packages to be renamed; we are trying to avoid this problem.

I asked you about the possible conflicts between different file types (in the other thread) because I didn't want to "overcrowd" the 0x1c050000 group; but since you confirmed that no conflict it's possible between different file types, there's no reason (but correct me if I'm wrong) to keep all the shenegraphic files other then materials and textures in the local group 0xffffffff.

Quaxi

4th Feb 2005, 01:22 PM

Numenor

4th Feb 2005, 03:52 PM

QUAXI:
My report about the new OW.
Everything seems to work fine; the cloned objects appear correctly in the game, even if the packages are renamed; and they can be recoloured correctly using OW.
The new little translucent windows are very beautiful, and useful too (the user now will know that SimPE is working...:)). The only problem about the windows is that it should *close* from the moment the Shenegraph Rename window appears until the Save dialog closes.

I noticed that in the cloned packages still there are the useless MMATs, and I've noticed that since we use the forced relocation, all the usless MMATs lead to a "flashing blue" recolour in the catalog.
I don't know how to instruct SimPE in order to choose which MMATs should be kept and which should be deleted. What I do manually is deleting all the MMATs that refer to MATD not included in the package.

Quaxi

4th Feb 2005, 04:01 PM

I don't know how to instruct SimPE in order to choose which MMATs should be kept and which should be deleted. What I do manually is deleting all the MMATs that refer to MATD not included in the package.

Actually that's what I told SimPE to do :D I'll check it again.

Btw. You can deactivate the Waitingscreen in the Options Dialog.

Numenor

4th Feb 2005, 05:20 PM

No, I'll never deactivate it, it's so cute!
But when I have to rename/save, it stays in front of the windows I need to interact with...

Quaxi

4th Feb 2005, 05:27 PM

I already fixed that. it was the very first test of the new Waitingscreen.

WDS BriAnna

4th Feb 2005, 05:48 PM

Interrupting the "important guys" thread for a request.

Hey, Quaxi! Can you (if you ever get time) make a clothing workshop? It would really just need to take a bodyshop package and grab the cres and shape mentioned in the 3IDR (and the gmnd and gmdc referenced by them) add them to the package and rename them with hashes; then change the 3IDR to the new files. :) Oh, and have I mentioned how much I love you?

MaxoidTom

4th Feb 2005, 08:40 PM

Hm?

Please let me repeat this, in order to make sure I did understand it correct:

1. forced relocation on all Scenegraph Files Filename with ##0x1c050000!
2. Group id of all Scenegraph Files is 0x1c050000
3. All references to Scenegraph Files from none Scenegraph Files need the forced relocation.
4. For all References to TXMT and TXTR Files we add the forced relocation ##0x1c050000!
5. All Other References won't have the forced relocation.

This brings up the question, where is a reference to a Shape by Filename?

1.) if you want to be absolutely safe, then yes, force relocate all scenegraph file names. however, see #2.
2.) yes, you can do this as well, though this increases the likelihood of filename (and thusly instance id) conflicts within your (0x1c050000) assigned namespace. ideally you would have local group ids (0xffffffff) for most of your resources except the ones that have are referenced by resources outside of the package file.
3.) not sure what you mean by this, but yes, if there are external references to resources within the file, that reference will need the forced relocation.
4.) yes, if they are external references (which they most likely will be)

RGiles

5th Feb 2005, 07:07 AM

If we get confirmation that Quaxi's test file is working with University, and we have tested the new Fix Integrity plugin to the extent that we're confident it's working on recolors specifically... THEN when we're secure in that I will be recommending to Delphy that we move non-CEP recolors that have been updated to comply out of Beta and into Downloads. So of course I want to be quite certain that it is making correct packages.

To MaxiodTom,
Numenor and I have wondered whether the CEP will continue to work with the University EP. It will as long as Maxis has not made changes to any of the Geometric Nodes from the original game, only added new ones for University objects. Can you tell us whether any of the original Geometric Nodes (for objects props, specifically) have been updated? I can only suspect that the birthday cake would have had the Geom Node updated for the new life stage.

To Quaxi,
Attached is the 3IDR plugin with the commit button moved to a place so that the plugin can now actually be used for something other than looking at, and bless your heart for providing the source.

RG

Numenor

5th Feb 2005, 10:47 AM

RG, I think that Tom hasn't downloaded yet the test packages by Quaxi from the other thread, since there is only 1 view, and that one was me...
As for the CEP, I'm confident that no specific changes will be made to the existing GMNDs (at least, to the parts that we know what are they for :)). I think there is no reason for Maxis to change them (well, maybe they'll fix the GMND for the Colonial Bed and the Tulip lamp ;)).
And if Maxis will change/update GMNDs that weren't included in the CEP, like the birthday cake, it doesn't concern the CEP anyway.
By the way, I have cloned the birthday cake and rebuilt all its RCOL chain (all the subsets and MATD were renamed) in order to make it recolourable; I succeeded, but when the sim grabs a slice, the new slice is a different object, created on the fly, and therefore won't use any other material then the default one. It's the same problem I had for the phone handset, but at least the handset is created *once*, while the slices are a lot, and their "life" is very short... :)

RGiles

5th Feb 2005, 11:02 AM

I don't think Tom's looked at it yet either. :) But after he does and so on... for the sake of sanity on the site, I think we need to have EP-ready recolors not mixed in with those that aren't. So I'm thinking of that.

For the Geom Nodes, my concern is that they know a reason some might be updated that we do not. ;) I think it's unlikely, but if some will be updated, it will be helpful to know in advance.

I got the same result with the cake, which was what I expected in the first place. The separate slices that people take away are not the same object, so of course they are not recolored. I do not know whether we should include this in CEP or not... and at any rate I do expect that one may change with the EP (a different number of candles), so we shouldn't add it yet if at all. I tend to think we should not add it just because those 2 cake objects would force a rewrite of parts of OW, and it's just not worth Quaxi's effort.

Sorry if I'm sounding a bit off... my run-in with fleabay on that thread in the adult betas forum has me upset at the moment.

RG

Numenor

5th Feb 2005, 11:28 AM

Eheheh...! :) I don't know exactly what the problem is, but anyway your posts should be grouped in a sticky: they worth a million FAQs! :D

RGiles

5th Feb 2005, 11:38 AM

I don't know either. Fleas make me itch, I guess.

Oh, but that reminds me, I have not seen Deedee around in ages, but I saw her tutorial on the SimPE site last night. Quaxi, tell her thanks if you talk to her. :D Anyone who can open SimPE can follow that tutorial. And of course thank you Quaxi for making it so easy for us all to update these thousands of packages.

I still predict chaos ;) but this way it's easily fixed chaos.

RG

Numenor

5th Feb 2005, 02:26 PM

QUAXI:

[EDIT: OMG! I didn't realized that the v 015 was out! I made my tests with the last "unofficial" release...)

(Original post)
My testing results.
Since the new OW seems working fine for cloned packages, I've run some tests in converting user-made clones, in order to see if the new Fix Integrity is suitable.
In my tests I made the following:
1) If the user had already renamed the CRES, I've only hit OK (no "update");
2) if the CRES wasn't renamed, I've chosen an alternative name for it, the hit Update and OK.

Basically it worked for all the packages; actually, I had the best results with very badly created packages (like Todd's ones: he only creates a new mesh and doesn't alter in any way the RCOL chain, no matter how hard I tried to let him understand the risks involved). For other, better created packages, it worked, too; but I had to correct some mistakes that the creator made in his original package (these errors can't be corrected by SimPE, obviously).
Lastly, I checked the Fix Integrity with one of Exnem's packages; they are the best created packages ever seen: he hashed even the reference to the MATD inside the subsets blocks into the GMND! Unfortunately, those hashed reference should be removed manually, but anyway exnem's work is great...

My overall judgment about the "Fix Integrity" conversion ability is that it should work. Anyway, the best results can be achieved only re-creating the packages, importing the GMDC and correcting the reference to the subsets (and the GUID, too).
I don't know if the mesh creators will spend their time converting their packages... I think that the objects that fully comply with the new procedure should use a special logo/icon/name so that the users will know if the object is "safe".

EDIT:
The conversion procedure work for existing recolour packages, as well, as long as the CRES was originally renamed by the creator. SimPE in these cases doesn't put the relocation prefix in front of the cres reference, into the MMATs, but it doesn't prevent the recolour to show up correctly.
Obviously, if the CRES is renamed during the conversion, all the existing recolour packages cease to work.

MaxoidTom

5th Feb 2005, 06:15 PM

1.) if you want to be absolutely safe, then yes, force relocate all scenegraph file names. however, see #2.
2.) yes, you can do this as well, though this increases the likelihood of filename (and thusly instance id) conflicts within your (0x1c050000) assigned namespace. ideally you would have local group ids (0xffffffff) for most of your resources except the ones that have are referenced by resources outside of the package file.
3.) not sure what you mean by this, but yes, if there are external references to resources within the file, that reference will need the forced relocation.
4.) yes, if they are external references (which they most likely will be)

I may have misunderstood #1. Only references to the filenames should have forced relocations, not the actual filename. When the game creates a resource key from a by-name-reference, the relocation is stripped and the key is created from the remaining filename. Now, I'm not sure if this makes a difference from your POV, but I thought I should mention it.

MaxoidTom

5th Feb 2005, 06:18 PM

Numenor

5th Feb 2005, 10:13 PM

My apologies, I haven't been picking up your nomenclature that quickly. What is the CEP you are refering to? I haven't had a chance to test the example package in the University EP yet, but will try to do so on Tuesday. However, remember that anything in downloads takes precedence over shipping data--it doesn't matter if it is the base game or an EP.

"CEP" stands for "Colour Enable Packages". Maybe you don't remember well (but we remember how kind you were in helping us with that Old Grandfather Clock!); basically, the CEP enables colour options for almost all the objects that originally came in only one colour.
For each object, we have duplicated its Geometry Node(s), and added to them a tsDesignModeEnabled block, containing one or two subsets that we wanted to enable colour option for. Then we created, for each of those subsets, a suitable Material Override.
All the Geometry Nodes were grouped in one package located in the Downloads folder; we kept the original TGI for our custom Geometry Nodes, thus "overriding" the original ones.
All the Material Overrides were grouped in a package located in the Sims3D folder, assigning them to the Local group 0xFFFFFFFF.
So, RGiles and I were wondering: if some of the original Geometry Nodes will be changed with the EP (in order to give the objects a different appearance/function), our custom Geometry Nodes will continue overriding them, thus preventing the modified objects to work properly.
In other words, we'd like to know if for any reason you are planning to change the Geometry Nodes for the base game objects (we don't care about the new objects that will be shipped with the EP). We need to know that, especially if you specify that the files in the Downloads folder take precedence over the game files (previously, we thought that the newer files took precedence over the older ones).

As for the test packages, Quaxi has posted on the Internal Development forum, but anyway, here they are:
LINK (http://www.modthesims2.com/attachment.php?attachmentid=26172).

And since this is too an important subject to have misunderstandings, let me summarize again what we are doing with the 0x1c050000 group (I'll try and use a correct terminology :)).

1) All the scenegraphic files (not only materials and textures, but also Shapes, Geometry Nodes, etc...) are in the 0x1c050000 group *and* their filenames have the ##0x1c050000! prefix. This shouldn't increase the chances of conflicts, since you told me that a Shape can never conflict with a Texture.
2) All the other files are in the local group 0xFFFFFFFF.
3) As for the references to scenegraphic files, we currently are putting the ##0x1c050000! prefix in all of them (e.g., in the Material Definition we have the reference to the texture expressed like: "##0x1c050000!UniqueTextureName"; in the Material override we have as reference to the Material Definition: "##0x1c050000!UniqueMaterialName"; and so on). We think that sometimes (especially for references contained into scenegraphic files and pointing to another scenegraphic file) this forced relocation isn't necessary, but it won't hurt, since we can still rename the packages (this is important for us).
Note that Quaxi said something different about the references in his previous post; but the solution that we currently have adopted is to use the forced relocation on *all* the file references.

Please let us know if there's something wrong in our procedure.
Thank you again for all the time you spend giving an answer to all our doubts and questions.

RGiles

5th Feb 2005, 10:36 PM

To the best of my ability to test it, the new "Fix Integrity" tool is working perfectly with all types of simple recolor packages regardless of which format they originally used. Yay. Which is what you'd expect with such a small subset of files. :)

I'm going to test a few more... if I find no errors, I am feeling pretty uppity about moving simple recolors out of Beta after they've been updated. This would not apply to anything altering meshes, of course, or to CEP recolors.

Any disagreement here, before I say anything to the admins about this?

RG

Numenor

5th Feb 2005, 10:50 PM

So far, it's quite hard to understand what recolours are CEP or non-CEP, since some non-CEP objects now have an added CEP subset...
Even the creator of the package may not have a clear idea about its being a CEP or non-CEP one.
Anyway, we could wait until the EP is released; once verified that the CEP still is valid, then we can move all the recolours to Downloads. Just my thought.

Quaxi

6th Feb 2005, 03:42 PM

The logo thing is a good Idea. As soon as Tom had a chance to look at our packages, we can offer that logo. (Don't want to start with it yet, cause we don't know the new procedure is save :D)

And about the Fix thingy. I plan to extend the Fix Integrity to rebuild the complete Scenegraph Chain as far as that is possible. So as long as all needed Files are in a package, that Tool would generate a well formed File.

But it obviously can never be completley automatic. For example, the User has to decide wich TXTR Reference should be used in which TXMT File.

EDIT:
@RGiles:
No complaints from my side :)

RGiles

6th Feb 2005, 03:57 PM

It's doing an excellent job on objects with different material states. Yay! I'm very very happy with this. I can't thank you enough, Quaxi. There are so many thousands of files out there on so many sites, especially for recolors.

If Tom is not able to confirm for us whether any of the original Geometry Nodes are changed in the EP, I will do this: I'll extract them all to a folder, install the EP and extract them all again. Then I'll run a binary file comparison on the 2 sets. That should tell us which (if any) of the Geom Nodes in CEP we need to update for use with the EP. I hope there are none. If there are we are left with the question of whether we should have 2 versions of CEP available, which would suck. :P I'm going to pre-order though, so if you guys want any early testing done you can order me around. :D

RG

Quaxi

6th Feb 2005, 06:42 PM

I'm going to pre-order though, so if you guys want any early testing done you can order me around.

lol, that's gonna be fun :D

Anyway, check out this "little" logo for EP-Ready content

Numenor

6th Feb 2005, 08:17 PM

Nice icon! I like it very much! :)

MaxoidTom

7th Feb 2005, 07:33 PM

"CEP" stands for "Colour Enable Packages". Maybe you don't remember well (but we remember how kind you were in helping us with that Old Grandfather Clock!); basically, the CEP enables colour options for almost all the objects that originally came in only one colour.
For each object, we have duplicated its Geometry Node(s), and added to them a tsDesignModeEnabled block, containing one or two subsets that we wanted to enable colour option for. Then we created, for each of those subsets, a suitable Material Override.
All the Geometry Nodes were grouped in one package located in the Downloads folder; we kept the original TGI for our custom Geometry Nodes, thus "overriding" the original ones.
All the Material Overrides were grouped in a package located in the Sims3D folder, assigning them to the Local group 0xFFFFFFFF.
So, RGiles and I were wondering: if some of the original Geometry Nodes will be changed with the EP (in order to give the objects a different appearance/function), our custom Geometry Nodes will continue overriding them, thus preventing the modified objects to work properly.
In other words, we'd like to know if for any reason you are planning to change the Geometry Nodes for the base game objects (we don't care about the new objects that will be shipped with the EP). We need to know that, especially if you specify that the files in the Downloads folder take precedence over the game files (previously, we thought that the newer files took precedence over the older ones).

As for the test packages, Quaxi has posted on the Internal Development forum, but anyway, here they are:
LINK (http://www.modthesims2.com/attachment.php?attachmentid=26172).

I don't believe we changed any of the original Geometry Nodes. If we did, they probably would have the same instance ids, so your stuff would still take precedence. However, to be safe, you should probably do a sanity check when the EP comes out. Probably can do so by checking what resources are in the EP.

And since this is too an important subject to have misunderstandings, let me summarize again what we are doing with the 0x1c050000 group (I'll try and use a correct terminology :)).

1) All the scenegraphic files (not only materials and textures, but also Shapes, Geometry Nodes, etc...) are in the 0x1c050000 group *and* their filenames have the ##0x1c050000! prefix. This shouldn't increase the chances of conflicts, since you told me that a Shape can never conflict with a Texture.
2) All the other files are in the local group 0xFFFFFFFF.
3) As for the references to scenegraphic files, we currently are putting the ##0x1c050000! prefix in all of them (e.g., in the Material Definition we have the reference to the texture expressed like: "##0x1c050000!UniqueTextureName"; in the Material override we have as reference to the Material Definition: "##0x1c050000!UniqueMaterialName"; and so on). We think that sometimes (especially for references contained into scenegraphic files and pointing to another scenegraphic file) this forced relocation isn't necessary, but it won't hurt, since we can still rename the packages (this is important for us).
Note that Quaxi said something different about the references in his previous post; but the solution that we currently have adopted is to use the forced relocation on *all* the file references.

Please let us know if there's something wrong in our procedure.
Thank you again for all the time you spend giving an answer to all our doubts and questions.

1.) This should be fine. Again, at least from Maxis's perspective on data, the filenames probably shouldn't have the ##0x1c05000! prefix, but only references to the filenames should. However, if it works for you guys, you can probably just let it be. Also, as I stated previously, ideally any scenegraph resources that are not referenced externally would have a group id of 0xffffffff. This will decrease the chance that they conflict with other scenegraph resources of the same type within the 0x1c050000 group id namespace.
2.) Good!
3.) Excellent!

Numenor

7th Feb 2005, 09:17 PM

OK, wonderful! *heaves a sigh of relief* :)
As for the ##0x1c050000! prefix in the filenames, if you don't mind, we are going to keep it: maybe I haven't understood well what you meant, but in my tests removing that prefix prevent the game to find the materials (all the scenegraphic files other then Material Descriptions and Textures are correctly found).
Again, thank you very much for your valuable help.

WDS BriAnna

8th Feb 2005, 06:05 PM

Object workshop is changing the group on the light references in the cres, even though it doesn't export the light so that light doesn't exist.

Numenor

8th Feb 2005, 08:13 PM

Yes, I noticed this issue, too; I posted something about this... let me see... Here it is! Post # 1099 (http://forums.modthesims2.com/showthread.php?p=204486#post204486); I was referring to the old version of OW, but seems that the problem survived to the update...

WDS BriAnna

8th Feb 2005, 08:37 PM

Yes, I noticed this issue, too; I posted something about this... let me see... Here it is! Post # 1099 (http://forums.modthesims2.com/showthread.php?p=204486#post204486)

How'd I miss that? :lol:

Numenor

9th Feb 2005, 12:30 AM

QUAXI:
some users are reporting objects reverting to original colour when exiting and re-entering the lot.
Seems that deleting the forced relocation prefix from the CRES reference into the MMAT fixes the issue.

Quaxi

9th Feb 2005, 03:22 AM

Thanks Numenor :D
Proofs that it was a good thing to not release the batch Converter right away :)

Oh and about the light thingy, I hope that the next OW will be able to handle (=copy) them.

Btw, i have to new things coming up. First of all the "Wizards of SimPe" thingy, which will allow you to create recolors much more userfriendly.
And the Second thing is, that I can preview 3DMehses + Texture now, outside the Game, that should be a little help when creating Recolors/Remeshes, cause you don't have to fire up the game for each test :D

RGiles

9th Feb 2005, 07:29 AM

Quaxi, that'll be a HUGE help. That's a really big deal. Wow! Thank you so much.

Numenor

11th Feb 2005, 09:10 AM

QUAXI:

There is a problem in the way OW collects files from cloned objects when creating recolour packages.
Since my tests showed that the forced relocation should be removed from the modelName variable in the MMAT, I suggested in my tutorial to do the same; but OW now can't pull the MMATs any more (it can't find a matching CRES), and the resulting package is empty.

But even if I restore the forced relocation in the MMAT, OW pulls the MMAT and the MATD, but not the texture, and I really can't understand why.

I know that in this moment you're quite busy with the exam; when you have some minutes spare, please, check this problem.

I'm attaching a test package: I've checked it and its internal structure is perfect, and it works in game.
As said before, in the MMAT the forced relocation is currently removed, and the recolour package will be empty; if you restore the FR, the recolour package contains only MMATs and MATDs.

Quaxi

11th Feb 2005, 01:12 PM

I probably forgot SimPE to remove a forced relocation from a reference before looking for a File with a specific name.

I'll have a look at it tonight.

Numenor

11th Feb 2005, 03:40 PM

Quaxi, I can't find the words to say how beautiful, functional and easy to use is the new recolour wizard...! Great job, as usual... no, more then usual! :D

I tested it with some random objects and works like a charm.
Just a couple of notes (they are not "issues", some of them were probably made on purpose...):
1) For multi-part objects, it's not possible to select what part to recolour.
2) for the Club Room counter (counter club), still are pulled all the MMATs related to the Chiclettina Fjord (counter loft)...
3) when creating a recolour package for a bed other then the colonial double bed, in the package there are (in addition to the files for frame and bedding) also the files related to the Colonial double bed frame (only the bedding should be "borrowed" from the double bed, not the frame).

All the other objects, CEP and non-CEP, seem to work correctly.

RGiles

11th Feb 2005, 07:23 PM

I also got a chance to test the Wizard, and I was only going to mention not being able to select the part to recolor. But other than that it is just beautiful and really a breeze to use.

Thank you so much, Quaxi, and I hope your exams go well this month.

RG

Quaxi

11th Feb 2005, 07:33 PM

Well, I decided to leave the Part Selection as i wanted it as simple as can be. Do you think I sould bring that selection back as an additional Wizard Step?

About the other two Problems. WOS uses the same Engine as the OW, so if stuff doesn't work in the OW it won't work in the WOS either.

Numenor

11th Feb 2005, 08:59 PM

Yes, basically it was just a reminder... :)

As for the part selection, I think that we can leave WOS like it is now (if one wants to recolour a specific part, can still use the standard OW).
The only problem I can think of is for an object with a standard recolourable part and a secont "textureless" part (e.g. the frame and the glass of a window): the resulting package will contain a recoloured frame but the standard glass (in the catalog there will be two identical glasses). Maybe WOS should pull the MMAT and the MATD only if the TXTR exists (textureless recolours can only be made by OW).
And I have a suggestion for the "Save package" window: maybe it would be useful to have a file selector? I know that saving in the Download folder is the simplest way, but maybe you could implement a "Default" flag, like the Clean installer: unchecking the "Default" option will allow to access the file selector. Just a thought.

RGiles

12th Feb 2005, 07:40 AM

We've been encouraging people for the most part to keep their recolors in separate packages, even if they intend for them to work together. For instance when I did the gothic crib, some people wanted only the black frame and others wanted only the bedding. If they are in the same package, a person who wants only the frame may delete the bedding and unknowingly lose both. So for that reason, I think the Wizard should have the step for choose which material. Just an opinion. :)

There's a bug now with OW with multi-state objects, but only CEP ones. A multi-state object that had design mode enable by default creates the correct recolor package. However if we enable Design Mode for the multi-state object in CEP, the recolor package only contains files for one of the states. This was tested with 0.17 and 0.17c. That's a lot of lightning fast updates there :D

RG

Numenor

12th Feb 2005, 10:11 AM

Odd, I made some tests on multi-state objects and the packages were correct. Then I've read your post and made some more tests (v. 017c, standard OW, all CEP objects):
AquaPlus Shower Stall (CEP): only clean state
Clean Water shower system: OK, both states
Basically Bare Bulb: OK, both states
Prisoner of Azkalamp: OK, both states

So, it seems that the problem occurs only on certain objects.

EDIT:
The Lunatech "Lighten Up" Lighting Fixture has a bug in the CEP (my fault): the "bulb" subset is enabled but there are no suitable MMATs; therefore the package is empty. But the other subset is correctly enabled, and nevertheless OW pulls only the unlit state.

Quaxi

12th Feb 2005, 12:22 PM

Hm, the only thin I've changed since 0.15 is, that the Fix thingy doesn't assign the forced Relocation to the CRES Reference in the Material Override, so maybe we had this Problem before?

RGiles

12th Feb 2005, 12:43 PM

I had tested another lit/unit object and ... damn, why didn't I write that down? :P See how useful I am? I tried. It was another CEP item with lit and unlit states, and only one state showed up. Actually I tested 3 of them (including that auquplus shower) and all failed... so I thought it was all of them. :/

Maybe we did have the problem before and no one reported it, so we didn't notice.

Numenor

12th Feb 2005, 03:11 PM

Hm, the only thin I've changed since 0.15 is, that the Fix thingy doesn't assign the forced Relocation to the CRES Reference in the Material Override, so maybe we had this Problem before?

Maybe. Personally, I tested all the objects when the CEP was released, but not lately.
Anyway, I had no complaints so far in the CEP thread.
Probably, everyone is messing up with remeshed objects, at the moment... :)

Numenor

13th Feb 2005, 11:01 AM

QUAXI, a little reminder (again, I know you are busy right now...): OW still doesn't create correctly the recolour packages for EP-ready re-meshed objects, because in the latest version the hash in front of the CRES reference (in the MMAT) was removed, and therefore the CRES couldn't be located any more by OW.

In addition to this, I have to forward you a request that I had from some users about the GUID database: they would like to delete/rename the registered GUIDs (sometimes, a GUID is registered but then the object is abandoned: it *is* possible to reuse the GUID, but in the database it remains associated to the old object name, and this is quite confusing). Maybe editing the GUID names should be enabled at least on the site GUID page, if not into SimPE.

Quaxi

18th Feb 2005, 01:10 AM

I think i solved that Problem now with Release 0.18.

Numenor

19th Feb 2005, 11:35 AM

Quaxi, RGiles, I hate to open again a "solved" problem, but these words by MaxoidTom still hover into my mind:
You should only really have to do this forced relocation for materials and textures--not shapes or geometry. That is because shapes can bind external materials to geometry subsets (design mode anyone?).

Now, we've chosen to use the 0x1c050000 group for *all* the scenegraphic file, including Resource Node, Shape, Geometry Node and Geometry Data Container.
And the objects works fine, but... they still are not perfect.

Look at this example: I click on an object in the catalog and I don't select any of the colour options; as a result, the default material is selected (the black colour).
http://forums.modthesims2.com/attachment.php?attachmentid=34285.

I place the object in the game and select the "Design Tool": if I click on the object the game tells me that the object can't be recoloured.
http://forums.modthesims2.com/attachment.php?attachmentid=34286

But if I buy the object and soon I select one of the available colour options, then the object is recolourable in design mode.
http://forums.modthesims2.com/attachment.php?attachmentid=34288
http://forums.modthesims2.com/attachment.php?attachmentid=34287.

This problem won't occur if:
1) The Resource Node and the Shape (and optionally the two Geometry files) are in group 0xFFFFFFFF;
2) The filenames of the above files have the the standard hash ("7F"+ 24-bit hash over filename).
3) The references to the above files do not contain any hash (the references contained in the TextList 0x85 and in the Shape, "Items" tab).

Note: it is still possible to rename the packages.

I don't know... This is not a problem, the way SimPE currently creates the packages is good.
But I've understood better what Tom told us, and I wanted you to know this.

EDIT:
IMPORTANT ADDITION - The object works fine, and the package can be renamed, even if the filenames have no hash at all! The game itself will take care of creating an internal hash for them, as it does for all the files in the 0xFFFFFFFF group.
This is even simpler! We were led on the wrong way by studying the older Maxis add-on objects and the packages created by BodyShop, but seems that the game engine is more reliable then we thought before...
What are the implications of this discovery?

RGiles

19th Feb 2005, 10:29 PM

The more we have in the -1 group, the safer the packages are, so I this is helpful I think. However I still do not really understand why this would have anything to do with binding external materials. I think I'm misunderstanding the word external in this context.

RG

Numenor

19th Feb 2005, 10:40 PM

Maybe I'm wrong, but I think that a Shape in the -1 group can act as a trait d'union between a geometry in the same group and a material in the global group (thus, external to its own group). Does it make sense?

RGiles

19th Feb 2005, 10:45 PM

Ah, yes that makes sense. What I fail to understand is what made this error occur when all parts of tha package were in the 0x1c050000 group.

Numenor

20th Feb 2005, 12:15 AM

With SimPE v.017, the Resource Node was in group 0x1c050000, with the forced relocation in its filename; and in the Material Override, the reference to the Resource Node had the forced relocation, as well. For unknown (to me) reasons, the recolours were unstable.
Then I suggested to delete the forced relocation into the Material Override: actually, in this way we have broken the link between the MMAT and the CRES: if I don't select a rolour in the catalog (i.e. I don't select a Material Override), the game *doesn't use* the "true" MMAT, because it "doesn't belong" to the object's CRES; instead, the default material from the Shape is used. That's why the game won't let me recolour the object: that (default) recolour can't be linked to the "true" MMAT.
So, the question is: why the game can't link the reference to the CRES (in the MMAT) with the actual CRES? The answer, in my opinion, is: because, despite what Maxis told us about the 0x1c050000 group being a "hardcoded global" group, it is *not* as "global" as the standard 0x1C0532FA group... :)
Examining the Maxis add-on objects (the ones with colour options), you'll see that the CRES are in the global group, and the game has no problem with linking the MMATs to the CRES. But if you change all the GroupIDs from 1c0532fa to 1c050000, *many* internal links break up.

Quaxi

20th Feb 2005, 03:48 AM

Well, Tom told us the 0x1c050000 Group WILL BE a Global Group in the EP. So we can't say for sure if it still will be a Problem ehn the EP comes out.

About the -1 Group. Not using the force relocation is probbly forcing the game to start some failure procedure which is probably slower (just a guess), so i don't like that idea very much.
And using the old 0x7f hashes over the package name is depreciated by Maxis. So I kinda don't know if it would be a wise idea to use the again.

but i was thinking about the CRES references in the MMAt Files. Maybe the packages didn't get unstable because of the Hash in the References. maybe the referenced CRES Files do not work correct.
SimPE leaves the cShapeRef Block in the CRES File as it is, but it might need some changing. Maybe if it is correct, the Hash in the reference is ok and maybe the game again uses some backup Code when we don't have the hash in the reference. A Backup code that can work without the cShapeRef Block.

Numenor

20th Feb 2005, 09:39 AM

I've run so many tests, since Tom told us about the 0x1c050000 group, that now I don't remember well, but this new group is indeed different from the other groups; maybe you're right: with the new EP the functions of this group will be improved, but if so, will we need to change again our packages? We'd better leave the things as they are now, until the EP will come out; then we'll see with our own eyes what will happen :)

As for the -1 group, Tom explained that in any case the game remaps all the 0xffffffff files calculating the hash over the filename. In other words, a relocation is always done, but it can be forced putting a user-created hash in front of the internal filenames. I think that the game looks for the files using a system of "paths", like Windows: if the reference has the forced relocation, the game looks into the forced group; if not, it looks into the same group of the package, and then (if the file can't be found), in the global groups. If I'm right, there will be no slow-downs in searching the files: since there is no forced relocation in the reference, the first try of the game will be the right one.
And anyway, the problem affects only the buy-bode phase: once the object is placed into the lot, the game creates its own references to find the right files.

What you say about the cShapeRef node (it's the "Reference" tab in the CRES, right?) proves my theory: in the Maxis add-on objects, the Shapes are in the -1 group, but the Reference tab reports them in Group 0x1C532FA; nevertheless, the game find the shape, because it first looks into the group assigned to the package, and then in the global group.
Anyway, this problem about the reference to the shape can't cause the unstbility of the recolour: if the link to shape breaks up, the object is invisible, not simply showed in its default colour.

Sorry for my long posts, but you know... I'm a Theorist, now :D

EDIT:
Forget the last part: the cShapeRefNode is *not* the "reference" tab... :err: :p

Quaxi

21st Feb 2005, 12:16 AM

Ok, i had a look at the clean/dirty problem.

I used the "AquaPlus Shower Stall" as my testing Object, and found out that the MMAT Files for the clean/dirty states do not have the same family Hash.
This is basically the Problem. Cause SimPE (and i think the game as well) selects alternative states based on the Family hash in the MMAT Files.

MaxoidTom

21st Feb 2005, 07:43 AM

So I think there may be some misunderstanding as to what I said about the reserved global group id of 0x1C050000 as opposed to the global group id of 0x1C532FA. By default, the game will, if it does not see a reference to a resource with the forced group relocation, will set the group to 0x1C532FA (for scenegraph resources). What I suggested was for you guys to one global, static, group id of 0x1C050000 for the forced relocation. This is still a global group id, but there still needs to be forced relocations on your guys' side.

I did take a look and tried to see if I could make the code fallback on either our global scenegraph group id (0x1C532FA) and then the one we reserved for you (0x1C050000), but the place where it creates a key from the resource name is so far removed from where it actually loads the resources in some instances did not make it too feasible.

Sorry if there was a misunderstanding. The group is still global, as it can be externally referenced without fear of being broken (which local group ids could not be depended on for this). If you need any help testing stuff out on the University EP code, just let me know.

Numenor

21st Feb 2005, 02:19 PM

What I suggested was for you guys to one global, static, group id of 0x1C050000 for the forced relocation. This is still a global group id, but there still needs to be forced relocations on your guys' side.

Tom, thanks for the confirmation: that's exactly what I meant saying that the 0x1c050000 group was "not as global as the 0x1c0532fa group"; I know, the terminology wasn't correct, but sometime I forget that you read these posts, too... :)

I did take a look and tried to see if I could make the code fallback on either our global scenegraph group id (0x1C532FA) and then the one we reserved for you (0x1C050000), but the place where it creates a key from the resource name is so far removed from where it actually loads the resources in some instances did not make it too feasible.
Probably this would not be necessary, anyway. I've found a way (different than the one currently used) that seems to better comply with all your suggestions, including the first ones you gave us on the Internal Development thread.
The package structure that I'm currently testing (and I need your advice on this) complies with the following rules:

1) Only the materials (Material Definitions and Textures) and the Geometry Nodes are in the 0x1c050000 group; their filenames *don't have* the ##0x1c050000! prefix (it would be useless: they already have the global GroupID).
2) All the other files, including Resource Node, Shape and Geometry Data Container are in the local group (0xFFFFFFFF); their filenames, too, don't have the forced relocation prefix (the game will choose freely a GroupID for them).
3) The references to the Material Definitions and to the Geometry Node contained either in the Shape and in the Material Override *have* the ##0x1c050000! prefix (this is necessary because the shape and the Material Override are in the local group: this is, I think, what you mean with "external reference to the global group").
4) All the other internal references *have not* the ##0x1c050000! prefix (e.g. the reference to the Resource Node contained into the Material Override doesn't need the forced relocation, since both files are in the same local group; in the same way, the reference to the textures contained into the Material Definitions don't need it, because both textures and Material Definitions are in the same global group).

If you need any help testing stuff out on the University EP code, just let me know.
Yes, please, I hope you can test the attached objects. In the zip there are three packages (all of them were built using the rules stated above); the objects are:
1) a large floor rug ("master");
2) a recolour for the large floor rug;
3) a small floor rug ("slave") that "borrows" the textures from the "master" large rug (I've inserted a tsMaterialsMeshName block into the Geometry Node pointing to the "master" Geometry Node: that's why the Geometry Nodes must be in the global group).
In my game these objects work fine: I can choose between the default colour and the the additional recolour, both for the large and the small rug.

I really hope that you'll find these objects compliant to the EP specs: the method we are currently using for creating the packages leads to good results, but the functionality of these packages, especially in design mode, isn't perfect. On the contrary, the new packages that I'm asking you to test work like a charm!

MaxoidTom

21st Feb 2005, 11:08 PM

Numenor: The rules you wrote up seem in-line with what I've stated before. I tried out the rugs in the University EP codeline and they seem to work well.

Numenor

21st Feb 2005, 11:34 PM

Thank you Tom, your effort was precious and... quick!
Sorry for not having answered before, but MTS2 site had some troubles, lately...

OK, then. I'm going to spread the word...
QUAAAAXIIII...!!! :)

Quaxi

23rd Feb 2005, 10:45 AM

i do hope the fixed objects SimPE created since 0.15 work as well, cause people will kill me if i tell them to fix those Objects AGAIN :D

RGiles

23rd Feb 2005, 10:53 AM

LOL. Poor Quaxi. These guys were using a beta process and if they aren't willing to make repeated changes to get the items stable and fully compatible then they should have waited. It's their own damned fault.

Numenor, that sounds perfect. Makes more sense than anything else we've done so far. :beer: for you.

We're all going to get hammered when the EP comes out. If I don't survive I just want you both to know it was great working with you. Tell my dogs I loved them...

RG

Numenor

23rd Feb 2005, 12:54 PM

There's no need to "Fix" again the EP-ready object: the EP format is good, the EP2 format is... perfect! :D

This applies to both remeshed objects and recolours.

If this new method will be implemented in the next release of SimPE, no one will have any problems. And if the batch update routine is modified as well, anyone who haven't already used it will update his files directly into EP2 format.

In the last days I've posted some "EP2" objects, and they are working great, even with old EP-ready recolours. Finally, the "linking" procedure by means of the tsMaterialsMeshName work flawlessly.
And when you select an object from the catalog, the default colour is already automatically selected (the green line around the thumbnail in the colour options); with the current EP format, the default colour was not selected, and if the user places the object in the lot without selecting a recolour (default or additional ones), the object would become *not recolourable*. I hated this! :)

RGiles

23rd Feb 2005, 01:15 PM

My suggestion is that we do our best to let creators know about this change, suggest that they update their objects again for the greatest compatibility, but be sure to say they absolutely do not have to. Actually my hope is that users will complain about the inability to select a recolor if they've placed the items with the defaut color, and the creators will come looking for a bug-fix. :D Yeah, sure... that'll happen.

RG

Quaxi

23rd Feb 2005, 01:28 PM

People read onyl what they want to read, so no matter what you suggest to the, they just read "EP-Ready II", and instead of continuing they just come here and complain :D

I am currently rewriting the SimPE Scenegraph Core (to be ready for the new EP Objects), which will effect the OW as well, so i will include the Changes as soon as that Core is completed.

Numenor

23rd Feb 2005, 04:22 PM

Many objects were created and/or fixed with the EP1 format, and I've seen no complaints so far...
I'd rather avoid announcing that a new fix should be performed (though optionally). They will complain for sure, then! :)

Since this affects only the remeshed objects, and not the recolours, if someone asks for help because his objects have the "default colour issue", we can simply suggest to "Fix Integrity" for it, without any renaming, just clicking "OK". Two seconds and the problem is solved... Don't you agree?

Quaxi

23rd Feb 2005, 04:37 PM

Yes, i will simply state for the next Release, that the Fix Engine has changed thanks to new discoveries by Numenor. :D

tharidos13

23rd Feb 2005, 10:44 PM

I have problems with the UVW mappings of textures.......somehow it will not go to simPE. This makes the textures srew up as a plane again and it ignore the UVW settings i give..........what to do?

Numenor

23rd Feb 2005, 10:47 PM

I don't think it's a SimPE problem... Maybe it's the method you use to UV map your mesh, or to import the mesh into the GMDC. You'd better post this question in the MeshTool FAQ thread, there are more experienced users there.

Quaxi

25th Feb 2005, 08:52 PM

Hm, about the resourcenode in the local group?

Would Recolors work then? If we have a cloned object with the CRES File in the LOCAL Group, the game engine will assign a random Group Number to it (random in the sense of we don't know it in advance)

So when we create a Recolor for that Object, which has the MMAT in the Local Group to and a named Reference to the CRES (without the forced relocation, as we don't know which group the file is in) will it work? I mean how will the game find out the corect Group (without calling a fallback code, that checks all Groups)?

Numenor

25th Feb 2005, 10:06 PM

I think that the game locates the CRES relying on its name, unregarding its Group Number. Only the scenegraphic files that are referenced from outside the package need to be in the global group. Actually, even the textures might be located in the local group (with a proper forced relocation).
The files that absolutely must be assigned to the global gorup are the Material Definitions and the Geometry Nodes, in order to let external objects to "borrow" the materials from the "main" object.

The recolours created by the current version of SimPE work fine.
I have tested many objects and recolour, so far, and all of them showed absolutely no flaws, issues or problems.

Do you need me to give you details about the differences from the EP-ready and the EP2?

Quaxi

25th Feb 2005, 10:18 PM

No, i think i got it working so far.

You can test it with simPe Version i have attached. But not everything might work correct with it.

As mentioned before I did change the Core of the OW. It is more Flexible noe in finding Files, and al Custom Objects should be Llisted now too.

Anyway. Clones, Recolors, single and batch Fix should now create EP2 Packages.

And about the cres again. I know that the game finds the cres files by filename, The question is, if that is the normal way the game locates the cres referenced from the MMAT or if this is the fallback code which then would be slower!

Numenor

25th Feb 2005, 11:30 PM

Mmmh... good question. Anyway, even if you are right, a little slow-down might occur when loading the game or in buy mode, not when playing in live mode... I wouldn't worry too much about that. In my opinion, at any rate the benefits of EP2 (in terms of stability and flexibility) are more important then the side effects it might cause.

Numenor

26th Feb 2005, 06:55 PM

QUAXI:
I think you'll know, by now, that the new OW has some problem when cloning/recolouring objects.
I've read this thread (http://forums.modthesims2.com/showthread.php?t=47522) and I tested by myself: they are right, the objects that give error are more then the ones that work...

I didn't realize it because I was busy converting (as a test) other user's remeshed objects to EP2. And I "discovered" something new (actually, I've already discovered this: I posted this info in my "Colour Options" thread and then forgot it...): if a Text List 0x88 exists, all its entries must match the "renamed" MATDs and must have the ##0x1c050000! prefix.

A last request: the batch converter can't be used to convert EP-ready packages to EP2 (obviously), but this feature would be useful, nevertheless.

Quaxi

26th Feb 2005, 10:55 PM

Yeah, i know about it, actually i think it is just one buggy line that was causing the Problems.

About the EP->EP2 readyness. Do you think it is needed? People should not need to batch convert their EP Ready Objects again, only fix single items.

If i add something to the Batch tool that says not EP2 ready, people will start to think that they need to update.

Numenor

26th Feb 2005, 11:50 PM

I was suggesting something "Some of the selected files are already EP-ready. Are you sure you want to fix them again?"
But probably you're right: since the standard EP recolours work fine with EP2 objects, the 98% of the files don't need to be re-fixed. And the re-meshed objects must be fixed one by one in any case. So forget it :)

RGiles

1st Mar 2005, 08:41 PM

OK, boys...

It appears that we may have some problems with CEP. As in it may not be working with University at all. Since Tom has mentioned there being some new issues with overriding Maxis files, I'm just the teensiest bit worried about that. ;) I haven't got the EP yet. Should have in an hour or so. And I'll start investigating. It's possible that timestamps on the pages are the issue, the EP files being newer than the CEP ones, so loading after. Then again... well we'll see. Just a heads-up here. ;)

RG

Numenor

1st Mar 2005, 08:46 PM

If the timestamp is the problem, it's easy to solve...
In Italy, shipping for University is scheduled to March 11th, so I rely on your tests!

WDS BriAnna

1st Mar 2005, 08:58 PM

The cep is working fine on my computer -- I don't have recolors of everything - but all the ones I have (lone daisy, toybox, aqua plus shower...) are perfectly fine.

I did reinstall the cep after installing University as a precaution.

Numenor

1st Mar 2005, 10:54 PM

Thanks, BriAnna! *sigh of relief* :)

Vanilla_Sim

1st Mar 2005, 11:36 PM

I just got my EP installed and it installed great and everything is fine. I then reinstalled the cep but haven't tested my objects yet. The thing I'm having a problem with is the SimPe Recolor wizard. Now, I know how to use it to recolor I'm not really great with all the technical stuff.

So here is the problem. I run the recolor wizard and it goes through everything loading the objects but there is no preview. We will be able to recolor objects from the new EP?

WDS BriAnna

2nd Mar 2005, 12:33 AM

By the way, Numenor & RGiles, if you need any help color enabling new University items for the next version of CEP, I'd love to assist. I'm pretty sure I understand what needs to be done for each thing, and it would help speed things up between now and when Numenor gets his copy.

(I NEED to recolor that vanity.)

RGiles

2nd Mar 2005, 12:43 AM

Cool, thanks Brianna. :) I should have the game tomorrow.

For the people with the "blinking blue" on all CEP recolors, I really do think it's the timestamp. no one has confirmed yet, because they want to piss me off :D

RG

Quaxi

2nd Mar 2005, 03:27 AM

WDS BriAnna

2nd Mar 2005, 04:08 AM

Quaxi:

C:\Program Files\EA GAMES\The Sims 2 University\TSData\Res\3D [Not a typo. The folder is called 3d]

(University is installed in a different folder. The "The Sims 2" folder is still there, as well as "...The Sims 2\TSData\Res\Sims3D" etc.The other folders inside res have the same names as in the sims 2 version, except for 3d. It even has it's own executable. I clicked on the old exe and it asked for my dvd. I didn't put it in so I don't know if the no-expansion version actually runs. They do share at least some information - since the cep is installed in the normal sims 2 sims3d folder -- and it works.)

[Risking death by parenthesis: as for the other cep issue, which is not ep related, I ran into this last night. I noticed that if I have a recolor of the aquaplus shower on, and designmode it back to the default, it uses the dirty version of the original recolor when dirty.]

Quaxi

2nd Mar 2005, 04:19 AM

Thanks for looking for the Folders. Do you by any chance happen to know where the University path is stored in the Registry?

WDS BriAnna

2nd Mar 2005, 04:27 AM

I'm not real good with regedit, but it looks like HKEY_LOCAL_MACHINE/SOFTWARE/EA GAMES/The Sims 2 University/Install Dir (My value is C:\PROGRA~1\EAGAME~1\THESIM~3\)

Also, in HKEY_LOCAL_MACHINE/SOFTWARE/EA GAMES/The Sims 2 it added a field called EPsInstalled with a value of Sims2EP1.exe -- if that helps with anything (checking if the ep's installed, etc.)

ladydrb58

2nd Mar 2005, 04:36 AM

I ran SimPe, and it is picking up all the files from the download folder, but the thumbnails are not showning up. I am running the latest version of SimPe, and redownloaded the CEP file also. Installed both, and the program is not responding like it was before University was installed.
There are more issues with the CEP, Somtimes the clean/dirty states that belong to the same mtriela don't have the same family value.
It's no big deal tho, but if the CEP gets redone, this should be fixed as well.

Oh, and could somone with the EP please check which additional Folders SimPE has to scan for Objects?

ladydrb58

2nd Mar 2005, 05:02 AM

Just wanted to state that I have the Thumbnails showning up, and SimPe is back to normal, I installed the latest version of simPe. Still having some problems with new mesh objects that will not allow University to load. Do not know if this is the correct thread for this issue, just a added note.
Thanks for looking for the Folders. Do you by any chance happen to know where the University path is stored in the Registry?

Inge Jones

2nd Mar 2005, 11:12 AM

Numenor

2nd Mar 2005, 12:16 PM

There are more issues with the CEP, Somtimes the clean/dirty states that belong to the same mtriela don't have the same family value.
It's no big deal tho, but if the CEP gets redone, this should be fixed as well.

Oh, and could somone with the EP please check which additional Folders SimPE has to scan for Objects?

I checked one by one all the entries in the _Enable...MMAT: only the AquaPlus shower Stall (the one pointed out by BriAnna) had a bad family value. I've fixed it, in my copy of the CEP.
Now the recolour package contains all the needed files.

INGE: we've created the "EP-ready" format following the guidelines stated in aggreement with Maxis. Obviously we couldn't test it with the actual EP, because it wasn't available yet.
But let me say that, now that the EP is out, the "EP-ready" format, in its last evolution that I call "EP2", seems to be perfectly compliant with the University.
Mind that the EP-ready was created for recolours and re-meshed objects, not for hacks (altered BHAVs still may conflict with the new BHAVs in University).
I think I can state by now, that if a recolour or a re-meshed object has problems with the EP, either it is was not correctly made in a EP-ready format, or it has a badly made scenegraphic tree. In both cases, the "EP-ready" format is not to blame, but the creators. In the last week I've helped many mesh creators to fix their packages, because they didn't know (or didn't understand) how a package should correctly be created.

Quaxi

2nd Mar 2005, 08:22 PM

Any insight on how the EP-Ready packages behave in the game now?

Numenor

3rd Mar 2005, 12:47 PM

QUAXI:
In the folders.xml, the line
<path root="ep1">TSData\Res\Sims3D</path>
should be corrected to:
<path root="ep1">TSData\Res\3D</path>

The new Scenegrapher is astonishing!

EDIT:
The hidden "Enable All Colour Options" gives me the following error (on both TS2 and EP objects):

Message:
The value can't be null.
parameter: input

Exception Stack:
System.ArgumentNullException: The value can't be null.
parameter: input
at System.IO.BinaryReader..ctor(Stream input, Encoding encoding)
at SimPe.Plugin.ObjectRecolor.AddMMAT(Rcol matd, String subset, String cresname, UInt32 instance, Boolean substate)
at SimPe.Plugin.ObjectRecolor.GetSubsets(Rcol[] shpes, Rcol gmnd, ArrayList subsets)
at SimPe.Plugin.ObjectRecolor.EnableColorOptions()
at SimPe.Plugin.Workshop.ReColor(IPackedFileDescriptor pfd, UInt32 localgroup)
at SimPe.Plugin.Workshop.Start(Object sender, EventArgs e)

Source:
mscorlib

Execution Stack:
at System.IO.BinaryReader..ctor(Stream input, Encoding encoding)
at SimPe.Plugin.ObjectRecolor.AddMMAT(Rcol matd, String subset, String cresname, UInt32 instance, Boolean substate)
at SimPe.Plugin.ObjectRecolor.GetSubsets(Rcol[] shpes, Rcol gmnd, ArrayList subsets)
at SimPe.Plugin.ObjectRecolor.EnableColorOptions()
at SimPe.Plugin.Workshop.ReColor(IPackedFileDescriptor pfd, UInt32 localgroup)
at SimPe.Plugin.Workshop.Start(Object sender, EventArgs e)

EDIT AGAIN:
I've noticed that now, when cloning a CEP object, OW pulls the original GMND, and not the CEP modified one. I tried to swap the entries in the folders.xml (moving the "download" one to the bottom), but to no avail. In my opinion, this should be fixed, in order to let the mesh modders the opportunity to use the CEP colour options.

Numenor

3rd Mar 2005, 01:43 PM

BRIANNA: the Vanity table is difficult to recolour; I'll try and enable colour options on the wooden part of the table and on the chair, but the white marble can't be recoloured.

RGiles

3rd Mar 2005, 02:08 PM

Well - and I say this with all respect for the toolmakers - it did seem a little premature to be referring to objects as "EP ready" when no one had yet tested them. I mean it's not generally good procedure to claim things for one's objects before testing under working conditions.
In the past couple weeks I have heard so many people say this that I'm ready for the beheadings to commence... but I didn't expect to hear it from the modders. Inge, you know full well that we've got Maxoids on the site helping us out. Tom has tested packages for us and we've run everything we've done by him. I can understand the average user thinking maybe we just pulled this out of our asses, but you know better. We didn't make it up. We did have it tested. We did follow the guidelines given to us by Tom.

I will scream the next time I hear this. :P

RG

Numenor

3rd Mar 2005, 02:23 PM

BRIANNA:
Correction: the Vanity Table is *fully* recolourable: the table, the chair *and* the marble!

RGILES:
I've discovered that my guess was right: if two subsets have the same name, they will be treated as one by the game, even if they are in different GMND (and GMDC)!
Therefore, with only one Material Override we can recolour multiple parts (meshes) of the objects, provided that they have the same name and related to the same CRES (in other words, the MMAT for the two parts must be identical).

RGiles

3rd Mar 2005, 03:00 PM

Numenor...

Are we starting to add new CEP items now? Or are we waiting a bit for the old objects and everything to get calmed down?

When we're ready to start on it, we should divide it up again. I haven't looked at the vanity files yet... it's such a lovely object. If it's not fully recolorable because of the number of groups, this one may be worth creating a clone just for recolors... that many people are going to want them. (That is, a clone so that we can edit the group names and make multiple groups change colors together... as I said, I haven't looked at it yet, so maybe this is unreasonable.)

EDIT: Haha. :D I guess I should read everything before I post. Yes, I had tested your theory with clones, so I knew you were right about that. That's why I mentioned cloning to rename them. But Wonderful, they already have the correct names so it isn't needed. Woot! :D

RG

Sisquoc9976

3rd Mar 2005, 05:12 PM

My obsevations of objects after EP installed....
Most of my recolors worked with no problem, a couple had to be updated a second time with the new SimPe, they now work great!
All the "new" meshes work fine.
The problem objects are the objects that were cloned from another object... they all reverted back to the original base they were cloned from. (I PM'd Quaxi about this, they showed as EP OK).
The items in question are: the canister set, the ironing board, the wine rack for the wall, the kegs, the angel statue and the ice sulptures.

Numenor

3rd Mar 2005, 05:40 PM

There was no need to PM Quaxi, this is not a SimPE issue.
The problem is that in all the objects you have mentioned, the creator didn't used a unique name for the Resuorce Node: all the CRES have their original name. In these cases, the Fix Integrity function must be used properly, to solve the problem. That's why we said that the conversion to EP is a job that should be done by the creators.
Anyway, you did well, pointing this out on each thread you downloaded the object from; hopefully, the creators will update their objects soon, now, and you''l be able to re-download them.

Quaxi

4th Mar 2005, 02:30 AM

Jup, i have to change the hidden Enabler Option to work again, didn't concentrate on that wehn updating the OW core. And I will also creect the GMND problem with the CEP as well as the clean/dirty state problem when cloning only default MMATs.

There is a lot of work at the Moment, so it may take one or two days.

Numenor

4th Mar 2005, 08:05 AM

Quaxi, have you read this post (http://www.modthesims2.com/showthread.php?t=48000) by Echo? I'd add that the catalog feature of the OBJD wrapper should be completed with a sub-catalog choice. I don't know if you already have this file, but I'm attaching anyway

Quaxi

5th Mar 2005, 01:28 AM

Thanks Numenor, that Problem was fixed i think in 0.23.

Numenor

5th Mar 2005, 01:45 AM

Quaxi, I don't know if you already was informed: when creating recolour packages for EP1 objects (that have the MATD names with the forced relocation), OW adds another ##0x1c050000! to the MATD reference into the MMAT; so, it looks like: ##0x1c050000!##0x1c050000!matd_name_12345.

On the contrary, with EP2 objects (and with TS2/University objects) OW v.025 seems to work fine.

EDIT:
Oddly enough, the Wizard can't recolour the CEP University objects (no problem with already recolourable UNI objects), while the standard OW can recolour all objects.

EDIT AGAIN:
As usual, I'm using these pages as a notepad to write down the to-do list... :)

OW (standard OW, for the Wizard I can't say ATM) has problems in creating recolour packages for particular CEP objects (TS2 or UNI dowsn't matter):

1) Objects with 1 or 2 original colour options: OK.
2) Objects with only 1 CEP option: OK.
3) Objects with 2 CEP options: the subset/texture choice window is empty; the "OK" button is grayed out; closing the window, OW creates an empty package.
4) Objects with 1 original option and 1 CEP option: the subset choice window shows only the textures related to the original option (the CEP subset is ignored, as if it was not recolourable).

Quaxi

6th Mar 2005, 01:34 AM

I think the EP2 format did reintroduce a old Problem. When you place a sink on a counter, it wil get the red cross Texture.

I got over your rules again and again, and i think i implemented it as you said, but i might be wrong there. So could you please have a look?

EDIT:
Ok, the only thing that seems to fix this, is using the FL on the TXMT and TXTr Filenames as well as in the references from the TXMT to the TXTR.

Numenor

6th Mar 2005, 11:02 AM

Quaxi:
My tests show that adding the forced relocation only to the TXTR reference in the Material Definition (and only in the "Properties" tab, if we want) is enough. I think that, for readability's sake, we can avoid adding the FR to the filenames.

Anyway, according to what we know (and MaxoidTom explained us), this problem shouldn't occur...
I think that when you select a recolour from the catalog, the game looks into the selected MMAT, finds the referenced MATD (that is in the 0x1c050000 group) and then finds the proper texture looking into the same group of the MATD (i.e. 0x1c050000).
But once the recolour is applied, the colour data are maybe stored by the game in an internal database, probably in a "special" group of its own; therefore, when a sink is applied, the game just looks for the texture in the "special" group, and it doesn't look in the 0x1c050000 group any more. This is the only explanation I can think of...

Well, I have another explanation, but it's too complicated to look real: the BHAVs (or internal routines) used by the game in design mode may be not written to take care of other Groups then the Global 0x1C0532FA...

Anyway, my suggestion is to apply the minimum changes possible to the current EP-ready structure, and so I think we should just add the FR to the reference to the TXTR and not to the filenames.

EDIT:
My theory is supported by another test: if we change the GroupID of the textures to 0x1C0532FA, and we delete any FR, the game correctly finds the countertop texture. I think that this problem is related to the different shape that is used when a sink is put on the counter: it resemble me the problems we had with the breakable objects (wrong texture applied when the shape changes).

EDIT AGAIN:
I think you are aware, by now, that the recolour packages *for the counters* are incomplete again... OW pulls the top (clean/dirty) for one GUID and the finish (clean/dirty) for the second GUID; so, four MMATs are missing (this obviously doesn't apply to the counters - like the value one - that have only 1 GUID).

Quaxi

6th Mar 2005, 11:51 PM

I figured the one with the Filenames yesterday, but forgot to post another Edit here. Sorry for that!
I also found the GUID Problem and solved it for Recolors in 0.26.

So waht is the word on extending the CEP for University. Will you take care of this when you (another European that has to wait) get the EP?

Numenor

7th Mar 2005, 12:14 AM

I'm going to download v. 026 now. Ehm... do you prefer me to post my issue alerts on your new forum or this thread is still suitable?

EDIT: your new SimPE forum is great! I will post my comments there, for sure :)

WDS BriAnna

8th Mar 2005, 08:32 PM

Guys, I'm running into a clothing mesh issue with ep2. I'd been getting a lot of people saying that my tutorial doesn't work anymore, and so I tried to replicate their problem and figured out why they aren't showing up now.

With the original ep format the parts of the clothing mesh: gmdc,gmnd,cres,shpe all had the 1C050000 group and worked.

With the FFFFFFFF group on the cres,shape, and gmdc now they won't work. If a sim was wearing the item, Bodyshop just finds a default skin instead of the newly meshed item. Otherwise the new mesh is nowhere to be found.

Is there a problem with us clothing meshers sticking with ep1? Can we set our 4 files to the 1C050000 group without causing problems?

Edit: Reading back through what Tom said "any scenegraph items not referenced externally should have FFFFFFFF" -- is that the problem? Since the mesh is a stand alone file that the bodyshop skins reference do it's parts need to be in the 1C050000 group?

Numenor

8th Mar 2005, 09:37 PM

BriAnna, since I'm not experienced with clothes meshes, would you please post here a package affected by the problem you described? I'd like to study it to check if the EP2 is compatible with skins.

Anyway, in my opinion, the EP1 can be used without any side effects.

Numenor

8th Mar 2005, 11:04 PM

I'm reading about some recolour issues reported by the users in different forums.
Seems that some objects, that previously were perfectly recolourable, don't work any more when the EP is installed.

When i recolored these, the images i have are fine on my hard drive. in the game the textures show up as white with black binary numbers on them.

piano
dartboard
soma wall tv
soma pancake tv
alienware computer
compact stereo

things that dont recolour:

chess table top
black laquer bar top

some other points:

i know i said this in another post (but i can't find it) the seat to the drums flashes blue
shiney time cooktop stove top part of it flashes blue.
(i know this isn't where blue flashing stuff goes probably but i am making the list for me too)

and the felt to the pool table seems weird, that might be me but i dont know because i have one color that works perfect and one that doesn't and they were both done exactly the same way. just the darker color comes out perfect and the lighter comes out with darker box shades looks like it's tiled when i zoom out.

chair cushions when you zoom out have some weird box thing in the front center.

the discourse dining table does some strange tiling thing when you zoom out.

Everyone has the EP installed (and RGiles in particular) is welcome to test and report if these issues are confirmed.

Another important thing: it was reported that all the Object Data contained in the base game are *duplicated* in the EP Object.package; lord knows how many files are duplicated. The most important thing to check is whether the GMNDs are duplicated, too, in the new Objects04.package installed with the EP.

WDS BriAnna

8th Mar 2005, 11:16 PM

Sure, here's a working and not-working version of the same mesh.

The only difference is the the group numbers (for the files in the mesh).

A quick overview of clothing meshes:

Skins, as created by bodyshop, contain a 3idr file that tells the game which cres and shape to use by tgi. Meshers find the gmnd, gmdc, cres, and shpe and put them in a new package file. We then use "fix integrity" and the scenegraph wizard to get unique names and tgis for our "mesh_" package.

Then we set the 3idr in the bodyshop skin to point to the new tgis for cres and shape. (After that, people can just bodyshop a skin using that mesh and bodyshop will keep these new cres and shape references.)

Incidentally, putting the shape and cres in the bodyshop file does allow the FFFFFFFF group to show up. This is not acceptable, though, since all skins using the mesh would all have to have their own copies and people wouldn't be able to make new colors for the meshes with bodyshop. (Imagine just the hard drive space implications if every single object recolor package needed it's own copy of the gmnd, gmnd, cres, and shape). There are currently around 3 dozen skins right now on various sites that use my long hair mesh, for example, and another 2 dozen or so using my miniskirt mesh.

Numenor

9th Mar 2005, 12:01 AM

OK. BriAnna, you guessed right: in this case the cres and the shape are to be considered "referenced externally" (because they are referenced in the 3DID file, that is assigned to a different GroupID) and so they must reside in the global group 0x1c050000, otherwise the game will never find them.
As a consequence, all the subsequent files in the scenegraph tree (i.e. the gmnd and the gmdc) must be in the same global group, as well.

I didn't understand that the mesh was contained in a separate file then the recolour.
The only solution for clothing meshes (and their recolours) is to comply to the "EP1" format, like you have done until now.

But explain me one thing. I guess that the file "5ffec44e_WDSFLares.package" was created with BodyShop, right? I noticed that the Material Definition is assigned to the 0x5FFEC44E Group, that is not a global group. And in your Shape ("Parts" tab), the reference to the Material Definition doesn't have the forced relocation (i.e. the ##0x5FFEC44E! prefix). Does the game finds the material without any problem? It's odd, it shouldn't be so...
But as long as it work, who cares? :)

EDIT: never mind, I've answered to my own question: the 3DID does the "linking" job.

WDS BriAnna

9th Mar 2005, 12:13 AM

Yes. :) The skin is otherwise exactly the way bodyshop leaves it, and other skinners can use the mesh with bodyshop without knowing anything about simpe or modding other than "include the mesh package with your skin".

RGiles

9th Mar 2005, 02:55 PM

Editted:

I've got about 4 objects left to test. Here are the problems that I've found:

The Resurrect-O-Nomitron
Only the base is color enabled. I think this is a GUID problem in the phone part. It wouldn't use the same GUID as the regular phone because it has different behaviors.

Superflux Über UV Guitar
Only the amp is color enabled, yet there are color options made by maxis available. I think Maxis screwed up and we need to find where. ;)

Genuine Buck's Famous Counterfeiting Machine
CEP is causing the center part of the object to go invisible, even for the original texture.

I started working from the bottom up and have only a few items left to test, and then I'll look into whatever problems haven't already been solved.

RG

RGiles

9th Mar 2005, 03:06 PM

Tom had reported specifically somewhere that I can't remember that bodyshop items had to use the filename hash and not the private group because they were referenced externally.

The context for his comment was that that this pattern was kept in the Homecrafter's Plus program because it used a lot of old Bodyshop code, but he didn't believe that it was necessary in that case, just a leftover.

I'm willing to bet that applies here with the new meshes as well. They are being referenced externally through the 3DIR files.

RG

RGiles

9th Mar 2005, 06:07 PM

I've finished testing what was left and the problems listed above are the only ones.

Edit: attached is an updatede GMND for the Counterfeiting Machine. Slave subsets won't work for it due to the naming conventions issue that Numenor discovered. We're going to have to apply recolors separately.

I'm going to look at the guitar. Maxis goofed up there somewhere. They enabled design mode, but it ain't working. ;)

Edit Again: The guitar is recolorable, but only using the design tool. That sucks. Doesn't look like we can do a damn thing about it but tell people, though.

Edit Even More: In the case of the Resurrection thingy, I'm getting the impression that we really can't recolor both parts effectively. For starters, you can't use the meshmaterials to point to the CRES for the wall phone. They share the same textures, but it's using its own CRES and GUID for the entire object including the phone (and the subset names are different anyway).

I've got it so that I can recolor both the pedestal and the phone base, but not the handset which oldly I can recolor while a sim is holding it, but then it reverts when they put it down. When I have both enabled, SimPE doesn't pick up on the fact that the pedestal is recolorable anymore, probably because it's seeing the phone base and the handset as the 2 recolorable parts. But the game still accepts recolors for the pedestal.

RG

Numenor

11th Mar 2005, 09:55 PM

You're absolutely right about the phone of the Resurrect-o-nomicron: I didn't realized they had different subset names, compared to the wall phone. So, I think we can only delete the phone from the GMND and let it stay not recolourable.

As for the Guitar, but this apply to the bubble machine, too, seem to me that at the last minute Maxis decided to remove the guitar from the "main" object, and treat it as an accessory. On the contrary, the bass is treated as a whole with the ampli (both meshes are in the same GMDC). I think tha't because the guitar is used by the sims in a more "free" style (they make it turn around them, they play it behind their back...), while the bass is more static.
Anyway, we can't do anything for the guitar, as well.
I'll state in the info file that it's recolourable only in design mode.
I said that this apply to the bubble blower, because the pillows were stripped from the main GMDC, just like the guitar. As a consequence, the pillow, too, are only recolourable in design mode. They left out even a tsMaterialMeshName, originally used to link the pillow to the base; now it only contains: "base (string)=" and nothing else...
Seems that they were in a great hurry in the last days before the official release :)

Thanks for the GMND of the Counterfeiting machine. So, you think there's no other way then enabling the two subsets separately... Maybe we should only enable one, then: two recolourable subsets seem too much for such an objects (have you ever seen a recolour for any other carrear reward? :))

RGiles

12th Mar 2005, 05:17 PM

I will have to look at that object again, and see what the colors of the different parts are like. I really don't think most people will be in a big rush to recolor it. ;)

RG

Numenor

13th Mar 2005, 11:38 AM

RGILES: for the three defective objects you pointed out, I did the following:
1) The Resurrect-o-nomicron: I removed the colour options for the phone and the handset.
2) The guitar: the ampli is recolourable, as well as the guitar itself; but to apply the recolour to the guitar you need to use the Design Tool; I've stated this as a Maxis known issues.
3) The counterfeiting machine: I decided to keep your GMND as is, with two separate recolourable parts; I don't think that the users will be much concerned about what we decide about it, anyway...

Beside these objects, are there any other objects that still need to be tested? I have started from the top and I currently have come to the "Laganaphyllis Simnovorii" (the cow plant). Everything is OK for me.

Are we going to publish the CEP v. 2.0? I can't wait any more... :D