Unity Visibility changes for preview packages in 2020.1

My opinions (as I believe this actually signals more than a UI change):

- Anticipate this not improving the situation much assuming issue is more with casual users - foresee more manifests on forums that people blindly copy

- @Korindian's post was great and status updates in forums would be fab. Though, surely not a new idea? I had assumed the cost of post-justifications of changes to earlier experimental stuff explained the lack of appetite for this. That said, if this happened - a paragraph summary in the package manager would be even better! Get all the status updates in one place.

- Experimental/verified status feels quite arbitrary. I believe In or Out exacerbates this. Is Collab in? Is Timeline? They have worse bugs than Burst or Entities imo.

- Discoverability/transparency is the change (not manifest v pacman). Developing an asset for years and accidentally finding out about DOTS.Timeline exists was painful and that wasn't even ever exposed in pacman - what other channel is there for finding out what Unity's working on so we can avoid overlap? It's part of a larger problem and I'm talking stuff in development for multiple years, not hack-week projects.

Appreciate anyone taking the time to read the above and all the hard work that everyone @ Unity puts in.

 

Definitely the wrong direction, in my opinion. Packages were clearly optional, previews were clearly labeled as such, there was no problem at all. There's really no need for extra hoops for this.

And to be honest, the way things are in the newer Unity versions is downright condescending. First, it's hiding preview packages. Then I enable them, in a wholly seperate menu, get *another* checkbox asking me if I am really sure that I am clicking what I want to click, then finally get stuff enabled...

....and Unity is STILL hiding stuff like the Entity package making me look all over if I missed something until I discover this thread. It's really not a good way to approach anything, and doesn't really inspire confidence in DOTS, which is a shame.

 

Maybe if Tech Stream versions can be the old way, and LTS version is new way. Most of the people complaining now would, I imagine, be on a Tech Stream, so they do as normal. And anyone building something permanant and new people will be automatically funneled to most stable LTS.

 

To be honest I'm REALLY glad that Unity is starting to clean up and curate the package list. There have been many times where I start working with a "preview" package thinking that it is almost ready for prime-time with only a few rough edges, and come to find out that it's basically pre-alpha, barely functional, and constantly has code breaking changes that require hours to fix. The term "preview" gives people the wrong idea and can waste a lot of time.

But I also agree with the people here saying that we should be able to opt-in to see and use experimental packages if we want, after signing off on a warning pop-up or something.

Here's my recommendations for the Unity team (if you're out there):

1. Scrap the "Preview" label
2. Categorize each package based on it's production-ready status:
   1. Verified
   2. Experimental-RC (Release Candidate)
   3. Experimental-Beta
   4. Experimental-Alpha
   5. Deprecated
3. Verified packages are always visible, but the other packages you'll have to "opt-in" and sign off on a warning.
4. Stronger warnings or opt-in requirements the more experimental / unstable the package is, so people know exactly what they're getting into.

**EDIT** Just saw DanielTG from Unity's post about this on June 30. Looks like we're basically on the same wavelength, which is great to see. So based on his post, the new categories will be:

1. No label (Verified)
2. Pre-release (Close to production ready)
3. Experimental (Basically in Alpha / Beta and will likely have code-breaking changes)
4. Deprecated (Hidden)

I like it! Looking forward to seeing this in the next release.

 

It's easy when you start out as a programmer to think you have to build things so robust that no one else can break them, but it's much better to just build a clear API and let people break things so they can learn and give feedback

Don't shoot yourself in the foot again unity. A package manager that can't browse all packages is an oxymoron. I definitely agree with a lot of the positive improvements but that is not a good idea, for all the aforementioned reasons

 

First you added packages in asset store (like textmeshpro and postprocess long time ago), then you moved them to package manager. Now you take some of them and hide them totally. Looks like hide and seek. "Pss, guys, wanna some dots? our managers hid them from you. find all dots parts in different places" .

But I think these are good news. first we will get the clean package manager and 2020.1 release soon. I think we will have things like burst and jobs. Entities package is not production ready and you clearly showing it in this decision. Its not a big problem to hide it, cause we can install it manually if we want bleeding edge techs and some beta test. The only thing I dont like is the order of your actions. Why not to give a solution for package manager before destroying the old one? Look at forum, people spend hours searching "what happenned and why". People even install old versions of Unity to continue testing them and to see packages in future versions.

I think these happened cause DOTS and features PR started too early. Too many things to handle quality. Its not a game jam, its a propriatary engine. I hope you know what are you doing.

Thanks for the actual news. Hope 2020.1 will be released soon. And I hope DOTS will be published. Maybe not in 2020. Thanks for your work guys.

 

The more I think about this the more I think its a terrible decision. I don't disagree that some packages have been perceived as being more ready than they are but I think the whole business of the preview label did little to dissuade that. You have many pages of marketing dedicated to talking about how dots is already the best thing since sliced bread, how tiny will revolutionize mobile, which end up linking to these things(and some really outdated links too). Its not just the discoverability of these things in the package manager.

For things that are no longer in development, they should be clearly marked as so in their description.
For things that we in very early development, they should've been given a better warning. Unstable, unsafe, prototype, experimental, all things that better convey it could be a rough ride if you decide to install such a package. Preview? That sounds like what you get at the cinema, almost something you could take for the real thing.

As mentioned in perhaps a tongue in cheek manner, package manifests containing hidden packages could be easily distributed, users could still install their way into a combination that doesn't work or they don't know anything about and you would still end up with the same problem, people talking about how xy or z being broken and this change would have done nothing to prevent it. The packages themselves don't contain much in the way of warnings or disclaimers.

Finally it makes it harder and more painful for us who do use them. I foresee bug reporting and making repro projects being far more tiresome than need be, if I need to refer to some obscure and outdated(because these forum threads tend to go that way) list of packages if I want to test combinations.

You guys should own that they are experimental and unstable, wear it on your sleeve, take some queues from nature put some big black and yellow warning signs when users go near these things. I don't see sweeping the mess under the rug(which I think you very much pulled out from us) being all that useful longterm.

 

TLDR:

• I 100% agree with everyone that has suggested more meaningful labeling in the package manager such as alpha, beta, release candidate, deprecated, and obsolete would be helpful.

• I also agree that a far better solution in the near term would be just to add another "show experimental" checkbox somewhere and maybe even a "show all" checkbox. Essentially this amounts to adding more filtering options.

• A better solution is create a more advanced package manager that can handle the complexity of a more advanced Unity engine.

• Hiding packages that Unity is tired of hearing complaints about and making them hard to discover is a really lazy and anger inducing solution.

Full Thoughts:

The Problem:

• Changing the Unity engine to be modular in nature was a great decision.

• As Unity has become more advanced with new packages being added, old packages being removed, and many complex dependencies between packages that need to be managed, it is clear that a more robust and feature rich package management system is now required.

• The crux of the current decision to remove/hide some packages seems to be that that package manager is simply not advanced enough to handle the modular design of the Unity engine.

• The particular pain point seems to be that there is there is no way to view/search/sort/filter packages in way that is meaningful "in the moment of the task" (aka, meaningful to what I'm trying to do at the time).

• This is leading to confusion as to:
  • Finding the package I'm looking for;
  • Figuring out which packages are stable and which are not (many preview ones are stable enough);
  • What are the dependencies between packages, and in particular what if I use two packages that have a common dependency, how can I see that?
  • All of this points to problems with poor organization, poor labeling, and poor visibility of information.

• It also leads to frustration from Unity for exactly the same reason, users are confused and complain about it on the forums, which leads to the impression that things are going in the wrong direction, or are too broken to salvage (neither of which are true).

• The solution isn't to abandon the package manager and hide or remove "problematic packages". It's to continue the development of the package manager, adding the more advanced features needed to support the modular design of Unity engine.

Proposed Solution (or at least a few ideas):

• The package manager is essentially the "asset manager" for the bits and pieces of the Unity engine itself. As such, ALL packages, regardless of their current state, should be a managed by the package manager (opposed to hidden away in a repo somewhere or on some list in a forum)

• Each package should be labeled or tagged in a sensible manner.
  • development state tags: experimental, preview, verified, deprecated, etc
  • categorization tags: Dots, XR, physics, graphics, sound, etc.
  • feature tags: HDRP, URP, ECS, 2D, XR Toolkit, Unit Testing, etc.
  • hint tags: mobile, apple, vfx, film

• Having meaningful tags would allow the search/sort/filter features to be opened up to users, allowing us to better find the packages we're interested in at that moment.
  • The simple "alphabetical list view" of all the packages is not enough anymore.
  • As Unity becomes more advanced, we need more advanced ways to explore and manage the packages and their dependencies.
  • Advanced searching, sorting, and filtering on tags would vastly improve the situation.

• The packages should be able to be organized into different views according various criteria.
  • Most asset management systems allow assets to be viewed in at least 3 ways:
    • List view (with the appropriate search/sort/filter applied)
    • Icon view (same a list view, but with a small icon instead of as a row in list or table)
      
    • Tree view:
      • based on dependency (this would allows us to actually see dependencies)
      • based on categorization of tags (similar to the way folders work on gmail or the way you sort spreadsheets based on column labels).
  • Having multiple ways to view packages is essential as the number packages increases and their development status changes mid-production.
  • It's important to realize that no two people will want to view packages the same way. Having options helps each person view the information they want in the way that they need for whatever task they are trying to accomplish. It changes from moment-to-moment.

• The dependencies between packages needs to be more visible.
  • Typically a tree view (hierarchy) is used for this
  • If a package depends on another, the dependency should show up as a parent-child relationship in a treeview.
  • It is okay for the same package to show up multiple times under different parents. This makes it clear that multiple packages depend on it.
  • Again, having multiple choices on how to view the dependency graph is helpful in this situation (look at any software development IDE. They all have multiple ways of viewing dependencies).

• The details pane in the current package manager already has 95% of the information I want, so I don't have any real complaints there. Maybe move the version information out from under the package in the list view and add it as a dropdown in the details pane.

And that's what I think about this whole thing. Unity, please do not shy away from creating a more advanced package manager that can actually handle the complexity of a more advanced Unity engine. You are on the right path, and yes you have some hard work ahead of you, but don't give up! With some effort, the package manager can be fantastic.

In the meantime, please do not hide or remove packages from the package manager. As a stopgap solution, please just add more filters such as a "show experimental packages" and "show ALL packages". Removing them adds yet another barrier to those of use that are actively using DOTS, XR, and many of the other preview packages on your list. It's already hard enough to get up and running.

Thank-you for your time. All the best. Good luck!

 

super frustrated finding stuff, searching git is tedious. I think a complete com. list help
eg.
com.ptc.vuforia.engine
com.unity.2d.entities
com.unity.ai.planner
com.unity.aovrecorder
com.unity.assetbundlebrowser
com.unity.assetgraph
com.unity.barracuda
com.unity.barracuda.burst
com.unity.build-report-inspector
com.unity.cloud.userreporting
com.unity.collections
com.unity.connect.share
com.unity.dots.editor
com.unity.entities
com.unity.film-tv.toolbox
com.unity.google.resonance.audio
com.unity.immediate-window
com.unity.mathematics
com.unity.meshsync
com.unity.multiplayer-hlapi
com.unity.package-manager-doctools
com.unity.package-manager-ui
com.unity.package-validation-suite
com.unity.physics
com.unity.platforms
com.unity.platforms.android
com.unity.platforms.linux
com.unity.platforms.macos
com.unity.platforms.web
com.unity.platforms.windows
com.unity.playablegraph-visualizer
com.unity.render-pipelines.lightweight
com.unity.rendering.hybrid
com.unity.renderstreaming
com.unity.scene-template
com.unity.simulation.client
com.unity.simulation.core
com.unity.simulation.capture
com.unity.simulation.games
com.unity.standardevents
com.unity.streaming-image-sequence
com.unity.test-framework.performance
com.unity.tiny.all
com.unity.transport
com.unity.upm.develop
com.unity.vectorgraphics
com.unity.webrtc
com.unity.xr.googlevr.android
com.unity.xr.googlevr.ios
com.unity.xr.legacyinputhelpers
com.unity.xr.oculus.android
com.unity.xr.oculus.standalone
com.unity.xr.openvr.standalone
com.unity.xr.arsubsystems
com.unity.xr.interactionsubsystems
com.unity.xr.windowsmr.metro

 

I don't think that com.unity.mathematics is just a dependency package. It is great tool and I am succesfully using it outside of Entitites. I don't understand this decision.

 

com.unity.mathematics is dependency of Burst (main reason this new math lib even exists is Burst rather than the ECS).

 

You can get benefit form Unity.Mathematics in il2cpp, even without Burst.

 

Not aware of this being a supported use case (about having performance benefits of using it with Il2Cpp without burst), but you can still add Unity.Mathematics manually, it is just not exposed in the Package Manager

 

Me, I just plain prefer Mathematics. Nothing beats the convenience of typing

position.xy

compared to

new Vector2(position.x, position.y)

. Not to mention, the whole thing just feels lighter somehow...(that's almost certainly from knowing it's intended for Burst compilation ).

The fact that there's no

angle(...)

method by default is only a minor inconvenience.

 

Most of Roadmap things are getting against their ETA,this is totally so sad...
They should stop those bragging talks and showoffs, looks like doing to show it to the investers & board.
Just be integrity and told us "sorry that's been delayed" will be OK.

 

It's threads like these that make me wish to have a dislike button in the forums. Hell it makes we wish for a despise button.

 

Why? What's your reasoning? All this thread is saying is that the package manager should be used to... you know... manage the packages.

And yes, I've read Unity's logic behind the decision to remove and hide some packages, and I respectfully disagree with it. In the short term, a few extra labels and checkboxes to show/hide the more experimental packages is all that was needed.

 

There is. It's called the reply button. ;-)

 

Yeah. I'm fine with adding new labels. I just despise the absurd logic of just hiding packages without asking anyone. What a bizarre course of action. The answers to the problem from the actual engineers at Unity is fantastic.

 

Well I understand peoples frustration, because it's very jarring to suddenly be broken out of your workflow, with no obvious guidance on how to access the new method of doing things. I think I lost a couple of hours, just trying to chase up how to get my favourite packages in. And I was pretty miffed.

But it's cool now. Easy as pie. Although I think they should put a video up on thier channel specifically to address how to click the little cog, and turn on preview packages. No one likes to be running around searching for the right forum post. But that would assume this is the permanant way to do things, which I don't know if it is.

Whatever they do, it should be broadcast on thier youtube channel, because I'm on Youtube all day, everyday, and I'm just going to guess others are too. Just change the video when you update the method.

But I don't know how this stuff works at big companies. They probably have to have it signed off by a Unity think tank, push it up through red tape and review cycles, and then it's probably walked in a suitcase in the Unity headquaters, to the upload room, where two keys are inserted into locks 20 foot apart and must be turned simultaneaously so a renegade employee can't do it alone.

 

I I found the cog immediately. The problem is that, the cog, she does nothing. You have to write the url for entities for instance. What the EFF?

 

Ok. I see what you mean. I have lots of preview packages on display after clicking that button, e.g. Animation Rigging, JOBS, and many more, but no Entities. I don't know if these are different tiers of readiness that they're trying to express, or if it is only Entities that is missing.

 

The change to pre-alpha,alpha,beta,rc is welcome and ditching ‘preview’ is as well. But a simple toggle to hide pre-alpha packages would have been better than to make us mess with the manifest. That way we can keep track of progress, failing adequate alternate means (up to date blog? RSS? etc) to do so.

This reminds me a lot about the time when I asked Unity why I had to click TEN times to get to the show-all-recently-upgraded assets from the asset store home page when browsing on a desktop (yes I know there are hacks to reduce that to half the clicks). The answer I got back was that this was actually their chosen solution to make it harder for users to see the new packages... because Unity thinks they are mostly of “poor quality”. So a URL hack was suggested to me instead. i.e. Their answer to the problem was to create another problem somewhere else. Of course their issue could have been addressed directly by introducing better quality control for packages but hey, why do that when you can just sweep it all under the carpet!

Having said that, I think the best option is the one mentioned a page or so ago... show all the packages in the tech stream, and only verified ones in LTS. Then it’s problem-solved in regards to stopping new users from getting into trouble, especially if you also rename .1 and .2 to alpha and beta for the tech streams. Basically my suggestion is to follow the tried-and-tested norms and conventions.

 

I'm pissed with this decision. I used package manager to add packages like entities or hybrid renderer to my small test projects. Now every time I need to add it, I have to manually edit json (of paste it through "add through git").

Is it so ****ing hard to add some option to show ALL packages as before? ****ing unbelievable.
Guess what, there are still people using Unity for prototype and for testing awesome experimental stuff you make.

Sometimes I used Package manager to discover interesting packages, check it's documentation or change log to see how development progresses, yeah **** that too.

Your approach: rather hide it "more" so people don't complain preview packages are in preview state is retarded.
And that annoying bar on the top right "Preview packages are in use" every time I start Unity pisses me too.

To provide constructive feedback instead of just criticism, here's my solution:
If you insist on "protecting" Unity users from your features do following.
Add option to Preferences "I'm not an idiot and I know what I'm doing" (working title)

When checked Package manager will show all packages, annoying bar will go away.
Title in the Unity window [PREVIEW PACKAGES IN USE] might stay.

 

Discoverability took the biggest hit. This is actually just the final nail in the coffin on that front, they have been removing that gradually for some time.

The whole we did this to help users is a lie. Unity uses labels for their own reasons mostly. There is little correlation between what they call stable/preview/experimental and reality when it comes to most of the packages released in the last couple of years.

DOTS animation is marked as experimental. It's been more stable then Hybrid Renderer yet the latter they made a big fuss about and a year plus later it's still a clusterfuck compared to animation.

ECS core has been more stable then SRP. Yet they pushed out SRP as ready for production.

And there never has been an issue really with people accidentally installing preview packages. It happens occasionally but not enough to warrant this.

So the reality is that this hurts those who actively use early packages more then anyone else. It won't really effect people who were not using preview stuff to start with. So it's a little mind boggling in that sense.

 

Oh no! Users are testing and using the preview packages we provide! Quick! Hide them away, before we find negative feedback inbetween the regular feedback!

 

Seems like the issue isn't the negative feedback. but users using those packages without actually knowing the true state of those packages (like I see some DOTS users complaining about breaking changes between Entities package releases that is affecting their in-production projects).

 

I see the same thing. IMHO it is amazing how few breaking changes there are when updating entities / the other DOTS packages.

My biggest issue with packages in Unity is that they should add some kind of versioning language on packages (Prototype, Alpha, Beta, Deprecated) so that users can better make decisions around using a package. The most important thing is to alert users that a package has been deprecated and is not being developed anymore.

 

I don't think this was the best decision....

Consider all the documentation, videos, and tutorials out there for people trying to learn this stuff, and now... They have to know this obscure forum post exists, grep the package names to find the one they're looking for

There's already a mechanism that people are familiar with, to Enable Preview Packages... Why not use that and have an Enable Alpha Packages option? At least then the user could possibly intuit what they need to do.

To intuit to go and find this thread.... That's just not possible

 

I just tried to setup XR and DOTS stuff with 2020.1 and yea, it's not hard... but it feels really really ass-backwards and stupid to do it. 3 different menus, clicking 4 or 5 different buttons and 1 "semi secret button", copy-pasting a package names from a web-page, then spending 10 minutes making sure the dependencies are actually there (because some of them are hidden by default too) and finding the ones that didn't download right, downloading them, and installing them from disk instead of from git. It was not a good user experience.

The old way in 2019.3 with everything visible was WAY better.

At the minimum, please just make experimental packages accessible by enabling 'experimental' in the project settings... just like you are planning to do with 'pre-release'. It sounds like "preview" is getting split into "experimental" and "pre-release" anyways, so please just make a checkbox for each one.

Also, why not just use normal dev cycle names like "alpha" instead of experimental, and "beta" instead of pre-release. And please please please include "deprecated" for things that are no longer actively developed/maintained but are still accessible in the package manager.

I honestly don't think the simple list view thing is working anymore... I don't understand why a treeview with the top groups being your 'dev state' would be so terrible. This seems very easy to understand to me:

+ "released"
- all released packages here
+ "beta" (pre-release)
- all beta packages here
+ "alpha" (experimental)
- all alpha packages here
+ "deprecated"
- all packages that are no-longer developed/maintained here.

Ideally, I'd like some fancier views and fancier search/sort/filter type things too... but I'd settle for at least a bit better organization like this.

The package manager should be the go-to place to manage packages, regardless of their "dev state". Something is very very wrong if it can't be used that way.

 

It's even worse in 2020.2... the webpage that listed the packages seems to have everything "experimental" removed. https://docs.unity3d.com/2020.2/Documentation/Manual/pack-preview.html with no "experimental package listing" anywhere in the documentation that I could quickly find.

For example, how the heck would we find the "Hybrid Renderer" if we were new to ECS stuff? It's not listed anywhere except the git repo. Unless I read something somewhere then spent time searching the git repo or had someone explicitly tell me it's at "com.unity.rendering.hybrid" I'd never find it.

I sure hope Unity's solution for discovering/finding and installing "experimental" packages comes soon. ...le sigh...

 

As someone trying to learn ECS atm I have to agree that the whole package manager situation is a nightmare, having to spend an hour on google and youtube just working out where to find and install the packages you need is ridiculous, just add an "experimental" toggle next to preview packages toggle and save us all some hassle please

And thanks to Francois85 for posting the .com list here, lifesaving

 

Again, I agree!! WHY are they worried about someone being confused? If they are confused about that, they probably shouldn't be developing!

 

I'm assuming this is all happening because silly people install packages they don't understand how to use and Tech Support has to waste huge amounts of time explaining to them that if you install something you don't understand how to use it won't work properly and its not Unity's fault you don't understand. If only idiots were filterable

 

Some of these replies are really unpleasant, I feel for the Unity reps that have to read these, if they still are.

My one grievance with this change is that you have to read between the lines to learn that ECS (likely) won't be in 2020 LTS. Obviously software development involves a lot of hard to predict development hurdles, but it would be nice if this information was centralized somewhere.

I had the impression ECS was reaching maturity. It's disappointing to have to learn in this indirect way that it won't be stable/supported for a long time.

But it also affirms my decision to focus on compute shaders over DOTS for my current project, so that's good.

Edit: To be honest, having to read between the lines to determine the state of support for these packages reduces my confidence in using Unity. I don't mind the change itself, but it should be accompanied by more transparency about the state of packages which were hyped up to the community, particularly DOTS. I want to be excited about it, but this lack of communication is a signal to me to re-evaluate using other engines, at this stage of my project.

I hope that's balanced feedback without being too negative, just pragmatic.

 

I've been excited to start some very basic experimentation with DOTS and today was my day. That was over an hour ago. I'm so confused... I still don't even understand exactly what packages I need to manually add to just start learning.

 

Why just not add new tag? "Highly experimental" for example if you need to say to developers that it's totally not production ready. We already have advanced settings in package manager which should be edited to show preview packages. Now we have some sort of super preview packages that we can't see in package manager and need to add manually. And now unity says "Wee look for solution to make adding removed packages more easily". Oh yes...I know this solution...it called Package Manager

 

Since there's no feedback from Unity team, I've created scripts which bring back previous functionality.
The DiscoverExtraPackages script explicitly searches for packages from a list and adds them into PackageManager window (when they exists).

This is not exact as previous functionality, which shown all packages, but it's the best I can do now.
I don't know if the list of "hidden" packages can be obtained from somewhere, if yes, please let me know and I'll update the script to download the list of hidden packages from URL.



Disabling annoying warning on toolbar:

Code (CSharp):

1. using System;
2. using System.Collections.Generic;
3. using System.Linq;
4. using System.Reflection;
5. using System.Text;
6. using System.Threading.Tasks;
7. using UnityEditor;
8. using UnityEditor.PackageManager.UI;
9. using UnityEngine;
10. using Object = UnityEngine.Object;
11.  
12. public static class DisablePreviewPackageWarning
13. {
14.     [InitializeOnLoadMethod]
15.     static void Init()
16.     {
17.         var type = typeof(PackageManagerExtensions).Assembly.GetType("UnityEditor.PackageManager.UI.PackageManagerPrefs");
18.         var instance = type.GetProperty("instance", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Static).GetValue(null) as Object;
19.         var property = instance.GetType().GetProperty("dismissPreviewPackagesInUse", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
20.         property.SetValue(instance, true);
21.     }
22. }
23.  

Showing extra packages in package manager:

Code (CSharp):

1. using System;
2. using System.Collections.Generic;
3. using System.Linq;
4. using System.Reflection;
5. using System.Text;
6. using System.Threading.Tasks;
7. using UnityEditor;
8. using UnityEditor.PackageManager;
9. using UnityEditor.PackageManager.Requests;
10. using UnityEditor.PackageManager.UI;
11. using Object = UnityEngine.Object;
12. using PackageInfo = UnityEditor.PackageManager.PackageInfo;
13.  
14. public static class DiscoverExtraPackages
15. {
16.     static string[] m_extraPackages = new string[]
17.     {
18.         "com.ptc.vuforia.engine",
19.         "com.unity.2d.entities",
20.         "com.unity.ai.planner",
21.         "com.unity.aovrecorder",
22.         "com.unity.assetbundlebrowser",
23.         "com.unity.assetgraph",
24.         "com.unity.barracuda",
25.         "com.unity.barracuda.burst",
26.         "com.unity.build-report-inspector",
27.         "com.unity.cloud.userreporting",
28.         "com.unity.collections",
29.         "com.unity.connect.share",
30.         "com.unity.dots.editor",
31.         "com.unity.entities",
32.         "com.unity.film-tv.toolbox",
33.         "com.unity.google.resonance.audio",
34.         "com.unity.immediate-window",
35.         "com.unity.mathematics",
36.         "com.unity.meshsync",
37.         "com.unity.multiplayer-hlapi",
38.         "com.unity.package-manager-doctools",
39.         "com.unity.package-manager-ui",
40.         "com.unity.package-validation-suite",
41.         "com.unity.physics",
42.         "com.unity.platforms",
43.         "com.unity.platforms.android",
44.         "com.unity.platforms.linux",
45.         "com.unity.platforms.macos",
46.         "com.unity.platforms.web",
47.         "com.unity.platforms.windows",
48.         "com.unity.playablegraph-visualizer",
49.         "com.unity.render-pipelines.lightweight",
50.         "com.unity.rendering.hybrid",
51.         "com.unity.renderstreaming",
52.         "com.unity.scene-template",
53.         "com.unity.simulation.client",
54.         "com.unity.simulation.core",
55.         "com.unity.simulation.capture",
56.         "com.unity.simulation.games",
57.         "com.unity.standardevents",
58.         "com.unity.streaming-image-sequence",
59.         "com.unity.test-framework.performance",
60.         "com.unity.tiny.all",
61.         "com.unity.transport",
62.         "com.unity.upm.develop",
63.         "com.unity.vectorgraphics",
64.         "com.unity.webrtc",
65.         "com.unity.xr.googlevr.android",
66.         "com.unity.xr.googlevr.ios",
67.         "com.unity.xr.legacyinputhelpers",
68.         "com.unity.xr.oculus.android",
69.         "com.unity.xr.oculus.standalone",
70.         "com.unity.xr.openvr.standalone",
71.         "com.unity.xr.arsubsystems",
72.         "com.unity.xr.interactionsubsystems",
73.         "com.unity.xr.windowsmr.metro",
74.     };
75.  
76.     static Type m_cacheType = typeof(PackageManagerExtensions).Assembly.GetType("UnityEditor.PackageManager.UI.UpmCache");
77.     static Type m_cacheInterfaceType = typeof(PackageManagerExtensions).Assembly.GetType("UnityEditor.PackageManager.UI.IUpmCache");
78.     static Type m_operationType = typeof(PackageManagerExtensions).Assembly.GetType("UnityEditor.PackageManager.UI.IOperation");
79.     static PropertyInfo m_getInstance = m_cacheType.GetProperty("instance");
80.     static PropertyInfo m_getPackageInfos = m_cacheInterfaceType.GetProperty("searchPackageInfos");
81.     static MethodInfo m_setPackageInfos = m_cacheInterfaceType.GetMethod("SetSearchPackageInfos");
82.     static PropertyInfo m_operationInProgress = m_operationType.GetProperty("isInProgress");
83.  
84.     static EditorApplication.CallbackFunction m_callback = OnProgress;
85.     static List<SearchRequest> m_requests = new List<SearchRequest>(32);
86.     static object m_searchAllOperation;
87.  
88.     [InitializeOnLoadMethod]
89.     static void Init()
90.     {
91.         // Hook package manager SearchAll operation
92.         var clientType = typeof(PackageManagerExtensions).Assembly.GetType("UnityEditor.PackageManager.UI.UpmClient");
93.         var instance = clientType.GetProperty("instance", BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Static).GetValue(null) as Object;
94.         var evnt = instance.GetType().GetEvent("onSearchAllOperation");
95.         evnt.AddEventHandler(instance, Delegate.CreateDelegate(evnt.EventHandlerType, new Action<object>(OnSearchAll).Method));
96.     }
97.  
98.     static void OnSearchAll(object operation)
99.     {
100.         m_searchAllOperation = operation;
101.  
102.         // Clear requests, in case any searches are running, they will finish without doing anything
103.         m_requests.Clear();
104.  
105.         // Kick off searching
106.         foreach (var id in m_extraPackages)
107.         {
108.             m_requests.Add(Client.Search(id));
109.         }
110.  
111.         // Re-register update callback
112.         EditorApplication.update -= m_callback;
113.         EditorApplication.update += m_callback;
114.     }
115.  
116.     private static void OnProgress()
117.     {
118.         // Wait for all requests to complete and for SearchAll opeartion to finish
119.         if (m_requests.All(s => s.IsCompleted) && !(bool)m_operationInProgress.GetValue(m_searchAllOperation))
120.         {
121.             // Then add results
122.             var packages = ((IEnumerable<PackageInfo>)m_getPackageInfos.GetValue(m_getInstance.GetValue(null)));
123.             var everything = m_requests.Where(s => s.Status == StatusCode.Success).SelectMany(s => s.Result).Union(packages);
124.             m_setPackageInfos.Invoke(m_cacheType.GetProperty("instance").GetValue(null), new object[] { everything });
125.  
126.             EditorApplication.update -= m_callback;
127.             m_requests.Clear();
128.             m_searchAllOperation = null;
129.         }
130.     }
131. }
132.  

 

Wow, thank you very much. This really shows that the most important part of Unity is the community. Always fixing the mistakes of bad management.

 

Thanks for the script!

Always nice to be in control as a user, without the need for handholding

 

You're awesome

 

Is it just me or I cannot add any preview package in a new 2020.1.3f1 project?

• Entities and Physics are no longer in the list view even with preview packages displayed
• Typing com.unity.entities or com.unity.physics in Add From Git URL does nothing.

So for now the only way I have to add these packages is to manually add them in the manifest.

Is this really the way to go moving forward?

This gives me some serious impressions that DOTS is getting less love from Unity and that is a true shame. If DOTS is the future of Unity, it should definitely be easy to install, not a totally hidden feature.

Edit: So it looks like that adding com.x works but I have to wait ~30 seconds while touching nothing in the editor for it to start importing. I still believe this approach is far from ideal and that this decision deserves to be reversed. Developers are not children, we understand what it means to use preview packages.

 

No mathematics, no render-pipelines.core? What wrong with you?

 

Since it was mentioned in the OP here, please see my bug about xr.subsystems. I can't upgrade any project to Unity 2020.1.3 created with an older version of Unity. So Package Manager shows zero packages. And I'm not even using that package!

https://forum.unity.com/threads/cant-upgrade-any-older-version-project-with-unity-2020-1-3.958195/

 

I just spent a couple of hours trying to figure out why I didn't have the PlayableGraph Visualizer and couldn't seem to add it in any way, even though there's plenty of mention of it in the Unity 2020.1 documentation about it before I stumbled onto this thread.

I really wish there was better communication about these kinds of changes, especially when it involves removing a feature that's pretty important to debugging a system that otherwise doesn't give much debugging information.

 

I find that Playables is largely unusable without the debugger. I know Playables is in maintenance mode, but given that there is no suitable replacement to playables / mecanim there really needs to be a debugger that is simple to install. What's the harm in users using an editor only preview package like the playable graph visualizer (even if it is no longer under active development)?

 

Same problem, I cannot add entities, hybrid renderer or physics.

Not working via "Add From Git URL". (and waiting afterwards).
Not working editing the manifest.

Any help?

 

One problem is that not every documentation got updated, for example the installation guide of the Network Transport package just says to use the package manager, some packages like the NetCode package mention the change.

 

The best package manager is notepad.
It's only worth opening to see if there are updates.

At least that's what Unity has reduced the package manager down to.
PM is probably developed by the collab team.

 

It took me almost two hours to find this. Here is a video about vector graphics, produced and published by Unity:

It says, "the release of unity 2018.2 introduced the brand new SVG file importer" followed by "we have to make sure we are running Unity 2018.2 or newer... you can grab the latest build of Unity through Unity Hub". This is followed by instructions showing how to install the vectorgraphics package through the package manager.

• I grab the latest version of Unity from Unity Hub. Everything looks similar on my machine, but no package is listed.

• I try to use the search field. As soon as I get to "vec" I get a blank screen. I head to the internet (as one does).

• I find the documentation page for vectorgraphics on unity docs; it shows as a preview version, I can handle that (though it's strange that it had an official release video in 2018).
  
• I google how to see preview packages. There are instructions for 2019, which do not match 2020, but I track through the extra clicks and make the change.
  
• I go back to the package manager (because it took me out of package manager to make the change) thinking things should be fixed. They are not.
  
• I spend an inordinate amount of time trying to find 2020 specific information, reading through pages and pages of forum posts, before I find this. On the second page I am able to find the list of packages that have been removed and tada there is vectorgraphics.
  
• Further on I find I can install it with the common name listed through the github url addition link. Finally it works.

Do you see how this might be a frustrating experience for someone just trying to check out documented and published capabilities? Because it sure was frustrating.