Generated landscape .uts and .utsh files must be write-enabled in order for landscape to load properly with world

[josh.trevisiol]

Hello, 

I am working to establish an effective pipeline for landscape creation for our work environment(Using Unigine 2.7.1). We use P4V for source control and have run into an interesting hiccup regarding read-only files.

After landscape generation, the landscape and world look fine on my local machine. However upon pushing the files to the P4V Database, my local files become read-only unless I check them out from P4V. This is where we ran into the hiccup.

Once the local .uts and .utsh files are pushed to the Database and marked Read-only, upon startup of the level, the engine fails to load them properly. I tested several cases and it appears that it requires write permission in order to properly load the .uts and .utsh files and display the landscape.

This is true for all PC's that sync the world and landscape content to their local files. Each needs to check-out the files, flagging them as write-enabled, in order to load the landscape. 

This was also able to be replicated without using P4V, by simply using Windows Explorer to mark the .uts and .utsh files as read-only.

Naturally we would like to avoid this file check-out clutter in our process, however I understand that this may be a misunderstanding as I am still learning Unigine.

I'm interested in any thoughts that could help or shed light on the situation with .uts and .utsh file types.

Thank you!

Edited November 20, 2018 by josh.trevisiol
Included engine version

[morbid]

Hi Josh,

previously we had a flaw in the file system that you've currently faced. Terrain was unable to load read-only tileset.

This was fixed after filesystem refactoring in 2.7.2, however, we never tested terrain global with P4V, but if the issue is only in read-only files everything should be fine. 

Can you check your use case with the latest SDK?

Thanks.

[jsebens]

Thanks for the information, morbid. Our maintenance is currently expired. We are in discussion to renew it, but for now, 2.7.1 is the most recent SDK that we have access to. 

Does the filesystem flaw apply only during development, or does it apply to builds as well? If we are unable to package and ship read-only terrain, then that is a very serious deficiency.

[morbid]

Hello @jsebens,

read-only terrain doesn't work in 2.7.1. 

2 hours ago, jsebens said:

If we are unable to package and ship read-only terrain, then that is a very serious deficiency.

When you're planning to ship it, what is the term?

Thank you.

[jsebens]

Thanks @morbid. By "ship it" I meant to distribute to customers. We have been planning to make our next update with Unigine 2.7.1 regardless of maintenance renewal.

If terrain cannot be read-only, it presumably couldn't be packaged into .UNG files for distribution. But I just realized that we do not package terrain into UNG currently, so that specific part isn't so important. We would still prefer to install read-only files on customer machines, of course.

The bug is especially inconvenient during development, as keeping checked-in files read-only prevents problems.

If the code changes to correct the bug were simple, could you provide them to us? We are a source licensee, so we can incorporate them.

[morbid]

Well, I meant the project deadline :) Bad wording from my side, sorry.

We already checked this issue and the bug was easy to fix for windows. Do you need it fixed for linux as well?

If windows is fine you can use source code patch (check Personal messages please).

Thank you!

[jsebens]

Windows is all we need - thanks for the quick help!

[morbid]

Great, please write me back after you test it.