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



Found in


Issue ID




When using Perforce and re-baking a NavMesh, the file created gets marked for removal instead of checking.

Version Control


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
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

Comments (2)

  1. 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.

  2. artofcode

    May 08, 2017 14:01

    This is still an issue in 5.6.0p1.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.