#EntityManager reference into a shared static.

1 messages · Page 1 of 1 (latest)

main halo
#

Good or bad idea ? why ?

Usecase :
Helper Library with statics function to avoid having to pass ref SystemState in the chain of functions & instead call the entitimanager from a shared static to keep the capability of burstcompile code.

If not a good idea. What is ?

austere delta
#

This kind of feels like the result of having bad underlying architecture - like how much are you doing on the main thread this is an issue?

#

I can't imagine having the need to even consider this and coupling to some global value doesn't sound great to me

#

That said, I don't think in theory that what you're suggesting wouldn't work fundamentally

#

well until you have more than 1 world

#

Also if you do this, you can no longer use SystemAPI

main halo
#

Yup

#

That was a theoritical question here

#

I tested and it does work , if you need multiples world , welp just create multiples sharedstatic : IN THEORY

austere delta
#

what if your system runs in 2 worlds? ^^

#

common in multiplayer

#

(but obviously if your game doesn't have multiplayer, this isn't a concern)

main halo
#

That's why i'm not gonna do it this wya 😄

#

I'm gonna work on multiplayer soon

#

so it will not work ^^"

#

on the other hand ...
I have a few system that take in input a LOT of data

#

As an example :

 public static void UpdateBuildingPreviewMaterials(
            Entity buildingPreview,
            ref FactoryStateSingleton factoryStateSingleton,
            ref BuildingsPreviewMaterialsSingleton buildingsPreviewMaterialsSingleton,
            ref SystemState state)
        {
            BuildingMaterialStatus status = BuildingsPreviewMaterialsSingleton.DetermineMaterialIdToUse(
                true,
                factoryStateSingleton.IsState(BuildingPreviewStateType.PlacePreview)
            );
            (int, int) materialsID = buildingsPreviewMaterialsSingleton.GetConveyorMaterialID(status, BuildingType.Conveyor);
            UpdateBuildingPreviewVisual(materialsID.Item1, buildingPreview, ref state);
        }

This helper is called in multiples places
My concern here was to avoid to repeat myself code wise

#

On the other hand I do have a lot of these in the packages i'm building and it's kinda tedious to add all the ref & passing the singletons in them just to avoid to repeat 3 lines of codes

#

and yes it's called from multiples systems

austere delta
#

i think helper structs are a lot less effort than helper static methods

#

you can just store all your data in the struct

#

BuildingHelper(Entitymanager state.EntityManager, FactoryStateSingleton factoryStateSingleton, BuildingsPreviewMaterialsSingleton buildingsPreviewMaterialsSingleton)
then just store them in fields
your methods just become this then
void UpdateBuildingPreviewMaterials(Entity buildingPreview)

main halo
#

ooof

austere delta
#

you can even do all the initialization in the constructor so it's easily re-usable in multiple systems

# 
BuildingHelper(ref SystemState state) {
    _entityManager = state.EntityManager;
    _factoryStateSingleton = state.EntityManager.GetSingleton<FactoryStateSingleton>();
    _buildingsPreviewMaterialsSingleton = state.EntityManager.GetSingleton<BuildingsPreviewMaterialsSingleton>();
}```
kind of deal (this getsingleton method doesn't exist, i just have an extension)
#

can even create it in OnCreate, and just have an Update(ref SystemState state) for example to update data if you need

main halo
#

Hummm

Never though of doing it this way

#

Do your GetSingleton method is something you shared somewhere ?

main halo
main halo
# austere delta ```cs BuildingHelper(ref SystemState state) { _entityManager = state.EntityM...

regarding your getSingleton ...
I've made my own ... but not sure what is the best way to avoid the entityquery creation ...

public static Entity GetSingletonEntity<T>(this EntityManager entityManager) where T : unmanaged, IComponentData
        {
            EntityQuery query = entityManager.CreateEntityQuery(typeof(T));
            Entity singletonEntity = query.GetSingletonEntity();
            query.Dispose();
            return singletonEntity;
        }
        
        public static T GetSingletonComponent<T>(this EntityManager entityManager) where T : unmanaged, IComponentData
        {
            return entityManager.GetComponentData<T>(entityManager.GetSingletonEntity<T>());
        }
#

I should probably cache it somewhere ...

austere delta
#

but yes that's basically how you have to get singleton

#

however if you need to get your singleton more than once (i.e. per frame)

#

just store the query in the struct, have an Update method to get the latest data from the query

#

note though, if you are getting the data per frame you should not use entity manager to create your query

#

you need to use SystemState

#

to ensure the system gets the dependency added to it

main halo
#

Makes total sense

main halo
austere delta
#

IBufferElement or other native containers

main halo
austere delta
#

mono won't complain about struct size until you hit 10,000 bytes

austere delta
#

to burst entity query creation

main halo
#

didn't know that part

austere delta
#

i wouldn't be surprised if CreateEntityQuery (params Type[]) got deprecated in entities 2.0

#

really shouldn't be used anymore

main halo
#

fair enought

#

but proper examples are still sporadic online ... Still struggling a lot as soon as I try to do a bit of complex stuff ^^

#

They anounced ECS 2.0 already ?

austere delta
#

no

#

but if they're going to do breaking changes, 2.0 is their chance

#

and i suspect it'd be nice to cleanup a bunch of old api

#

could be 2024 could be 2030 ^_^"

main halo
#

looool

austere delta
#

(pure speculation)

main halo
#

Indeed , what is missing is a proper cookbook I think

balmy arrow
#

Would it be fair to assume they are holding a lot back for unity 6? Or is ECS not considered a core part

austere delta
#

thankfully at least 1.0 api is reasonably stable now

#

so hopefully should decrease over time

austere delta
#

(which is basically the pre-cursor to unity 6)

main halo
#

@balmy arrow welp we need to update 😄

balmy arrow
#

Yep

austere delta
#

i do suspect a few of the, upcoming rumoured entities features may require a newer version of entities

#

but who knows

#

(they are announcing stuff soon btw if you haven't seen news today)

main halo
#

huh ? nope have not seen anything , lemme check the forum

austere delta
#

Discord:

For the most part most of the new changes are additive, but we're looking to deprecate or remove some APIs and there are more than a couple of pieces that will be superfluous.
I'm writing up a forum post to go into detail and verify what I can and can't share
hopefully you'll agree that it's going to be cause for celebration

Forum:

I can confirm that a lot of us have been working on various future entities somethings for quite a while now; I've gotten mixed messages about when we'll be allowed to say what about them, so I won't expound for now.

That's mostly why I haven't been talking that much here or in discord for a while. That said, I am basically very into the somethings and I genuinely think and hope y'all will be too.

My overall advice to people using entities is that it's extremely not going away in the future, and I think it's a great idea to build stuff on it now for that reason. I think the concerns about needing internal access are quite valid, I can confirm we all care about them a lot, and I hope we can significantly reduce that in the future.

#

save you searching

balmy arrow
#

So seems like effort put in now won't be squandered

main halo
#

yup

balmy arrow
#

Which has been a worry of mine

main halo
#

pretty much not going anywhere 😄

balmy arrow
#

Big learning curve to get to the top of just to find you're at the bottom again 😂

main halo
#

Welp and you are not going to take care of the networking ...
I just hope that what i've done in the last few days is going to help for that 😄

#

At least now we have more stuff bursted ... Will still need to optimize burst later but for now that will do ^^

#

@austere delta any advice for the architecture regarding multiplayer ?
Like , some trap I should avoid at all cost ?

austere delta
#

are you using netcode?

#

and what style of game

balmy arrow
#

Factorio style

#

@main halo will have to answer the former

#

If he hasn't fallen asleep at his pc

austere delta
#

well factorio style is definitely interesting

#

i haven't made one but have thought about it a bit

#

and you definitely need to network as little as possible

#

all the stuff on belts, shouldn't really be networked objects

#

just locally simulated ideally

#

or at least, infrequently networked and predicted very well

balmy arrow
#

My hope is that we can do a lot of approximation, rather than run into the same issues factorio has

austere delta
#

i havent played factorio match

#

but i played a lot of satisfactory

#

and based on the bugs i experienced as a client they definitely weren't syncing the belt items

balmy arrow
#

😂

#

Yeah factorio is a desync generator when it comes to networking

austere delta
#

but yeah, just get some type of massive test going early

#

and test architecture often

balmy arrow
#

👍

austere delta
#

no point investing a bunch of time in architecture that can't scale

#

when thats like the whole point of htese games

balmy arrow
#

Yep

#

We met modding Dyson Sphere Program

#

Which has some major performance problems

#

Trying to address those issues from the ground up

#

I don't think any particular networking implementation has been decided on yet

main halo
#

netcode for entities

#

This is where we are putting our progress

#

but i've been working on that for a while now , there is a lot not shown yet 😄

main halo
#

for each item