Behoben Berechnung Bevölkerung

  • Themenstarter DeletedUser16052
  • Startdatum

DeletedUser50003

Gast
Das Problem hat mehrere Ursachen.
Das Backend (was die Developer sehen) rechnet mit Kommazahlen.
Die Kommazahlen aus dem Backend werden auf- oder abgerundet und dann dem Spieler dargestellt.

Das Problem hat genau eine Ursache.
Das Problem ist, dass die Developer mit Kommazahlen rechnen, wo es nichts mit Kommazahlen zu rechnen gäbe. Jedes Gebäude kostet immer eine ganze Zahl von Bevölkerung (oder Null) jede Einheit immer eine ganze Zahl von Bevölkerung. Es besteht mathematisch überhaupt kein Anlass auf Einführung irgendwelcher Näherungswerte mit Nachkommastellen. Dieser Unsinn hätte von einer funktionierenden Qualitätssicherung sofort im Keim erstickt werden müssen, dh. ein Konzept mit überflüssigen Nachkommastellen zur Überarbeitung zurückgestellt werden müssen. Wenn man das nicht tut : Die (unnötigen) Geister, die ich rief, werd ich nun nicht los.
 
die Kommastellen könnten wegen der Therme nötig sein
am besten man würde da von 10% auf einen absoluten Wert umstellen
Meinetwegen 300 Bhp mehr.
 

DeletedUser50003

Gast
Das sind aber zwei Paar Schuhe. Die Erteilung von Bauaufträgen und die Rekrutierung von Einheiten hat nichts damit zu tun, welche Wirkung ein Gebäude (Therme) hat, nachdem es fertiggestellt wurde. Dass der gegenwärtige Wert (10% der Bevölkerung ab Bauernhofstufe 35) gerundet werden muss , steht aber außer Zweifel.
 
Ich kenne das Problem schon bevor diese Änderung kam und es gab auch fix einen Bugtracker dazu, aber in welcher Zeitspanne der erstellt worden war oder wie aktiv der gehalten wurde, oder ob der bei Archivierungsaufträgen verschwand kA. Das ist aber ein bereits sehr altes Problem. Dürfte jedem Spieler mit vielen Städten und längerer Laufzeit mal über den Weg gelaufen sein.

Von welchem Problem sprichst Du? In dieser Bugmeldung geht es um die Probleme, die durch die neue Berechnung (mit Dezimalstellen) beim Gebäudebau entstanden sind. Diese neue Berechnung ist nachweislich erst mit Update 2.103 im Januar 2016 eingeführt worden.

Wenn Du also von einem "sehr alten Problem" mit den BHP sprichst, muss es sich um ein anderes handeln. Kannst Du Dich vielleicht daran erinnern, wie und wann sich jenes alte Problem manifestierte und in welchem Zusammenhang es auftrat? Ich verstehe momentan nämlich nicht ganz, in welchem Zusammenhang Du hier von "Laufzeit" und "vielen Städten" sprichst. Es scheint ein älteres Problem mit den BHP gegeben zu haben, von dem die meisten aber nur noch zu wissen scheinen, dass es extrem selten aufgetreten ist. Das ist ein bisschen arg vage - vielleicht ließe sich mit ein wenig mehr Info ja daraus erschließen, warum unsere Innos zu den Dezimalstellen Zuflucht genommen haben.

Ich finde es ausgesprochen frustrierend, dass mit der Umstellung auf die neue Forensoftware der alte Bugtracker und sein Archiv komplett verschwunden sind. Mir fehlen die alten Fehlerbeschreibungen und vor allem auch die früher noch etwas ausführlicher ausfallenden Erläuterungen und Diskussionen dazu ungemein, nicht nur bei den "Wiedergängern" unter den Bugs.

Irgendwie erinnert mich das Dezimalstellen-Problem bei den BHP an die UM-Änderungen bei den WWs: Man erkennt ein extrem seltenes Problem, ist darauf fixiert, genau dieses Problem zu lösen - und übersieht dabei, dass jene Lösung viel mehr und häufiger auftretende Probleme im Schlepptau hat als ursprünglich vorhanden waren. Und dann behebt man die neuen Probleme nicht, weil es zu aufwendig wäre...^^

Das mit der Umstellung auf einmal - Bevölkerung rausschaut, wenn auf Dezimalstellen umgestellt wird und sehr viele Spieler mal nicht voll ausgebaute Städte haben, dürfte doch logisch sein?

Kannst Du bitte erklären - gerne an einem Beispiel - weshalb es für Dich "logisch" ist, dass bei einer Umstellung auf eine BHP-Berechnung der Gebäudestufen mit Nachkommastellen negative Bevölkerung entsteht?
 
Zuletzt bearbeitet:

DeletedUser55768

Gast
Die alte Berechnung vor der Umstellung hatte auch ihre Schwächen. Durch die Änderung dieser Berechnung haben wir den Unterschied durch die Kommawerte sogar noch reduziert (von mehrstelligen Werten auf - theoretisch - jeweils 1 Bevölkerung pro Fehlberechnung). Es besteht nach wie vor die Möglichkeit, bei extremen Unterschieden ein Repair Script laufen zu lassen. Das wird dann von uns angeschmissen, sobald wir Meldung bekommen (z.B. in Tickets). Ist natürlich nur ein workaround und kein fix.

Ich werde gern das Thema noch mal ansprechen, aber vorerst liegt es erstmal weiter unten in der To Do list rum.
 

DeletedUser764

Gast
Von welchem Problem sprichst Du? In dieser Bugmeldung geht es um die Probleme, die durch die neue Berechnung (mit Dezimalstellen) beim Gebäudebau entstanden sind.
Das Problem ist allgemein (früher und heute) ein und das selbe (TE - Text beachten, was gemeldet wurde, da geht es nur um Bevölkerung fehlt!). Wodurch der Fehler ausgelöst wird, "ev" nicht. Wenn du sagst, der Fehler ist bevor dieses Update kam, nicht aufgetreten, dementiere ich das und zwar genau das, darum auch das Zitat und Umschreibung worum es geht.


Wenn Du also von einem "sehr alten Problem" mit den BHP sprichst, muss es sich um ein anderes handeln.
Nö, es "kann" nur. Wer weiß ob nicht mal die Dezimalstellen schuld daran haben, das es nicht passt, sondern der Fehler bereits im alten Programm steckten, du etwa? Wenn ja erkläre mir das bitte

Kannst Du Dich vielleicht daran erinnern, wie und wann sich jenes alte Problem manifestierte und in welchem Zusammenhang es auftrat?
Ich kann nicht sagen wann das Problem anfing, für das müsste ich bei Innoarbeiten und selbst die könnten ev nicht mehr gesehen, wann es überhaupt anfing, außer sie hätten die Daten nie löschen lassen. (Was nach 30 Tagen der Fall ist [normal, das es paar Ausnahmen gibt ist klar, wird hier aber vermutlich nicht so sein])
Ich kann nur benennen wann ich es mitbekommen habe und das war lange vor deiner Updatezeit, die du als Grund allen Übels benennst, was ich nicht bestätigen werde, eben weil es früher bereits auch der Fall war. Über die Häufigkeit dieses "allgemeinen Fehlers", auf Welten die mit deinen Update konfrontiert worden sind, kann man nicht so locker benennen, das es uneffizienter in Zukunft arbeitet. (Um als Überbegrifflichkeit zu benennen: Den das würde voraussetzen, das man eine Welt neu startet, nachdem das Update raus kam und die Häufigkeit zu früher (also bevor das Update kam) und nachher zu prüfen kann, ohne das Verfälschungswerte von der Umstellung auftreten)

Kannst Du bitte erklären - gerne an einem Beispiel - weshalb es für Dich "logisch" ist, dass bei einer Umstellung auf eine BHP-Berechnung der Gebäudestufen mit Nachkommastellen negative Bevölkerung entsteht?
Die negativ Bevölkerung ist deswegen für mich logisch, weil man Dezimalstellen (willkürlich) in ein System einführt, das vorher nicht damit gearbeitet hat. Die Dezimalstellen sind schließlich so angepasst, das es stets auf voll ausgebaute Städte passt.
Das Beispiel: (die Zahlen stimmen alle nicht, aber ein Beispiel zur Verdeutlichung)
Bauerndorf Stufe 14 braucht statt vorher 15 notwendige bhp jetzt 15,3 oder 15,5
Die Mine Stufe 38 braucht statt vorher 130 notwendige bhp jetzt 130,3 oder 130,5

Wie die Berechung im Hintergrund von statten geht weiß ich jetzt nicht oder ob darin bei irgendeinem Gebäude bereits ein Fehler sein könnte, weiß ich nicht, schließt aber nichts aus, weil beide Berechnungsarten eine Neuberechung in der freien Bevölkerungsansicht macht und beide Varianten negative Bevölkerung "bringen", außer man hatte Glück mit der Umstellung auf alle neuen Dezimalstellenwerte, was sehr unwahrscheinlich ist, da nur wenig Spieler alle Städte voll ausbauen (bei einer voll ausgebauten Statt stimmt die Berechnung nach der Umstellung immer, ansonsten war schon vorher eine fehlerhafte Berechung gewesen, die damit korrigiert wird.)

Also führen wir das Beispiel "weiter"
wenn alle Dezimalstellen im Hintergrund zusammengerechnet werden ehe es für den User sichtbar ist. Kommen wir auf 15,3 + 130,3 = 145,6 bhp die notwendig sind, wo vorher 145 nur notwendig waren, ergibt bei der Aufrundung = 146 notwendige Bhp und somit -1 Bhp.
Wenn alle Dezimalstellen einzeln errechnet werden wären wir bereits bei 15,5 = 16bhp und 130,5 = 131bhp, wo vorher nur 145 notwendig wären, kommen wir nach der Aufrundung auf 147 und somit -2 Bhp.
Ist das verständlich genug? Und wie das berechnet wird kA und juckt mich "für die Antwortsgebung, welche du zitiert hast" auch nicht, weil automatisch vermehrt -bhp auftauchen werden und das in beiden Fällen und das beide Male logisch.
 
Nein, Terra, der Threadersteller spricht nicht neutral von fehlender Bevölkerung, er spricht davon, dass ihm die Bevölkerung nach einem Beben abhanden gekommen ist. Er spricht somit von der Mauer, und es kann eigentlich keinerlei Zweifel bestehen, dass exakt der uns seit Januar 2016 mit schönster Regelmäßigkeit heimsuchende Fehler beim Wiederaufbau der Mauer nach einem Beben gemeint ist, bei dem am Ende noch 3 freie BHP angezeigt werden, aber für Stufe 25 4 freie BHP vorhanden sein müssten.

Ich stelle hier am Wochenende mal eine Tabelle ein, aus der hervorgeht, wie viele BHP früher für die einzelnen Mauerstufen berechnet wurden, wie viele BHP jetzt für die Mauerstufen berechnet werden, was dem User ingame im Baufenster an BHP-Bedarf angezeigt wird, und was dem User tatsächlich pro Stufe an BHP abgezogen wird. Das ist nämlich hochinteressant, da es schon so anfängt:

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

Eine voll ausgebaute Mauer kostete früher 84 BHP, jetzt nur noch 83,7 BHP, wenn das Wiki nicht lügt. Es ist somit ausgesprochen seltsam, dass am Ende nun immer 1 BHP fehlt, wenn man das Ding nach Beschädigungen wieder voll ausbauen will.

Wie gesagt, ich gieße das am WE mal in Tabellenform von Stufe 1 bis Stufe 25, aber schon bei Stufe 2 und 3 wird eigentlich klar, dass durch die Nachkommastellen (von denen für die Berechnung wohl mehr als eine verwendet wird) neue Probleme geschaffen wurden, und worin diese bestehen. Das sind keine Phantasiezahlen, sondern Zahlen, die einerseits aus der Gegenüberstellung der alten und der neuen Zahlen in der entsprechenden Wiki-Tabelle stammen, andererseits soeben direkt ingame von mir abgelesen wurden, als ich gerade eben auf Iuktas (IT) besagte drei Mauerstufen baute.

---

Zum alten Problem, das durch die Änderung von Januar 2016 behoben werden sollte, kannst also auch Du nichts Konkretes beitragen. Ich bezweifele ja durchaus nicht, dass es jenes frühere BHP-Problem gab, aber da ich von November 2011 bis Januar 2016 auf keiner meiner Welten (Psi, Rethymnon, Sestos, Dyme, Warrior World, Rise of Heroes, Sandbox, Sandbox 2, Sandbox 3, BPV Test) jemals Probleme mit negativer Bevölkerung oder Diskrepanzen zwischen den angezeigten und tatsächlich benötigten oder verbauten BHP hatte, hoffte ich, dass sich einer derer, die sich an ältere BHP-Probleme erinnern, etwas mehr dazu sagen kann. @Faey, habt Ihr dazu Erkenntnisse, welchen Fehler die geänderte Berechnung damals beheben sollte?
 
Zuletzt bearbeitet:

DeletedUser764

Gast
Es gibt keinen Grund mich zu verneinen, auch ist es nicht seltsam das vermehrt nach der Umstellung -Bhp kamen, weil wie bereits belegt logisch.
-
Was das Threadthema (TE) angeht:
Es dreht sich um den Bug der fehlerhaften Berechnung um mehr als nur die Mauer alleine (zwar ist die Mauer natürlich auch ausschlaggebend, weil eben keine volle Zahlen hat [was voll fail ist mMn]), auch wenn man diese Fehlermeldung wegen der Mauer erstellte!
-
Und weil es um mehr als nur die Mauer geht, ist die Zahl nach dem beben auch womöglich falsch und warum das so ist habe ich sogar in 2 möglichen Beispielen + Erklärung angegeben und das nur eine Berechnung davon stimmt sagte ich auch und das kann auch dieses hier sein:
(z.b Zahlen) Kommen wir auf 15,3 + 130,3 = 145,6 bhp
Das sind 2 Gebäude aber! Nicht die Mauer alleine! Das habe ich bereits mal geschrieben in der Erklärung.....
-
Die Mauer wird also nicht einzeln berechnet, was du aber sagst, das muss es aber nicht und wird es höchstwahrscheinlich nicht sein, sonst wäre das Problem doch viel einfacher zu lösen...

Du kannst also nicht von einem reinen mauerbezogenen Problem reden, wenn du die Dezimalstellen der Mauer bebehalten willst und nicht weißt ob der TE nur voll ausgebaute Städte hat, den nur dann gilt das was du sagst und meines zählt bei allen Punkten wo keine voll ausgebaute Stadt vorhanden ist. Weißt du etwa ob der TE ev nicht auch andere Accs hat?

Ich ziehe meine Aussage, die du verneinen willst kein bisschen zurück. Meine getätigte Aussage (die Erklärung zu allem nr46) dazu ist konkret genug. Deine ersten 5 Erklärungsabsätze waren für mich unnötig und haben nichts von mir widerlegt, sondern nur bestätigt.
Die Mauer-Tabelle (mit dessen bhp-zahlen) widerlegt ebenso nichts.
Die Beispielszahlen von mir wurden genannt, weil es für meine Erklärung für dich keine wirklichen Zahlen braucht, sondern nur das Verständnis das die Dezimalstellenzusammenstellung am Ende durch unterschiedliche Gebäudestufen verursacht wird und nicht zwangsweise mit der Mauer alleine.
-
Außerdem hast du eine Erklärung meinerseits zu mehreren Punkten gewollt, die habe ich beantwortet. Dazu frage ich mich wie ein Spieler wissen soll, wann der Fehler bei einem vor allen anderen Spielern war? Glaubst du wirklich jedem fällt das auf oder meldet das überhaupt? ^^ Ich weiß bei jeden Fehler den ich melde, nicht ob ich der erste mit diesem Fehler bin.^^ Und manchmal melde ich nicht mal einen Fehler (omg :D), entweder weil es kein Fehler sein muss, weil dazu Inno alles klar definieren müsste, was sie nicht machen. Oder weil es so unnötig ist, das zu melden. Und früher gab es eine Zeit da wurden Fehler für längere praktisch nicht behoben, also auch praktisch kaum gemeldet, als die User das mitbekommen haben und dieser Bhp-Fehler bei mir viel glaub ich auch genau in diese Zeit, wo der Fehler bei mir auftrat. Da kann so viel versemmelt gewesen sein, viel Spaß mit weiteren Daten von anderen Usern dazu, wie es früher war, ich sag es ist hoffnungslos, überhaupt wenn du als nicht Innoangestellter daran arbeiten willst (lol²)
 
Zuletzt bearbeitet von einem Moderator:
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

Ich wollte eigentlich am Wochenende gemütlich ein paar Mauern hochziehen/abreißen und die Ergebnisse in Tabellenform zeigen. Das erstere habe ich getan, das letztere wäre vergebliche Liebesmüh. Es ergeben sich, je nach sonstigem Ausbaustand der Stadt, nämlich unterschiedliche "Sprünge" von der oben gezeigten Art auf unterschiedlichen Gebäudeleveln. Trotz des lästigen Fehlers hatte ich beim Gebäudebau (die Mauer ist ja nur das Beispiel, das am heftigsten ins Auge sticht, weil an Mauern weit häufiger "gerüttelt" wird als an anderen Gebäuden) noch nie so genau hingesehen wie am vergangenen Wochenende, und das, was ich da sehen musste, war haarsträubend.

Mindestens sechsmal pro Mauer stimmt der im Baufenster angegebene BHP-Bedarf für die anzustoßende nächste Stufe nicht mit dem überein, was tatsächlich abgezogen wird. Das ist ein knallharter Fehler, liebe Innos, der sich beim Abriss wiederholt - was unter anderem zu dem eingangs beschriebenen Problem führt, da man teilweise beim Abriss einer Stufe weniger BHP gutgeschrieben bekommt, als man zuvor für ihren Aufbau tatsächlich abgezogen bekam.

Mir ist vollkommen unbegreiflich, warum man angesichts ausschließlich ganzzahlig angezeigten BHP-Bedarfs bei allen Leveln aller Gebäuden und einem ausschließlich ganzzahlig angezeigten BHP-Vorrat dann unbedingt im Hintergrund mit anscheinend mehreren Nachkommastellen rechnen muss. Warum zieht das System beim Gebäudebau nicht einfach 4 BHP ab, wenn ein Level 4 BHP kostet? Bei den BHP, die von Truppen belegt sind, sehe ich bei der Berechnung von Kampfberichten etc. ja durchaus die Notwendigkeit von genauerer Berechnung und Rundungen, aber warum man sich bei den Gebäuden solche Probleme geschaffen hat, kann ich mir beim besten Willen nicht erklären.
 
Es ist bei den Rechnungen im Hintergrund einfacher für das System, wenn es überall mit den selben Zahlen rechnet und nicht hier so und dort anders. Euren ärger können wir durchaus verstehen, doch aktuell wird sich an dieser Berechnung nichts ändern. Außerdem kann man bei diesen Problem auch gerne den Support anschreiben, so dass wir, wie @Faey bereits sagte ein Repair Script auf der Welt laufen lassen, wobei dies auch nur eine kurzfristige Hilfe ist und keine dauerhafte Lösung, so das der Fehler nicht mehr auftritt.

Da dies nunmal nun nicht geändert wird, verschiebe ich diesen Thread ins Archiv.
 
Ich bin nicht einverstanden mit dieser Verschiebung. Es handelt sich um einen bestaetigten und ungefixten Bug. Macht eine eigene Kategorie auf "wird nicht behoben", wenn Ihr das für geboten haltet, aber im Archiv haben ungefixte Fehler nichts verloren.
 
Es ist bei den Rechnungen im Hintergrund einfacher für das System, wenn es überall mit den selben Zahlen rechnet und nicht hier so und dort anders.
Das ist so nicht richtig. Da ja bei Grepolis ständig andere Variablen verwendet werden, wird das auch hier kaum anders sein, von daher rechnet er eh ständig mit anderen Zahlen/ Formaten/ Formeln.
Die Daten werden danach in eine Datenbank abgelegt, und von dort wieder aufgerufen, wenn man die Zahl dort benötigt.
Zu mindestens sollte das so sein, wird es vermutlich auch!

Außerdem sind tatsächlich auch die Zahlen pro Bauwerk, pro Einheit, pro Schiff ständig andere; ja bei Einheiten sind es ausschließlich Ganzzahlen.

Wie auch immer, das Ganze hat eher mit einer Konzeptschwäche der Gamedesigner zu tun, als mit der Programmierung, und dort müsste dann auch nachgebessert werden. Programmieren kann man praktisch alles, es ist nur eine Frage des Aufwandes!

In diesem Forum gibt es jedoch schon kilometerlange Diskussionen darüber, wie Grepolis seinerzeit aufgesetzt und entwickelt wurde. Stichwort: Spaghetticode ;)

Da allerdings seitens des Providers hier kein Interesse mehr besteht, wird sich wohl auch nichts dran ändern.

Meine Empfehlung wäre: Schreibt pro Fehler/ Welt mind. täglich ein Ticket, wenn der Aufwand des Scriptes den der Korrektur übersteigt, wird evt. noch mal drüber nachgedacht.
 
Ich bin nicht einverstanden mit dieser Verschiebung. Es handelt sich um einen bestaetigten und ungefixten Bug. Macht eine eigene Kategorie auf "wird nicht behoben", wenn Ihr das für geboten haltet, aber im Archiv haben ungefixte Fehler nichts verloren.

Der Fehler wurde bestätigt und wird wie gesagt nicht behoben. Deshalb bleibt der Fehler auch im Archiv, das Archiv ist eine Sammlung unserer Fehlermeldungen. Ihr könnt leicht erkennen ohne zu suchen welche Fehler nicht behoben werden.
  • Das Rot vom Präfix, kann man nicht übersehen.
  • Wenn ihr auf den Präfix klickt, zeigt er euch nur die Fehlermeldung an, die den selben Präfix haben.
xaehhssdm68.jpg
 

DeletedUser29593

Gast
Wenn ich mir so vorstelle, ich sei Ziel einer GO und kann die Mauer nicht hochholen, weil mir verdammte 1 oder 2 BHPs fehlen, ist dies mehr als suboptimal. Im alten System würde ich dann, sofern vorhanden, zwei Landeinheiten auf den letzten, für diese Zwecke vorbehaltenen Bauernhof schicken, um BHPs freizusetzen. Nun gibt das neue Bauernhofsystem so etwas so gut wie nicht her.

Mag sich alles wie Erbsenzählerei anhören, dennoch ist dies eine Situation, in welcher man nicht noch mehr Dampf benötigt als schon vorhanden. Doch im Grunde ist dies alles kein Wunder, weil auch die Designer sich sagen, so what, ihr kauft euch sowieso alles ein. Wozu die Aufregung. Da fehlt es an an der Liebe zum Spiel, die inhouse offensichtlich nicht belohnt wird, da die Ressourcen für laufende Features mit Grundrauschen benötigt werden.


.
 
Wie bereits mehrfach erwähnt, kann man sich hier gerne a den Support Weden und wir schauen dann, dass wir das Script einmal laufen lassen.
 

DeletedUser54031

Gast
Wie bereits mehrfach erwähnt, kann man sich hier gerne a den Support Weden und wir schauen dann, dass wir das Script einmal laufen lassen.

Bekomm ich dann auch meine Stadt zurück die ich wegen des Bugs verloren hab oder die Truppen? Oder im Umkehrschluss der Gegner seine Chance eine Stadt zu erobern der zwar genug Off getimmt hatte aber die Stadt dann wieder wegen eines nicht behobenen Fehlers wieder aberkannt bekommen hat? Es ist eben nicht immer damit getan ein Script laufen zu lassen.
 
Wenn ich da dann ne Woche auf ne Antwort warten muss, hilft das in solchen Fällen, wenn eine Stadt angegriffen wird, überhaupt nicht.

Nun, eine Woche benötigt es bei uns nicht um ein Ticket zu beantworten. Dies Funktioniert in den Meisten Fällen innerhalb von 24 Stunden. In ganz vielen Fällen jedoch auch schon früher. Wenn man natürlich am Wochenende einen Community Manager benötigt, kann es auch länger dauern, was hierbei jedoch nicht der Fall ist.

Bekomm ich dann auch meine Stadt zurück die ich wegen des Bugs verloren hab oder die Truppen?

Nun, wenn du wegen einer fehlenden freien Bevölkerung eine ganze Stadt verlierst, würde ich dazu tendieren zu sagen, dass da mehr schief gelaufen ist als wie nur diese eine Bevölkerung ;)

Aber nein, eine verlorene Stadt, ist nunmal eine verlorene Stadt und kann auch vom Support nicht ersetzt werden.
 
Oben