Can materials and animator controllers be moved to its own folders in Unity

Harald · 1 июл 2024

belovedquestioningly Submit the assets to a server;

Please always describe any steps as precisely as possible. "the assets" is very vague, did you add all assets of the folder to version control? "submit to a server" is very vague as well. What version control software you're using, how did you submit the assets?

I have to repeat the question of my previous posting, since you haven't answered it:

Harald What are the changes you see, can you share a diff? In general please always describe everything with as much info as possible.

Bbelovedquestioningly · 10 авг 2024

Hi Harald,

Apologies for my late response, I did not have access to my machine for some time. Answering your questions, by assets I meant the files in the picture attached which is the
All three files generated by spine export
.atlas.txt
.png
.skel.bytes

Files generated in unity
the material file generate
skeletondata asset
animatorcontroller

Can you describe what "What are the changes you see, can you share a diff?". Would you like to see the diff for these three files?

Harald · 12 авг 2024

belovedquestioningly Can you describe what "What are the changes you see, can you share a diff?". Would you like to see the diff for these three files?

Yes. It would be interesting to see a diff of the files that you find problematic that they changed. You posted the following text earlier:

Which when connected to a version system, (we used P4V), it marks the files _Atlas.asset and _Material.mat as modified even though there are no visible changes. Is there a way to avoid this? Thanks.

Since there are no "visible changes" that you see, it is necessary to see a diff of these files.

Bbelovedquestioningly · 15 авг 2024

In Unity what I see,

Diff in perforce looks like the two assets are unmodified, if I choose ignore line endings:

If I chose recognize line endings and whitespace:

Harald · 16 авг 2024

belovedquestioningly Thanks for the additional info. Then it's highly likely that you've configured your version control system to always checkout files with a different line ending (e.g. lf instead of crlf) than the one that Unity produces when writing asset files on your machine. So when you checkout your files, you receive one line ending and when Unity just touches the file it's of a different line ending. You thus need to make sure both line ending styles match to avoid undesired diffs.

Bbelovedquestioningly · 16 авг 2024

The checkout happens in Unity and looks like it is because of Line 698 which marks assets dirty even though there are no changes.

Harald · 19 авг 2024

@belovedquestioningly Sorry, the term checkout I used might have been misleading here. I don't mean "checkout for editing" but in git terminology meaning "download and setup of your local files by your version control system".

In general your version control system should not care whether Unity's asset database marks anything as modified if there is no actual diff of the files. That is, unless Unity is configured to lock or check-out-for-modification any files in your version control system upon marking them dirty and performing the asset database save operation. However, you said that these files are marked as modified and not as checked out / locked (and the icons in your earlier posting look like that as well).

Do you and your colleage (where you get the differences) perhaps work on MacOS and the other one on Windows? As Unity seems to always use LF line endings for asset files regardless of platform, it might be that one of you has your version control system configured to convert line endings to a common format different than Unity's LF. This line ending conversion typically happens either upon checkout (local download) or upon commit.

Bbelovedquestioningly · 19 авг 2024

Both me and my colleague work on a Window Machine, the project was also developed on a windows machine.

Sorry I should be clearer, by modified I mean it marks the asset as modified for Perforce to pick up. With my experience with SetDirty function, it is possible that using it will mark it modified for Perforce to pick up even if there is no differences.

Here I have attached a dummy script that marks selected asset dirty:

using UnityEngine;
using UnityEditor;
public class MarkAssetDirty : MonoBehaviour
{
    [MenuItem("Assets/Mark Selected Asset Dirty")]
    private static void MarkSelectedAssetDirty()
    {
        Object selectedObject = Selection.activeObject;

        if (selectedObject != null)
        {
            // Mark the selected object as dirty
            EditorUtility.SetDirty(selectedObject);
            // AssetDatabase.SaveAssets();

            Debug.Log("Asset marked as dirty: " + selectedObject.name);
        }
    }
}

I have run this script on my prefab, which in perforce turning off line ending difference shows no changes,

and if I turn on line endings

but the asset is checked out

Harald · 20 авг 2024

belovedquestioningly With my experience with SetDirty function, it is possible that using it will mark it modified for Perforce to pick up even if there is no differences.
..
which in perforce turning off line ending difference shows no changes,
[image of no differences]
and if I turn on line endings
[image of full file marked as different]

I'm not sure I understood you correctly, as the above seems contradictory: If turning off line ending difference shows no changes, but turning on showing line ending difference displays the whole file, it means that there are line-ending differences comparing the old and new file state.

This would easily be explained if beforehand line endings were e.g. CRLF (e.g. due to Perforce downloading or committing files in CRLF line ending), and after Unity writes the same file, they are LF.

Could you perhaps send us one of the problematic files in the two versions, once before they are touched by Unity, and once afterwards (when perforce lists them as checked out or edited). You could attach the files to a forum posting or send them to us via email to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context.

Harald · 20 авг 2024

Harald This would easily be explained if beforehand line endings were e.g. CRLF (e.g. due to Perforce downloading or committing files in CRLF line ending), and after Unity writes the same file, they are LF.

This behaviour would also be confirmed by the default line ending settings in Perforce here, which are to use local, meaning CRLF on windows. So every time you get the latest revision from the p4 server, you get CRLF files, and when Unity touches the file it's LF.

Bbelovedquestioningly · 21 авг 2024

File in state before opening in Unity:

When Unity is opening and since I have notepad++ open during this process, it shows file modified

after Opening in unity:

File 1: Before Unity

spineboy-pro-atlas-preunity.txt

632B

File 2: After Unity

spineboy-pro-atlas-postunity.txt

632B

Harald · 22 авг 2024

belovedquestioningly When Unity is opening and since I have notepad++ open during this process, it shows file modified

Note that Notepad++ uses the file modification date for that, not actual diffs.

Thanks for sharing the additional files, these are now identical and display no diff in Perforce Merge:

Unfortunately this still does not answer the important question: When viewing the version control state of the file, did this file show as "not modified" or "not checked-out" before opening Unity and show as "checked-out for editing" afterwards?

I'm asking mainly because the above (no line ending diff) contradicts what you've posted previously, the screenshot of the Perforce diff showing line ending differences:

belovedquestioningly and if I turn on line endings

The important remaining question is the following:
Whether when committing the file you sent us with LF line endings to your repository, then checking in e.g. Notepad++ that there are LF line endings, and then opening Unity, is the file afterwards marked as "changed" or "checked out for editing"?

Bbelovedquestioningly · 23 авг 2024

Yes originally I had my workspace set to be on local (which is windows and made it look like there were line ending changes in my first screenshot), but after I manually set it to use Unix and force got latest before opening in Unity which sets the line endings of file as LF on my local machine, when Unity opens, files are marked "Checked out" that has this tick symbol in unity

When viewing the version control state of the file, did this file show as "not modified" or "not checked-out" before opening Unity and show as "checked-out for editing" afterwards?

Yes

Here is a video of the whole process:

Harald · 23 авг 2024

belovedquestioningly (which is windows and made it look like there were line ending changes in my first screenshot)

The Perforce diff showed 1 line ending or whitespace diff. If there were no line-ending differences, then it must have been other whitespace differences.

Here is a video of the whole process:
..

Thanks for making the GIF. This video however again shows that you are having 1 diff of line endings or whitespace:

The two files that you sent us earlier showed no diff even with comparison method - line ending and whitespace differences enabled.

Bbelovedquestioningly · 23 авг 2024

Harald Yes so I am not sure what change I should do on my end.

Harald · 26 авг 2024

@belovedquestioningly I have just performed some tests locally with Unity's perforce integration. It indeed seems as if the line endings are not the problem, but just the Unity integration which performs an auto-checkout.

The non-zero diff likely comes from CRLF line endings on the server file revision, which just shows when comparing the server's head revision (displayed as having CRLF line endings, even though according to config should not be using CRLF strangely) against the local workspace copy (correct LF lineendings). As a result you never saw the CRLF line endings in the Assets folder or in the files you sent us, since it's only the temp server-revision file which shows CRLF endings.

We'll see if it can somehow be avoided that a checkout is triggered (by re-serializing the assets, even if the result is the same) even though leaving an unmodified file. You could of course use "Revert unmodified", but I understand that that's somewhat inconvenient and could be forgotten.

Harald · 30 авг 2024

@belovedquestioningly We have just pushed a commit which fixes the unnecessary auto-checkout of Perforce on identically re-created assets by programmatically reverting the files if unchanged. The issue has been tracked under this issue ticket:
EsotericSoftware/spine-runtimes2618

A new spine-unity 4.2 unitypackage is available for download here:
https://esotericsoftware.com/spine-unity-download