Refactor the state machine in input.js

[Rolf Sievers]

In the binaries/data/mods/public/gui/session/input.js file, there is a comment which reads:

// TODO: it'd probably be nice to have a better state-machine system, with guaranteed
// entry/exit functions, since this is a bit broken now

What is there

A rather basic implementation of one concrete state machine. (no abstraction) On closer inspection, it turns out those are actually a bunch of smaller state machines glued together along their entry and exit paths to a „default state.“ There is a second state machine as well, for postGui event processing.

Proposed change

A lightweight abstract system which does not know a lot about it's content. It has a state (Bandboxing, Building, Tribute), such a state describes the mechanics of a „smaller state machine“ from the current code. The outer wrapper is not a state machine (no transitions) as it does not posses any interesting feature. The inner state is not forced to be a state machine, it's internal structure is not inspected by the outer wrapper. As most of the „smaller state machines“ have just a single state, that prevents unnecessary abstraction.

This untangles all the different features contained in that one function.

Furthermore the central code of preEngine event handling and postEngine event handling can be unified.

Interface of a „state“

Without specifying any particular structure yet, a state must allow the following:

• Initializing it (The state receives a quitCallback to terminate itself)
• Processing an event (returns whether it was eaten or not)
• Terminating it

Obvious solutions would be:

• pass three parameters
• pass an object

[Itms]

Backlogging this due to stopped activity.

[Imarok]

Move tickets to In-game UI as UI & Simulation got some sub components.