magique
Full Member
Posts: 194
Posts: 194 
|
Post by magique on Mar 17, 2016 20:15:49 GMT
Since I was working on integrating Curvy with CGK, I ran into the issue where code "inside" the Plugins folder cannot access code "outside" the Plugins folder. I solved this by moving Curvy inside the Plugins folder. However, Curvy is not a Plugin so it really doesn't belong there. As I see it, neither is CGK. The definition of Plugin in Unity is as follows:
In Unity, you normally use scripts to create functionality but you can also include code created outside Unity in the form of a Plugin. There are two kinds of plugins you can use in Unity: Managed plugins and Native plugins.
So, for it to be a plugin, it really would be some code developed outside of Unity and be in the form of a DLL. Is CGK an externally developed DLL? If it's code developed in Unity and is not external then it really should be outside the Plugins folder so that it can freely access other modules such as Curvy without having to re-located that asset.
|
|
|
|
Post by DarkTonic Dev on Mar 17, 2016 22:29:38 GMT
You are correct that it’s not a plugin by that definition. We chose to include source code instead of a DLL for several reasons. A couple are that customers with coding knowledge would not be able to point us to a specific line number of a bug or to send me proposed code additions (these both happen regularly).
Native and managed DLL’s are not the only usage of the Plugins folder. We primarily chose to put our assets there to reduce compile time. Yes, a DLL in any folder would also reduce compile time but the tradeoff was not acceptable due to the reasons above.
Anyway, compile time. Explanation: code in the Plugins folder is only recompiled when a code file in Plugins is changed. If we were to place Core GameKit in Assets, or Standard Assets, any time you modified one of your scripts (not even a code file in Core GameKit), Core GameKit code would need to recompile entirely (as well as any of our other plugins you may use). To summarize, another use of the Plugins folder is to place infrequently changed code there to reduce compile times. Actually, a lot of Unity users put ALL 3rd party code in the Plugins folder for this reason. There’s even a product on the Asset Store that moves assets there for you (Mad Compile Time Optimizer).
For your situation, you did move Curvy into Plugins, which is fine and will further help your compile times, unless Curvy is a DLL (which is already compiled). It still won’t hurt anything even if that is the case, unless the asset breaks when you move it. Many good assets will work fine when you move them because this is a common desire - to not have 30 top-level folders inside "Assets".
|
|
magique
Full Member
Posts: 194
Posts: 194
|
Post by magique on Mar 17, 2016 22:49:51 GMT
I believe you may be incorrect. Code only appears to be recompiled if a file has changed. If I change one file in my code, it doesn't seem to trigger compilation of other files that haven't changed. If it does then it sure re-compiles them very fast because I've never seen any huge compile times for a small code change on my part. Can you reference the documentation that shows that everything is recompiled? I'm looking for evidence of that now, but nothing definite so far.
|
|
|
|
Post by DarkTonic Dev on Mar 17, 2016 23:09:27 GMT
I'm not incorrect. My current game has about 24 assets from the Asset Store and compile times were about 30 seconds every time I changed a single C# file, just horrendous! I then moved all the assets into Plugins and only my game code remained in Standard Assets. Compile times are now 5 seconds unless I change a code file in Plugins, in which case it's back to 30 seconds. You either have an absolute beast of a computer or you just don't have that much code in your game yet, so it compiles really fast. My previous games were like that. Have a read of this on Reddit: www.reddit.com/r/Unity3D/comments/27geht/speed_up_c_script_compilation/, 3rd response "for those skimming". Also read this: answers.unity3d.com/questions/215517/how-to-get-faster-script-compilation.html, answered by Roberto_sc. and vigihome's comment on that about the separate csproj files for each special folder. A csproj file does not recompile if no file inside it changed. I know this is true because of my day job. I see it every day. Lastly, I found the actualy Unity page about this: docs.unity3d.com/412/Documentation/ScriptReference/index.Script_compilation_28Advanced29.htmlRelevant portion: "Scripts that are placed in the first group, will take longer to compile, since when they are compiled the third group needs to be recompiled too. Thus if you want to reduce compile times, put scripts that seldom change into group 1 and scripts that change a lot into group 3." |
|
magique
Full Member
Posts: 194
Posts: 194
|
Post by magique on Mar 17, 2016 23:19:54 GMT
Interesting. No, I have something much less than a beast for a computer that's for sure. And with all the assets I have in my project there are quite a number of scripts to compile as well, but it's still fairly quick. Although, at times in some of my projects I've wondered about it taking longer than I would expect. This is very disconcerting. If it can realize that it doesn't need to recompile scripts in Plugins then it's obviously capable of not recompiling things that haven't changed so it's so strange that they just automatically compile everything outside Plugins for no particular reason. Seems like an easy fix on Unity's part, but they obviously don't want it that way for some reason.
|
|
|
|
Post by DarkTonic Dev on Mar 17, 2016 23:39:28 GMT
I don't think it's anything in Unity's capability. Visual Studio projects (vsproj) just work like that. They have to recompile if something changed, to detect other compile errors and make a new DLL (or whatever Unity uses at runtime). It's the way Microsoft made it (or perhaps Xamarin attempting to mirror MS). And Plugins is a csproj, Standard Assets is, and so on.
No, no, everything outside plugins only compiles again if a code file there changed as well. Unless it's the group 3 depending on group 1 thing mentioned above.
|
|
