Feature/extra checks and features

[brunomikoski]

This pull request introduces several improvements and bug fixes to the ScriptableObject Collections system, focusing on code generation utilities, filename validation, and object identity management. The changes enhance usability in the Unity Editor, ensure safe asset naming, and improve the reliability of collection item comparisons.

Editor Utilities and Menu Improvements:

• Added new menu items in SOCollectionsContextMenuItems.cs to generate all static access files and indirect access files for all collections, with proper validation to prevent execution during play mode.

Filename Validation and Utilities:

• Introduced IsValidFilename and ToValidFilename extension methods in StringExtensions.cs to ensure asset names are valid and safe for file creation, including handling Windows reserved names and extra invalid characters.
• Updated ScriptableObjectCollection.AddNew to use ToValidFilename for asset names, improving reliability of asset creation.

ScriptableObjectCollectionItem Identity and Lifecycle:

• Changed the GUID property in ScriptableObjectCollectionItem to a simple getter, and added an OnValidate method to ensure a valid GUID is generated in the Unity Editor. [1] [2]
• Updated equality and hash code logic in ScriptableObjectCollectionItem to use the item's GUID, improving object comparison and dictionary/set behavior. [1] [2]

String Sanitization Enhancement:

• Improved the Sanitize method in StringExtensions.cs to treat any non-alphanumeric sequence as a word separator, resulting in safer and more consistent asset names.

[lgarczyn]

I was wondering what's the purpose of the GUID generation. Wouldn't it be possible to just use an asset postprocessor to store the item's guid as soon as it is created? This would fix the issue of duplicating an asset also duplicating the guid.

[brunomikoski]

I was wondering what's the purpose of the GUID generation. Wouldn't it be possible to just use an asset postprocessor to store the item's guid as soon as it is created? This would fix the issue of duplicating an asset also duplicating the guid.

I remember having issues with the asset postprocessor in the past, where trying to serialize stuff at that stage was causing issues, but it could be definitly be one alternative.

But Ideally I need something super reliable for this, it should never be invalid, and it should be changing around since would make the indirect references invalid, I will take a look more into a better alternative

[lgarczyn]

I was wondering what's the purpose of the GUID generation. Wouldn't it be possible to just use an asset postprocessor to store the item's guid as soon as it is created? This would fix the issue of duplicating an asset also duplicating the guid.

I remember having issues with the asset postprocessor in the past, where trying to serialize stuff at that stage was causing issues, but it could be definitly be one alternative.

But Ideally I need something super reliable for this, it should never be invalid, and it should be changing around since would make the indirect references invalid, I will take a look more into a better alternative

I definitely end up with zeroed guids quite often, so I don't think the current solution is super reliable either ^^. I think Weaver uses asset postprocessors, and we used them pretty effectively to automatically store lists of sprites

[brunomikoski]

I was wondering what's the purpose of the GUID generation. Wouldn't it be possible to just use an asset postprocessor to store the item's guid as soon as it is created? This would fix the issue of duplicating an asset also duplicating the guid.

I remember having issues with the asset postprocessor in the past, where trying to serialize stuff at that stage was causing issues, but it could be definitly be one alternative.
But Ideally I need something super reliable for this, it should never be invalid, and it should be changing around since would make the indirect references invalid, I will take a look more into a better alternative

I definitely end up with zeroed guids quite often, so I don't think the current solution is super reliable either ^^. I think Weaver uses asset postprocessors, and we used them pretty effectively to automatically store lists of sprites

Humm yeah maybe I didn't noticed that they are going missing that often because of the previous setup that always fixed itself. Do you have some reproduction steps that I could debug why they are going invalid?

[lgarczyn]

Couldn't reproduce it for some reason, I just notice it later when it gets fixed and I see the git diff. In any case, relying on the item or collection editor to fix things is not very reliable.

[brunomikoski]

It has been working like that from the past 5 years, so its definitly reliable enough, but I'm testing with the post processor if improves things in any way