Der Fehler lässt sich leider nur unfassbar aufwendig ein für alle Mal beheben. Dazu muss das ganze System der Bevölkerungsberechnung umgeschrieben werden. Das steht aber nach wie vor auf der Liste, auch wenn das Verhältnis zwischen Aufwand und Nutzen nicht gut ist.
Zur Erinnerung: Die damalige Ankündigung:
https://de.forum.grepolis.com/index.php?threads/angepasste-bevölkerungskosten-für-gebäude.32885/
Es konnte vorher also in seltenen Fällen vorkommen, dass Spieler nach Gebäudeausbau plötzlich eine -1 in der BHP-Anzeige hatten - ein Problem, das Inno durch diverse BHP-Neuberechnungen infolge des vermaledeiten Updates auf den damals laufenden Welten von seltenen Einzelfällen ironischerweise praktisch zum Standard gemacht hat. Erinnert Ihr Euch noch? Ich hatte vor der Neuberechnung niemals negative Bevölkerung in einer Stadt gehabt; nach dem Update, dass das Problem beheben sollte, hatte ich jedoch auf all meinen damaligen Welten etliche Fälle. Und dazu wurde uns noch besagtes neues Problem als Draufgabe kredenzt, das bis heute besteht.
Die "unfassbar aufwendige" Umstellung der BHP-Berechnung auf den jetzigen chaotischen Zustand wurde Anfang 2016 durchgeführt, ohne jede Not. Es war Zeit und Geld dafür da, diesen Fehler zu produzieren, während es nun seit zweieinhalb Jahren Zeit und Geld für jede Menge Unnötigkeiten gab, nicht aber für die Behebung des damals ohne Not ins Spiel gebrachten Fehlers. Jeder einigermaßen denkende Mensch, in jedem Falle aber jeder Spieler, der mit Rundungsverhalten in Grepolis vertraut ist, hätte sofort Alarm geschlagen, wenn vorab (und nicht erst nach Wochen der Proteste) darüber informiert worden wäre, dass der ganzzahlig angezeigte BHP-Bedarf von Gebäudestufen nunmehr im Hintergrund mit Nachkommastellen berechnet und für die Anzeige im Spiel dann wieder auf ganze Zahlen gerundet wird (wobei der "Rundungsabfall" dann im Frontend fallweise entweder unter den Tisch fällt oder zusammengekehrt wird, was dazu führt, dass entweder die angezeigten BHP, wie hier im beschriebenen Fall, in Wirklichkeit gar nicht zur Verfügung stehen und das Gebäude nicht gebaut werden kann, obwohl es laut Anzeige baubar wäre - oder aber bestimmte Gebäude nicht wieder ganz aufgebaut werden können nach ihrer Demolierung durch Katas oder Erdbeben, weil die angezeigte BHP-Zahl plötzlich geringer ist als die vorher verbaute).
Die Berechnungsumstellung führte damals gleich in den ersten Wochen nach dem Update zu einer Zahl an Fehlermeldungen, die es notwendig gemacht hätten, die Sache sofort wieder zurückzurudern. Es möge mir bitte niemand sagen, dass es von der Vorgängerversion damals keine Sicherung gegeben hatte und
damals deswegen keine Rücknahme möglich gewesen wäre. Stattdessen wurde noch wochenlang behauptet, es liefe alles korrekt und wie beabsichtigt, obwohl es Screenshots zum neuen Problem hagelte.
Aber mit der Rücknahme von "unfassbar xxxxxxxen" Änderungen tut sich Inno leider mindestens genauso schwer wie mit der "unfassbar aufwendigen" Behebung hausgemachter Fehler. Mehr als zweieinhalb Jahre sind ins Land gegangen, und mir kommt jedesmal von neuem die Galle hoch, wenn ich über die Auswirkungen dieses Schildbürgerstreichs stolpere (wenngleich diese Auswirkungen Revo-Spielern vermutlich häufiger sauer aufstoßen dürften). Und seither ist es somit ein Nebenjob der CMs, Tickets zu dem Thema zu bearbeiten, indem sie mittels Repair-Script eine Volkszählung in der betroffenen Stadt durchführen - natürlich nur bei den wenigen Spielern, die das überhaupt noch bemerken, es überhaupt noch zum 150. Mal melden wollen, überhaupt noch wissen, wo das Problem liegt, und zudem irgendwo gehört haben, dass es überhaupt ein Repair-Script zu dem Thema gibt.
Es ist ja nicht etwa nur so, dass sich mit schöner Regelmäßigkeit runtergeknallte Mauern nicht mehr auf Stufe 25 ausbauen lassen, weil die Backend-Kalkulation einen Frontend-BHP gefressen hat (und ihn dafür manchmal an unerwarteter Stelle rülpsend wieder ausspuckt). Wer sich mal die Mühe macht und beim Ausbau einer gesiedelten Stadt bei jedem Bauauftrag mitschreibt, welcher BHP-Bedarf angezeigt wird, und wieviele BHP tatsächlich abgezogen werden, kommt aus dem Staunen nicht mehr raus - da sind Differenzen bis zu zwei BHP (nach oben und nach unten) drin, und diese Differenzen treten pro Gebäude nicht nur einmal auf. Mein damaliges Beispiel (ist nicht statisch - Abweichungen hängen auch vom sonstigen Ausbauzustand der Stadt ab):
Mauerstufe 1: 2 BHP (alt) - 2 BHP (neu) - benötigte BHP laut Anzeige im Baufenster: 2 - abgezogene BHP: 2
Mauerstufe 2: 2 BHP (alt) - 2,5 BHP (neu) - benötigte BHP laut Anzeige im Baufenster: 2 - abgezogene BHP: 3
Mauerstufe 3: 3 BHP (alt) - 3,2 BHP (neu) - benötigte BHP laut Anzeige im Baufenster: 3 - abgezogene BHP: 2
Schon bei den ersten drei Mauerstufen sah ich also bei meinem damaligen Experiment deutliche Differenzen zwischen dem im Wiki angegebenen BHP-Bedarf für die Gebäudestufe (BHP neu), der Anzeige der benötigten BHP im Baufenster/Senat, und den tatsächlich abgezogenen BHP. Ein Kollege hatte sich mal eine Komplettliste über die Abweichungen bei einem Stadtausbau angelegt, die einfach nur haarsträubend aussah. Sollte man hübsch einrahmen und dem Grepo-Team schicken.
Abgesehen davon bin ich nach wie vor der festen Überzeugung, dass der Aufwand für die Fehlerbehebung maßlos übertrieben dargestellt wird. Es gibt keinen nachvollziehbaren Grund, warum ganzzahlige BHP nicht in Frontend und Backend gleichermaßen ganzzahlig dargestellt und berechnet werden können, und das kann nicht wirklich kompliziert sein.
