Search Issue Tracker
Fixed in 2017.1.0f3
Fixed in 5.5.X, 5.6.X, 2017.1.X
Won't Fix in 5.4.X
Votes
3
Found in
5.5.2p4
Issue ID
895425
Regression
Yes
When using Perforce and re-baking a NavMesh, the file created gets marked for removal instead of checking.
When connected to a P4 database with a Navmesh file already in there, re-baking the same Navmesh will cause the file to be marked for removal upon next Version submit.
Steps to reproduce:
1. Set up Perforce server.
2. Open attached NavMeshperforce.zip
3. Commit and Update all files to server.
4. Select the cube and re-bake the navMesh
5. Observe how the already existing file is marked for removal instead of checking.
Expected outcome: File gets refreshed and marked for checking in the database.
Actual outcome: File gets marked for removal, because "there is already a copy of it in the database"
Reproduced on v 5.5.2p4, 2017.1.0a4
Regression from v 5.5.0f3
Sidenote: The user also mentioned that this issue also happens with OcclusionCullingData asset when using the occlusion culling bake window.
Fixed in: 2017.2.0a3
Backported: 2017.1.0b10
Backported: 5.6.2p1
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [Android] The warning "Internal: JobTempAlloc has allocations that are more than the maximum lifespan of 4 frames old - this is not allowed and likely a leak" is displayed when ShaderVariantCollection.WarmUp is called
- RectangleContainsScreenPoint returns false for some points even when the points are in the rectangle
- [iOS] Stacked camera does not render when using post effects
- TextField cannot be edited in an extended Editor window when double-clicking it
- [VisionOS] visionos build do not add plugin or frameworks
artofcode
May 09, 2017 10:57
For anyone else blocked by this issue, to resolve it, you'll need to revert the delete status, but before doing so, copy the NavMesh file to another location, so the new navmesh can be copied back over after the revert.
I made a batch file that I execute after the navmeshes got built in the script that performs this. Trying to do these steps through the Unity version control provider class didn't seem to do the trick and was causing a disconnect between the navmesh file and the scene.
Make sure the P4 variables are set in the environment variables (P4USER, P4CLIENT, P4PORT) and you can execute the following steps through a batch file: (Call it using System.Diagnostics.Process, using the absolute path for the NavMesh.asset file you want to fix the delete status for)
------------
copy /y "%1" "%1-backup"
copy /y "%1.meta" "%1.meta-backup"
p4 revert "%1"
p4 revert "%1.meta"
p4 edit "%1"
p4 edit "%1.meta"
move /y "%1-backup" "%1"
move /y "%1.meta-backup" "%1.meta"
------------
It might be possible to pass along the user/pass/host variables for P4 by extracting them from the Provider config variables. That way each user doesn't need to set the P4 variables in their environment variables, but haven't tried that yet.
artofcode
May 08, 2017 14:01
This is still an issue in 5.6.0p1.