DOTS Editor 0.7.0-preview Release

With the release of 0.7.0-preview of the DOTS Editor package we have now released the new Systems Window. This can be found in the file menu “Window > DOTS > System Schedule”.





The System window is an improvement over the systems list view of the Entity Debugger. Its purpose is to allow users to debug and discover the systems in their DOTS enabled project. In the close future, it will also allow users to see the interaction between entities and the systems acting on them.


First, you’ll notice the new icons that represent System Groups, Systems, and ECB Systems. This is to help easily pinpoint the different types of systems in the project.


We can now also disable System Groups.


To keep world information manageable, we have hidden the other worlds in the world dropdown list. To enable it again, we have added a setting to show all of the available worlds in the project in the Preferences window. We have also moved the options (“Show Full Player Loop” and “Show Inactive Systems” to the right of the search button.





When a system is selected, there is now a Systems details preview window that shows up on the bottom and can be hidden by clicking on the header. This allows a user to view the queries related to the system and also contains a button that will show system dependencies only defined by that system.


By clicking on a component in the Queries section, a user can also find other systems that have queries containing the same components.





Filter Syntax
To filter by a component: c:<component name>
To filter by system dependency: sd:<system name>


Please leave your feedback here and any issues that you may have noticed.


Enjoy!


Known Issues:

• Limited search. The search is currently a limited feature, for example, it is only filtering strings and only inclusive matches.
  
  
• The details section of the System window can cover a selected system
  

 

It should show custom groups and custom systems (systems with DisableAutoCreation/AlwaysExecute/UpdateinGroup attributes). Enable "Full Player Loop" in the top right options button to see the Unity monobehaviour systems. If things aren't working as expected, can you please share some more details.

There is currently a bug where you cannot see a custom system if it is being scheduled against another world (aka a custom player loop). You should still see it with show Full Player Loop. The work around is to view it in the EntityDebugger for now if you want to view the list per World.

 

@nicolasgramlich Not exactly, we intend to do the opposite.

The next window that we will release will most likely be a dedicated entities window. The first step will be to release it as a standalone window (just like this one) in order to gather feedback from users. While iterating on the feedback, we'll add connections between the two windows, such as filtering the entities by systems and by query. We'll also revamp the search to allow searching by name and by id.

We know it is a little confusing to have the new tooling sit beside the Entity Debugger, but we feel it is a necessary evil until we can offer at least the same feature set. Once we are satisfied that the new windows provide a better experience for the users, we will remove the Entity Debugger.

 

@thelebaron Initially, the entities window will allow to browse the entities using the Parent and Child relationship. It will not affect how the entity inspector currently works.

However, we are also looking into revamping the entity inspector. That should come after the entities window. As a starting point, we'll only allow custom inspectors to be written. After an internal pass on creating inspectors for Unity provided components (let's not ever run into setting yourself as a parent), we'll look into allowing to write back to the entity. It's one of those things where it's very easy to activate, but difficult to nail down, as there are many pitfalls. For example, editing a shadow World would corrupt the GameObject conversion. This one is easy to spot, but there are definitely other, more devious situations where editing can be problematic. So we will take our time on that one and make sure it will be safe and pleasant to use.

 

@Enzi One thing to note is that our mandate with these windows is to surface what is going on under the hood. We will be more than happy to change the tooling whenever the underlying systems change. It is one reason why we wanted these tools to be in a different package, so that we can assemble them like a user could. We do have to cheat here and there and call some internal APIs, however the end goal is that we should only use public APIs. If we can't build the tooling on top of public APIs, it means the users won't be able to either.

At the moment, the system schedule is automagic. A call to change this has been echoed several times on the forums and I agree it with many of them. It is known, but as far as I know, there are higher priorities to deal with before tackling this.

About your custom bootstrap, do you tick the world manually?

 

@Scorr It's not so much because we want to show timings, it has more to do with the fact that these systems will be called every frame. Manually ticked systems are.. manually ticked, which means they can be ticked every frame, more than once every frame, once every second, conditionally ticked if it's Monday, etc. In those case, we cannot guarantee that the system will be called every frame and there are no good ways for us to track good metrics on it at the moment (internally, we track the timings using profiler marker).

We're looking into other ways to give you access to the systems without them being scheduled. However, we won't mix scheduled and unscheduled systems in the same view, as that would bring more confusion.

Ideal situation for me is we can open up how the schedule is populated to users and these systems would then show up in the window. In the meantime, we'll explore other solutions, such as creating inspectors for some of the constructs that we have (systems, archetypes, world, etc.), so that we can show more specific information (list of sub system for a give system, the shared component values on archetypes, etc.)

 

@Jes28 That's fair.

We're using the same method of calculation that the Entity Debugger currently uses. We do want to expand on that eventually (i.e. choice between average, min/max, median, etc.)

 

@nicolasgramlich Those are good suggestions, I'll take them back to the team.

A note for the search, we're working on using the Quick Search package to enable extended search scenarios. This would be done as an optional dependency, meaning that if you have the Quick Search packaged installed (and you should ), then we can allow more functionalities; if not installed, we'll revert back to the more simpler we have right now.

 

@DreamingImLatios Yes, that would be because the time recorder is stored per system instance, which was how the Entity Debugger was storing it.

I'll bring this back to the team, so we can track multiple insertions of a single system instance.
Thank you for reporting this.