Usually, one uploads a digital asset and an accompanying hip file and that's all. You're done. If you need to do an update, simply submit the updated asset and the store will receive it as a new version ( an number the version accordingly).

For more complex assets, it can be beneficial to use dependencies. These are sub-assets which are nested inside a bigger main asset. This is useful when the main asset is complex enough that you want to manage and update it in separate parts.

e.g. The main car asset has two dependencies:
-wheel asset.
-vehicle rig asset

Because these dependencies are also assets in the store, any time they get updated, any cars that depend on them will receive the update. This is useful if you plan to make a fleet of cars but only need to update the wheel asset. In this case, updating the single wheel asset, will affect the entire fleet.

Most asset authors do not need to concern themselves with dependencies. It's really a workflow for complex assets with re-useable sub-assets.

So you've decided that you're gonna be a power author and make assets with re-usable parts, which can be updated independent of the main asset.
You are in dark territory friend.

To create a re-usable dependency, you need to follow a few rules.

• Upload the dependency first
  Get it activated
  Download this activated store version
  (note that the store version has been appended with your account name)
  Use this store version of the dependency in you main asset.
  
  Now upload your main asset.
  That's it.
  Any time you update the dependency, all main assets that use it will get the update.
  
  There are gotchas to watch out for when updating the dependency. See next thread. Below is a diagram showing how dependencies can be organized.

As mentioned in the previous post, dependencies must be store versions of an asset. This is because when an asset gets uploaded, it's name is changed to be unique.

When updating a dependency, you must edit this store version of the asset, which has it's unique name.

e.g. The wheel.otl, when uploaded, becomes user::wheel.otl

To update the wheel, and have it work as a dependency, you must edit this user::wheel.otl version which you downloaded from the store.

After you are finished editing, upload this user::wheel.otl and the store will recognize it as an update.

All assets that depend upon this wheel will receive your update.

The image below illustrates the relationship between the main asset, it's dependencies, the .hip file, and how their upload is managed.

The dependency (labelled “D.A.”) is uploaded to the store.
It gets activated
The store version (labelled “Store D.A.”) of the file is downloaded and used in a main asset (green “Big D.A.”).

The main asset is saved and uploaded to the store.

What about name space version numbers?

For example; if I upload xTools::xBend::1.0 to the store and people start using that version. What happens when I upload xTools::xBend::1.1

The reason the version number has changed is because it breaks parameter mappings with 1.0, and I wouldn't want people using 1.0 to receive updates.

I do want them to be updated to 1.1 when they create new instances of xBend.

This is currently how OTLs work. Does the store support this?

From what I know, if you change the version of your OTL, the store will register it as a new asset. So all changes that you upload without changing the version will be stored in the same asset, where people will always download the latest version. Otherwise it's a brand new asset as far as the store is concerned.

pusat
From what I know, if you change the version of your OTL, the store will register it as a new asset. So all changes that you upload without changing the version will be stored in the same asset, where people will always download the latest version. Otherwise it's a brand new asset as far as the store is concerned.

Does that also remove purchase history by users?
Also does the update notification inside Houdini still work?

AFAIK the purchase history doesn't carry over. Because if it did, then what if you want to charge for it? I am not sure though.

Update notifications should still work for the same assets. But it wouldn't notify Bend 1.0 users if you uploaded Bend 2.0.

pusat
AFAIK the purchase history doesn't carry over. Because if it did, then what if you want to charge for it? I am not sure though.

Update notifications should still work for the same assets. But it wouldn't notify Bend 1.0 users if you uploaded Bend 2.0.

So how it works now in Houdini is if you have both xBend::1.0 and xBend::2.0 installed. It'll only show xBend::2.0 in the tab menu. Any HIP files using xBend::1.0 will still use that version as long as it's still loaded.

If I wanted to update xBend::1.0 to fix an issue, then there isn't a problem.

Sometimes I want to “rethink” an approach to a problem, and that's when you increase the version number.

So shouldn't the store work the same way as Houdini? Both xBend::1.0 and xBend::2.0 should exist in the store, but only 2.0 appears in the catalog.

Purchase history should be the domain of the author. For example, I might change the math in xBend so that it's faster but produces a slightly different result. People's renders would be different during the life of a project if I just updated version 1.0. So I would publish 2.0, but that doesn't mean I want to charge them again but I still want to charge $$ dollars for that tool.

This kinds of requirements can be tough to nail down.

For most users,you should not need to add name spaces yourself at all. This is done automatically at upload.
If you want to save a little time on the upload/activation process, then do the following:

• Simply create your digital asset with the vine_from_curv name.
  Do this for all your assets, including dependent (nested) assets..
  IMPORTANT; create the dependency assets first. Don't use name spaces.
  Later, the store will append your account name onto the asset for you.
  
  Once your assets have been created locally, upload them in the following manner:
  Log into the store.
  in Houdini, go to your lowest level (most nested dependency asset).
  RMB over the asset on choose “upload to Asset store”.
  Do this for all the assets, starting from the bottom level and working upward.
  
  Now, where it concerns explicit version control, you may want to edit the version suffix manually. More to follow…

Logged RFE 50959: Hidden asset version # support

Good idea, thanks!

compositor

• Simply create your digital asset with the vine_from_curv name.
  Do this for all your assets, including dependent (nested) assets..
  IMPORTANT; create the dependency assets first. Don't use name spaces.
  Later, the store will append your account name onto the asset for you.

• 
  Firstly, this contradicts the Houdini manual.
  
  

  The namespace identifier lets you name your assets without worrying about using the same name as a built-in Houdini node or as a third-party asset you might use someday.

  
  This is useful for creating assets you might want to distribute to other users. It is also useful to allow separate artists in the same facility to create their own assets without having to worry about name clashes when their assets are used together later.
  
  This raises the question of why the workflow for the store does not follow the convention of the manual.
  
  Also, most users would first creating an asset for internal usage. So a namespace is required to prevent conflicts. The decision to add it to the store may come at a later unknown time. Your workflow assumes they are starting from scratch, but that seems to contradict the entire idea behind the store. The idea is “sharing assets you've created” compared to “creating assets to be shared”.
  
  

  A useful convention to ensure you use a unique namespace name is to reverse the DNS address of your website.

  
  Why isn't this convention being used by the store? If an asset has a namespace that is a valid DNS, then it should not have to be changed by the store. The store could also do a DNS lookup to verify the domain exists. Downloading a key file from the root could also verify DNS ownership. This is what Google and Yahoo do to verify domain ownership.
  
  If the asset does not have a namespace, then the store should be using a reverse DNS such as com.orbolt.username
  
  This was in the manual, but the store follows a different convention. I don't like things like that. Maybe I have O.C.D?
  
  Otherwise, I agree with everything you said.
  
  There is still another issue that has bugged me about the store.
  
  The idea of 1 asset per catalog entry. It's a real show stopper for me. I don't understand why this was done, because almost all the “tools” or “rigs” I've built in Houdini require more then one asset for harmonious operation. You could have an asset that handles the arm bones, another for the leg bones, another for face controls but they really are all part of a single character rigging tool. It makes no sense to sell each individually, and you can't make the “legs” asset an internal asset, because you never know how many legs a character might need.
  
  With the current model, the legs and arms would have to be items in the store with each having their own price, but worthless unless you buy the important “character rig” that uses them. You could give those away for free and character for the rig, but I just find the whole thing confusing and pointless.
  
  Already the store has started to collect useless common assets that are used by other assets from that author.
  
  One possible solution is to allow authors to “hide” assets that are just there for dependency reasons. These would be downloaded but not show in the catalog.
  
  Sorry, another one of my long store rants.

hopbin9
One possible solution is to allow authors to “hide” assets that are just there for dependency reasons. These would be downloaded but not show in the catalog.

+1

I just have uploaded a very small component that I use in different places but is too small I think to have around in the store. It will make sense as part of other assets.

I hate to raise this but…
a way of supporting two top level assets is to have an hda that oncreate extracts it's contents…not sure what kind of havoc this may create but it might be something to look into.

“Log into the store.
in Houdini, go to your lowest level (most nested dependency asset).
RMB over the asset on choose ”upload to Asset store“.
Do this for all the assets, starting from the bottom level and working upward.”

– Im a little confused. I thought one had to wait for asset A to comeback from the store before putting it in asset B?

From the thread im also learning/ assuming/ confused by a few things…

- versioning… Is this set by orbolt and therefore potentially different from a vesioning scheme I might use ie… v2.0 of smoo_tool could be version 1.0 on the store ?

- when a new version is uploaded…is there a way to designate it as an update or a significant ver change?

Assuming versingin X.YYY.ZZZ ….
I would expect…

X -changes are normally significant/incompatible changes. In this case I would expect it to be a separate listing/download AND the old to still be available - Is it? And if so it seems there is no way to designate upgrade vs new user price?

ZZZ change I would assume to be minor bug fixes, help, icons enhacing etc… and there for considered the “newest” of an asset –I think this is the case.

Then what about YYY changes – these are usually non breaking changes that may add a new or updated feature? Is there a way to designate these as an update like ZZZ vs as an upgrade/new version like X?

If an embedded (A) asset get update, how does its version affect the version of the outer asset(B)… ie I would expect ZZZ change in A to cause a ZZZ change in B. –But in the case of XX or YYY changes, the changes functionality of A could potentially affect OR NOT the featues and functionality of B – how will these case get handled. Is the author notified of all other asset embedding this one leaving it up to individual Author to decide the scope of the verisoning change?

Im a little lost on how version are kept consistant between tools, who sets them and how it might affect pricing. Can anyone clear up how this does or might work in the future?

The process for uploading dependencies can go two ways.
One is a bit faster than the other.
If you want to save some time, use the RMB>upload feature from within Houdini.This will…

• upload the asset to the store
  get it's new name
  and replace it in your working Houdini file.
  It eliminates the step (If you only use the website UI ) of downloading the updated asset from the store, installing it into your scene, just to find out what it's new name is.
  
  
  In either case, the asset needs to be approved before you will be able to upload the master asset with the dependencies already in place. Yep we're working on this one…

RE:contradictions between the store documentation and Houdini's, where it concerns versioning and namespaces.

Please remember that The Orbolt store is in Beta. A lot is changing on the fly in response to your input.
This can result in a lack of parity between the Orbolt Asset stores documentation and Houdini's. Sorry for the confusion, and thanks for enduring through our growing pains.

Namespace Prefix
The Orbolt store uses namespace prefixes to add the authors account name.
If you add a prefix to an asset, the store will replace it with your account name anyways.

Namespace suffixes are used to define upgrade versions. Those are meant for major changes to the asset that might potentially break compatibility. The store versions the minor changes and allows you to create a major revision. The major version of an asset will appear pretty much as a new asset. In fact it's not much different from renaming the asset.

• It will need to be purchased.
  It will appear twice in the store.
  If you want free version updates, do not add a version. The store will track free version updates, and display them at the store, and in the Details window when you click on the asset icon inside Houdini, in the Orbolt Asset browser window.
  
  Yes, there is potential conflict if you manually override either the namespace prefix or suffix.
  You could end up with an asset that is received by the store as a new asset, instead of an update.
  Your version numbers could become erroneous.
  Your versions could become doubled-up.
  Any of these could break dependencies with your asset.

First, Id like to point out that I wasn't clear that it can all be done inside session with dependencies upload – and thats just awesome :-D

Its not clear to me a couple the sceneries I had mentioned work out… namely feature enhancement that does not qualify a major leap – ie.. can the version be incremented as ie 1.0.0 -> 1.1.0 vs 1.0->2.0.0 to stick with fairly standard version conventions. Im not clear when referring to “minor” are we talking about what would normally be in the zzz part of xx.yyy.zzz?

And in both cases of a major breaking XX change or a feature enhance YYY change, if there a way to distinguish pricing for users of previous version – it seems like “no”??

id also like to point another thread I started on suites as it was straying from topic, but the idea of hiding would not really solve all situations on its own, when you want multiple nodes included – for those interested i outline some situations

Thanks for splitting the thread up and posting “Suites” separately.

As far as ‘minor“ versions go, you are correct in your belief that there is no way to make a ”minor" free version name on an asset. A version name change IS a new asset for all intents and purposes.

Simply put: A name change in the node type name is a new asset.

The only visible indication of free minor updates are what you see on the website and on the asset details window.


One of the guys here suggested that it might be possible to change the display name (the name displayed in the tab menu). I haven’t tried it though.

compositor
The image below illustrates the relationship between the main asset, it's dependencies, the .hip file, and how their upload is managed.

The dependency (labelled “D.A.”) is uploaded to the store.
It gets activated
The store version (labelled “Store D.A.”) of the file is downloaded and used in a main asset (green “Big D.A.”).

The main asset is saved and uploaded to the store.

Is it still limited to 2 levels? I'm asking because I have somebody being interested in a procedure I have, but it is consisting out of at least 5 level deep nested assets. :?
And is the procedure still as mentioned above?

Cheers!