@SimGuruModSquad /
@SimGuruEugi : I don't know since when this is possible, but as of 1.4.83 (maybe earlier, I can't tell) it has turned out that the in-game design tool will only work on custom objects when the group ID of their catalogue instance and object definition (COBJ and OBJD) is 0x00000000 and the first half of the instance ID too. Otherwise, custom objects will throw a “Script Call Failed” error when trying to recolour them in-world.
This is probably not a good thing, since it makes ID collisions a lot more likely and you also said that all custom stuff
should use a custom group ID and so on .. dunno, would this be a bug? Do you think you can do something about this on your side; or alternatively, do you think there's a chance of getting this to work on “regular” custom objects (with group 0x8000000 or whatever and 64bit IIDs) by way of a script mod, perhaps? I tried to look into the latter before but it went way over my head -- maybe someone like
@scumbumbo could comment on the doability of that.
Comments
In short, I'm just not sure where to look, and it's quite possible the bug is in C where it's completely inaccessible to us, or the AS which is only slightly more accessible.
This was all in a much older game version though, I dont know whether that code is still the same and/or whether I'm even right about instance_manager.py having anything at all to do with the design tool. Just thought since you're a lot more Python literate, maybe you have poked at that issue before and would know more about it.
Awesome, thank you!
ETA: just to clarify, by “as of 1.4.83” in my post above I didn’t mean to imply that this has worked differently in earlier games – only that I can’t tell, since I can’t roll back and custom objects were a relatively recent addition.
@SimGuruModSquad are there any news on this? It's slowly but surely getting a bit irritating to use older CC objects now, since one doesn't really expect that "Script Call Failed" thing any more .. OTOH changing the IDs would mean having to re-buy all the objects in game which is also not ideal. And the longer we keep using the short IDs the higher the likelyness of collisions ..
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
The object you linked to is one that seems to have been changed at some point to 32bit IDs -- is that what you need for testing? (Can't tell when you downloaded it) Or objects that are according to your specs (with group 0x80000000 and long IDs)?
This might be interesting to test with: catalogue objects for kitchen cabinets/counters, the workingness of which (with the in-game model selection and all) also depends on the ID -- I don't remember the details exactly but I believe they needed to have a group ID of 0x00000000 in order to work. Might be good to check whether or not this kind of thing would work with 0x80000000 as well. The instance IDs of that are 64bit. (The "No-Drop" package is the interesting one.)
This is also old, with group 0x80000000 and 64bit IDs. Or this or this or this.
--
A remaining problem might be that as long as the design-tooling goes by the MODL ID, people can still stick different objects in the same thumbnail and the design tool recolouring procedure will not be able to switch between them .. IDK; would it be possible to give them a somewhat more interesting failure message than "Script Call Failed"? Something along the lines of "You can only redesign between variants of the same item" .. ? (Or can this be made to work too, perhaps? I seem to recall that in the pre release CAS demo there were some pants in the same thumb that were actually a different mesh .. but then that's CAS, not objects.)
Right now it apparently goes by catalog thumbnail ID (and/or colour swatch entries as SGEugi states here), but that is sometimes a bit impractical: the catalogue would be a lot easier to manage if it were possible to give similar items the same ID and have them grouped together that way (like those four different wall-mounted wardrobe racks, or the oodles of collectibles that make debug mode a scrolling exercise), without getting Script Call Failed errors when the game attempts to design-tool between them even when they only have one material variant each (so there's nothing to design actually).
Would it be possible to make this work like:
- In the catalogue, show everything in the same thumb that has the same thumbnail ID and let the user select by clicking on the colour swatch (i.e. like it is now)
- On an object in world, only activate the design tool when *this MODL* has more than one material variant, and have it switch between the variants regardless of what thumb ID they have -- when there is only one variant, show the "Design Tool Cannot be used on this object" hovertip instead
?
Unless I'm overlooking something, that would seem quite logical .. and offer a lot more flexibility for CC creators and modders in regards to sorting stuff in the catalogue. The catalogue is already large by default, and when people download CC by the gigabyte on top of that, you can imagine that catalogue management becomes a bit of a concern .. right now the trend seems to be to give everything a separate thumb ID for no other reason than to avoid those Script Call Failed errors.
(Maybe the above would be possible by way of a script mod? Not sure ..)
@pbox - regarding your suggestion about changing the way the design tool determines how to populate itself. I'll take a look - if you have an example mod the exhibits the bad behavior that would help me more quickly identify what needs to change. Thanks.
I'll take a look later and get you some examples of what I mean. TIA!
1. Lavender Shrubs (contained in this upload) -- these are hardly CC at all, the only thing custom is the COBJ/OBJD (they are Maxis World objects made available for Build/Buy):
Here I stuck 0x0000000000002C69 (“plantCEShrub_02”, MODL 0x4A0D8A548718EB05) and 0x000000000000BEFE (“plantGD_RBH_glade_shrub_01”, 0x48CF1B87C9B65AF7) into the same catalogue thumbnail (SwatchGrouping/PropertyID) as the base game “Lovely Lavender Bush” since their shape is nearly identical; they are only a bit bigger and have different colours. When trying to designtool between them, one gets “Script Call Failed” (in 1.10 too) -- far as I can tell this is because the MODL is different. I’d find it more intuitive if one could put very similar objects into the same catalogue thumbnail and have them behave like recolours in game .. or perhaps just get the “Design Tool Cannot be Used” error, instead of “Script Call Failed”.
2. Kitchen counters (from here)
Six recolours of the BlandCo counters/islands that are using the same “body” textures as the Maxis ones, only the top is different. Because they’re the same colours I also gave them the same SwatchGrouping as the existing ones; they have the same internal names for the material variants as well (set1, set2 etc). Here I do *not* get “Script Call Failed” (not before 1.10 either; those have short IDs), but the design tool still acts a little confusingly when switching between CC and Maxis:
This is the default variant of the Maxis object
When I select one of the custom variants, it’ll show the equivalent variant of the Maxis object instead, as long as the design tool is still active
However, once I let go, it correctly displays the custom one
It’s the same the other way around (i.e. when going from CC to Maxis object). It’s as if it didn’t know which “set3-materialVariant” I mean, but in the end it actually does.
ETA: 3., here is another little test package I’ve just thrown together -- it’s one of your wall-mounted deco coat racks plus three variants of two of the other ones all in one catalogue entry (this is in Dressers, not deco, since it’s been made to work like a dresser). With 1.10 it now works fine to switch between the variants of each in-world, but not between the different racks of course (Script Call Failed) -- there’s nothing really “bad” about that, it’s just a bit inconsistent how in the catalogue, one can switch between all of them (different models too) but not once the object is in world.
Also the error message could perhaps be something less scary? “Script Call Failed” really makes some people go “omg my game explodes” =/
ETA: To clarify, the COBJ appears to load (object appears with red X in build/buy) but the OBJD fails to load.
ETA 2.0: Pbox got me straightened out, it appears that using 0x80000000 for the group will restore sanity.
ETA: But when using group 0x80000000 it worked fine, thanks again @pbox
Ah that's good to know, thank you. I guess this means that most if not all of the existing older objects should work just fine -- I know that TSRW automatically set the groups to 0x80000000 and I assume other tools did the same thing, since that what it says in the specs. You probably only had this issue because you were manually fiddling with it but that is not something a lot of people do.
Although it is nice to reduce catalog clutter by merging multiple similar items into the same catalog entry it also has the effect of making it so that the in-game design tool does not function correctly. Because no one could make CC that utilized the design tool anyway no one realized this so there is some amount of older CC, like this painting collection, out there that will not work correctly with the design tool.
Probably the easiest way to fix it for your own game would be to clone the first .package as custom content, export the images out of all the other .packages, add swatches to the new clone, and import the images in on the new swatches. Unless you renumbered each swatch with the original instance number in the object catalog and object definition fields any instance of the original paintings you had in your game would be removed when you removed the original painting .packages and you would need to replace them with the new painting clone. Optimally, you would let the creator of this cute collection know there's a problem and that it isn't difficult to fix it...especially if you don't mind a compulsory replacement of missing paintings when the original set is removed from the Mods folder.