DOTS Editor 0.8.1-preview Release (0.8.2-preview hotfix)

Unity Engine
, ,
1

Edit:
0.8.2-preview Hot fix was released to fix compatibility issues with Unity 2020.2.a17

This is a minor patch release for the DOTS Editor package. One of the major fixes was allowing the support of non-default worlds for the Entities window. We cannot test and accommodate for every scenario of user generated systems so please give us more feedback around this area. Let us know how your systems are set up if they do not work with the windows.

We’ve cleaned up many of the search bugs and added some quality of life improvements to the windows. We have also minimized the line height so please give us feedback around this. We understand it is an accessibility issue so we’re taking the utmost care to deliver properly when it comes to this topic. The goal of this change was to keep the lists consistent with the existing Hierarchy window.

You can get the latest changes via the Package Manager

Changelog
[Fixed]

  • Entities Window: Now supports non-default world bootstrappers (works with netcode setup and custom user world bootstrappers)
  • Entities Window: Inspector now clears selection when deselecting an entity
  • Entities Window: Window selection now clears when selecting something else in the editor
  • Entities Window: Search by any component type instead of only IComponentData and ISharedComponentData
  • Entities Window: Made component types case insensitive in search
  • Entities Window: Now supports duplicate component type name (if multiple types are found all of them will be used in the search)
  • Entities Window: Now always shows results as a listview instead of a mix of treeview/listview based on the search
  • Entities Window: Now shows an error message when failing to resolve a component type name when typing c:mycomponent
  • Entities Window: Now shows a message when no entity match the requested search
  • Entities Window: Changed visual elements height from 20px to 16px
  • System Window: Fixed the issue with cropped system name becoming un-cropped for a moment upon tree view refresh
  • System Window: Changed visual elements height from 20px to 16px
  • Fixed restoration of the previously selected world after domain reload
9 Likes
2

Thanks for the update, though after some quick tests, it appears this package update isn’t compatible with 2020.2.a17 or a18(tested with my project and a new empty project, I get a blank inspector when clicking entities).

3

Can confirm it works on a15. UIToolkit also didn’t work in newest alpha, 15 is latest one that works there (dunno if it’s same issue).

Thanks for supporting non-default worlds in the entities window! I know it was said there will be a new dedicated inspector window, but perhaps in the meantime you could have clicking entities show them in the current inspector, same as entity debugger. This would already cover a large use case for having to open the old entity debugger currently. We don’t need to edit them, just being able to see what values a component has like it shows right now is of great benefit.

I hope that the systems window gets the same treatment for supporting manually ticked worlds. I wanted to reply to [mention|dzE9vyZ3GgkXpUpKOJIMSw==] 's post in the other thread but it’s for old version so I’ll do it here:
“However, we won’t mix scheduled and unscheduled systems in the same view, as that would bring more confusion.”

Why is there such a big distinction between scheduled and unscheduled? (I assume scheduling means running every frame here) I feel like making the distinction is even more confusing. Even in the default world not every system gets scheduled every frame, conditionally ticked systems are a common use case in ECS. I’d still want to know the timings of a system and what dependencies it had, even if it only ran for the particular frame I’m looking, or 10 times in a frame. If you want to be fancy you could show it greyed out and show the metrics of when it last ran between parentheses or something. Of course I could be misunderstanding the language here, since the way I understand the current implementation already mixes scheduled and unscheduled systems.

If it’s about metrics, wouldn’t the current implementation already work fine on systems that don’t tick every frame? Since you’re currently using ProfilerMarkers and Recorder, it just wouldn’t add time if it didn’t run that frame. And if it ran 10 times that frame, that’d still be reflected in the metrics.

I’ve been looking at the implementation (what a lovely thing to be able to say in unity context, kudos for this) I also don’t understand the heavy reliance on PlayerLoop. Apart from this seemingly arbitrary scheduling distinction, is there another reason why you don’t just get the Worlds from World.All and iterate the selected World to show systems? That’d seem like the more simple approach and would work with custom worlds.

Edit: I read my own post again and I can imagine it could be read with a negative tone, this is not the intention. I’m just looking for clarification and maybe used more words than necessary.

4 Likes
4

Hi, this is a new bug for the Entity Window when running in 20.2. We’ll release a 0.8.2 very soon to patch it. Thank you for your feedback

5

@thelebaron
Hot fix was released. Try updating to 0.8.2-preview to fix the 2020.2.a17 issue.

2 Likes
6

Wow that was fast. Can confirm entity selection works now, thanks!

2 Likes
7

thanks, it does indeed work now

1 Like
8

I don’t see DOTS editor in the package list (I have preview packages on) - Am I missing something? (Unity 2020.2.0a18)

9

Unity is now hiding preview packages. More info in this thread

10

com.unity.dots.editor Is what your are after to save you wasting hours

2 Likes
11

How should this work? I’m not seeing any systems in my world.
I’m not using ScriptBehaviourUpdateOrder.UpdatePlayerLoop and have a MonoBehaviour.Update instead which calls all the systemgroups update.

Doesnt’ seem compatible, is it?

12

Hi Enzi, the Entity Window does not rely on a system anymore. The data it needs to be kept up to date is obtained by a set of utility classes that are updated periodically by the editor loop (the one calling OnUpdate on EditorWindows).
So as long as the Entity Window’s OnUpdate method gets called the window should keep up with the latest changes in the world it inspects.

You said it doesn’t seem compatible, have you had any issue with this solution in your particular usecase ?

13

Oh, sorry. I misread the patch notes! I can see entities fine, what I meant was the Systems window. Those are empty for me and I’m not sure what the current state is on that. Hard to find any info other than it’s expected to use ScriptBehaviourUpdateOrder.UpdatePlayerLoop(world) which I’m currently not, I have a custom monobehaviour update method.

14

Curious about your use case @Enzi . Have you added your custom system to the World list?

“World.DefaultGameObjectInjectionWorld.GetOrCreateSystem().AddSystemToUpdateList(myecssystem);”

Are you using the “DefaultGameObjectInjectionWorld”?

Would really like to know how you set up this manually ticked system.

1 Like
15

Sure, it’s not anything fancy - it’s modeled around what I could find from ECS samples and the first iteration of Netcode before it was rewritten for the new player loop.

I have a monobehaviour with ICustomBootstrap that overrides Initialize, creates a world and systems and in update I call Update on componentSystemGroups. So all those groups are manually ticked and not handled or registered in the Unity PlayerLoop. Personally I don’t see anything wrong with it and it’s much easier to read than untangling ComponentSystemGroups. At least I like the approach of composition around it.

I’ve taken a look at the new netcode and there it’s all bundeled in SystemGroups where the top groups are exactly called once and only subsystems are called more often, like the clientPrediction.

The approach, of course, is okay but I feel like you’ve taken the control out of ECS when you expect the profiler tools to use PlayerLoop and not a composition.
Some sort of manual registration for the Systems window would be okay. Currently it all seems auto-magically with using PlayerLoop.

1 Like
16

@Scorr Hey!

No worries :slight_smile:

The distinction is there because that is how it is implemented in the core ECS. By default, some system groups are added to the player loop and every systems in those hierarchies will be ticked every frame. The mandate we’ve receive for the Systems window is to display the resulting schedule of systems.

We’ll provide ways to do this, we just haven’t gotten to it yet. The way that the timings are gathered needs to be revamped because they have the same assumptions as the systems scheduling (part of the player loop, one instance of a specific system, etc.) Now, a lot have changed since and not everything under the hood has followed properly.

No, they are not currently mixed. We are only showing the scheduled systems. Some of the scheduled systems might not run (disabled, queries don’t find entities, etc.), but they are still part of the overall player loop.

Like I mentioned above, this needs to re-worked a little bit. The ProfilerMarkers and Recorders are created/queried by name and the name is built from the system’s and the world’s name, which doesn’t allow to track multiple instances of the same system very well, as well as ticking a system instance multiple times per frame.

The window relies on it because that’s how the default workflow is implemented underneath. System scheduling has been pretty opaque and limited and it is, in my very personal opinion, something that needs to be refactored to allow for more flexibility and more custom usages.

As a general rule, while the core features are being worked on, we’ve decided to create the tooling to reflect the default proposed workflows. This is in part because we need to validate that those workflows are the correct ones for the various users. If those workflows are not the correct ones, it should be fixed in the backend rather than adding workarounds in the tooling. So far, going with this approach allowed us to find core issues and report them to the proper teams.

As stated above, we’re also going to add ways to look at systems in general (scheduled or not) eventually.

17

@Enzi You can look at the post above for more clarity on why we are going this route for now.

From the various use-cases and workflows I’ve seen in the wild, I think it’s clear we need to review how the scheduling works as a whole. We need to establish what is the proper workflow to use and what is considered supported and what is not. You are using the Update method of a MonoBehaviour, I’ve seen usages through OnEnable/OnDisable, through editor windows, through callbacks, etc. Since it’s public API, you can call it pretty much anywhere and as many times as you want.

In a more general note, we are not allowing extensibility on this window just yet, because we are still working on the feature set and the UX. Once that is stabilized, we can look into having user code be called here and there.

18

What is the latest version we can run in Unity 2020.1?

19

The latest version of the DOTS editor is 0.9.0-preview.1 and is compatible with 2020.1

1 Like
20

Is there a way to make the systems inspector auto expand on play, or an option to toggle such behaviour? its a little annoying to unfold the systems list every time playmode starts

2 Likes