Configuration refactoring

[stm2]

Bei den ganzen Gerede über Konstanten neulich, habe ich mir mal überlegt, wie man das besser machen könnte und das kam dabei heraus: https://github.com/eressea/server/compare/develop...stm2:6628b2d7805c13f4d8be8b597ed3162a1b93e41b

Statt

int multi = get_param_int(global.parameters, "rules.trollbelt.multiplier", STRENGTHMULTIPLIER);

schreibt man jetzt

    int multi = eressea_parameter_int(E_RULES_TROLLBELT_MULTIPLIER);

Die Parameter mit Defaults landen in settings.h (falls ich die Archtitektur da richtig verstehe). Außerdem sollen natürlich alle #defines, angefangen bei denen in config.h, auch zu Parametern werden und in settings.h landen.

Zwei Vorteile:

• Die Parameter sind alle an einem Ort anstatt irgendwo im Code herumzuschwirren, was die Dokumentation für Spielleiter leichter macht.
• Der Zugriff ist effizienter und die Duplizierung der Caching-Logik mit statics ist aufgelöst.

Fragen: Was ist der Unterschied zwischen Variablen in config.h und in settings.h und ist diese Unterscheidung sinnvoll?

Ist dagegen softwaretechnisch was einzuwenden?

Es schafft zwar eine gewisse Kopplung, aber das Problem ist im Grunde jetzt schon vorhanden und man muss das, glaube ich, getrennt lösen.