Search Unity

Unity Visibility changes for preview packages in 2020.1

Discussion in 'Package Manager' started by LeonhardP, Jun 12, 2020.

Thread Status:
Not open for further replies.
  1. Korindian

    Korindian

    Joined:
    Jun 25, 2013
    Posts:
    577
    I agree that it should be better communicated what the status of each of these packages is before hiding them. I also think it would be better to keep them viewable in the package manager, but make it very clear what the status of the package is with color and text, or have some type of confirmation before installing the package.
     
  2. sinjinn

    sinjinn

    Joined:
    Mar 31, 2019
    Posts:
    144
    Well I don't see it's so bad, you just have to enable in the project settings. Reaction seems very ravenous at times.
     
    Edy likes this.
  3. MaskedMouse

    MaskedMouse

    Joined:
    Jul 8, 2014
    Posts:
    752
    it's unexpected because the expected context is that settings of the Packages shown are available in the Package Manager window itself, not in project settings as a project setting.
    When I opened up 2020.1 beta I got confused and did not even know it has been moved to the project settings. I had to google it to only find out that they moved it.
     
    R0man and protopop like this.
  4. sinjinn

    sinjinn

    Joined:
    Mar 31, 2019
    Posts:
    144
    Fair Point. I can admit, I spent a good hour or more on figuring out how to do it through the package manager, only to later learn I could turn it on in the project settings. And I was kind of very frustrated at the time. But now it's like it never happened.
     
    R0man likes this.
  5. Rallix

    Rallix

    Joined:
    Mar 17, 2016
    Posts:
    135
    No – that's how it works now; what people talk about is the proposed change.
    What they're saying is that the packages won't be accessible inside Unity anymore (even if you enable preview packages in Project Settings), only if you already have them in your project, or if you somehow learn about them somewhere else. Otherwise, you'll be limited to packages under active development which are verified or almost verified, assuming they are "big enough".
     
    R0man and GliderGuy like this.
  6. DanielTG

    DanielTG

    Unity Technologies

    Joined:
    Feb 15, 2018
    Posts:
    110
    Hi everyone,

    I just wanted to jump in and thank you all for the feedback. Your concerns are heard loud and clear. I understand the message may not have clearly communicated around 'preview packages', which as a label is part of the problem, and something we will address. Here is some additional context to what Leonhard and Charles have already shared in previous posts that I hope will help.

    The change introduced earlier in the 2020.1 beta cycle with the new Package Manager project settings to enable "preview" packages in the Editor was the first phase. The Unity Package Manager is a project based setup and it was an appropriate fit compared to the previous (OS) user setting... just a sneak peak: Additional project settings for managing 'Scoped Registries' will coming soon in 2020.1; previously this was only doable via the project manifest.

    The latest change for packages no longer being discoverable by default (with or without the new project setting on) is about establishing a clearer path. Not specifically about where to discovery these packages/updates but also a clear two way communication path with the teams working on these solutions and workflows...

    Sneak peak on the planned changes for 2021.1 to labeling: Preview is going away. Verified label is going away. What we have proposed is:

    "Experimental" : packages / package versions that are in early development accessible through the but will not be listed by default in the Package Manager UI. No specific release ETA for this category of packages.
    "Pre-release": for all package versions that are in beta quality state and planning to ship in the coming release cycle; accessible by enabling 'pre-release' (formerly preview) in the project settings

    No Label = the new verified. Packages and package versions that are fully released and supported for a Unity version.

    We value your feedback and appreciate all comments. I hope this helps.

    Thank you,
    Daniel
     
  7. charlesb_rm

    charlesb_rm

    Unity Technologies

    Joined:
    Jan 18, 2017
    Posts:
    485
    As stated in the blog post, it has been moved to Project Settings.
     
  8. francois85

    francois85

    Joined:
    Aug 11, 2015
    Posts:
    1,634
    Remove dead packages , make all preview packages visible in tech streams. In LTS version hide EVERY thats not verified.

    I can’t tell you how many time I’ve had to blow away the manifest file to resolve a conflict cycle. Usually at this point I feeling pretty frustrated , if I needed to dig for these packages there will be a lot of cussing.

    Hiding preview packages this way is not a good solution to the problem.
     
    Moonblade-Studios, transat and R0man like this.
  9. Raive

    Raive

    Joined:
    Jan 6, 2013
    Posts:
    15
    It is very sad when open-source software has more focus, direction and planning than this utter mess of an engine.
     
    RafaelMartin and banan1234 like this.
  10. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,844
    Can Unity add more descriptive labels about the status of preview packages? For example, instead of just calling all of those packages "preview", you could use more descriptive words like pre-alpha, alpha, beta, release candidate, etc.

    The challenge right now is that some preview packages are pre-alpha and others are release candidate, but both of those are lumped together as "preview". Developers know to treat pre-alpha software packages differently from release candidate software packages, but only when the software is labeled properly.

    Maybe Unity could use the following wiki page to label packages in a more transparent way:
    https://en.wikipedia.org/wiki/Software_release_life_cycle
     
    laurentlavigne and R0man like this.
  11. ShilohGames

    ShilohGames

    Joined:
    Mar 24, 2014
    Posts:
    2,844
    Maybe Unity could use the following wiki page to label packages in a more transparent way:
    https://en.wikipedia.org/wiki/Software_release_life_cycle
     
  12. sstrong

    sstrong

    Joined:
    Oct 16, 2013
    Posts:
    1,867
    After so much hype over DOTS, now to see it "disappear" (entities and mathematics) from Package Manager is disappointing to say the least. Having them listed as preview or alpha/beta seems much more in-line with industry standards.

    Having to edit the manifest is rather odd when there could be a simple "show alpha/beta" package button (like Show Preview). Playing with the manifest file is a great way to break your projects. Unity should do this for you (like it does now).

    Like others on this thread we really think you should reconsider. With backward compatibility now almost a thing of the past in Unity, we're all wondering where this will end.

    Don't misunderstand me, I like the Unity platform and have invested heavily in it over many years in terms of effort and resources.
     
    R0man, Vaarz, pm007 and 1 other person like this.
  13. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    2,832
    Edited the list to remove the following packages that will remain visible:
    • com.unity.xr.arcore
    • com.unity.xr.arkit
    • com.unity.xr.arkit-face-tracking
    • com.unity.xr.windowsmr
    • com.unity.xr.oculus
    • com.unity.xr.magicleap

    The above XR platform packages are verified and very much in active development.
     
    Last edited: Jul 7, 2020
    hippocoder likes this.
  14. rsodre

    rsodre

    Joined:
    May 9, 2012
    Posts:
    227
    This makes no sense to me. Having flags to enable and disable what we want to see and install is a clear enough path. Hiding completely is blocking access to the path.

    Just make something else clear to us please.
    Will the Enable Preview Packages settings make the hidden packages discoverable in the Packages Manager or not?
     
    raincoil, Noisecrime and francois85 like this.
  15. charlesb_rm

    charlesb_rm

    Unity Technologies

    Joined:
    Jan 18, 2017
    Posts:
    485
    Hi ShilohGames, this is indeed the model towards we plan moving for 2021.1. Stay tuned for more information about this.
     
  16. francois85

    francois85

    Joined:
    Aug 11, 2015
    Posts:
    1,634
    I think Unity needs to reach out to the community on this one. I really don’t like where the package manager is heading alongside with SRP plans on no longer shipping as a package.
     
    JoNax97, sstrong and Noisecrime like this.
  17. slime73

    slime73

    Joined:
    May 14, 2017
    Posts:
    73
    I've found Unity.Mathematics to be very useful in my large project even without any DOTS or Burst code. Why is it being removed?
     
  18. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    1,628
    Have to agree with others here on the misguided and deliberate nerfing of the package manager in an attempt to solve a problem that was of Unity's own making and not with the package manager itself.

    Whats worse is I only just discovered this after a cross-post from the Render Pipelines future thread.

    While the labelling of packages has been pure insanity, the package manager itself is not the problem but the solution, so why aren't Unity using it as such?

    Personally i'd be adding options to the package manager to fulfill filtering needs to solve this problem, even if they were hidden away in the preferences, under an additional 'guard' option of 'Enable advanced filtering. That filtering would be

    enable experimental
    enable pre-release
    enable LTS only

    etc

    Clear and specific filters to tailor the results of the package manager to the needs of different developers. I guarantee if developers have to 'add from git' or go searching around then the package manager will see a huge drop in use and usefulness.

    In fact at this point I wonder why even bother to have the package manager at all if this is the direction being taken. Just get rid of it, embed all verified packages with each major revision of Unity editor and be done with it, as that seems to be the logical conclusion of where this is going.

    I'm not even very happy with the direction its taken with assetStore package manager. Initially it was really cool, but in the last version I tested I have to manually load packages ( in alphabetical order ) in batches of 25 or 100! It then takes ages too load these and apparently has some weird memory issues, because after loading all 200+ assets I own the package manager started having graphical glitches ( I couldn't reproduced so haven't logged a bug yet ).

    Its getting to the point where the asset store section is trying to do too much, showing screenshots and the like that its becoming as slow and painful as the web browser version. All I wanted and needed was a nice quick method to import frequently used store packages and update ones where needed.
     
    R0man, Edy, protopop and 1 other person like this.
  19. DanielTG

    DanielTG

    Unity Technologies

    Joined:
    Feb 15, 2018
    Posts:
    110
    @rsodre if the package is truly a "preview" aka "pre-release" in the future releases after the 2020.x cycle then it will be made visible in the Package Manager Ui with the "enable preview" project setting.

    If the package is "experimental" (the original list of packages at the start of this thread) then the "enable preview" project setting does not apply and the package will need to added manually either through the manifest or via the UI method @Charles_Beauchemin mentioned earlier in this thread.

    Hope this helps.

    Thanks
    Daniel
     
  20. Mariusz_H

    Mariusz_H

    Joined:
    May 4, 2018
    Posts:
    15
    So why is com.unity.mathematics on above list? It is marked as verified in Package Manager.
     
    Last edited: Jul 6, 2020
    rustinlee, laurentlavigne and R0man like this.
  21. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    284
    Yes pretty much, we don't feel it's at the right stage yet to be considered a verified package. We've been gathering feedback and are planning to resume development for 2021.

    Cheers,
     
    goncalo-vasconcelos likes this.
  22. corjn

    corjn

    Joined:
    Feb 6, 2014
    Posts:
    159
    Is it the same for Burst and Jobs ? There is a lot of tools from the asset store depending on them.
     
  23. Korindian

    Korindian

    Joined:
    Jun 25, 2013
    Posts:
    577
    I really appreciate you clarifying this as well, because I was planning on doing UI development with UI Toolkit for my game. Now I see that resolution independent graphics for UI Toolkit won't be fully supported until sometime next year or even later perhaps, and I need to make decisions for my game right now.

    This brings up a fundamental issue that I feel Unity needs to address. You're showing a large list of packages which are going to be hidden because they're experimental or possibly deprecated or abandoned in the original post, but we're not clued in as to the status of each of these packages and their possible future. Shouldn't your above post also be posted in the appropriate Vector Graphics forum threads, or stickied in the UI forum for everyone to know the status?

    Shouldn't status updates and reasons for being hidden/removed/deprecated/abandoned for each of the packages listed be posted in their appropriate forums? Perhaps even a blog post that lists all the packages and the status for each of the packages?

    From that list, I'm also using the AssetBundle browser as well as the Cloud User Reporting package, and I wasn't aware either were experimental. Addressables is not covering the use case for modding on desktop platforms in a convenient or elegant way (and there's no documentation about it), whereas using the AssetBundle API directly does, and the AssetBundle browser makes that process so much easier. I had built my own user reporting service, then decided to use Unity's Cloud User Reporting instead, and now it looks like it's going to be abandoned as no development has happened on it at all recently, and Unity is now going to hide it from the package manager. What's the status of it? Can the team responsible for it give an update on the forum or in a blog post?

    I was planning on using the Playables Graph visualizer as it was mentioned in a few places in the Unity documentation, blog posts, and forum threads to use Playables for animation, but now that package is being hidden. So is Playables experimental, being abandoned, or what?

    I was planning on using the Build Report Inspector as well, but now that's being hidden, so what's the status on this? Is it being integrated into core, is it very much experimental, is it being abandoned?

    Do you kind of see the pattern here?

    I'd like to make informed decisions about what tech I should be using, but I can only do that if Unity communicates clearly what the status and plans are for these packages. Perhaps you guys have a lot of internal discussions at Unity about the status of all these things, but as users we also need to know your decisions so we can plan and act accordingly. The recent SRP post by the graphics leads at Unity was a great example of this, and was very helpful for knowing what your plans are and the decisions you're making. We need more of this type of communication for each package from the teams responsible for them so we can make the best decisions. Thanks for listening.
     
  24. francois85

    francois85

    Joined:
    Aug 11, 2015
    Posts:
    1,634
    Is it getting too complex ?
    Ive got some packages moving back to core like SRP with an option override with git, some hidden from the package manager, some visible in the package manager and some overridden/added by git.
     
    JBR-games and Noisecrime like this.
  25. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    1,628
    So if all these packages are removed from the package manager how does one 'discover' them?

    The only way I see that happen is if someone reads every single forum, every day to pick up on announcements, or scrape the Unity repositories on github/bitbucket.

    This feels like another backwards step and is frustrating as periodically I was able to simply enable 'experimental packages' in the manager and browse all the interesting features that Unity had in development. It revealed some very cool packages, some I use daily ( e.g. FBX exporter ) and others which i'd planned to experiment with when I had time.

    Again all this seems so counter-productive. We have a package manager that is designed for optimal and clear delivery of packages to developers. However due to poor naming and communication has led to developers grabbing experimental, preview or incorrect versions. The solution to remove/obfuscate those packages is a bizarre choice as their availability is NOT the problem. The solution is to improve the naming, communication and visibility within the package manager.

    Honestly I do not understand why the package manager isn't being used to address the problem as surely that was/is its purpose in the first place?
     
  26. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    2,832
    Edited the list to remove the following packages that will remain visible:

    com.unity.editorcoroutines
    com.unity.testtools.codecoverage
     
  27. protopop

    protopop

    Joined:
    May 19, 2009
    Posts:
    1,488
    Why not just call it "beta" then?
     
  28. MegamaDev

    MegamaDev

    Joined:
    Jul 17, 2017
    Posts:
    68
    What, Mathematics is getting hidden? I was sure that you'd gotten that one past preview....

    (In practice it's not going to make much of a difference to me, considering I've already got in-house packages depending on it and probably forcing it to show up, or at least be included by default. Still. Why.)

    (Oh crud. Does this mean Mathematics isn't stable!? I would've never guessed, and it'd be really bad to be sprung upon by this.)
     
    R0man likes this.
  29. desertGhost_

    desertGhost_

    Joined:
    Apr 12, 2018
    Posts:
    222
    I asked about this package and other verified packages being hidden and got the following answer:

    So basically the math package is only meant for advanced users?

    IMHO it shouldn't be hidden...
     
    R0man and Noisecrime like this.
  30. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    284
    Like Charles said, those packages are verified and still available to use. Not being shown in the package manager UI will not break existing projects or compatibility between other packages or tools from the asset store. They just need to be manually added via the manifest.json file.
     
  31. francois85

    francois85

    Joined:
    Aug 11, 2015
    Posts:
    1,634
    I really hope you guys reconsider hiding packages, it’s really making things a lot more confusing IMHO.
     
  32. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    284
    You're absolutely right. Actually, for you to use so many Unity packages while being unaware of their actual state is a strong indicator that we did something wrong and justifies our decision to take a step back and do some cleaning. We should and we want to provide better clarity about which package is production-ready or when it will be, and this is a step in that direction.

    I like your suggestion of posting more status updates in respective forum sections, I will take action on it.

    Cheers,
     
  33. corjn

    corjn

    Joined:
    Feb 6, 2014
    Posts:
    159
    You're not fixing it, you're just making it worse. It's too late, Burst and Jobs are well known and used in the Unity community. This is just terrible for usability. Now I'll basically have to edit the manifest file in every new project i'm making (I use Burst and Jobs in every new project, it's propably the best thing Unity made during the last 2 years).

    Also, think of assets like Magica Cloth, Boing Kit, Vegetation studio pro. They are all using Burst. They also are top selling assets. It means every new users of these assets will have to edit the manifest file.

    You're not simplifying and helping users by hidding your most used packages. Hiding Kinematica would make more sense as it's very new and unknow.

    It's not a big deal, but it's super annoying. And Unity not listen to it's community, again (#SRPLife), is annoying too.

    One good thing you could make to improve the package manager would be to allow users to install previous versions of asset store packages. Often, asset store devs are pushing broken updates (and it's fine, every programs has bugs. The problem is not being able to go back, unless you have a git).
     
    KAJed, jashan, R0man and 2 others like this.
  34. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    609
    They are not hidding neither Burst or Jobs, did you saw the openning post?
     
  35. corjn

    corjn

    Joined:
    Feb 6, 2014
    Posts:
    159
    Yes, look 4 posts above. Maybe i'm wrong, but "Unity.Mathematics" will be hidden and Burst + Jobs needs Mathematics.
     
  36. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    609
    They are gonna hide the Mathematics from showing up by himself in the package manager, Burst, that depends on Mathematics, will still be listed and will install Mathematics when installed.
     
    laurentlavigne and benoitd_unity like this.
  37. benoitd_unity

    benoitd_unity

    Unity Technologies

    Joined:
    Jan 2, 2018
    Posts:
    284
    Hidden packages are still working for when they are declared as dependencies for other packages.
     
    corjn likes this.
  38. slime73

    slime73

    Joined:
    May 14, 2017
    Posts:
    73
    I understand. What I was trying to say is, I don't think my project is very unique, and it already has a lot of mileage out of Unity.Mathematics outside of any Burst or Entities context. Therefore I believe there are many current and future projects developed by other people which would benefit from using Unity.Mathematics, and hiding it will hurt those projects.

    I'm curious what the specific reason for hiding Mathematics is - I have a hard time believing hiding it would be a net positive compared to the projects that would miss out on using it, especially since the problems I see with it can be alleviated a bit by documentation changes. Speaking of documentation, hiding it also makes it harder to find official resources on it for projects that do use it, unless I'm mistaken.

    I also don't believe Unity as an organization has much first-hand experience with creating projects of the scope that mine is, so gathering community input when making decisions that affect those is more important than ever. I don't mean to imply you should just follow whatever I say, but I do mean to say over the years there have been many changes which went live and then had to be hastily patched after obvious problems showed up in real use cases (eg: prefab roots not being editable without going into Exclusive Prefab Mode, in 2018.3. And AssetDatabase v2 being so slow that it made large projects unusable, and 2019.3 had to be delayed after people found out through the Betas). I hope this won't be another one of those, although the scope of this change isn't so drastic.
     
    MegamaDev likes this.
  39. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    1,628
    So just noticed that EditorCoroutines is included in this culling. This was a package I grabbed to look into further while browsing available packages in the 2019 package Manager and I feel provides a good test case for this brave new world.

    I've now spent over 40 minutes trying to work out what the git url would be to add this.

    Check the Manifest
    The first thing I did was check out the existing package that i'd downloaded and the PackageManager manifest which states the url as https://packages.unity.com. So yeah not helpful at all. I'm sure I could eventually work out what the full url would be, but I'm not even sure if the package will remain on this site or be updated.

    It also wouldn't be of use in the future as the package wont exist in the Manager anyway, but I figured it might give a hint as to where to find these things in a generalised way.

    Search the Net
    Next step Bing search for 'Unity editorCoroutines'

    First top link (https://unitylist.com/p/k58/Unity-Labs.Editor-Coroutines) is to UnityLists a useful (crowd sourced? ) site that collates all manor of Unity assets, scripts, projects and tutorials from across the web. It links to a nuget release on git for a modernization of a users old code for doing editor coroutines. Whats confusing is that its tagged with UnityLabs, so is this the same as the official Unity package or something different? The version doesn't match the package I have and browsing the git the directory structure it is completely different. No this doesn't appear to be what i'm looking for at all.

    The second and third links are to the Unity Manual and it does refer to com.unity.editorcoroutines, yay! But all it is is the documentation and it tells you to use the packageManager to download it ! No hint as to what the url would be to add as git.

    Fourth link (https://docs.unity3d.com/Packages/com.unity.editorcoroutines@0.0/manual/index.html) is to an outdated documentation to the official package, but neither it nor the most recent version provides git url information. Instead they say to use the PackageManager!

    Then we have more Unity Manual links, an assetstore link and a forum thread ( which discusses some drawbacks with the package )

    Next page of results are more links to the Unity manual, the com.unity.editorcoroutines docs, UnityLabs again, the git for UnityLabs, a gist, another random git and so on.


    Check the existing Package ( cheating )
    Final step, check the package in the Unity project. Randomly open all the support files in the package. Happen on package.json and it appears to maybe have the git url, Yay success!

    "https://github.cds.internal.unity3d.com/unity/com.unity.editorcoroutines.git".

    Bit worried about the 'internal' part of the path but at least I know have a url. Of course totally impractical as the problem is with the new approach Unity are taken I couldn't get the package in the first place.

    Ok so lets test this. Open PackageManager, select 'add from git', copy & paste url and hit 'Add'

    ERROR
    'Unable to add package : No'git' executable was found. Please install Git on your system then Restart Unity and Unity Hub!


    Are you kidding! Do you have any idea how angry I am at the moment! I have never been this pissed off at Unity in the decade i've been using.

    No i do not want to install git!
    No i do not want to waste, what, 50 minutes now, trying to install a package that was previously a simple click.
    What a complete waste of my time - i'm done.

    To top it all i've still NOT found a reliable or simple means to find the actual url to this package or its git.

    So tell me

    1. What is the url for this package and how I exactly would I discover it?
    2. In the future how would I discover useful packages like EditorCoroutines, fbx exporter, Mathematics and the like?
    3. Why do I need git to download the package?
    4. Why do I need git when the package manager was capable of grabbing the package in the past.
    5. Why are Unity doing this?


    EDIT
    Right so tucked away as a reply to a comment on the blog post is a little secret, you can just use 'com.unity.editorcoroutines' in the add git url! Yeah well that's not totally counter-intuitive. It also states 'for now' so no idea if that means it will be going away at some point in the future or not.
     
    Last edited: Jul 9, 2020
    sevenfivel, Fewes, a436t4ataf and 3 others like this.
  40. cultureulterior

    cultureulterior

    Joined:
    Mar 15, 2015
    Posts:
    67
    I just found out about this. This is idiotic- the discoverabilty was the best part of the package manager!
     
    JBR-games, Fewes and GliderGuy like this.
  41. corjn

    corjn

    Joined:
    Feb 6, 2014
    Posts:
    159
    Thanks for clarifying, it makes more sense that way then :)

    But please, think about my feature request above "allow users to install previous versions of asset store packages." I'm sure it would be very usefull to a lot of people.
     
  42. calabi

    calabi

    Joined:
    Oct 29, 2009
    Posts:
    184
    Yeah I guess I'm going to have stop using DOTS and other beta packages, if its going to be too complicated and difficult to even find and use them. I was enjoying using it too, even reported and found a few bugs.
     
    Noisecrime likes this.
  43. realtoughguy

    realtoughguy

    Joined:
    Jul 19, 2015
    Posts:
    9
    I don't really get the logic here.
    I see Unity devs saying this is for clarification and to minimize confusion, but it's not clarification, it's obfuscation, and it's also quite confusing.

    Why not give the package manager clear filtering UI (with only production-ready packages visible by default), clear communication of package development status, big fat warning labels and maybe even a warning dialog when you try to install experimental packages?

    Why fracture everything, spread it out, separate it? Why make more new stuff that the user needs to figure out and actively think about (and for that matter, that developers need to maintain)? Why add unnecessary dimensions to installing packages?
    It actually appears the goal is to make things more difficult and complicated. As far as I can see, this decision is just going to waste time and brainpower for everyone.
     
    JBR-games, protopop, Vaarz and 7 others like this.
  44. jonlundy

    jonlundy

    Joined:
    Apr 15, 2016
    Posts:
    25
    This is a horrible idea. Sure it is easy to type in a package name, if you remember the precise path, and remember the chain of dependencies. It was easy enough to forget all the packages you have to add for dots, now you will have to go track down the names and type them in. Perhaps take an idea from IDEs and have repositories of packages, and at least segregate related stuff into a named repository.
     
  45. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,065
    I honestly think this is a good decision. Surely it wasn't easy and won't please everyone, but I think it's a necessary move in order to make Unity return to the stable path: the package manager containing only high-level, tested, verified packages everyone could use with confidence.

    At the same time, developers wanting to use them at low level, or at the risk of not being reliable can still use them. But they must know exactly what they are doing and the risks involved. I believe this is a step in the good direction.

    IMHO DOTS/ECS shouldn't have come out to the public yet. Surely it will be great if Unity decides to rewrite part of all the engine using with it, so we could have faster components. But its a so low-lever architecture, low-level API and even low-level language (equivalent to C, not even C++) than using it requires the same time and effort as writing a game engine ourselves. I expect Unity to write the engine for me and just provide me with high level components I can use easily, not me having to actually write those components myself.

    Currently it's easy to see that DOTS is still years away of being actually usable in Unity at user level. I think that removing it from the package manager is totally reasonable.

    Again, expert developers who want to use it still can use it. It's not going anywhere. It's just not exposed to everyone as if it were a production-ready, high-level, ready to use system in Unity.
     
  46. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,065
    +1!
     
  47. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    879
    Just to add my thoughts here, I feel this is a solution to a number of real problems, but in my view it is the wrong solution.

    The problems are:
    1) It is too easy for people to "infect" their projects with preview packages.
    2) Once things are public and shown there is no way to put the cat back in the bag
    3) There has been zero improvement in the age old Unity problem of abandoning features at 90% completion.
    4) There have been no communication improvements on the status of features.

    Some of the things that have been mentioned here as candidates for hiding were no only announced, they had blog posts associated with them, they had entries in the Unity versions they were introduced in and then nothing. Zero communication. Now we find out that they were orphaned and will be hidden by default. That is not good.

    The package manager having all of this preview stuff had disadvantages but it had one very big advantage:
    It was a step towards more transparency on what is being developed at Unity. That was a breath of fresh air. It was not perfect, because there was no further information about what is going on, some packages had updates and then suddenly didn't anymore, but for those of us that like to know what is actually happening it was great.

    It is sad to see this move towards transparency abandoned, there must be a better way.
     
  48. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    879
    I disagree rather strongly to this, the problem here is not at all that this stuff is public. It should be public. A lot of projects have been improved by them and a lot of stuff that was previously impossible is now possible because of them. The problem was the push for mainstream acceptance even though the long term goal is not to write all of this low level code, not the public release of the Jobs system, Burst, Unity.Mathematics and the ECS libraries.

    Just in my project now I have three different assets that perform as well as native Unity code, integrated into built-in Unity systems that were impossible to cleanly extend before. We have been waiting for a decade for this to be possible waiting for Unity to rewrite the whole engine to be able to do this would have been tragic.
     
    KAJed, jashan, Jes28 and 4 others like this.
  49. calabi

    calabi

    Joined:
    Oct 29, 2009
    Posts:
    184
    In my opinion some things you can't just develop in isolation and come out with it in full a few years later. Something like DOTS needs to be battle tested throughout and would be more of a mess if they did it that way and it would take longer to learn and longer to develop. People have to use these things in the end. Even the Media Molecule developer's realised this with Dreams. Its like a feedback loop where people learn and the developer learns and it improves the software much more efficiently.
     
  50. elJoel

    elJoel

    Joined:
    Sep 7, 2016
    Posts:
    120
    IMHO a step in the wrong direction. Instead of closing things off from the public, packages should all be open on Github like the SRP. That way users could get a much better feeling of the state of the package and make a more informed decision whether to include it into the project. Instead of fighting the users by complicating access to the packages and only releasing them when "ready". Unity should open up and work alongside the users. I agree with the poster above the packages need to be battle tested and actually used in their early versions. The package manager was a great addition and i hate that you are castrating it by closing down.
     
Thread Status:
Not open for further replies.
unityunity