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

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

 

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

 

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

 

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 ?

 

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

"World.DefaultGameObjectInjectionWorld.GetOrCreateSystem<SimulationSystemGroup>().AddSystemToUpdateList(myecssystem);"

Are you using the "DefaultGameObjectInjectionWorld"?

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

 

@Scorr Hey!

No worries

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.

 

@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.

 

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

 

The system list should maintain the open/closed states after domain reload. It should be less annoying when we fix this bug. Expanding all by default is an interesting feature. Noted.