This is a very simple fix for the common issue that custom objects are throwing “Script Call Failed” errors when one attempts to use the design tool on them – the group ID of the COBJ and OBJD needs to be zero and the first half of the instance too (in TSRW the latter is labeled “Instance ID” (as opposed to “second instance ID”)).

Please note (March 20): Please see the quote/link in post #12 -- Maxis have confirmed this to be an issue on their side, so you may want to wait for a proper fix before you start to change existing objects. But as a temporary workaround, I guess this is still useful:

Obsolete as of 1.10 (August 6, 2015) -- this is fixed now.

This is really annoying, because it means the game relies a lot on using only 32bit instance numbers, which puts us back in the days of TS1 and TS2 with their potentially clashing instances - you remember we had to have a registry of used numbers?

Yeah I know. But just changing the group wouldn't work; some of my objects already have a group ID of 0 (modular cabinets and such) and they don't -- only when the first half of the ID is set to zero in addition, they become recolourable in game.

I suspect this is something that only works in recent-ish games btw; I know I have experimented a lot with exactly those instance numbers when I made catalog objects for cabinets a couple months ago .. I would think Maxis changed something between then and now to get this to work at all.

I expect it's something like the early part of TS3 where if there was any scripting referring to the instance number, you had to force it to a 32bit IID. I think that was fixed in a patch. That will explain the "script error" tooltip, as the 64bit reference doesn't fit the data type. Have you tried leaving the top bit set in the group and just changing the IID?

You mean in TS3 there was a fix in a patch so that scripts would also work with 64bit IDs? Or fixed so that it would work at all? (I missed most of that I guess, I was rather inactive during the TS3 era)

We'll see what happens, I guess -- if it's only for a temporary workaround, using 32bit instances for a limited amount of time woudln't be so bad after all. I guess Maxis should also have an interest in getting this to work with group IDs other than 0 and full instances since that is what would be compliant with their own specs for CC ..

ETA, I posted at EA about it -- we'll see what they have to say about it.

ETA2, didn’t see your question before:



Yes I checked, that doesn’t work (the game didn’t find these objects at all, X-ed out thumbnails and such). Also doesn’t work when only the group is 0 – that is already the case in some modular objects I made (custom COBJ/OBJDs for cabinets, e.g. here ); those do not work with the design tool either. Or at least they did not when I made them .. I should probably doublecheck again.

Funny that overrides like in this post (which have the original unchanged instances for obvious reasons) are also throwing script errors when put in the same thumb ID .. I didn’t check now, I guess it might only work with consecutive IDs or something?

Oh, great, that´s really useful, thanks!
I just tested this a bit yesterday, too; I set the group IDs to zero, but that didn´t work, as you said. I hadn´t a closer look to the first Instance part, so this is great! (Although it is not really great, when you think of the consequences ).
Thank you very much!

EDIT: I forgot - I tried to fix the group IDs yesterday in TSRW in Edit->Project Content, but this did not work for me, got an error message and TSRW crashed. Seems that this part is probably not ready yet.

Ah, thanks for that info! I’ve only renumbered image resources so far in TSRW, I think, and that worked fine -- didn’t actually check whether renumbering COBJ/OBJD worked too. I edited that part out of my first post now.

Yes, renumbering the textures works fine. I renumbered 12x60 textures from my boxes manually, to make them use the same textures and only include each texture one time in a Master-package.

I think I will wait a little while before I fix my packages and see, what EA says in your thread, although the first answer isn´t encouraging.

Got an interesting PM about this:



@Menaceman44 , does this happen when the recolours are sorted in the same catalogue thumbnail (have the same SwatchGrouping) as the Maxis objects, or does it always happen? I can’t check right now, am not on the machine with the game stuff on it. But I seem to recall it wasn’t really clear to me how the InstanceManager or whatever it was called knows which object is the current one when I looked at the Maxis code; maybe it’s using the SwatchGrouping .. if that is the case, giving custom recolours their own SwatchGroupings might be enough to un-confuse it and have it use the correct textures again.


Another thing I can’t test right now but am curious about (maybe someone else wants to give it at try?) is, what happens when instead of truncating a custom 64bit ID to 8 digits, one would use the 32bit hash instead? If the cause of the problem is some piece of Maxis code expecting a 32bit hash where custom objects deliver a 64bit one, this might help for not having to re-buy all the objects in game. -- Nope, doesn’t work. Those objects still count as different objects.

@plasticbox - I always group my recolours of EA objects with the originals so that my catalogue isn't overrun by duplicate objects that just come in different colours. If I make them as a stand-alone catalogue entry with their own SwatchGrouping (or PrototypeID as Studio calls it) then the design tool works exactly as intended
I explained the issue in more detail over on the Studio forums and orangemittens gave a reply about 8 posts further down the page; http://sims-studio.proboards.com/post/8677/thread

plasticbox, did you see - there is a new answer in your thread in the offical forum from SimGuruModSquad, seems to be at the C++ side and they are trying to fix it. Really good news.

Yup, just saw that and also wanted to post it here:



http://forums.thesims.com/en_US/dis...omment_13436387

--



That’s good to know, thanks for the info! =)

What names do you give your colour variants? Are you using the same names as EA ("set1-materialVariant" and the like), or are they something like "menaceman1" etc? If you do the former normally, perhaps try making a small test object with customised names .. I believe the confusion comes from the fact that the game doesn't properly differentiate between the modls but thinks everything within the same thumbnail is the same object, and then when the names of the variants are also the same it's losing track of which is which.

I don't actually manually set the colour variant names. I've just always let Studio do whatever it does to create a package. I'll have to go check what they're set to now.

ETA: They appear to just be using the default EA naming of "set# -materialVariant". I'll try changing it and see what happens.

ETA2: All I managed to do was break the recolour package. I tried keeping the "set#" part as it was and just altering the part after the hyphen as well as just altering the number to place my recolours in sequence with the EA originals. All either of these changes achieved was to prevent the game using any custom textures past the first design, and as before, they could not be selected unless it was a recolour that was originally placed.
I'm assuming I needed to change the colour variant name in more than the one location I could find it listed in Studio?

If you *just* change the name in the OBJD, that will indeed break the package (the first colour variant is, in Maxis objects at least, also the one that is used as a fallback for when the game cannot find a proper one, so I guess that is why you now only saw that one). If you want to change this manually, you would have to 1. change the name in the OBJD and 2. replace the corresponding hash in the Type300List in the MODL and all LODs that have this list with the FNV32 hash of your new name. This is how the game knows which material definition to use for which object instance. (See also here -- I've compiled some info on those resource types in an info post earlier today)

I can't tell whether S4S would let you change the material variant name in a way that would also update these entries .. I've only done this manually and with TSRW so far.

Anyhow, I just tested this myself the other way around, with an object of mine (the "Towering Intellect" bookcase recolours from here) that already had custom names/hashes for the material variants, so I changed the group/instance IDs of the COBJ and OBJDs like described above -- the result was that switching between custom instances worked fine, switching between the original ones also worked fine, but switching from one to the other kind throws a Script Call Failed error. It does not use any wrong textures though. So it's kind of "not working but in a more correct way" =P.

We'll see what happens once the Maxians get around to try and fix it, I guess .. maybe it'll Just Work then, maybe not. With CAS parts, sticking completely different objects (different mesh and all) into the same thumbnail works fine if I remember correctly, so it's probably not impossible.

The difference with CAS parts though is that there is no Design Tool or similar required for them. You pick a colour from the "catalogue" and your Sim is wearing it. To change clothes you always go back to the "catalogue" view. I imagine that if CAS did have a Design Tool to use then it would also be broken in this way.
This is, of course, pure conjecture on my part though.

So turns out they had forgotten about it .. I asked again now, this was the answer:




http://forums.thesims.com/en_US/dis...omment_13783368

This is fixed in 1.10.