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.




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!

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.

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.

Yes, I noticed this issue, too; I posted something about this... let me see... Here it is! Post # 1099; I was referring to the old version of OW, but seems that the problem survived to the update...

How'd I miss that?

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.

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

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

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.

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.

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.

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

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.

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.

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

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.

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?

I had tested another lit/unit object and ... damn, why didn't I write that down? 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.

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...

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.

I think i solved that Problem now with Release 0.18.

Quaxi, RGiles, I hate to open again a "solved" problem, but these words by MaxoidTom still hover into my mind:


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/attac...achmentid=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/attac...achmentid=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/attac...achmentid=34288
http://forums.modthesims2.com/attac...achmentid=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?

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

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?

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.