Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. The 2023.1 beta is now available for testing. To find out what's new, have a look at our 2023.1 feature highlights.
    Dismiss Notice

Unity Future .NET Development Status

Discussion in 'Experimental Scripting Previews' started by JoshPeterson, Apr 13, 2021.

  1. Nad_B

    Nad_B

    Joined:
    Aug 1, 2021
    Posts:
    149
    For UI I would have loved if Unity had gone the XAML way in their new UI toolkit, exactly like this: https://www.noesisengine.com (they could've just bough it). It's a breeze to work with and VS already have the necessary tooling for it, along side the excellent Blend which could be used by UI designers. Just imagine how it's easy for developers to use ViewModels, data binding, RX and other goodness .NET developers are used to in WPF, UWP and Xamarin.Forms/MAUI.
     
    Last edited: Apr 1, 2022
    Huszky and WinterboltGames like this.
  2. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Thank you thank you thank you <3
     
  3. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Isn't WebView2 only the windows specific implementation? I don't think you would get that on iOS or Android. Unity's UI toolkit is already converting web technologies into a cross platform "web view".
     
  4. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    692
    In MAUI there is WebView that's the version I meant, WebView2 is Edge and only for native window apps required, I got that mixed up.

    There is no webView in UI toolkit, just because it uses a CSS-like style syntax with USS doesn't have anything else to do with web. UI Toolkit is closer to XAML, just with different style mechanism.
     
  5. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    100
    Still blazor could be used. When running blazor hybrid the code runs on the device not in the browser. https://docs.microsoft.com/en-us/aspnet/core/blazor/hybrid/?view=aspnetcore-6.0
    Yes, creating a new browser render for each canvas would be a bad idea, but creating something like mobile Blazor Bindings for Unity where you can have custom elements which will spit out normal unity ui elements would be awesome. With the time and effort put into the UI toolkit it could be a really performant and easy to use system.
     
  6. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    692
    No, the rendering itself uses still the web view (browser), but the component logic run native and not in the browser .
     
  7. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    100
    No, mobile Blazor Bindings uses native element. https://docs.microsoft.com/en-us/mobile-blazor-bindings/ the blazor render ing engine is really flexible and can be used to Output anything not just html/css
     
  8. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    692
    HTML content ist still using web view, and otherwise you use XAML and Xamarin.Forms (MAUI in future) with razor syntax. And Xamarin.Forms are mostly wrappers for native OS controls.
     
  9. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    100
    I think you misunderstand my comments. Yes the Mobile Blazor Bindings project spits out xamarin.forms element from the razor representation. I proposed a new system which spits out unity ui component as the output. No ios/android/windows native code. Using html content could be restricted either at the framework level or through an analyzer error
     
  10. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    692
    Do you mean UXML it Razor syntax then? That might be more interesting.
     
  11. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    100
    Something like that. Use razor syntax with custom XML markup elements the same thing the mobile bings uses for native ui elements. Also create new layout elements which are more idiomatic for developers coming from other ui frameworks (tables anyone?) (html/xaml). The key point being that you use the razor syntax for this.
    Obviously this would require a lot of work, but given that the experimental Bindings library was made usable with in 1.5 years by 4 devs at Microsoft, working on it part-time, I cant image unity could not do this within a year or two with a decent sized dev team.
     
  12. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    That is exactly what I asked for in my original request, give us blazor for uxml/uss, if they can expand that capability to staright up allow html/css through blazor too. See
    if you want to dig a little deeper into how the blazor component is rendered through maui.

    But I think the best suggestion would be for the UI toolkit to have a "Blazor Element" component, which can be styled like any other uxml/uss element. Then the content rendered onto that element would come from html/css of a regular blazor app. That way the existing UI toolkit workflow can exist as is, while supporting those who choose to use blazor alongside or instead of the default workflow.

    This is pretty much what Microsoft has done across WinForms, UWP, Xamarin etc. They just provide a component that can render the blazor dom. To be clear, I don't think we want maui, we want blazor for Unity UI.
     
  13. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Will this msbuild/csproj version of Unity allow us to specify our output with more control than we have now? I for example would like to have control over where my build output goes when building a player.

    e.g All of my library dll's are output to /Build/Libraries, my own project build dll's are output to /Build/Binaries, with an exe in /Build.

    Having this kind of flexibility in the player build system would be great.
     
  14. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    692
    Here lies the problem, HTML/CSS is always rendered with a "browser". The reason is simple: rendering HTML is too complex. Microsoft and previously Opera even abandoned their own HTML render engines.

    It would theoretically be possible, e.g. for a main menu, but as I said, in my opinion something like this would not be suitable for games. I don't know the performance of Razor, but these technologies are designed for websites, they may be way too slow for gaming.

    On the web, for example, SVG is also used and instead of HTML, the CMS that I use, for example, creates the page tree in the backend using SVG, and as far as I understand it, because it has better performance.
     
  15. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Also does Unity have any plans for a quantized mesh renderer akin to UE nanite?
     
    Last edited: Apr 1, 2022
  16. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Go watch the video I linked, you don't need a browser. This is how in maui you are able to work with native capabilities inside blazor. If it were in a browser you would be limited by the native capabilities exposed via the browser, which you aren't in maui.
     
  17. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Stay on topic or we will have to clean up the thread.
     
    Fabio-Severini, dmaj, Saniell and 5 others like this.
  18. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    507
    For the sake of getting maybe back on track, I didn't see the actual GDC Unity talk linked yet (which unfortunately has some audio problems but still worth the watch). While we wait on maybe a more in-depth blog.

     
  19. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    600
    Awesome news from the talk. Thanks Josh!
     
    NotaNaN likes this.
  20. PutridEx

    PutridEx

    Joined:
    Feb 3, 2021
    Posts:
    1,035
    Good stuff. In a way I watched that video twice. :D
     
  21. vis2k

    vis2k

    Joined:
    Sep 4, 2015
    Posts:
    4,276
    Thanks for sharing!
    Great news by @JoshPeterson again. Nice to see so many technical details instead of marketing speak.

    Sounds like a lot of sane decisions, like transitioning from custom asmdef to existing .csproj.
    Really gives hope for the future of Unity!

    ---
    Btw if you are on mac, you can slide output to the right speaker to make the video sound normal:
    2022-04-05_11-10-02@2x.png
     
    Last edited: Apr 5, 2022
  22. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    100
    @JoshPeterson Thank you for the great talk on GDC. Everything you mentioned seems great, and I am really excited to see the future of the .NET development with Unity.

    The only problem that I can see is with the package management you described. From the talk it seems that you still want to keep UPM around, and keep Unity code off of NuGet. I understand that Unity might find in uncomfortable to use NuGet as a distribution platform, but doing it in the described way just makes no sense to me. As it seems the UPM packages will still fundamentally ship plain cs files and assets, and the only improvement is to to the build pipeline. This means that instead of shipping dlls and assets, the shipped source files need to be compiled by the consuming project. Also it means that when you want to reference other projects distributed through UPM (which will happen all the time) you have two different ways to track versioning of dependencies, which makes an already hard task even harder.

    I understand that you don't want to confuse people with publishing nuget packages only meant for unity but we already have this - in .NET 5 you can't consume framework packages or Xamarin, but everybody just accepted this and we are okay with it. Having 2 different package managing systems doing literally the same thing makes no sense and it also means that unity has to keep another team around to maintan UPM
     
    goncalo-vasconcelos likes this.
  23. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,411
    I don't think we have that on the plan now. The Unity player build is pretty complex at the moment. I don't expect that users will be able to change the output location of assemblies. But it is something we can consider.
     
  24. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,411
    Wow, sorry about the audio problems, I don't know what happened! We are seeing now if we can do something to improve this.

    Our blog post is in-progress now. I don't know yet when it will be published, but I'll mention here when it is.
     
    SugoiDev, Tanner555, NotaNaN and 6 others like this.
  25. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    367
    NuGet is working well for the .NET ecosystem and we want to leverage it, hence why we are working on bringing support for using NuGet from Unity, to open more opportunities in reusing/interoperating with more parts of the .NET ecosystem.

    On the other hand, Unity packages are built around the ability to build from sources, which is something that is not supported today by NuGet. And we are highly relying on this. Why being able to distribute with sources is important for the Unity ecosystem?
    1. It provides the ability for our users to modify existing packages code to fit their needs. You don't need to fork, or clone a repo, recompile...etc. and this ability is quite critical for many game developers, to be able to modify the "fixed" behaviors of the engine.
    2. It provides the ability to have a lot more compilation switches accessible to our users (and package developers) that can be turned on/off and better scale with compilation permutations. With a precompiled model like NuGet, it is impossible to provide such feature. Let's take the simplest example: When you compile a library in "Debug", you will get a different codegen for .NET assemblies that will provide a much better debugging experience. With NuGet, assemblies are compiled in Release and you don't have the choice of the debugging experience. Extrapolate this to e.g experimental features that you could enable/disable, or additional asserts that can help your library to be more robust during the development phase that you don't want to have in a final player, or specific code required for a specific platform. The list goes on. Even in NuGet, they know that Runtime Identifiers don't scale.
    3. A consequence of 2), it allows to make the same code in a package compatible with multiple Unity versions.
    4. Because we are more and more relying on Roslyn Source Generators, if a package provides a source generator and other packages will be impacted by it, updating this package will allow to update the source generated for all the dependencies. Only possible because we ship packages with source code.
    5. A Unity package can be a lot more than what a NuGet package usually provides today: it can have multiple projects, tests, documentations, game assets... We hope also to potentially allow to compile native code, and usually, when it comes to native code, you better want to have source code instead of precompiled binaries. Even the NuGet ecosystem is thinking about it.
    6. A Unity package is only relevant for the Unity ecosystem, which is wider than the .NET ecosystem (while we can leverage NuGet). Even if we were using NuGet as a "packaging layer", the Unity packages would not be usable outside of the Unity ecosystem, so there is little incentive and benefits to change all of this now.
    7. If you look at other more recent ecosystems, e.g like Rust, you will see that source based distribution is usually perceived as a more friendly ecosystem because it comes with many advantages that I listed above.
    Hope it clarifies the benefits of packages with source code and the Unity Package model, and why we are investing into this direction.
     
    Last edited: Apr 5, 2022
  26. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    100
    @xoofx yes, thanks for the in-depth reply
     
  27. RaventurnPatrick

    RaventurnPatrick

    Joined:
    Aug 9, 2011
    Posts:
    95
    In the GDC talk you mention the Unity CoreCLR Player with a Milestone of "Future".
    Any chance we might get a more concrete estimate in the blog post? :)
     
  28. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,411
    Maybe! We're hard at work on it now. The lack of an estimate is not really about hiding anything, but more so about us having confidence in a meaningful date/release. So if we have enough confidence when the blog post is published, we'll definitely communicate that. If not then, we will communicate it as soon a we can.
     
    Elringus, Tanner555, Jes28 and 9 others like this.
  29. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    545
    I don't see the point of
    AwaitableCoroutine
    . Why not just make the Unity APIs return
    ValueTask<T>
    which can be implemented efficiently internally? Users can use the existing
    Task/ValueTask
    for their own async code, or other libraries that are already optimized for general async/await like
    UniTask
    and
    ProtoPromise
    . I think tutorials just need to start teaching
    async Task
    instead of coroutines.

    [Edit] Also the guy that said async/await doesn't work on web, it does. It's just some of the APIs that use threads don't work (like Task.Delay)... Also hoping to get managed threads on the web at some point.
     
    Last edited: Apr 5, 2022
    Protagonist, Huszky, NotaNaN and 3 others like this.
  30. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    545
    Btw, I am a fan of
    CancellationToken
    on Unity objects, but a better name might be
    OnDestroyedToken
    or something like that.
    CancellationToken
    itself is not descriptive of what it's for, and conflicts with the name of the type itself.
     
    Thygrrr, Thaina and Anthiese like this.
  31. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    600
    I second this. And if for any reason you have to make your own task-like construct, please rethink the name. I believe it would be wise to move away from the coroutine naming..
     
  32. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    972
    Unity please buy UniTask or use it as basement for your version.
    UniTask already do it work good and have good short name please buy it or make your version from it as open as possible and name it UnityTask not AwaitableCoroutine nor SpecialCaseUnityTaskThatReplacesCoroutine!!!

    We dont like long names they dont help to understand code :)

    UniTask.Delay work everywhere because UniTask mostly is Async programming not parallel. It dont use threads under the hood. In My opinion UniTask actually better then .Net Task of ValueTask exactly because it make explicit distinction between asynchronous and parallel programming not fuse it together like Task do :)
     
    Last edited: Apr 9, 2022
    Thygrrr, Thaina and JoNax97 like this.
  33. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    54
    The naming for AwaitableCoroutine is not yet fixed, I agree with you that it gives the false sense that it is only for gameloop coroutines, and we will likely revisit the name.
    We want to introduce our own awaitable type in Core, because it will give us a lot of opportunities in term of optimizations that we can't do with a package such as UniTask. Package code can only be implemented in managed code. In Core we have more flexibility, such as directly raising a coroutine completion from Native code.

    A concrete example is for gameloop coroutines such as "EndOfFrameAsync()" or "EndOfFrameAsync()", UniTask has to introduce PlayerLoopSystem extensions and keep track of pending coroutines in its own datastructures. Unity already has a native (and battle tested) datastructure for keeping tracks of gameloop coroutines and resuming them at the correct moment: the prototype we wrote leverage that, and all the gameloop AwaitableCoroutines are resumed directly from this native component.

    Similarly, all Unity objects inheriting from AsyncOperation are implemented in native code. Having the native code itself raise the continuation is really important for us.

    Furthermore, many operations involving GPU computing are asynchronous, and are driven by low level native code. Once again, having the possibility to raise continuations directly from native code is highly beneficial in those cases.

    One other aspect to take into consideration, is that we implement our own AsyncMethodBuilder for this type, which makes it easy for us to make Unity-specific assumption about the threading model and execution environment leading to more efficiency than what we would have with Task/ValueTask.

    We also have some thoughts about the future: controlling the implementation details of this coroutine type, will open the door to optimized code paths in IL2Cpp, and maybe in the future even make async methods awaiting only on AwaitableCoroutines burstable - big emphasis on the "maybe" here, as this has not even been discussed internally yet.
     
  34. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    54
    This is actually a very good suggestion. I'll check if we can still rename it.
     
  35. simon-ferquel-unity

    simon-ferquel-unity

    Unity Technologies

    Joined:
    Apr 1, 2021
    Posts:
    54
    Also, we have already started discussions with @neuecc who is leading UniTask. Our goal here is to work together so that higher level constructs (support for progress callbacks, task operators etc.) provided by UniTask can work with the core awaitable coroutine types as well.
     
    IARI, marcospgp, hessel_mm and 16 others like this.
  36. BlackclawsK

    BlackclawsK

    Joined:
    Jan 9, 2019
    Posts:
    82
    We heavily use UniTask and in general async methods in our codebase. We don't use a single coroutine as the current interface for those feels very dated when async/await exists and performs pretty well already. So this sounds like a step in the right direction. I like the idea of implementing an even more optimized version of async/await handling in the Core of Unity, but please make sure it follows normal async/await conventions as much as possible.

    Its good that you're already talking with @neuecc and I'm looking forward to seeing what the Unity implementation looks like :)
     
    marcospgp, IARI, Jes28 and 2 others like this.
  37. MiTschMR

    MiTschMR

    Joined:
    Aug 28, 2018
    Posts:
    165
    I think the direction Unity is taking now with the .NET Core integration and talking with other devs to improve the engine is very promising :)
     
    Tanner555 and bdovaz like this.
  38. Hertzole

    Hertzole

    Joined:
    Jul 27, 2013
    Posts:
    402
    We also heavily use UniTask and at this point, I don't know when I last saw a coroutine! What I especially hope for when it comes to your own implementation is that there will be no weird issues with threads. With UniTask, everything runs on the main thread but easily gives me the option to switch to some other thread using UniTask.SwitchToThreadPool() and back with UniTask.SwitchToMainThread(). It makes working with async/await a breeze! And the fact that it's so similar to normal .NET tasks makes it easy to convert to and you can use your async skills if you're working with UniTask or with normal tasks. No weird "Unity specific workaround".

    I really hope Unity doesn't provide a stripped-down experience or something too custom to Unity. I would expect parity with UniTask at least!
    I look forward to seeing what Unity has in store for us!
     
    Protagonist, NotaNaN, Jes28 and 2 others like this.
  39. BlackclawsK

    BlackclawsK

    Joined:
    Jan 9, 2019
    Posts:
    82
    I totally agree, the Unity system needs to integrate seamlessly with existing async/await enabled libraries and core dotnet functionality. UniTask allows that already so its definitely doable and I really hope the customization is only the cherry on top and not a wholly different cake :) fingers crossed
     
  40. turanmeric

    turanmeric

    Joined:
    Mar 10, 2022
    Posts:
    3
    I just downloaded Unity 2022.1.0b14 beta, and it seems that HTTP/2 is still not supported. Would you be able to share an expected date for HTTP/2 support for Unity?
     
    Thaina likes this.
  41. Saniell

    Saniell

    Joined:
    Oct 24, 2015
    Posts:
    73
    Mentioning threading. In that GDC talk you said that no changes to thread-safe Api will probably be made, which is a shame honestly.
    Can we at least get "I know what I'm doing and I don't mind crashing the engine" mode that disables such checks? Because it makes no sense to me why I can disable any safety checks when running Job/Compiling Burst, but unity still babysits me on managed side.

    There are plenty of APIs that just read value or pure functions that aren't marked with this magic attribute. I'm pretty sure CalculateFrustumPlanes is/was one of those, for example. I want to get application name from another thread, what can possibly happen to it at runtime?
    Or as another example, I know why GetComponent may not be thread safe, but if in my game, I do 100% know that when I call GetComponent noone touches that object, noone destroys component then why am I forced to be limited with no option to do what I want?

    If being fast is focus of unity, then I believe you should do something about "non thread safe" nonsense
     
  42. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    I'm also really interested in this for gRPC because as it stands we have to use Grpc.Web in Unity to fudge things over Http1. This doesn't support bi-directional/duplex streaming to my knowledge so has been a bit of a pain point.
     
  43. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    Also I have been using UniRx as there is issues using the regular implementation of System.Reactive in Unity. Do you guys think the move to CoreCLR will mitigate this or is there some deeper problem as to why Observables don't work out of the box in Unity?
     
    hessel_mm likes this.
  44. KeinZantezuken

    KeinZantezuken

    Joined:
    Mar 28, 2017
    Posts:
    53
    I have a question about async/await implementation showcased. In the video you have an example where you used async/await to call into Unity API functionality like WaitForEndOfFrame. Now, since Unity API is not thread safe, my understanding is that you either limit async/await to single-threaded model or these calls to UnityAPI actually just some syntactic sugar and it is compiled to some kind of co-routines calls in the end.
    Regardless of what it is, though, in both cases this is becoming dangerously close to aforediscussed situation with null comparison operator overload. Through the whole talk it was stressed multiple time how one of the goals you want to achieve is bring development in unity closer to familiar, traditional .NET [C#] ecosystem dev. However, when we talk about asynca/wai in .NET development we usually talk concurrency and typical concerns that come with it: shared data protection, thread-context awareness, which is not the case for a given in the slides example since that would be executed on frame-by-frame basis on single thread.
     
  45. ProtoTerminator

    ProtoTerminator

    Joined:
    Nov 19, 2013
    Posts:
    545
    @simon-ferquel-unity I did a deep dive on async method builders for ProtoPromise (similar to UniTask), and the way it works is it passes an
    Action
    to the awaiters for continuation. The awaiter handles how that
    Action
    is invoked, which could be from native code like you said. But how does that help with your custom async type? The awaiter controls the continuation, unless you use the builder to force continuation on the main thread like
    Task
    does with the captured context, but that's less efficient, and that still must be done on the managed side, so I don't see how it helps (and you already force the existing complete callbacks to invoke on the main thread).

    That has nothing to do with
    async AwaitableCoroutine
    . If you await an
    AsyncOperation
    and it invokes the continuation from native code, it will do the same thing whether the state machine is an
    async UniTask
    or
    async AwaitableCoroutine
    . So what are you gaining there? You can't raise an
    async AwaitableCoroutine
    's completion from native code as you claimed, because it has to go through the managed state machine to run user code. It has to complete from managed code.

    New APIs such as
    EndOfFrameAsync()
    don't have to return
    AwaitableCoroutine
    to invoke from native code. They can use any awaitable type you choose that doesn't necessarily have to work with the async keyword. In fact, I would argue that returning
    AwaitableCoroutine
    wouldn't even make sense, as that type screams "this is user code!" to me.

    And of course your implementation would be more efficient than Task/ValueTask. That's why UniTask even exists, because Tasks aren't very efficient (though they have gotten much more efficient in Core than Framework).


    I don't mean to be aggressive here, I'm just really trying to understand the real benefits of such an addition over UniTask. The only benefit I see is forcing all continuations on the main thread, which is really only a benefit for beginners, and Task already does that by default since you added the
    UnitySynchronizationContext
    .

    Okay, maybe that's a real benefit? I admit I haven't worked with Burst, so I don't know if that would be useful or not. But you also said that hasn't even been talked about.

    [Edit] Ah, I just realized you use the
    AwaitableCoroutine
    's builder to efficiently hook up to known awaitable types that Unity uses, like
    AsyncOperation
    , instead of passing the
    Action
    continuation through the interface. That makes sense and now I feel stupid about the rest of my post. But tbh,
    UniTask
    could do the same thing if you decided to work with them instead of creating one from the ground up.

    [Edit2] If that is your optimization plan like I expect, you should check out another thread where I tried to do exactly that, but still saw boxing allocations in IL2CPP that you may want to fix. (I originally posted in this thread, but it was moved) https://forum.unity.com/threads/specialized-operation-inside-a-custom-async-method.1231227/
     
    Last edited: Apr 7, 2022
    Prodigga likes this.
  46. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    825
    I wish ReactiveX like UniRX or System.Reactive would also come into unity system. Currenly now I have a hard time trying to get System.Reactive to work in unity
     
    hessel_mm likes this.
  47. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    825
    Totally agree on this, however we only need nuget just for using old library so it could be separate system altogether. Which there was already UPM that support source code import from git url. I wish you would focus on complete that feature (allow git package dependencies)

    On the other hand I agree that next gen coding would be more welcome source code package everywhere. And I disagree that package that has been written in unity would only usable outside of the Unity ecosystem. There are many times I would like to split my code into be unity parts and utility parts. The latter could be useful anywhere and that's why I very need git package dependencies. So that I could distribute my utility code in one package and have my other package also rely on it
     
    Jes28 likes this.
  48. ScottKane

    ScottKane

    Joined:
    Aug 24, 2019
    Posts:
    81
    I don't understand why having Unity source included in projects isn't optional. e.g if I want to be able to modify sources, enable a checkbox that uses UPM, otherwise pull in precompiled from Nuget. While I agree that the use case of modifying engine code exists, I think it represents a much smaller section of users. I have no need to modify any of it, so why am I paying the compilation cost for something I don't need. Should always be opt in.
     
  49. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    825
    Because even if you don't modified it, recompile it give many benefit such as preprocessor directive per platform/condition. And debugging. Also you can learn and investigate the internal process and how to shape the parameter when calling API if there was any problem

    And the catch here is, unity also try to cache the compiled of package for you. So you just compile it once when you import and you will get the dll cached locally if possible. So you don't have that much burden of recompilation even all the package is raw source code
     
    Huszky, xoofx and goncalo-vasconcelos like this.
  50. julienkay

    julienkay

    Joined:
    Nov 12, 2013
    Posts:
    112
    I'm very excited about this and can't wait to hear more.

    I also want to reiterate what has been said before. This thread is the best example among all the Unity features for good and transparent communication on such ongoing developments. Very much appreciated!
     
    marce155, bdovaz, NotaNaN and 2 others like this.