dotween
dotween copied to clipboard
Demigiant
Package Manager and assembly definitions
Are there any plans for moving onto unity's new package management system and usage of assembly definitions? Nothing urgent here, just an enhancement idea. Tried to move "Demigiant" into "Packages", added packages.json and registered it with manifest - so far works well. Utility Panel is dead though, probably it wants dotween folder to be at hardcoded place? I'm sure you are really busy, but just for the record dropping a few links on what I am talking about
https://docs.unity3d.com/Packages/[email protected]/manual/index.html https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
Besides utility panel, as to what I had to do to make assembly definitions work with DOTween:
- Create core asmdef file in "Modules" folder Seeing how project went modular way, there is a potential to breakdown every module into it's own folder and give asmdef file for every folder. That way switching modules will be as easy as having a core asmdef which adds/removes references to module assembly definitions.
- Put scripts from "DOTweenPro" into "DOTweenPro/Scripts" and create pro asmdef file in Scripts For some reason if I created asmdef in DOTweenPro as is some strange errors were popping up, got the feeling asmdef was fighting dll.
- Reference both core and pro asmdefs from source code
Ahoy!
Thanks a lot for the investigation on the matter: I will keep these info as a precious reference :) I'm waiting for Unity 2018.3 which will finally make the package manager available to everyone, and then I'll implement it for sure.
Cheers, Daniele
It is highly recommended that you use assembly definition files for all the scripts in the Project, or not at all. Otherwise, the scripts that are not using assembly definition files always recompile every time an assembly definition file recompiles. This reduces the benefit of using assembly definition files.
Important point, to support both methods it would be cool to have a checkbox in settings menu. Like, "Use Assembly Definitions". Since .asmdef files are plain text files, they can be generated and deleted with ease,
I'm maintaining a multiple projects setup that has a copy of DOTween in each sub project just because of the utility panel problem. So I hope this feature would be done the sooner the better. No pushing from me, though, just hope so.
I plan to finally experiment with asmdef today, but not on Package Manager to be honest :B It still seems very alpha so I'm verging on the side of "let's postpone that more".
@laicasaane can you explain me more? I'm not sure I understood everything of the setup and of the problem there :B
@Demigiant My project has been divided into 3 sub projects inside it, 1st is the core, 2nd is for the players, 3rd is for the content makers. All of them use DOTween and other libraries. Others can be made into local packages just fine, but DOTween couldn't. Actually I had reported that issue here https://github.com/Demigiant/dotween/issues/238
I know there wouldn't be any issue in runtime, and this only affects the Unity editor. But I really don't like errors and exceptions appear even in the editor, so I've to put a copy of DOTween in each sub project to avoid this exception.
I too had some problems trying to isolate dotween into a package for multiple projects environment. Don't have a playground at hand, but if I remember correctly the cause of the problem was something like hardcoded paths for some elements of the plugin. As in, trying to access files(settings or editor images?) from the "Assets/smthsmth" while real path for package is under "Packages/PackageName/Assets/smthsmth". Setting paths to resolve for Assets and Packages respectively, depending on if dotween integrated or plugged with project, should solve the issue. Another possibility of what might go wrong is Resources.Load api, since if there are a few packages/projects with same files it does not differentiate of what to use and things may go wrong.
I feel like this is actually a common problem for plugin makers this days. Unity is halfway onto breaking engine parts into packages, while some users are jumping ship and divide environment too. At this point I can only advice this approach to those who do not use plugins, have no plans to add them midway(which is hard to anticipate) or use them selectively - only tested and confirmed stuff. Meanwhile, let's hope DOTween will be able to support new approach sooner than later ;)
Ah! Thank you both for the info. I was going to post a new version with auto-asmdef creation which I just finished, but after reading what you wrote I'm going to try and at least implement a way to find DOTweenSettings in any folder, so even if I don't do Package Manager myself it should work for you. Back in a short while, I hope :P
Ok I created an external DOTween package and tried until now to make it work, but I finally had to ragequit :B I managed to get all references correctly, but the problem is that I also need to modify files via the editor, and it's a complete mess. I experimented but the lack of documentation is too great, so I'll postpone this for the day Unity decides to make Package Manager a little more open, sigh :|
In the meantime, here's v1.2.225, where I added a button in DOTween Utility Panel to create the asmdef files. It creates one for the modules and one for DOTweenPro loose scripts (if present). I managed to create DOTweenPro's directly in the DOTweenPro folder by manually adding references to the asmdef json when it's created.
Ahoy! The documentation remains too intricate (for the things I need to do with DOTween), so until Unity officially allows the implementation of external packages with at least some API I'm postponing this :|
Hi ! I'm using Git packages for most plugin I use in every project. It's sooo useful and easier to maintain. It's not too hard to use, you should look at it to make your plugin compatible. It would be awesome to not import it in every single project...
@mob-sakai made a couple of packages that are available via git https://github.com/mob-sakai/SoftMaskForUGUI https://github.com/mob-sakai/ParticleEffectForUGUI https://github.com/mob-sakai/UpmGitExtension
Mhmm ok you're convincing me to give this another try :P But I already know this will require quite a lot of time (I'll have to change the editor initialization logic of DOTween and other systems). I'm in crunch right now so I'll see if I can start working on this by the middle of next week.
I come back to it now and then, but always encounter new problems (see last one here). I definitely intend to work more on it but too much of DOTween is mutable and built with the options you choose via DOTween Utility Panel's modules, so it doesn't seem a good fit for the Package Manager. The alternative would be to make it less mutable like it was before, but I think that is a much greater advantage than PM.
Sooo, in short, for now there's no date for when this might happen, and it might not happen :|
I don't know why someone would desactivate basic unity modules. The only one I don't care, is 2D Toolkit.
But anyway, instead of having one package that is mutable, why don't you try to have multiple package and include them in the package manager when needed. You could have something like :
- DoTween.Core
- DoTween.Modules.UI
- …
That's how unity manage their own modules in the packages manager. And we can simply activate/desactivate a module by adding/removing a line in the manifest. Moreover, you can specify which revision you want if you need to support multiple unity version.
The separation into basic Unity modules was a feature that required a lot of work, which I added after some users asked it :B It's rather important because if, for example, you have no Physics in your game and no script referring it then Unity doesn't include the Physics system in builds, so it helps making builds slimmer by removing stuff you're not using.
The multiple packages idea sounds neat, I'm going to try that out :)
I've deployed a customized repo so I can use DOTween with Unity package management system. And it's working almost fine so far. The only thing broken is DOTween Utility Panel. The panel won't show, and the DOTweenSettings.asset is read-only. At the moment, this is my strategy to solve that problem: edit the settings within an empty project, then copy that settings asset file over the main project.
Really hope to use DOTween via UPM officially one day.
Sadly it's even more complicated than that. The Modules system changes actual DOTween files, so even if that would work it would overwrite all Modules-based DOTween scripts for all projects using the package, which is not nice :| I hope one day to give this more time (because it's gonna be a long and major refactoring) but I'm prioritizing other things for now (like a DOTweenTimeline which I've been working on for the last months :P)
Beside that feature you are working on, could you prioritize making the settings accessible no matter where it is? IMO this is the only problem urgently needs to be fixed. The modules system could wait.
I never really thought of implementing it with a "disabled Modules" option. I will think about it but it is kind of sad.
For the time being, I think you should let all modules turned on by default, and let people know that if we use DOTween as a package we won't be able to turn off those modules, and that should be the limitation at this point. I think since all modules are on by default, only in some rare cases people will run into any problem and have to import DOTween directly into their project.
This behaviour is more relax than the current one: the settings that is not editable directly in the project is really annoying.
@Demigiant If you implement UPM you could resolve this better.
Check UniTask repo on how implement UPM support:
https://github.com/Cysharp/UniTask#upm-package
Then you could separate in more packages.
com.demigiant.dotween com.demigiant.dotween.ugui com.demigiant.dotween.physics ...
And we would use the packages we want.
Regarding DOTween *.asmdef support I have a problem and is that if I enabled it it would generate a different *.meta with a different GUID. I have my packages depending on DOTween by GUID so in different projects your *.asmdef GUID is different and it brokes our references.
I don't know why someone would desactivate basic unity modules. The only one I don't care, is 2D Toolkit.
But anyway, instead of having one package that is mutable, why don't you try to have multiple package and include them in the package manager when needed. You could have something like :
- DoTween.Core
- DoTween.Modules.UI
- …
That's how unity manage their own modules in the packages manager. And we can simply activate/desactivate a module by adding/removing a line in the manifest. Moreover, you can specify which revision you want if you need to support multiple unity version.
@Demigiant If you implement UPM you could resolve this better.
Check UniTask repo on how implement UPM support:
https://github.com/Cysharp/UniTask#upm-package
Then you could separate in more packages.
com.demigiant.dotween com.demigiant.dotween.ugui com.demigiant.dotween.physics ...
And we would use the packages we want.
Regarding DOTween *.asmdef support I have a problem and is that if I enabled it it would generate a different *.meta with a different GUID. I have my packages depending on DOTween by GUID so in different projects your *.asmdef GUID is different and it brokes our references.
+1 to both of these suggestions. TBH it feels like users asked for the DOTween modules approach because it was basically a workaround for the lack of a proper package management solution. Now that upm exists, I think the DOTween modules implementation is no longer necessary and should be replaced with separate packages that depend on a core package. Users can then decide via the package manager which modules they want.
It seems like the main blocker is the fact that specific ScriptableObjects are assumed to be in specific locations in a project. I think this is generally a risky approach since it makes lots of assumptions about project layout. A suggestion I have is to invert the dependencies - either pass in references to the ScriptableObjects when you need them, save them off as properties so they can be set independently, or provide callbacks to let the user supply the objects. As far as the utility panel, maybe you just don't show anything until the user drags in or provides a location for the Settings object.
I know that this would be a major refactoring, but it's worth it. upm is here to stay and all of Unity's engine components are being converted to use it. I think the comments blaming Unity for lacking documentation are unfair honestly. The documentation is quite good IMO and lots of plugins are starting to refactor to support upm (NaughtyAttributes, Deform, etc).
We are just in the middle of packaging all our plugins and modules through UPM as well and actually the only 3rd party asset that can't be used through UPM seems to be DOTween. At this moment it can get so critical we will be probably looking to implement our own tweening library rather than using DOTween the old fashioned way, which in a big company was clunky to begin with. So we are welcoming Unity's modular iniciative and UPM and hopefully DOTween can join the bandwagon.
Huge DOTween fan, would love to use it as a package as well. Any update on this? Unity move towards packages seems to be clear.
Seems like someone hijacked (maybe not intetionally) the DOTween package on OpenUPM: https://openupm.com/packages/com.demigiant.dotween/
@leandro-manifesto The problem is there is no way we can edit DOTweenSettings even if there is a copy in Resources folder
I don't know what the hijack means :B I've continued to make tests and discuss the issue with other devs (since by now I gave up hoping that UPM will get better and more dev-friendly) and I think I have a way (inspired from your suggestions of separating modules in packages), but it's a really complicated way that will take a while to be implemented and I'm giving priorities to other DOTween stuff first (like the Timeline, if you heard about it). I really have no timeframe for this. After I release the Timeline I will probably move to this though.