If these two component are added to the same entity, the inspector will show both components’ fields as fields of one of the components, a.k.a. the inspector will show two times the same component.
namespace Test.T1
{
public struct ComponentData : IComponentData
{
float time;
Entity Prefab;
}
}
namespace Test.T2
{
public struct ComponentData : IComponentData
{
int count;
}
}
More over, assuming this gets fixed, then the next issue is how to distinguish components if they have the same fields, because the inspector doesn’t show the namespaces of the components (like it does for systems).
You should never have multiple components of the same name. It shows the principle design issues. In fact, bad design. Do not bring them from OOP to DOD paradigm.
Rename each component to something meaningful and distinguishable from each other.
Each name identifier should have only one purpose. Just like single responsibility principle. So follow that.
If you want multiple property of same type data, use dynamic buffers, or multiple entities as children of parent entity.
If i hypothetically have 2 cars, one is ghost car and one is real car, then i want to name the component car, there is nothing wrong with that, i just put them in 2 different namespaces and name them Core.Ghost.Car and Core.Real.Car. But unity inspector has issues displaying these two components on the same entity.
In my particular case i have 2 different emitters on the same entity, and each emitter has its own settings, and i can’t name them EmitterSettings and put them in different namespaces because unity can’t handle it.
I never looked into namespaces, but nested structs and classes work. I currently am using that for something like MyParentStruct.InnerStruct would be what is displayed in the inspector. (My usecase though was predominantly due to lack of generic support in the various versions of entities. It may work now, but won’t know until next weekend work cycle)
Edit: I’m not sure I agree though, that namespaces should be taken into account in the inspector view. Inline with what Antypodish said, you’d want to name them design wise. A nested struct/class accomplishes that whilst also providing your variation in the inspector
That is because design of systems is different in DOTS than OOP Monobehaviour.
You need review your design principles, when working with DOTS.
Meaning, if you got for example particle system, there should be dedicated system, which handles type of particles, regardless which part of code is coming from.
Your name spaces should be tapping into such systems, relevant compoments or dynamic buffers.
You can solve the issue also, by creating entity per particle system. Or as I did mentioned, use dynamic buffer. But don’t let confuse yourself with components missnaming.
I have seen people on the forum been doing attaching same components names multiple times on game objects. Then you can not figure out what is what.
In our project (Sanctuary: Shattered Sun RTS) we have tons (thousands) of particles in runtime. We use Unity’s one. And supports modding. We have one, or maybe 2 systems handling them. Even particles have different purpose. Like smoke, projectiles trails, explosions etc. Plus particles emmits child particles.
The easiest approach is, to make dedicated entity per particle. But you can approach this also from different angles.
I am indicating that your design has flows, which are of different nature. Even if Unit fix supposed bug.
I don’t remember anyone having similar design issues here, as such is typically avoided.
Usually problem is around multiple same components in entity. And that is usually solved with DynamicBuffer.
I suggest to take special care when designing names spaces, so there is no ECS components of the same name. It will avoid uneccessery confusions during the development process.