Search Issue Tracker
Fixed in 1.0.0-preview.7
Found in [Package]
[InputSystem][Editor] Generated C# file is not checked out when overwriting
When using Perforce or PlasticSCM for version control, assets must be checked out for write access. The importer currently just goes and tries to overwrite file contents if the generated code has changed. This will fail if the asset is write-protected (IIRC Perforce indeed write-protects the files whereas PlasticSCM doesn't).
We need to communicate with the VCS integration to check out files, if needed.
May make sense to forego code-generation in this scenario. Something to consider.
1. Create project and set up Perforce integration for it.
2. Create .inputactions asset, enable "Generate C# Class" for it and check it in.
3. Check out the .inputactions asset, edit it, and save it.
Result: the .inputactions asset importer will try to overwrite the .cs file and thus produce an error because the file is read-only.
Expected behavior: The importer should first check the file out using Unity version control APIs.
Also, try saving out the `.inputactions` asset *without* checking it out. This results in an exception.
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
- NullReferenceExceptions are being thrown when saving a ScriptableObject with an array of a type with a CustomPropertyDrawer that uses TrackPropertyValue
- Applied velocity is inconsistent when using Rigidbody AddForce() with ForceMode.VelocityChange
- Crash on AudioUtil_CUSTOM_HasAudioCallback when exiting Play Mode while the Inspector is displaying a GameObject with an empty script attached
- Scroll offset is framerate-dependent when scrolling with velocity in the Device Simulator
- "Object.FindObjectsOfType<T>() is obsolete" warning is thrown when using "Transitions Plus" asset