I'm currently preparing my first two assets for upload which present different difficulties, which along with these posts…

http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&p=123777#123777 [sidefx.com]

– have sent me to the same conclusion – there seems to be a need for “collections”, “suites”, “albums” – some kind of grouping into a single download. Sorry if this already exists, but I see no mention of it and uploads seem to point there isn't.

Where there are several mechanisms in Houdini to group assets together -the functionality isnt there in Orbolt as far as I can see. Putting multiple HDAs in a single OTL seems to be out, since only needs top level def is wanted per archive. There are 3 situation that immediately come to mind, some that have been discussed.

- a node is uploaded and only intended to be used internally to another op… theres always breaking the internal one from the def before HDA'ing the 2nd -but that loses the functionality of the outer node updating with an inner node release.

- an asset that appears in slightly different forms in multiple context ala “switch”, “merge”, “null”. This is the situation I am currently running into and additionally problematic because the OBJ level asset has the SOP level context at its core.

- a single tool spanning multiple contexts…. ala pop attractor/sops meta, obj bones/ CHOPS ik, etc…. where embedding one in the other will diminish functionality.

In the second case, I can upload the SOP and once approved, download it embed it in the OBJ and upload. I can charge only for the sop and make it required by the obj. This would insure everyone that buys the OBJ has both nodes, but not the other way around. Particularly true with new version delays between the sop and subsequent obj upload.

The third case isn't quite that pretty… Spread the price across the 2 node and instruct user to download individually, charge for one and the other is free… either way there is no guarentee that anyone ends up with both nodes.

Is there a way to delay the release to the store, where I am still able to download it myself to embed in another asset? At least this way they are released the same time? With a collection designation this could minimally solve the problem.

Without groupings/collections there could be risk of quick bloating of the store with individual listings that are in reality part of the same thing. I have already seen a couple of these when browsing – downloads noted as only useful as part of something else.

No thoughts on this guys?…
Im already encountering all these sceneries as Im readying for upload..
I guess it also could just be me …..

Aren't dependency assets the thing you're looking for then?

If it's not dependency's what you're looking for, I agree it might be worthwhile to look into something like this, but I do feel they might be close to what you need/want.

Dependencies should do much of what you refer to in the 1st post. Albeit there are caveats to work around.

I know that there are at least 3 or 4 of you working on suites.
From what I can surmise, the main issues are:

• 1.Having to upload dependencies first, wait for activation, then upload parents.
  2.Having to upload multiple dependencies, supply icons, hip files etc (would rather upload en masse)
  3.Display of numerous dependencies. Would prefer to (optionally) hide dependencies at the store.
  4.Management of versions
  5.Management of naming.
  
  How would you prioritize the list above?
  Is there anything big missing from this list.
  
  
  …and can you tell me what the suite you're working on is about (what can I say, I'm curious).

Just to be clear on ‘dependencies’ unless we are talking about it in a broader sense to include HDAs not embedded into another… to put it another way….

I have nodes types foo and bar. At the heart of foo and bar is simply nodetype A. So a foo and bar are both dependent on A. Nodetype A on its own is useless, so we hide it. Now we are presented with seeing foo and bar as profiled hdas in the store.

But in the case of foo and bar being made to use together (this applies far more for utility/pipe type tools than model/tx assets) getting either guarantees getting hidden nodetype A – but not each other, so a hierarchically greater thing is introduced that is neither foo nor bar but a grouping we call ‘smoo’ And Over time HDAs can be added or taken away from Smoo.

I supposed this COULD be accomplished with a dummy HDA containing all the others thats never meant to be used, hide it from the TAB menu, and hide all dependents from the store, then likely have all the dependants at the same spot in the TAB menu – essentiall a ‘null’ asset– but this is sloppy and Im think more of a strictly organizational arbitrary grouping for presentation, upload, download and to reduce clutter.

– I would say versioning in general in a consistent way across products in format beyond XX is of big importance – as a TD, more specific levels make me happy and I think for things to make it into production use, quick indicators help understand instantly if it a bug fix, feature change (might require more evaluation) or a major change – might involve major cascading changes. And although, at least speaking for myself, I might use XX on the node revision the is in reality likely a package release version that is more specific or in the very least a release of a major version is tied to an svn version XX svn version 345. . etc…

- uploading enmas I guess would be lower for me.