I thought we WERE talking layouts here, otherwise why would you even remotely care about re-ordering parameters? Of course if you're just adding tags, go ahead, do whatever, it doesn't matter then because if a user has to see tags you have a mistake somewhere in the design or are not providing the right tools for inspection. You might as well add blobs at that point though, they are much better insurance against user mistakes and provide clear entry and exit states, and the price of ser/deser is negligible even on large amounts of them, and at that point you're at least not limited in data types anymore.
I don't remember the past discussion you mention, but no, I don't like define callbacks to begin with, and sure don't use them for layouts :) I have experimented with a number of solutions over the years, including exploiting the current system with events and file monitoring, but in the end it's simply too damn limited. All you point out about files makes sense in the context you describe it in, but you're still up a creek without a paddle if you need any dynamism to the layout, whcih is what I'm referring to. PPGs (which front custom properties, unavoidably) are THE only inbuilt mechanism in XSI to offer interfaces that persist with the scene, if you need them to be created on the fly and respond to user interaction, what you describe is simply impossible in Soft, whereas it is in some other applications. You are offering a very limited subset of what a custom property is in the first paragraph, as you are limiting it to a collection of unchanging (as far as the user interaction is concerned) parameters, and something else that doesn't address the problem I'm talking about in the third. I'm now confused about what we'd be discussing here :) Replacing or tweaking parameters through events is possible, and has been done, but again it doesn't offer a thing when it comes to user interaction, and the cost can be exorbitant. Doing it sparsely like on scene load or save is far from enough, and doing it more frequently like on selections is simply going to lag the user into ripping their hair out. It's not that people haven't tried it because they don't like the idea, many have tried it and found it simply insufficient. As for names, as long as your tag has an ID bundled it's easy to repair any damage for a minimal cost, as a fall back or as a manual process. I am officially confused to hell now though about what we're trying to shed some light on, so I'll probably bow out of this :) On Tue, Dec 4, 2012 at 11:37 AM, Matt Lind <[email protected]> wrote: > 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:* [email protected] [mailto: > [email protected]] *On Behalf Of *Raffaele Fragapane > *Sent:* Monday, December 03, 2012 3:06 PM > > *To:* [email protected] > *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.**** > > -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
