koobas.hobune.stream
Using Hidden folders for editor stuff?
Hi I would have two scriptable objects one will be used on runtime but the other one that is related to the first one, will have stuff only related to custom editor windows, so i would like to have an Editor folder under a Database folder, the thing is that i would like to hide this editor folder from users both on windows explorer and the project view in unity (I know they can show hidden folders but that is the best i can do am i not?) why would i like to do it? to prevent users from fiddling with the scriptable objects inside the editor folder (that can cause breaking on the system) so I thought this would be used :
DirectoryInfo info = new DirectoryInfo(editorPath);
info.Attributes |= FileAttributes.Hidden;
At the same time i made a folder under assets directory and manually set it to hidden and launched unity, well, the folder didn't load in the project view, that is excellent, but now i have one question, will assets database load access this hidden folder? can i use such a hidden folder within code or will it fail? unfortunately, for few days i won't have access to the code at run time to see if it will work or not because i am doing massive refactoring, and that is why i am asking it, because if it won't work, i need to come up with another solution :/ (although i think i won't find any other solution at all)
You shouldn't even think about such an approach. Some kind of middleware shouldn't manipulate folders on my PC or trying to hide something inside the project. If you create middleware, your customers are other developers. If they break their project that's their problem.
There are two solutions which are acceptable:
Simply add a large comment header into the source file and explain that nothing should be changed in here or things can break. This is usually the best and easiest solution.
Compile your classes you don't want to be changed into an assembly. Of course you need seperate assemblies for editor and runtime code. Classes inside assemblies can still be used but not edited unless someone decompiles your assembly to get back the source code. This is what most plugin developers do. The advantage is that even several classes can be bundled into one "plugin". The disadvantage is that as a developer it's more difficult to understand what those classes do. They would need to use some kind of .NET reflector to decompile your dll.
Also keep in mind that if you want to create something for the assetstore that all users might want to use it. With all i mean also Mac and Linux users. Hacky solutions like hiding folders is a no go.
Hmm thanks for heads up, i didn't thought about mac and linux users, although i am already packaging the classes to a dll, but the thing is, what will sit inside that editor folder is a scriptable object that keep data related to editor stuff in it, those data will be related one to one to another scriptable object that is keeping the non editor and runtime stuff, the plan is to drop editor related data as building time so that the asset size and the amount of data being serialized become as $$anonymous$$imum as possible on run time. But i think you are right, specially when the thing i am developing would be a node editor for dialogue tree and behavior tree, then other users would be professionals, if not, the $$anonymous$$imum i can do is to figure a way to make a custom inspector with a bold yellow title alone that says, hey don't delete this asset manually and use the editor window :D
