Ok, seems like "module" is the name of choice. Fine.
I'll rename this in a few days, but for the moment I'm heading towards the next exam.
And there's something else I would like to suggest: Apart from the ScopedSingleton it might be useful to let every module have a static function that gets executed just before loading the GameStates so the module can do some sort of initialisation. I would not do this at module loading time since then there's not even configValues. We could introduce a second function that gets called upon graphics loading but I don not claim this is necessary, just an idea.
Hm, basically I see the point about loading- and initialization-functions in modules, but in all modules I did so far there was no need for this. Do you see an example where it could be handy? The main "problem" probably is that something like a module-main-function also request a module-main-file. This makes modules much more powerful since this allows them to execute more than just some static "hello here I am" initialization code (aka CreateFactory). While this may be nice from the modules point of view, it also spreads the initialization code over several files which makes it less predictable. So personally I don't dislike the suggestion, but we should have a real reason for doing so.
---
Now after this threads topic shifted from directory structure to modules in general, I also want to discuss another point:
We have some code-parts in orxonox which are basically built like a module (mostly independent and self-contained), but in one point linked with a main class. This holds for example for the weaponsystem or the pickupsystem which both are comparable large parts of the code which will also expand much more in the future (we'll have tons of weapons and pickups). Both subsystems are completely independent of other code, but they are linked with the Pawn class (each pawn has a WeaponSystem and a PickupCollection). And both WeaponSystem and PickupCollection can't be separated from the rest of the module, because they each need ~5 other classes.
Now there are two options:
1) Put all basic classes of those subsystems into the main library and create a module only out of the spezialized weapon and pickup classes.
While this may be a good idea general, it also shows that for each new subsystem in the game the main library keeps growing and therefore it's impossible to add a new feature (which is somehow linked with the Pawn) in a module only (or a "real" optional plugin).
2) Don't link those subsystems directly with Pawn. Instead use the fact that we're facing a "has a" relation and outsource the link to somewhere else, for example (A) a static map in the module (like static map<Pawn*, WeaponSystem*>) which stores an instance of the subsystem for each Pawn.
We could also use (B) anonymous classmembers in Pawn, for example Pawn::map<Identifier*, BaseObject*> which would be used like this: mypawn.map[Class(WeaponSystem)] = new WeaponSystem() and afterwards myweaponsystem = orxonox_cast<WeaponSystem*>(mypawn.map[Class(WeaponSystem)]).
Of course both solutions need a map which slows the code down, but by definition those subsystem aren't central (you can only shoot once per tick or pickup one item at a time) an because the modules are independent, no other class can use them in other situations.
So the main problem of both suggestions (A) and (B) boil down to the need for a construction- and destruction-listener for Pawn (and for any other class in general).
Personally I like option 2, but I'm not yet decided whether I prefer (A) or (B). However my intention goes towards (B) since it doesn't need a static map (and "anonymous classmembers" sounds so damn cool I just HAVE to implement it
)