Refactoring of existing cheats (see #1679)

[kubaau]

First few commits from PR #1679 :

• refactors existing cheat code ("winter" code, toggle human AI player, armageddon) into new Cheats and CheatCommandTracker classes

[Flamefire]

Great use of the circular buffer, good idea!

It does make sense to separate the cheats and the key/command tracker although I don't really like putting the cheats into the world class or having the command tracker be a part of the cheats creating a cyclic dependency and having to do cheats.trackX -> tracker.trackX

So maybe add an instance of each class to the game interface?

[Flamefire]

I guess it makes more sense to move this check to the caller

[kubaau]

I'd rather keep this here. This logic gets (slightly) more complex when other functions get involved, like in the bigger PR @ https://github.com/Return-To-The-Roots/s25client/pull/1679/files#diff-d98c107f14a70f47245ba076ec4e845508c123b64120cd47c4b8e6f9f14b4384R21 . It also clearly shows that this function does nothing for char keytypes.

[Flamefire]

I see. So the idea for those functions is to return true if they handled the event and if not the next function gets a shot.

So maybe checkSpecialKeyEvent is better. I was confused about calling "specialKeyEvent" and "charEvent" with the same event which looked odd

[kubaau]

I will rename track to check or something similar. "Track" is a byproduct of refactoring that does not explain much.

[Flamefire]

IMO cheats are not part of the world but rather belong to the interface. Or is there a reason for moving them down? I'd make an instance of Cheats in this class instead which also avoids going through game->world_.GetCheats and the inconsistent access here, i.e. why isn't this using GetCheats?

[kubaau]

I agree completely. In principle it does not make much sense for Cheats to be in World. The problem is that if you look at the cheats in the other PR most of them can easily be implemented by going through World. Also a lot of cheat implementations only need to know if IsCheatModeOn() and do not need the internals that GetCheats() gives. This avoids doing GetCheats().IsCheatModeOn().

Moving Cheats to GameInterface makes intuitive sense, but some of the classes that use Cheats know nothing about GameInterface. I think they would at least need GetGameInterface to be part of GameWorldBase and then any calls to cheats would need to go through world().getgi().dosomething(). To avoid this would require passing GameInterface all over the place.

Also a case can be made for cheats to be outside of the GameInterface: for example in S2 the cheat activation state is preserved through games. To achieve this (if desired) Cheats would have to be in some more global state.

[Flamefire]

There is nothing wrong with cheats modifying the world. They also don't need the gameinterface as that would be backwards: The GameInterface has a cheats and world. The cheats use the world (modify it)

So my idea was to pass the world into the cheats class (controller->model pattern) where needed.

But I see you need the cheats in the GameWorldViewer. Maybe they are better of there. That could break the cycle: GWV has cheats and world-reference, cheats has world-reference. That could even be just a reference in GWV where dskGameInterface has the actual class (and possibly the handlers/tracker)

Actually I caused some confusion here: The interface is the desktop, not the GameInterface class itself. I guess that would work then.

[kubaau]

Sorry for the delay. I'll take a look at this (and other PR's) shortly.