More entities than expected in a system when adding ComponentData?

[fast fjord]

Hey so, I'm been doing ESC for the past week and I'm reading as much documentation as I can
I have two Systems, ClientUserJoinSystem and CharacterSystem
The purpose is a Player with a Device joining the game and getting a character to spawn when a button is pressed
The first system takes a InputActionProperty and subscribes to its action when performed
Once it's performed, it does the following

            Entity entity = CheckedStateRef.EntityManager.CreateEntity();

            CheckedStateRef.EntityManager.AddComponentData(entity, new Characters.CharacterData());
            CheckedStateRef.EntityManager.AddComponentData(entity, new UserPlayer { inputUser = newUser, playerIndex = playerIndex, controlScheme = controlScheme });

This works just fine, and the entity gets created with UserPlayer
Thing is, whenever I go and check CharacterSystem in the System tabs... (first pic related)
There's two entities in the CharacterSystem, which confuses me, Characters.CharacterData does not get instanced anywhere else but in the code snippet I posted (second pic related for references in visual studio)
So I'm extremely confused with the entity count, I don't know if it's supposed to say that or not, I don't know if I missed something in the manual

In CharacterSystem I did

            foreach (var (cd, entity) in SystemAPI.Query<RefRO<CharacterData>>().WithEntityAccess())
            {
                Debug.Log($"{entity.Index} ver {entity.Version}");
            }

And it only prints the same line over and over again, with the same entity index and version, so I just don't know

Maybe I should mention that the first is a SystemBase, and the character system is ISystem

[surreal zealot]

show the full system

you're probably requesting a singleton or something (ecbs?)

[fast fjord]

https://hatebin.com/guszseorjf
Here's both of the systems, ClientUserJoinSystem is a mess (with comments) because its a migration of a migration I made from input's system PlayerInputManager
Neither users or characters are supposed to singletons

the code snippet i posted is from line 181

Also both systems are in different assemblies, ClientUserJoinSystem's asmdef has a dependency in Characters asmdef
The documentation says that one world has a EntityManager, and since they are all in the same world, all entities get put in the same place despite the weird asmdef setup I have

[surreal zealot]

oh its very simple ^_^'

well just click on your system and look at the inspector

it will show what entities are being picked up in the system and what query they match

[fast fjord]

Oh

That's a thing you can do

[surreal zealot]

yeah this is what i was expecting

the state.RequireForUpdate is just creating a separate query

to the code gen

not really sure why they aren't matching/being re-used

that's usually a thing unless it broke recently

[fast fjord]

So the (2) is from entity queries, not the actual entities in the system, one from character system (which is empty) and other from uhhh

state.RequireForUpdate?

yeah

and then the other is SystemApi.Query

these two are the (2) queries that appear in the system

[surreal zealot]

yeah i would have expected it to simply re-use the query

since they seem to match identically

not sure why this hasn't happened

but anyway it won't cause any issues

side note: you no longer need [BurstCompile] on the top of ISystem

it's implied by default

as long as you have it on the OnUpdate etc method it'll be fine

(this is the one exception to the rule for defining BurstCompile)

[fast fjord]

what about the one in the client join system? I have one above the class definition, and unity isn't throwing any errors about it, despite being a SystemBase?

I have no idea if it actually does anything

[surreal zealot]

well it won't do anything on a systembase

oh you are trying to burst compile the OnUpdate on systembase?

why is it a systembase

[fast fjord]

Do SystemBases get optimized by the codegen? or should I remove the partial?

[surreal zealot]

you should make it an ISystem ^^

oh though

you have some weird things going on here probably not easy

[fast fjord]

there's private Action<InputAction.CallbackContext> _joinActionDelegate; and I didn't see any way to make it an ISystem

Also private AsyncOperationHandle<InputActionAsset> inputActionLoadHandle;

[surreal zealot]

yeah keep it systembase

but your [burstcompile] isn't doing anything

you may as well remove it

burst compile only works on static methods

(ISystem again being an exception due to unity doing some magic)

[fast fjord]

Oh I guess it does need partial

[quick kestrel]

It's slowing down compilation

[surreal zealot]

^ TRUE

[fast fjord]

Okay gotta keep that in mind