Post by Admin on Jul 16, 2016 3:28:33 GMT
Brandon Catcho @bcatcho Aug 19 2015 03:28
@svdvorak, not too bad. I also looked into using the IComponents to help configure my entities but I'm not using Vexe or have another solution to help with displaying the IComponent classes. I was thinking about reusing the TypeDrawers that comes with Entitas (Entitas.Unit.VisualDebugging/Entity/Editor/TypeDrawer) but it's very coupled to the Entity editor class.
Another thing I tried was making my IComponents serializable and using them like normal properties on my configuration class. This worked but was a tad rigid.
Overall I don't have that many configurers so I don't mind updating them by hand. On top of that there are more interesting decisions these configurers make and I would have to do that by hand anyway.
|
Post by Admin on Jul 16, 2016 3:28:43 GMT
Brandon Catcho @bcatcho Aug 19 2015 03:37
For large scenes, however, you will be deserializing many IComponents and adding those to the heap as separate objects. That will have all the usual heap consequences that come with using many small classes. I think your implementation will be fine until your scenes become very large and you have to load and unload assets semi frequently.
Furthermore (and I'm sure you already know this) Object.FindObjectsOfType is very slow and allocates an array for all the objects it finds.
|
Post by Admin on Jul 16, 2016 3:28:57 GMT
Brandon Catcho @bcatcho Aug 19 2015 03:51
If I had any real criticism, it would be this line:
entity.AddComponent(ComponentIds.ComponentToId(component), component);
That line worries me. You are taking an IComponent that was instantiated outside of a closed system (Entitas), injecting it into the system and hope everything goes well. Generally this is not a good idea as you are passing ownership of the class to an opaque system and it's lifecycle is now out of your hands.
Here's a more specific example. This is a portion of an auto-generated IComponent called ExternalMover:
public Entity ReplaceExternalMover(UnityEngine.Transform newRootTx) {
var previousComponent = hasExternalMover ? externalMover : null;
var component = _externalMoverComponentPool.Count > 0 ? _externalMoverComponentPool.Pop() : new CatchCo.Stalks.Gameplay.EntityComponents.ExternalMoverComponent();
component.RootTx = newRootTx;
ReplaceComponent(LockStepPoolComponentIds.ExternalMover, component);
if (previousComponent != null) {
// !!!!!!
_externalMoverComponentPool.Push(previousComponent);
}
return this;
}
The line after all the exclamation points is the key part. If you call entity.ReplaceExternalMover() it will find a new ExternalMover component from a pool and it to the entity. Next it will take the ExternalMover that was previously there and push it back into a component pool.
In your situation this means that there is a Stack somewhere that is holding on to a reference of your configuration component. Even if you unload the original asset/gameObject, the component will remain in the pool. And if the component had a reference to any other classes, it will prevent the GC from cleaning those up as well. etc etc
|
Post by Admin on Jul 16, 2016 3:30:01 GMT
Laurence Roberts @lsjroberts Aug 19 2015 05:03
Does anyone else have issues when deleting components? I find that they keep coming back into the Generated folder.
Also deleting the whole folder causes massive issues when it tries to regenerate from scratch, throwing errors like:
Assets/Sources/Features/CreatePlayerSystem.cs(12,14): error CS1061: Type `Entitas.Entity' does not contain a definition for `AddLabel' and no extension method `AddLabel' of type `Entitas.Entity' could be found (are you missing a using directive or an assembly reference?)
In the case of that second issue all it generates is the empty CoreAttribute.cs, CoreComponentIds.cs and Pools.cs classes
|
Post by Admin on Jul 16, 2016 3:30:56 GMT
Laurence Roberts @lsjroberts Aug 19 2015 05:16
It seems the only way to get past that is to comment out all the systems and references to them, generate the rest, then put the systems back in
|
Post by Admin on Jul 16, 2016 3:31:06 GMT
Brandon Catcho @bcatcho Aug 19 2015 05:20
I usually:
delete the generated file for the component
fix all the errors that causes.
delete the component
The only step that is different than deleting any other class is step 3.
|
Post by Admin on Jul 16, 2016 3:31:15 GMT
Laurence Roberts @lsjroberts Aug 19 2015 05:35
ok cool, I'll try that next time, ta
|
Post by Admin on Jul 16, 2016 3:31:26 GMT
Andreas Wilcox @svdvorak Aug 19 2015 07:34
@bcatcho Thanks for the great feedback! I agree that it's a bit of wishful-thinking regarding memory handling and I know that FindObjectsOfType is slow but it was the easiest and fastest solution I could think of and it works well enough for the small size of the project currently. Though I didn't think at first that a few built in types worth of memory lost to be that bad but I did just remember that some components reference other classes so it's a bit worse than I thought. And as I mentioned you have to add a bunch of components that you're not really interested in but the system needs. But I did like how you can essentially extend any game object easily by adding the components to get the behaviour you want. I think your solution would probably work better in the long run, you'd just create configurators for a specific behaviour (like your combat one) and do similar extension by adding multiple configurators. And I just noticed that your code could handle multiple configurators already =)
|
Post by Admin on Jul 16, 2016 3:31:41 GMT
Brandon Catcho @bcatcho Aug 19 2015 07:43
Honestly, you would have to have very large and inefficient scenes to worry about the memory impact of a list full of a few components. It's probably the least of your worries - I was just extrapolating.
I do think you should keep an eye on that last comment about entity.addComponent as I think it could be the source of memory leaks/ bugs some day.
I'm glad you took the time to post your implementation though. Once I accumulate enough of this stuff I may end up making a helper library to aid in bootstrapping your Entitas-Unity project.
|
Post by Admin on Jul 16, 2016 3:32:07 GMT
Andreas Wilcox @svdvorak Aug 19 2015 07:49
True, as it stands now in my small project it won't matter (and probably won't for a while), still worth to keep in mind. And I'm kinda getting sold on your configurator-solution anyway. I think a helper library would be great, there are some systems and components that I think a lot of people use in one way or another (Position, Rotation, View, etc) and it would be nice to have those components and systems (RenderPositionSystem for example) readily available.
|
