Improve Console Commands

[rgrieder]

There are currently some issues and missing feature with console commands. I would like to compile a list here that can be discussed and modified:

1. Activity: Console commands should have the possibility to be active/inactive
2. Lifetime: Console commands should be more dynamic so you can create and destroy one at will (and avoid memory leaks).
3. Accessibility: Console commands should have access permissions.
4. Dispatching: What about console commands that can be applied not to one single static function but to all objects of a member function? It would be almost like the config values but with 5 possible different arguments and no ini-file entry.
5. Preconditions: Is it really necessary that all classes using CC must derive from OrxonoxClass? It is of course mandatory for 4.

There is already some basic construct to realise accessibility but it is not yet implemented. I think this might be quite important because sometimes these console commands ease programming by magnitudes if you want to avoid some singleton-hacking or so.

Btw: I assigned the severity of the ticket "critical" because we currently have memory leaks due to console commands.

[rgrieder]

I've got a proposition on how to implement points 1, 2 and 4: Every Console Command must be declared statically (resolves language issues), but can be declared in a way that makes it dynamic. The CC could then be activated with something like activateConsoleCommand() or activateConsoleCommand(this). The latter could be called more than once for multiple instances of a class. deactiveConsoleCommand([this]) would deactivate it (for this instance).

Point 2 (Lifetime) would inevitable drop out because all commands get statically handled anyway. And there I also propose to store all commands in the CommandExecutor instead of the identifier (which only keeps a reference to it). This is mainly for consistency because CCs without corresponding class have to be stored there anyway.

[landauf]

I suggest linking the console commands with smart pointers

[rgrieder]

Agreed. It starts with createFunctor and createExecutor which both must return a smart pointer for the sake of good programming It's probably a good idea apply these smart pointers almost everywhere fitting. Except of course for self contained code that already works properly.

[rgrieder]

Has this ticket been completed?