A custom property is a structured userdata intended to be placed within a specific scene context, such as on an object, cluster or other scene entity. They're useful for tagging objects and for identifying scene items. A sticky-note, of sorts. If you're using them for any other purpose, then you should re-evaluate why you're using them at all.
We do very aggressive scanning and validating of data and have never run into such a problem of 'false positives'. Not even once. We use custom properties because they provide a way of tagging scene elements that is not prone to user error. No matter how hard the user tries, they cannot change the property's "Type". Our assets have to function in software environments which need to make safe assumptions at runtime. Custom properties provide that safe haven. CustomParamSets do not as there is nothing in them you can depend on to get the same answer twice with certainty. All it takes is for a user to rename a CustomParamSet and all hell breaks loose. Often happens from routine operations such as duplicating or merging objects. Self installed Custom Properties are immune to that problem. The Layout of a custom property is separate from its definition. In fact, you can define the PPGLayout in a separate file and have it linked in using PPGLayout Logic. That alone likely avoids the problem you are now reporting. The external file supports both PPGLayout logic and PPGEvent logic. We have parameters that need to be populated by SQL queries as our assets can go years at a time without being touched. Our databases, on the other hand, go through frequent change as gameplay and other systems are frequently tweaked and honed. Tables often change in structure or get dropped and moved around. The custom properties in the scenes reading from those tables need to respond without having to be opened again. Having the PPGLayout dynamically driven from external file makes it possible as we merely have to update the external file and push the change into the workgroup. Based on past discussion, I am lead to believe you are using the ad hoc method putting logic at the bottom of your _Define callback in your custom properties to see if parameters exist or not, then dynamically stuff them in after the fact if they don't. I know some people advise that route, but I strongly disagree as it creates a scenario of complex uncertainties which leads to later instability. Try using the method I've long suggested that nobody seems to try - use events and replace the properties en masse on scene load. This involves a scene load event which scans the scene for custom properties, and compares versions of the properties in the scene vs. those installed in the workgroup. If the scene version is older, you re-instance the custom property into the scene, copy the old parameter values across to the new property then delete the old property. This ensures data is up to date and synced with the latest state of the property. Yes it is a little work to set it up, but it's significantly more reliable and easier to trouble shoot because the rules are simpler, centralized, and predictable. It also allows you to extend the system for other options such as conditional updates, deprecation, or conversion from one property type to another. Whatever problems you're experiencing, we have never encountered them here and we lean on custom properties very heavily. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane Sent: Monday, December 03, 2012 3:06 PM To: softimage@listproc.autodesk.com Subject: Re: reorder custom parameters The problem with properties having to exist in a plug-in is that the moment you need any decent extent of dynamism in the layout you are SOL, so it's not really an option, and while you could get users to ignore errors, if you have automatic log compiling, summaries, monitoring etc (and we do) then you get false positives, and those are beyond annoying and enter dangerous grounds. Even if we accept that users will not panic and will remember what failures are tolerable and which ones aren't, purely for the sake of argument, because it ain't gonna happen, when you go to the farm/automation then you have to handle all those exceptions to erroring, and sorry, but that's just NOT going to happen as the risk for an excessively fault tolerant farm environment is never, ever, worth it. The only way around the lot is to have your own property cooking to create and destroy the error prone parts of the process on various events, but again, it will only be fine if your dynamism is at creation time, the moment you want truly dynamic layouts with proper garbage collection, there truly is no way out of it (without having hundreds of parameters stashed away hidden for when you might need them, with all the unacceptable added load that entails). In short: No, sorry, custom properties and persisting faulty layouts that appear to be working despite a polluted log are not conducive to a clean and healthy pipeline, they are the exact opposite, they are a damaging and muddying nugget in the pipe that usually turns cantankerous quick.
