IG mount point naming

[Lales.Charles]

Hi,

Stephane already mentioned this issue here:

Investigating with CIGI demo, simply changing IG mount point name, you quickly find impacted files:

• rain_decal_base.basemat and region_blur.basemat have some shader paths with "ig" in it
• IG_double_x64.dll IGEditorPlugin_double_x64.dll use such path to look for visibility tracker

If for the first we can update files, we're blocked by binaries.. and don't have other choice than to name as well ig.mount

For you to understand why we're doing things differently: we pack all (interesting for us) templates and addons in one location / repository / mount point read only. We even put there the .runtimes since that should be consistent over other machines. We do have then:

•  AH_UNG_ASSETS
  • addons
    • scans
    • vegetation
    • vfx
    • (not the weather since redundant / conflict with ig one...)
  • ig
  • vr

From app data, we try to use only 1 mount point shared_UNG_ASSETS.umount, that makes 2 issues -> ig is not named ig, and location is not direct to ig folder.

All this explanation to come to a proposition to improve mount point definition:

• "name" key optional to consider if declared instead of filename
• multiple mount points in 1 file

Let's consider following samples.

Standard ig.mount file:

{
	"version": "2.15.0.0",
	"data_path": "D:/wkspaces/AH_UNG_ASSETS_2-15/ig",
	"readonly": false
}

Renamed shared_UNG_ASSETS_ig.mount file:

{
	"version": "2.15.0.0",
	"data_path": "D:/wkspaces/AH_UNG_ASSETS_2-15/ig",
	"readonly": false,
	"name": "ig"
}

Extended shared_UNG_ASSETS.umount file:

[{
	"version": "2.15.0.0",
	"data_path": "D:/wkspaces/AH_UNG_ASSETS_2-15/ig",
	"readonly": false,
	"name": "ig"
},
{
	"version": "2.15.0.0",
	"data_path": "D:/wkspaces/AH_UNG_ASSETS_2-15/addons/vegetation",
	"readonly": false,
	"name": "vegetation"
}]

Of course if one location is not found, simply ignore it, but don't fail complete file load and other consistent path definition.. 

What do you think?

Feasible in coming soon 2.15.1?

Kind regards,
Charles

[silent]

Hi Charles,

Changing IG mount location is quite risky operation, we recommend to keep files and mounts structures as it comes with IG template.

I'm also not quite sure that I understand your idea about multiple mounts in a single file. What' the difference between 2 mounts with 2 files and a single mount with multiple entries inside? Right now we don't plan to extend mounts functionality due to a lot of already known regressions and overall complexity of testing and stabilization procedure.

That issue that you linked in your post is a simple bug and such situation should not lead to instant crash.

Thanks!

 

[Lales.Charles]

Hi,

It is more than recommend, it is clear constraint on ig mount point name..
There is no crash of the editor you're right, but multiple error msg...

Multiples mount points in one json array file reduce simply number of mount point files..
E.g. dealing with multiple terrains, with a common base, assets from you.. and especially multiple flying entities.. we start to have a lot.

What about the new optional property "name" to specify an alternative to the file name?
How ever the json are defined.. at the end, you have kind of map or dictionary <key, path> right?
Property name would simply override filename before to be set as key in this data collection.

Kind regards,
Charles

[silent]

Thank you for clarification!

I've added your proposal for multiple mounts in a single file to our internal tracker for devs to verify.

Right now it's not considered as feature yet, so it may take us some time to evaluate it and implement / not implement.

[Lales.Charles]

Thanks, multiple mount point in 1 file would interesting, but optional property "name" to override filename if declared is good as well.

Typically we could name ig.mount the way we'd like, and keep the system compliant with only "ig" everywhere.

Let's consider a mount point named shared_UNG_ASSETS_ig.umount -> here issue since it is not ig.mount.

{
	"version": "2.15.0.0",
	"data_path": "D:/wkspaces/AH_UNG_ASSETS_2-15/ig",
	"readonly": false
}

Proposition, one more time with optional key -> the same shared_UNG_ASSETS_ig.umount can be virtually considered as ig.mount

{
	"version": "2.15.0.0",
	"data_path": "D:/wkspaces/AH_UNG_ASSETS_2-15/ig",
	"readonly": false,
	"name or internal_name": "ig"
}

Regards,