PDA

View Full Version : Obsolete: Making objects design tool compliant without re-cloning (1.4.83)


plasticbox
19th Mar 2015, 12:24 PM
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 (http://forums.thesims.com/en_US/discussion/comment/13957224/#Comment_13957224).


To fix this in s4pe without having to re-clone the entire thing:

1. open the package in s4pe, sort by type, select a COBJ or OBJD from the resource list and doubleclick

http://thumbs2.modthesims2.com/img/1/7/8/2/8/2/MTS_plasticbox-1514232-designtoolfix_select.JPG


2. In the window that opens, set the Group ID to 0x00000000 and the first 8 digits of the instance ID too.

http://thumbs2.modthesims2.com/img/1/7/8/2/8/2/MTS_plasticbox-1514234-designtoolfix_reskey2.JPG


Hit OK, repeat for all the COBJ and OBJD resources in your package, save your package, done.

I just tested with one of my own objects and it worked. Unfortunately using this method means there is no way to avoid having to re-buy these objects in game, because the instance of the COBJ/OBJD is exactly how the game tells them apart ‒ even when nothing else changes, with a different instance on those resources the game willl treat them as different objects.

Seeing as essentially using a 32bit ID significantly reduces the amount of custom IDs available (see comments below), it might be a good idea to also watch out for a fix from Maxis or perhaps a script mod that makes this work for everything, and treat this as a temporary workaround rather than a real solution.


This is in 1.4.83.1010.

Inge Jones
19th Mar 2015, 12:50 PM
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?

plasticbox
19th Mar 2015, 1:01 PM
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.

Inge Jones
19th Mar 2015, 1:03 PM
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?

plasticbox
19th Mar 2015, 1:07 PM
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 .. :rolleyes:

ETA, I posted at EA (http://forums.thesims.com/en_US/discussion/821369/design-tool-question-re-custom-object-cobj-objd-ids) about it -- we'll see what they have to say about it.

ETA2, didn’t see your question before:

Have you tried leaving the top bit set in the group and just changing the IID?

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 (http://modthesims.info/download.php?t=543893) ); 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 (http://modthesims.info/download.php?t=543787) (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?

julsfels
19th Mar 2015, 5:41 PM
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 :D ).
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.

plasticbox
19th Mar 2015, 7:36 PM
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.

julsfels
19th Mar 2015, 9:00 PM
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. :rofl:

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.

plasticbox
20th Mar 2015, 12:39 PM
Got an interesting PM about this:

Thanks for the info. I'll have to give it a try and see what happens with my custom thumb recolours.
The only other issue I have come across with having design tool enabled recolours of EA objects is that the design tool will not work when switching between an EA colour and a custom one, or vice versa. It pulls the wrong texture files. This isn't an issue for stand-alone CC objects, only additional colour packages.

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

Menaceman44
20th Mar 2015, 4:17 PM
@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

julsfels
20th Mar 2015, 9:21 PM
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.

plasticbox
21st Mar 2015, 2:52 AM
Yup, just saw that and also wanted to post it here:

Hey guys, yes confirmed there is a problem here - I did not verify that it used to work but regardless it should be fixed. It's likely a problem on the C++ side. Will take a look as soon as I can, will keep you posted.

http://forums.thesims.com/en_US/discussion/comment/13436387/#Comment_13436387

--

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

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.

Menaceman44
21st Mar 2015, 11:29 PM
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?

plasticbox
22nd Mar 2015, 2:03 AM
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 (http://modthesims.info/showthread.php?t=551120) -- 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 (http://modthesims.info/download.php?t=550327)) 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.

Menaceman44
22nd Mar 2015, 3:36 PM
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.

plasticbox
24th Jun 2015, 10:35 PM
So turns out they had forgotten about it .. I asked again now, this was the answer:

Ack! Sorry I totally forgot about this one, thanks for the reminder. I have determined the problem - should be relatively straightforward fix, although slightly more complicated that some of the other ones of this nature we've fixed. So may take a bit longer to get to you guys, will let you know when the fix is released.

For my testing I just used this object, chosen somewhat randomly from MTS. If you have any specific content you'd like me to test with, feel free to point me at it.

Thanks,
SGMS


http://forums.thesims.com/en_US/discussion/comment/13783368/#Comment_13783368

plasticbox
15th Aug 2015, 3:47 AM
This is fixed in 1.10.