Core Initialization Routine

[Fohlen]

As described in #354 splitting core and flex will need changes on the core side as well. The startup routine for the core should therefore look like

Tasks

• [x] Parse the comand line looking for the gRPC instance_id argument
• [x] Receive Inexor Tree events via gRPC from Inexor Flex
• [x] Block until Inexor Flex has sent the tree event initialization finished
• [x] Load instance configuration from a TOML file (#424)

Additionally we will benefit from a new clean initialization and shutdown routine as far as that we can more clearly determine when libCEF has to be started and terminated, as well as making it easier to work on #321

The TODO for the next major release is:

• Overhaul the current initialization routine
• Remove the command line and cubescript parsing as much as possible
• Do the same for the server, which is related to #339

[aschaeffer]

Hmm, this is a duplicate of #354 ? What you described is the main intention of #354.

[Fohlen]

It is the copy list for the corresponding C++ implementation. Just to keep that in mind.

[aschaeffer]

Ok, the C++ implementation details / progress goes here.

Yes we can and have to hold back SDL2 initialization until the Inexor Tree is fully initialized.

The main difficulty is that the current implementation of the C++ sub modules cannot be initialized with arguments and we have to pass the instance id/port to the RPC sub module.

Another difficult issue is, that Inexor Flex will populate parts of the tree and Inexor Core will populate other parts of the tree. We have to care about priorities during initialization.

[aschaeffer]

Moved the remaining tasks to #427