Seems to me that in most cases velocity should still be used as normal, it can just become zero, and prevent further input from adding to it (and the stuff for handling character movement, could reasonably also access some spell status etc. components)? Then all the physics maths should just work out by itself.

And potentially in some cases depending on design you still want gravity, momentum to apply so a frozen/dead object might still move a bit.

I do it the same way - my Movement-component has a “paused” bool which allows me to halt en entity right where it is, and resume later. I don't think there is anything strange about it - no matter what the context, entity/game-object systems will probably always end up needing different mechanisms for handling subsystems like movement. Detaching the component for example is not valid for that use-case, since you need to retain the values (speed, etc…). Simply disabling it (if you have a general “disabled” state for your components) might be another solution, but might also not be applicable for that use-case (depening on how you treat “disabled" components; in my system a disabled component is virtually non-existant until re-enabled or explicitely requested). So yeah, I think having some sort of boolean to toggle this is perfectly normal.

Tanzan said:
i think that the power of ecs is that we just have a placeholder (entityid) and by adding components to them (dynamically) we add or remove members and so functionality (through the systems) to them. again guys thx for thinking with me,

In truth, I'm not using the ability to dynamically attach/remove components all the much anymore. For me the power of ECS lies in being able to develop features in isolation without running into the problems that rigid inheritance could lead to. For me, having a “move” component on an entity mean “this entity has the ability to move”. Whether the entity moves at that point in time is up to the component. If an entity becomes unmoveable for a large period of time or permanently, I detach the component or deactivate it, but if say my cutscene pauses the movement of my player-avatar, I simply “pause” the movement and animation. There are certainly up or downsides to eigther approaches, but you shouldn't be afraid to keep a simple problem like “I want to pause movement” simple and not overcomplicate it out of fear or just to comply with a purist-version of a pattern ?

Tanzan said:
i agree that we need some control of course, but worst case will be that every entity ends up with almost every component which will be toggled on pause.

Oh pause I approached differently, since it pauses all game entities I just stopped most of the update stuff executing (basically skip the entire fixed step update, except input which feeds into the ui)

Tanzan said:
The way how you describe your solution looks a lot like component based developing (which again is nothing wrong with) and not ecs

Well, I'm pretty much using a hybrid-approach at this point, but I'm still using an ECS in the sense that components are mostly data (and very easy to copy/pooled), and logic is handled by systems operating on a bunch of components. I dropped the messaging-part though and now mostly call methods on systems to implement specific logic, and do some other things that go against the pure “ECS” idea. But I'm still much closer to ECS then unitys “component based” approach.