[Solved] Get system by interface ? (sim-eth-es)

General Discussion
1

Hi Paul

I want to add an other physic system in sim-eth-es example named BulletPhysicState. also i want to keep SimplePhysics which you wrote.
And for decoupling these physic systems from other systems i created an interface PhysicSystem for now it is like this

public interface PhysicSystem {
    public void addPhysicsListener( PhysicsListener l );

    public void removePhysicsListener( PhysicsListener l );
}

then in ZoneNetworkSystem i changed it like this

@Override
    protected void initialize() {
        getSystem(PhysicSystem.class).addPhysicsListener(physicsObserver);
    }

    @Override
    protected void terminate() {
        getSystem(PhysicSystem.class).removePhysicsListener(physicsObserver);
    }

So that ZoneNetworkSystem can work with both SimplePhysics or BulletPhysicState.
but it seems getSystem(PhysicSystem.class) return null when i call it with interface.

I wanted to ask your idea about this and what is the best solution for solving this ?
(I can use EventBus instead to decouple physic system but before that i want to know your idea)

2

If you want to be able to look up the physics system by the interface then you have to register it by the interface with the GameSystemManager. I can’t see that code so I can’t comment further.

1 Like
3

Ah…Yes. Worked.
Just one question, can i register systems which are not extending AbstractGameSystem ? For example my view level systems like BulletPhysicsState which are extending jme’s BaseAppState. Will GameSystemManager control life cycle of them ?

4

You can register anything. Services themselves must implement the GameSystem interface but the GameSystemManager is a general bag for any type of thing you want to register there… that’s why register() takes an Object.

However, you should consider that AppStates are inherently ‘view’ and one should hesitate to register them directly. In this case, JME is wrapping some back-end stuff in a convenient ‘view’ level class… so I’m not sure there is much way around it aside from implementing your own BulletPhysicsSystem that does the same job as the app state. Probably more work than you want just to get something working.

But in general, the idea is that your game systems might be running on a server… in which case the BulletAppState has no place there.

1 Like
5

Ah, i see. Thanks for explanation.

6

Just found that i do not need to use AppState at all.

7

If you happen to create a nice bullet-based GameSystem implementation then I’m sure there are a couple of other monkeys that might find that interesting.

You can’t be the first person to want to use bullet on a server… and modesty aside, I think the GameSystemManager is a decent way to manage that sort of thing on the back end.

1 Like
8

Yes, going to do that. Will be glad to share it with community :slight_smile:

9

Will look forward to seeing it :slight_smile: