.runtimes, .meta, mount points and file path

[Lales.Charles]

Hi,

We are still struggling to define a proper setup insuring .runtime and .meta stable over different machines.

To our knowledge, same file but different location -> .meta changed.

Using mount points, we tried to setup same drive letter, using cmd subst.. but we still then have modifications.

Could you explain bit more how file hashes are calculated?
What would you suggest? 

Kind regards,
Charles

[silent]

Hi Charles,

It would be nice if we can do the same steps that you and get the same results. Could you please give us a detailed step-by-step guide (and maybe some example test files that are having different .meta)?

Thank you!

[Lales.Charles]

Sure, right now what we observed:

• Plug external SSD 2 times, using other USB devices, induce a change in letter of this SSD
• Mount same drive e.g. U: towards these different locations
  > subst U: D:/wkspaces/ and the other time, > subst U: E:/wkspaces
• In both situation, use a mount point declared as follow:
  {
  "version": "2.15.0.0",
  "data_path": "U:/AH_UNG_ASSETS/",
  "readonly": false
  }
• Between D: and E:, even if in mount point it is U:, it seems that .meta (hash) change..

Regards,
Charles

[silent]

Thanks for the clarifications!

We will try to reproduce this behavior and see what we can do about it.

 

[vvvaseckiy]

Hello Lales.Charles,

Unfortunately we were unable to reproduce this issue by provided steps, so it's might be that type or structure of assets may affect reproduction. Could you please attach example of file(+ .meta) which meta's changed in mount, or at least specify which type of asset exposed to this behavior. 

Also, does this bug reproducible in basic mount setup on local drive, or it only appears with virtual drives?

[Lales.Charles]

Hi,

You're right, I performed complementary tests using empty project + 1 mount point -> drive mounted doesn't impact.

But then I found out maybe what we're doing not right: rebuild .runtime.
Keeping exactly same file system (mount point, drive letter), we do have differences in allocated id to some ObjectMeshStatic.
I guess this is what we were doing between 2 different machines, to reset our .runtime, expecting consistency.. 

Is it normal?

Regards,
Charles

[vvvaseckiy]

If I understood you correctly, you only share .fbx + .meta between two different machines, and .runtimes generated each time on both machines. If that so, it is expected for node id's to change on generating runtime. If node id's required to be the same, .runtimes should be stored with assets, and assets shouldn't be reimported

[Lales.Charles]

Hi,

Exactly, it wasn't sure how optional or required it is to put .runtimes under versioning (Plastic SCM) as well.
In fact, depending on access rights and client picked (Gluon let user select sub part of the repository),  .fbx + .meta in local may vary.
If the user get all .runtime, more than needed, then he'll get some wng or err msg.. or?

So, if we put .runtimes as well, that's fine.
But how to make sure .runtimes are consistent to current .fbx + .meta?
(External modification, e.g. Plastic or Explorer)

Kind regards,
Charles

[silent]

Hi Charles,

Quote

But how to make sure .runtimes are consistent to current .fbx + .meta?

The only way to do this is to work with the repo that contains all the sources for these runtimes, so the Editor would be able to control the full cycle of asset lifetime (importing, changing, renaming and so on). 

In other cases when you starting to do a partial mounts / unmounts from different proects, use windows junctions / hardlinks you may (or may not) have some guids desync occasionally.

Unfortunately, there is no solution exist that will prevent this from happen. From time to time you may observe various errors that you would need to investigate and fix (we are also doing the same fixing for our internal repos, so if there was a way to avoid it - we will be very happy).

[Lales.Charles]

Ok, then why node Ids in runtime files are changed at each runtime generation?

As you suggest (and seems to do internally), we will rebuild times to times our runtimes (eventually continuously on Plastic event trigger).. and will have to live with useless changes on some .runtime

Clearly, but you can say no: would you share LoC for file hash generation, as for these ids?
It is only for our info and understanding ;-)

Regards,
Charles

[silent]

Quote

Ok, then why node Ids in runtime files are changed at each runtime generation?

That's because they are always being generated as random numbers. And they are still generated as random, so there is a little chance that this IDs will match. If you will open any NodeReference for edit inside working Editor all the IDs will be also regenerated, but it doesn't mean that there is any issues with the content itself, it's just working like this.

Maybe initially we would be able to find a proper solution for that, but that for sure would need some more time.

Thanks!