'Locking' objects (assets, entities, fields) so they can't be modified

[yaustar]

This requires extra discussion about what problems developers are trying to solve here. Some of the issues have been:

• Enabling an entity that needs to start disabled
• Accidentally making changes to an object
• Working on a set of assets that they don't other people on other branches to be able to modify (Git LFS Lock/Perforce lock behaviour)

Enabling an entity that needs to start disabled: Is pretty common, especially with UI. It's arguable it should be solved on a project code level where it's always set to be in the correct state at run time. What would be great is if an entity could be edited in a separate viewer (like a prefab editor). That way it can be worked with without enabling it in the scene.

There's also the opposite problem of wanting to hide an entity in the scene without disabling it.

Accidentally making changes to an object: Could we make it more obvious that changes have been made since the last checkpoint in the branch? Eg an orange dot?

Git LFS Lock/Perforce lock behaviour: I'm not 100% on this. It has been very useful in the past with binary assets on large projects. Would being more aware of changes in the project/making them more visible help mitigate this.

[Maksims]

There's also the opposite problem of wanting to hide an entity in the scene without disabling it.

That is doable by disabling model/render/element component.

Enabling an entity that needs to start disabled: Is pretty common, especially with UI. It's arguable it should be solved on a project code level where it's always set to be in the correct state at run time. What would be great is if an entity could be edited in a separate viewer (like a prefab editor). That way it can be worked with without enabling it in the scene.

Usually, the problem lies in code composition, where code is added to entities that are disabled, but easily can be added to parent for example.

[yaustar]

That is doable by disabling model/render/element component.

It's still modifying the entity though (and doesn't handle children). The ideal would be able able to hide an entity on the Editor level without having to modify the entity itself.

[Maksims]

It's still modifying the entity though (and doesn't handle children). The ideal would be able able to hide an entity on the Editor level without having to modify the entity itself.

Definitely worth knowing what context they have exactly. Often many problems arise from lack of adjusting workflows.

[ki11roy]

LFS is a weaker concept, as it prevents pushing locked asset to the central repository, but developer is not aware that it is locked and free to make changes until that push. And the Editor works real-time and can sync lock requests much better. A better description for the that is an editor lock, which means "I am working on the object, so it is read-only". At the same time, if you really need you can unlock the object, because it is more like a question of awareness and not permissions.

A good example would be using of Unreal Editor with Perforce, like How to Use Unreal Engine 4 With Perforce Helix Core, with an exception that we have no Check Out phase.

6. Use the Unreal Editor (If You’re A Designer or Technical Artist)

The Unreal Editor has built-in integration for Helix Core, maintained by Epic Games. Designers primarily use the Unreal Editor >with Helix Core for version control.

Asset files (with the extensions .uasset and .umap) are binary files modified in the Unreal Editor. They cannot be opened as text >or merged in a text-based merge tool.

When you want to work on an asset, you just click on it in a UE content browser. You’ll see a “check out” choice. The file is l>ocked automatically when you make that choice.

When you’re done editing files you have locked, check in or submit those files. This uploads the changes to the server and >releases the lock on the files.

Not sure how it should work across branches though. Maybe it should.

[Maksims]

Locking systems are used mainly in environments with async collaborative workflow, where conflicts of data due to multi-user edits on the same data are a problem.

We have a fully real-time environment, and using OTs, conflicts on multi-user edits are resolved immediately, so there is no need for a locking system from a technical point of view.

This is a team communication problem, not a technical one.

For larger teams, one good workflow tip I give is to use branches - as office rooms. If you want to collaborate with somebody, you go to the same room. If you need a solo environment, just go to an empty room. This conceptually fits way better to real-time collaboration + branches (versioning) workflow. Also prevents branch-per-feature workflow, which is not the best in terms of project size due to specific on the way versioning back-end is implemented in PlayCanvas.

[vmwxiong]

Bumping this to mention that we have a very frequently used template that we use to configure data for each of our stages. Designers create dozens of instances of this template for each stage, and change the values of each one. Everyone is aware that you should never apply changes to this template, but multiple times we've had designers accidentally hit apply, and essentially need to scrap all of their work since their last checkpoint as a result.

This feature would make things way less error prone. Thanks!

To add an example: Entity A has size set to 5 Entity B has it set to 6 Entity C has it set to 5 Template has it set to 1

If they hit apply on entity C's change, then set it back to 1, and apply again, entity A will take that change. Now scale this up to hundreds of entities across a scene, and it quickly becomes clear why this can't be fixed by just updating the template again with the "right" value.

[yaustar]

Another bump to this from a customer

[yaustar]

I've just spoken to another customer that would really this feature on a large team