Post by Admin on Jul 16, 2016 3:48:39 GMT
Simon Schmid @sschmid Aug 16 2015 00:06
New release 0.21.0 addresses the issue that @judelco described, where destroyed entities are still in the groupObserver.collectedEntities and therefore also are passed to a reactive system. See the release notes because your existing systems might need to be updated, because the pool.DestroyEntity(entity) behaviour is changed. In a nutshell: calling pool.DestroyEntity(e) will immediately destroy the entity. It's the very last step in the lifecycle of an entity. It won't trigger group.OnEntityRemoved anymore but group.OnEntityWillBeDestroyed.
For reference, I updated Match-One and Entitas-CSharp-Example. They use all new recent features like MultiReactiveSystem, IEnsureComponents, and the new pool.DestroyEntity(e) behaviour
JuDelCo @judelco Aug 16 2015 00:09
Thanks Simon, i hope my fix proposal has served as an idea
I will now check the changes done in both repositories
Simon Schmid @sschmid Aug 16 2015 00:28
@judelco sure, thanks a lot!
Christian Schuster @chrischu Aug 16 2015 01:18
@sschmid What do you think about issue #20 and the corresponding pull request #21 ?
JuDelCo @judelco Aug 16 2015 01:19
I think is not necessary
Christian Schuster @chrischu Aug 16 2015 01:19
There is no other way around the problem though....
And I don't think there is a significant disadvantage to renaming the interface/method...
JuDelCo @judelco Aug 16 2015 01:21
You can always do:
void MonoBehaviour.Start() {}
void IStartSystem.Start() {}
Simon Schmid @sschmid Aug 16 2015 01:21
Naming wise, I think it makes sense. But I didn't really understand, how you can run into problems
JuDelCo @judelco Aug 16 2015 01:22
stackoverflow.com/questions/2371178/inheritance-from-multiple-interfaces-with-the-same-method-name
Christian Schuster @chrischu Aug 16 2015 01:23
The problem occurs when I have systems that have some public fields for configuration and it would be cool to change the configuration in the Unity Editor.
Simon Schmid @sschmid Aug 16 2015 01:23
ah, I think i get it now
You want to implement IStartSystem in a MonoBehaviour
Christian Schuster @chrischu Aug 16 2015 01:23
Therefore these systems need to be MonoBehaviors
JuDelCo @judelco Aug 16 2015 01:23
But you can do it
can*
This composemode<->chat mode in gitter makes me crazy
Simon Schmid @sschmid Aug 16 2015 01:24
Configuration is data and should be represented with entities
Systems should have no state
Christian Schuster @chrischu Aug 16 2015 01:26
So I have to put my configuration either in code (not a good idea)
Or in some other format I have to think of that I can then load and turn into entities which then can be used by the systems....
The "configuration" btw is often as simple as linking another GameObject that represents some UI.
And that would be hard to represent with entities...
Simon Schmid @sschmid Aug 16 2015 01:30
to quote @mzaks from his blog post Games, Data and Entitas
"A careful reader might noticed that I wrote configuration is „fixed“ data. I put the word fixed in quotes. I did it on purpose because configurations are not always fixed. Some times designers might want to change them even when the game is already rolled out. A designer might even want the configuration to be changed for a random amount of users. This technique is called A/B Testing."
Christian Schuster @chrischu Aug 16 2015 01:31
I read all his blog posts, still I think there is a pretty big difference between configuration (which key does what etc.) and what I'm doing.
Simon Schmid @sschmid Aug 16 2015 01:31
Do I get it right: you want to link some gameObjects on MonoBehaviour, and you want to use these linked gameObjects in the system
Christian Schuster @chrischu Aug 16 2015 01:32
Yes, exactly.
For example when I create UI with the Unity UI system (which is obviously then manifested in GameObjects).
JuDelCo @judelco Aug 16 2015 01:33
Make them public and create a IStartSystem that reads all unity entities with that script and load those gameObjects from them.... ?
Simon Schmid @sschmid Aug 16 2015 01:33
What are these GOs, and what are they supposed to do? (want to see if there's an alternative)
Christian Schuster @chrischu Aug 16 2015 01:33
Ok concrete example
I have a grid-based game and a selector element that I move with my keyboard
Every tile in the grid has some information associated with it
For example: Is it a mountain or is it a meadow
To show this information I created some UI elements with Unity's UI system.
Whenever the selector element moves, I need to update the UI elements.
So in effect when the PositionComponent of the entity with the SelectorComponent is replaced.
Simon Schmid @sschmid Aug 16 2015 01:37
As you said, every tile in the grid has some information associated with it - that's very good. By selecting a tile a RenderTileInfoSystem could instantiate a popup prefab, position it and populate it with the corresponding information of the tile
Christian Schuster @chrischu Aug 16 2015 01:39
The only trouble is that I then have mixed together design-time UI information (UI positioning, size, etc.) with run-time game information (currently selected tile).
And I completely loose the advantage of being able to easily change my UI in the Unity editor (which is the exact strong suite of the new Unity UI system).
I think one could even make the argument that what I store in my systems is not even state.
JuDelCo @judelco Aug 16 2015 01:41
Flag that UI selector with a tag, or unique empty script, ... and then in a IStartSystem search in Unity with "GameObject.FindGameObjectsWithTag/FindObjectOfType" or similar and then link that gameObject with the entity/component in Entitas.
At runtime, if you want to change that selector, you will need to make changes with EntitasUnityDebugger menu
Or make it a prefab and instantiate it like "AddViewSystem" in the Entitas examples
Christian Schuster @chrischu Aug 16 2015 01:42
Prefab makes me loose positioning information/design time experience (as stated before).
Tagging leads to a whole bunch of strings in my code.
Strings that can easily fall out of sync...
Simon Schmid @sschmid Aug 16 2015 01:43
but you are still able to change the UI in Unity, or I get sth wrong. What I do: I have multiple template prefabs for all popups in my games. They all are layed out in Unity and have some lorem ipsum data.
JuDelCo @judelco Aug 16 2015 01:44
And a monobehaviour script "UIElementScript" with only a public string member with the ID ?
Simon Schmid @sschmid Aug 16 2015 01:44
Either a system updates the content, or, they take care of them self, by observing the pool
Christian Schuster @chrischu Aug 16 2015 01:44
How do you accomplish they second part?
"Taking care of themselves by observing the pool"?
I assume themselves = prefabs?
Simon Schmid @sschmid Aug 16 2015 01:45
Match-One ScoreLabelController.cs
Christian Schuster @chrischu Aug 16 2015 01:46
And you want to tell me that this is no system?
Because it looks like it does very similar things to a reactive system.
Simon Schmid @sschmid Aug 16 2015 01:47
yeah, you're right.
JuDelCo @judelco Aug 16 2015 01:47
Is the same but configurable in Unity editor
the idea i think is still keep all the logic away of Unity
Christian Schuster @chrischu Aug 16 2015 01:47
So you see my argument that there is really no harm to have a system derive from MonoBehaviour right?
JuDelCo @judelco Aug 16 2015 01:47
that only "links" the logic in entitas and unity
if you want in the future make a port with another framework or renderer, if you make systems with monobehaviours it will be harder to port
Christian Schuster @chrischu Aug 16 2015 01:49
I'm not saying EVERY system needs to be a MonoBehaviour.
I'm saying it would be useful if SOME systems could be.
JuDelCo @judelco Aug 16 2015 01:49
Yes, and i tell you that can be possible
Christian Schuster @chrischu Aug 16 2015 01:49
And those systems would break when you change the framework, just like the ScoreLabelController does.
JuDelCo @judelco Aug 16 2015 01:50
You can always do:
void MonoBehaviour.Start() {}
void IStartSystem.Start() {}
stackoverflow.com/questions/2371178/inheritance-from-multiple-interfaces-with-the-same-method-name
Christian Schuster @chrischu Aug 16 2015 01:50
@judelco I really wasn't born yesterday, I know what explicit interface implementations are.
It doesn't change the fact that it complicates things (if ever so slighty).
I think in general it is not a bad idea to make it easy to distinguish between Start/Update (Unity) and Initialize/Execute (Entitas) at a glance
Simon Schmid @sschmid Aug 16 2015 01:51
As I mentioned, naming wise I think it makes sence, and I guess I might merge #20
Christian Schuster @chrischu Aug 16 2015 01:51
Cool
JuDelCo @judelco Aug 16 2015 01:52
Renaming methods could be the same problem in another framework with different method names isnt ?
Simon Schmid @sschmid Aug 16 2015 01:52
But I wanted to hear, what kind of problems you meant, and if there's an alternative, that might make more sense
Christian Schuster @chrischu Aug 16 2015 01:52
Of course @sschmid
I'm not blaming you for not jumping on the first chance to rename a pretty central method/interface in Entitas
Simon Schmid @sschmid Aug 16 2015 01:53
@judelco true
Christian Schuster @chrischu Aug 16 2015 01:54
@judelco true, but I imagine that might be the least of one's worries when switching to another framework.
JuDelCo @judelco Aug 16 2015 01:54
Yes
Christian Schuster @chrischu Aug 16 2015 01:54
And I think it falls under YAGNI
JuDelCo @judelco Aug 16 2015 01:55
Anyway i agree with the change because this entitas repo is very "unity" relevant
Simon Schmid @sschmid Aug 16 2015 01:55
@chrischu well, proper naming can make the difference 
JuDelCo @judelco Aug 16 2015 01:56
That leads me to another question.... makes sense to rename in the other entitas languages repositories the same change to preserve the same api ?
Christian Schuster @chrischu Aug 16 2015 01:56
Yeah, proper naming is also coincidentally the hardest thing about programming...
JuDelCo @judelco Aug 16 2015 01:57
though i doubt they are equal at this moment xD
Simon Schmid @sschmid Aug 16 2015 01:57
@chrischu definitely
@judelco yes, the other entitas repos are maintained from different ppl and have slighly different apis and also different implementations, crafted for their plattform
the c# version for example is the only one with mutable components
JuDelCo @judelco Aug 16 2015 03:23
I have some questions about the changes in the new Entitas version... the first one:
Entitas-CSharp-Example:
RenderPositionSystem.cs -> Why did you implement IEnsureComponents interface ?
JuDelCo @judelco Aug 16 2015 03:28
Oh ... i think i know now why.... maybe RemoveViewSystem deletes the view in that frame for some reason (deletion of Resource component or flagged by Destroy component). Okay, so the next question...
Second one is the same but repeated in some classes
In Entitas-CSharp-Example:
RemoveViewSystem.cs -> If a View component is deleted in a system that runs between removeViewSystem and DestroySystem the system wont be notified
In Match-One:
FallSystem.cs -> If a GameBoardElement component is deleted in a system that runs between FallSystem and DestroySystem the system wont be notified
FillSystem.cs -> If a GameBoardElement component is deleted in a system that runs between FillSystem and DestroySystem the system wont be notified
ScoreSystem.cs -> If a GameBoardElement component is deleted in a system that runs between ScoreSystem and DestroySystem the system wont be notified
RemoveViewSystem.cs -> If a View component is deleted in a system that runs between removeViewSystem and DestroySystem the system wont be notified
CreateGameBoardCacheSystem.cs -> If a GameBoardElement component (or Position) is deleted in a system that runs between CreateGameBoardCacheSystem and DestroySystem ... ?
-> For example, GameBoardSystem meets the conditions said before with isDestroy = true
Most of those thoughts doesn't matter in the actual implementations of the examples of course, but the last i don't know...
Simon Schmid @sschmid Aug 16 2015 03:35
Oh I see, I have to do some more updating in the example project... I'll check and let you know
JuDelCo @judelco Aug 16 2015 03:35
The "problem" i want to say is maybe some circumstances where the code could not work (like the last case)
Ok ! @sschmid
And the last one...
If some class suscribes to OnComponentAdded / OnComponentReplaced / OnComponentRemoved event in Entity class, that entity could be reused after destroyed but will still trigger the events to old suscribed delegates (not the Pool delegates, those are unsuscribed always on entity destroy, i'm talking of custom code)
So... shouldn't entity class force to clean suscribed delegates on those event dispatchers on entity destroy ? (That must be done inside Entity class the way events work)
Simon Schmid @sschmid Aug 16 2015 03:38
good point!
you can create an issue for that, if you want
JuDelCo @judelco Aug 16 2015 03:40
Ok
JuDelCo @judelco Aug 16 2015 06:07
Seems like Entitas.Unity.VisualDebugging doesn't refresh now on entity destroy. There must be a change in some group to refresh
Simon Schmid @sschmid Aug 16 2015 06:13
Yes, the new destroy behavior changes a few things. VisualDebugging still needs to be updated.
JuDelCo @judelco Aug 16 2015 06:14
:+1:
JuDelCo @judelco Aug 16 2015 06:27
One last thing. Maybe you forgot to add 'protected' to the new updateGroupsEntityWillBeDestroyed function in Pool class ?
Like the other two delegate functions over it
Is a minor thing, I know xD
Simon Schmid @sschmid Aug 16 2015 06:36
Thanks! I see, I got some work to do
New release 0.21.0 addresses the issue that @judelco described, where destroyed entities are still in the groupObserver.collectedEntities and therefore also are passed to a reactive system. See the release notes because your existing systems might need to be updated, because the pool.DestroyEntity(entity) behaviour is changed. In a nutshell: calling pool.DestroyEntity(e) will immediately destroy the entity. It's the very last step in the lifecycle of an entity. It won't trigger group.OnEntityRemoved anymore but group.OnEntityWillBeDestroyed.
For reference, I updated Match-One and Entitas-CSharp-Example. They use all new recent features like MultiReactiveSystem, IEnsureComponents, and the new pool.DestroyEntity(e) behaviour
JuDelCo @judelco Aug 16 2015 00:09
Thanks Simon, i hope my fix proposal has served as an idea
I will now check the changes done in both repositories
Simon Schmid @sschmid Aug 16 2015 00:28
@judelco sure, thanks a lot!
Christian Schuster @chrischu Aug 16 2015 01:18
@sschmid What do you think about issue #20 and the corresponding pull request #21 ?
JuDelCo @judelco Aug 16 2015 01:19
I think is not necessary
Christian Schuster @chrischu Aug 16 2015 01:19
There is no other way around the problem though....
And I don't think there is a significant disadvantage to renaming the interface/method...
JuDelCo @judelco Aug 16 2015 01:21
You can always do:
void MonoBehaviour.Start() {}
void IStartSystem.Start() {}
Simon Schmid @sschmid Aug 16 2015 01:21
Naming wise, I think it makes sense. But I didn't really understand, how you can run into problems
JuDelCo @judelco Aug 16 2015 01:22
stackoverflow.com/questions/2371178/inheritance-from-multiple-interfaces-with-the-same-method-name
Christian Schuster @chrischu Aug 16 2015 01:23
The problem occurs when I have systems that have some public fields for configuration and it would be cool to change the configuration in the Unity Editor.
Simon Schmid @sschmid Aug 16 2015 01:23
ah, I think i get it now
You want to implement IStartSystem in a MonoBehaviourChristian Schuster @chrischu Aug 16 2015 01:23
Therefore these systems need to be MonoBehaviors
JuDelCo @judelco Aug 16 2015 01:23
But you can do it
can*
This composemode<->chat mode in gitter makes me crazy
Simon Schmid @sschmid Aug 16 2015 01:24
Configuration is data and should be represented with entities
Systems should have no state
Christian Schuster @chrischu Aug 16 2015 01:26
So I have to put my configuration either in code (not a good idea)
Or in some other format I have to think of that I can then load and turn into entities which then can be used by the systems....
The "configuration" btw is often as simple as linking another GameObject that represents some UI.
And that would be hard to represent with entities...
Simon Schmid @sschmid Aug 16 2015 01:30
to quote @mzaks from his blog post Games, Data and Entitas
"A careful reader might noticed that I wrote configuration is „fixed“ data. I put the word fixed in quotes. I did it on purpose because configurations are not always fixed. Some times designers might want to change them even when the game is already rolled out. A designer might even want the configuration to be changed for a random amount of users. This technique is called A/B Testing."
Christian Schuster @chrischu Aug 16 2015 01:31
I read all his blog posts, still I think there is a pretty big difference between configuration (which key does what etc.) and what I'm doing.
Simon Schmid @sschmid Aug 16 2015 01:31
Do I get it right: you want to link some gameObjects on MonoBehaviour, and you want to use these linked gameObjects in the system
Christian Schuster @chrischu Aug 16 2015 01:32
Yes, exactly.
For example when I create UI with the Unity UI system (which is obviously then manifested in GameObjects).
JuDelCo @judelco Aug 16 2015 01:33
Make them public and create a IStartSystem that reads all unity entities with that script and load those gameObjects from them.... ?
Simon Schmid @sschmid Aug 16 2015 01:33
What are these GOs, and what are they supposed to do? (want to see if there's an alternative)
Christian Schuster @chrischu Aug 16 2015 01:33
Ok concrete example
I have a grid-based game and a selector element that I move with my keyboard
Every tile in the grid has some information associated with it
For example: Is it a mountain or is it a meadow
To show this information I created some UI elements with Unity's UI system.
Whenever the selector element moves, I need to update the UI elements.
So in effect when the PositionComponent of the entity with the SelectorComponent is replaced.
Simon Schmid @sschmid Aug 16 2015 01:37
As you said, every tile in the grid has some information associated with it - that's very good. By selecting a tile a RenderTileInfoSystem could instantiate a popup prefab, position it and populate it with the corresponding information of the tile
Christian Schuster @chrischu Aug 16 2015 01:39
The only trouble is that I then have mixed together design-time UI information (UI positioning, size, etc.) with run-time game information (currently selected tile).
And I completely loose the advantage of being able to easily change my UI in the Unity editor (which is the exact strong suite of the new Unity UI system).
I think one could even make the argument that what I store in my systems is not even state.
JuDelCo @judelco Aug 16 2015 01:41
Flag that UI selector with a tag, or unique empty script, ... and then in a IStartSystem search in Unity with "GameObject.FindGameObjectsWithTag/FindObjectOfType" or similar and then link that gameObject with the entity/component in Entitas.
At runtime, if you want to change that selector, you will need to make changes with EntitasUnityDebugger menu
Or make it a prefab and instantiate it like "AddViewSystem" in the Entitas examples
Christian Schuster @chrischu Aug 16 2015 01:42
Prefab makes me loose positioning information/design time experience (as stated before).
Tagging leads to a whole bunch of strings in my code.
Strings that can easily fall out of sync...
Simon Schmid @sschmid Aug 16 2015 01:43
but you are still able to change the UI in Unity, or I get sth wrong. What I do: I have multiple template prefabs for all popups in my games. They all are layed out in Unity and have some lorem ipsum data.
JuDelCo @judelco Aug 16 2015 01:44
And a monobehaviour script "UIElementScript" with only a public string member with the ID ?
Simon Schmid @sschmid Aug 16 2015 01:44
Either a system updates the content, or, they take care of them self, by observing the pool
Christian Schuster @chrischu Aug 16 2015 01:44
How do you accomplish they second part?
"Taking care of themselves by observing the pool"?
I assume themselves = prefabs?
Simon Schmid @sschmid Aug 16 2015 01:45
Match-One ScoreLabelController.cs
Christian Schuster @chrischu Aug 16 2015 01:46
And you want to tell me that this is no system?
Because it looks like it does very similar things to a reactive system.
Simon Schmid @sschmid Aug 16 2015 01:47
yeah, you're right.JuDelCo @judelco Aug 16 2015 01:47
Is the same but configurable in Unity editor
the idea i think is still keep all the logic away of Unity
Christian Schuster @chrischu Aug 16 2015 01:47
So you see my argument that there is really no harm to have a system derive from MonoBehaviour right?
JuDelCo @judelco Aug 16 2015 01:47
that only "links" the logic in entitas and unity
if you want in the future make a port with another framework or renderer, if you make systems with monobehaviours it will be harder to port
Christian Schuster @chrischu Aug 16 2015 01:49
I'm not saying EVERY system needs to be a MonoBehaviour.
I'm saying it would be useful if SOME systems could be.
JuDelCo @judelco Aug 16 2015 01:49
Yes, and i tell you that can be possible
Christian Schuster @chrischu Aug 16 2015 01:49
And those systems would break when you change the framework, just like the ScoreLabelController does.
JuDelCo @judelco Aug 16 2015 01:50
You can always do:
void MonoBehaviour.Start() {}
void IStartSystem.Start() {}
stackoverflow.com/questions/2371178/inheritance-from-multiple-interfaces-with-the-same-method-name
Christian Schuster @chrischu Aug 16 2015 01:50
@judelco I really wasn't born yesterday, I know what explicit interface implementations are.
It doesn't change the fact that it complicates things (if ever so slighty).
I think in general it is not a bad idea to make it easy to distinguish between Start/Update (Unity) and Initialize/Execute (Entitas) at a glance
Simon Schmid @sschmid Aug 16 2015 01:51
As I mentioned, naming wise I think it makes sence, and I guess I might merge #20
Christian Schuster @chrischu Aug 16 2015 01:51
Cool
JuDelCo @judelco Aug 16 2015 01:52
Renaming methods could be the same problem in another framework with different method names isnt ?
Simon Schmid @sschmid Aug 16 2015 01:52
But I wanted to hear, what kind of problems you meant, and if there's an alternative, that might make more sense
Christian Schuster @chrischu Aug 16 2015 01:52
Of course @sschmid
I'm not blaming you for not jumping on the first chance to rename a pretty central method/interface in Entitas
Simon Schmid @sschmid Aug 16 2015 01:53
@judelco true
Christian Schuster @chrischu Aug 16 2015 01:54
@judelco true, but I imagine that might be the least of one's worries when switching to another framework.
JuDelCo @judelco Aug 16 2015 01:54
Yes
Christian Schuster @chrischu Aug 16 2015 01:54
And I think it falls under YAGNI
JuDelCo @judelco Aug 16 2015 01:55
Anyway i agree with the change because this entitas repo is very "unity" relevant
Simon Schmid @sschmid Aug 16 2015 01:55
@chrischu
well, proper naming can make the difference 
JuDelCo @judelco Aug 16 2015 01:56
That leads me to another question.... makes sense to rename in the other entitas languages repositories the same change to preserve the same api ?
Christian Schuster @chrischu Aug 16 2015 01:56
Yeah, proper naming is also coincidentally the hardest thing about programming...
JuDelCo @judelco Aug 16 2015 01:57
though i doubt they are equal at this moment xD
Simon Schmid @sschmid Aug 16 2015 01:57
@chrischu definitely
@judelco yes, the other entitas repos are maintained from different ppl and have slighly different apis and also different implementations, crafted for their plattform
the c# version for example is the only one with mutable components
JuDelCo @judelco Aug 16 2015 03:23
I have some questions about the changes in the new Entitas version... the first one:
Entitas-CSharp-Example:
RenderPositionSystem.cs -> Why did you implement IEnsureComponents interface ?
JuDelCo @judelco Aug 16 2015 03:28
Oh ... i think i know now why.... maybe RemoveViewSystem deletes the view in that frame for some reason (deletion of Resource component or flagged by Destroy component). Okay, so the next question...
Second one is the same but repeated in some classes
In Entitas-CSharp-Example:
RemoveViewSystem.cs -> If a View component is deleted in a system that runs between removeViewSystem and DestroySystem the system wont be notified
In Match-One:
FallSystem.cs -> If a GameBoardElement component is deleted in a system that runs between FallSystem and DestroySystem the system wont be notified
FillSystem.cs -> If a GameBoardElement component is deleted in a system that runs between FillSystem and DestroySystem the system wont be notified
ScoreSystem.cs -> If a GameBoardElement component is deleted in a system that runs between ScoreSystem and DestroySystem the system wont be notified
RemoveViewSystem.cs -> If a View component is deleted in a system that runs between removeViewSystem and DestroySystem the system wont be notified
CreateGameBoardCacheSystem.cs -> If a GameBoardElement component (or Position) is deleted in a system that runs between CreateGameBoardCacheSystem and DestroySystem ... ?
-> For example, GameBoardSystem meets the conditions said before with isDestroy = true
Most of those thoughts doesn't matter in the actual implementations of the examples of course, but the last i don't know...
Simon Schmid @sschmid Aug 16 2015 03:35
Oh I see, I have to do some more updating in the example project...
I'll check and let you knowJuDelCo @judelco Aug 16 2015 03:35
The "problem" i want to say is maybe some circumstances where the code could not work (like the last case)
Ok ! @sschmid
And the last one...
If some class suscribes to OnComponentAdded / OnComponentReplaced / OnComponentRemoved event in Entity class, that entity could be reused after destroyed but will still trigger the events to old suscribed delegates (not the Pool delegates, those are unsuscribed always on entity destroy, i'm talking of custom code)
So... shouldn't entity class force to clean suscribed delegates on those event dispatchers on entity destroy ? (That must be done inside Entity class the way events work)
Simon Schmid @sschmid Aug 16 2015 03:38
good point!
you can create an issue for that, if you want
JuDelCo @judelco Aug 16 2015 03:40
Ok
JuDelCo @judelco Aug 16 2015 06:07
Seems like Entitas.Unity.VisualDebugging doesn't refresh now on entity destroy. There must be a change in some group to refresh
Simon Schmid @sschmid Aug 16 2015 06:13
Yes, the new destroy behavior changes a few things. VisualDebugging still needs to be updated.
JuDelCo @judelco Aug 16 2015 06:14
:+1:
JuDelCo @judelco Aug 16 2015 06:27
One last thing. Maybe you forgot to add 'protected' to the new updateGroupsEntityWillBeDestroyed function in Pool class ?
Like the other two delegate functions over it
Is a minor thing, I know xD
Simon Schmid @sschmid Aug 16 2015 06:36
Thanks! I see, I got some work to do
