Feedback: Update 2.132

  • Themenstarter DeletedUser55768
  • Startdatum
So, da mittlerweile ein paar Inhalte im Changelog zu finden sind, kurze Anmerkungen und Rückfragen dazu:

  • Colors in the auto-completion dropdown are now adjusted to Grepolis colours.
  • Attack planner - Target town can now be selected by both ID or name.
  • Warehouse and favor storage calculation text changed.

Beim ersten Punkt ist die Rede von den Dropdown-Menus, die zum Beispiel beim Einfügen von BB-Codes auftauchen, wenn man Städte- oder Spielernamen in BB-Code übersetzen lassen will und nach den ersten Zahlen/Buchstaben eine Liste möglicher Stadt- oder Spielernamen angeboten bekommt. Aktuell ist der Hintergrund dieser Dropdown-Menus einheitlich hell, die oberste oder ausgewählte Möglichkeit ist blau hinterlegt. Nach der Änderung folgt der Hintergrund nun dem hier auch im Forum so beliebten Grießbrei-Schema, die oberste bzw. ausgewählte Möglichkeit entspricht nun in der Farbgebung etwa dem hiesigen Forenhintergrund. Ich wollte Euch das eigentlich in einem Screenshot zeigen, aber die Dropdown-Menus erweisen sich gerade als etwas schüchtern und verschwinden, sobald ich per Mausklick das Screenshot-Programm auslösen möchte.

Man könnte nun natürlich nach Sinn oder Unsinn einer solchen Änderung fragen; vielleicht glaubt ja jemand, wir haben zu wenig gelb im Spiel, oder das Farbschema im Forum wird eher akzeptiert, wenn man es wirklich überall unterbringt - aber nach einem Blick auf die Fehler, die nicht behoben werden, lässt man es wohl lieber und schont seinen Blutdruck.

---

Dass Zielstädte im Angriffsplaner nun über ID oder Namen eingetragen werden können, hat uns vorhin glatt ein (Lach-)Tränchen der Rührung in die Augen getrieben. Erst konnte man Städte nur über ihre ID eintragen, dann nur über Namen/Dropdown-Menu. Nun, nach Jahr und Tag, kann man das Ziel nun tatsächlich über Namen oder ID eintragen, zumindest wenn man zuvor das richtige Kästchen vorwählt. Mein Kollege fluchte vorhin leise vor sich hin, da er die ID als BB-Code aus dem Stadtinfo-Fenster geborgen hatte, der Eintrag in den Angriffsplaner aber nur die pure ID verlangt, was er als ausgesprochen unpraktisch empfindet. (Wie gut, dass ich seit der "Überarbeitung" des Angriffsplaners diesen nicht mehr benutze...^^).

---

Was ist mit der Änderung des Textes zu Lager- und Gunstspeicherberechnung gemeint? Was ist geändert worden, und wo?

---

Fehlerbehebungen:

  • Favors penality from island quests now affects only the selected town.
  • Players without an alliance can now assign colors to other players/alliances on the map, and the color remains after refreshing the page.
  • Hall of Fame - In certain cases an alliance was not added as Master of the World.
  • World ending - Sometimes a world was ending the day later.
  • Inventory - Having two happiness caused the inventory to not load.
  • Conquest - Start/End were not properly calculated if there was a delay while processing actions.
  • Hero - A wrong message where shown when sending an attack with only the hero by himself.
Der Gunstmalus der Inselquest hat nun nur Auswirkungen auf die ausgewählte Stadt? Wie ist das gemeint, wie soll das funktionieren?

Zweimal Zufriedenheit (im Inventar, nehme ich an...^^) verhinderte das Laden des Inventars? Ich wusste ja, dass zu viel Zufriedenheit schädlich ist..^^

Nach Lags bei der Abarbeitung von Befehlen wurde Beginn und Ende von Eroberungen nicht richtig berechnet? Will man uns gerade etwas veralbern und behaupten, dass das zukünftig nicht mehr vorkommen wird? (Zancle, die Rettung naht...!^^)
Zu diesem Punkt wäre eine Erläuterung angebracht, denn hier wird der Eindruck erweckt, als würde 2.132 eine Lösung für Probleme a la Zancle oder Apollonia oder zz5 beinhalten, und daran glaube ich nun wirklich nicht. Solange es besagte Lags gibt, wird es auch "verrutschte" Ankunftszeiten geben.
 
Zuletzt bearbeitet:
28268980dx.jpg
 
Nach Lags bei der Abarbeitung von Befehlen wurde Beginn und Ende von Eroberungen nicht richtig berechnet? Will man uns gerade etwas veralbern und behaupten, dass das zukünftig nicht mehr vorkommen wird? (Zancle, die Rettung naht...!^^)
Dies wird auch im DevBlog nochmal ausdrücklich erwähnt. Es ist wohl in den letzten 14 Tagen verstärkt an den Performanceproblemen - natürlich an der Abschaffung dieser ;)- gearbeitet worden. Insbesondere die auftreten, wenn auf einen einzelnen Spieler besonders viele Bewegungen laufen.

Ich muss ehrlich sagen, der Wunsch ehrt Euch, allein mir fehlt der Glaube, dass das tatsächlich behoben werden kann, obwohl es früher tatsächlich nicht so gehäuft aufgetreten ist.

Naja, ich bin skeptisch und abwartend zu diesem Punkt!

Weiteres aus dem DevBlog sind Versprechungen, sich mehr um die Wünsche der Community zu kümmern o_O

Hmmm auch da fehlt mir die Überzeugung, dass das umgesetzt wird. Ihr habt in den letzten Jahren einfach zu oft enttäuscht :(
 
Zuletzt bearbeitet:

Adler94

Ehemaliger Entwickler
Nach Lags bei der Abarbeitung von Befehlen wurde Beginn und Ende von Eroberungen nicht richtig berechnet? Will man uns gerade etwas veralbern und behaupten, dass das zukünftig nicht mehr vorkommen wird? (Zancle, die Rettung naht...!^^)
Zu diesem Punkt wäre eine Erläuterung angebracht, denn hier wird der Eindruck erweckt, als würde 2.132 eine Lösung für Probleme a la Zancle oder Apollonia oder zz5 beinhalten, und daran glaube ich nun wirklich nicht. Solange es besagte Lags gibt, wird es auch "verrutschte" Ankunftszeiten geben.

Die konkrete Änderung an dieser Stelle wird bewirken, dass Start- und Enddaten von Belagerungen bzw. Revolten "zurückgerechnet" werden - sie werden also beginnen, als wären sie zum richtigen Zeitpunkt angekommen und verarbeitet worden.
So wird dann zum Beispiel auch der Nachtbonus korrekt berücksichtigt für alle diese Befehle. Was wir allerdings leider nicht zurückberechnen können, sind Zauber oder Effekte. Wenn diese zwischen ursprünglicher Ankunftszeit und tatsächlicher Abarbeitungszeit ausgelaufen sind, wirken diese leider nicht mehr - dies ist in unserem aktuellen System leider auch nicht lösbar :(
 
Die konkrete Änderung an dieser Stelle wird bewirken, dass Start- und Enddaten von Belagerungen bzw. Revolten "zurückgerechnet" werden - sie werden also beginnen, als wären sie zum richtigen Zeitpunkt angekommen und verarbeitet worden.
So wird dann zum Beispiel auch der Nachtbonus korrekt berücksichtigt für alle diese Befehle. Was wir allerdings leider nicht zurückberechnen können, sind Zauber oder Effekte. Wenn diese zwischen ursprünglicher Ankunftszeit und tatsächlicher Abarbeitungszeit ausgelaufen sind, wirken diese leider nicht mehr - dies ist in unserem aktuellen System leider auch nicht lösbar :(

Naja man muss es auch nicht übertreiben und alles auf die Sekunde genau planen und machen. Dank ATR hätten die Bonis auch so nicht gereicht usw.
Und beim Belagerten sind die Bonis eh weg wenns Kolo anlegt.

Nachträgliche alles Gute zum Burzeltag.
 
Was wir allerdings leider nicht zurückberechnen können, sind Zauber oder Effekte. Wenn diese zwischen ursprünglicher Ankunftszeit und tatsächlicher Abarbeitungszeit ausgelaufen sind, wirken diese leider nicht mehr - dies ist in unserem aktuellen System leider auch nicht lösbar :(
Was ist mit der Miliz?

Auch von mir alles Gute nachträglich!
 

Adler94

Ehemaliger Entwickler
Was ist mit der Miliz?

Auch von mir alles Gute nachträglich!

Danke euch beiden ;)
Für die Miliz (wie für alle Einheiten in der Stadt) gilt dasselbe wie für Effekte/Zauber (denkbar wären ja auch Situationen mit gerade rekrutierten Einheiten), diese Informationen werden bei der Ankunftsverarbeitung "geladen". Wenn zu diesem Zeitpunkt Miliz/Effekte/Zauber laufen (das könnte theoretisch auch bedeuten, dass deren Auslaufen genauso verzögert ist - allerdings geschieht dies auf verschiedenen Ebenen), werden sie berücksichtigt, ansonsten nicht. Insofern kann man hier schlecht eine allgemeingültigere Aussage treffen als "abgelaufene Modifikationen können nicht wiederhergestellt werden".
 

DeletedUser50003

Gast
Die konkrete Änderung an dieser Stelle wird bewirken, dass Start- und Enddaten von Belagerungen bzw. Revolten "zurückgerechnet" werden - sie werden also beginnen, als wären sie zum richtigen Zeitpunkt angekommen und verarbeitet worden.
So wird dann zum Beispiel auch der Nachtbonus korrekt berücksichtigt für alle diese Befehle. Was wir allerdings leider nicht zurückberechnen können, sind Zauber oder Effekte. Wenn diese zwischen ursprünglicher Ankunftszeit und tatsächlicher Abarbeitungszeit ausgelaufen sind, wirken diese leider nicht mehr - dies ist in unserem aktuellen System leider auch nicht lösbar :(

Es sollen nur die Start- und Enddaten von Belagerungen (und Revolten?) zurückgerechnet werden. Aus den folgenden Erläuterungen betreffend Miliz/Effekte/Zauber geht vielmehr hervor, dass die Beschreibung "sie werden also beginnen, als wären sie zum richtigen Zeitpunkt angekommen und verarbeitet worden" so nicht stimmt, sondern sie werden nur "enden", als wäre das Kolo zur geplanten Ankunftszeit auch abgearbeitet worden.

Entgegen der verfehlten Meinung von Spock muss in diesem Spiel selbstverständlich Alles auf die Sekunde genau zur geplanten Ankunftszeit abgearbeitet werden, da die Zeiteinheit in diesem Spiel nunmal Sekunden sind, und sich Alles Wesentliche um die (geplante) Ankunftszeit von Angriffen dreht, die nicht willkürlich irgendwie (aufgrund von systemimmanenten Schwächen) verschoben werden können.

Ich persönlich war auf Zancle ein Leidtragender der Lags vor dem NB. Ich habe eine Serversekunde nach dem letzten Vorangriff die Miliz aktiviert und durch das Auseinanderklaffen von ursprünglicher Ankunftszeit (und nur die ist eine Bekannte, an der man sich orientieren kann) und tatsächlicher Verarbeitungszeit wurde die Miliz von dem letzten Vorangriff vernichtet (obwohl danach aktiviert!) und die Miliz hätte im Zusammenwirken mit den backgetimten Landeinheiten zur Abwehr des Koloangriffes gereicht, der (fast) ausschließlich mit Stichwaffen erfolgte. So begann die Belagerung nur aufgrund eines Systemfehlers und dauerte auch um 4 Sekunden länger, als von der ursprünglichen Ankunftszeit des Kolos gerechnet.

Soweit ich obige Ausführungen zur geplanten Änderung verstehe, ändert sich an der Reihenfolge der Truppenbewegungen (mit der tatsächlichen Abarbeitungszeit, auch wenn sie von der geplanten ursprünglichen Ankunftszeit irgendwie verschoben abweichen) bis zum Koloangriff gar nichts. Es wird hinkünftig nur nachträglich kosmetisch die Belagerungszeit korrigiert, sodass sie nicht 8 Stunden nach der tatsächlichen Verarbeitungszeit, sondern nach der geplanten ursprünglichen Ankunftszeit enden wird. Damit wird der Eroberer gleich nochmal begünstigt, weil er jedenfalls den vollen Nachtmodus hat.

So wie hier beschrieben, ist die geplante Änderung eine reine Augenauswischerei (nur kosmetische Korrektur der Belagerungszeit) und somit total wertlos. Weiterhin gilt, dass das aktuelle System nicht in der Lage ist zu täglich wiederkehrenden Spitzenzeiten alle Befehle zur geplanten Zeit korrekt zu verarbeiten. Ja es ist nicht einmal eine restitutio ad integrum technisch möglich, also eine nachträgliche vollkommene Herstellung des ursprünglich (gewollten) Zustandes (natürlich mit allen Zaubern und Effekten, da diese aufgrund Ihrer Mächtigkeit ein unverrückbarer Bestandteil sind).

Zu erwähnen bleibt noch, dass durch die sinnfreie neue Awardflut - mit den gefühlt Hunderten von neuen Awards wegen vernichteter Einheiten, die gerade in der Anfangszeit einer Welt zu Zehntausenden kurz vor dem NB herabregnen, Befehlsanzahl und Laganfälligkeit des Systems natürlich zu allem Überdruss erhöht wurde.
 
So, ich hab da jetzt mal ne Nacht drüber geschlafen und es sind ein paar Fragen offen geblieben. Deswegen markiere ich hier mal Justus, Marco und unsere CMin vielleicht trägt jemand die Fragen mal weiter....@Adler94 @dev-grepo @Faey... und es finden sich ein paar Antworten. Also ich bin grundsätzlich jemand, der gerne Kolos identifiziert und austimed. Machen aber bestimmt noch viel mehr Spieler als ich. Diese haben ja erstmal mit der neuen Abfolge schlechtere Karten.
In Bezug auf Miliz - haben wir ja schon festgestellt, aber auch in Bezug auf noch mal schnell gezauberte Truppen, die sehr wahrscheinlich dann dem Belagerer zugeschrieben werden wenn knapp gezaubert, richtig?

Soweit so gut.

Wann passiert mir das Ganze? Wenn der ganze Server lagt?- was ich als Spieler ja vorher nicht sehen kann, weil bei mir vielleicht nur 10 Atts laufen dann 30s Pause vor dem Kolo sind, was praktisch eine Situation ist, die danach schreit ausgetimed zu werden um dem Gegner keine Bashies zu schenken. Oder nur dann, wenn bei mir viele viele Atts laufen??

Es wäre schon wichtig, das genau zu wissen um in solch Situationen auch die richtigen Abwehrmaßnahmen zu treffen.

Wenn ich meine Truppen rücktime sind diese nicht betroffen weil sie ein Befehl sind der ordentlich in die Befehlskette eingearbeitet wird. Ist das auch so richtig? Oder gibt es dort auch Ausnahmen?

Auch wäre wichtig zu wissen, ob das jetzt die Standardabfolge ist und immer gilt, oder ob sie nur in den größten Belastungszeiten stattfindet.
 
Zuletzt bearbeitet:

DeletedUser50880

Gast
  • Inventory - Having two happiness caused the inventory to not load.

Zweimal Zufriedenheit (im Inventar, nehme ich an...^^) verhinderte das Laden des Inventars? Ich wusste ja, dass zu viel Zufriedenheit schädlich ist..^^

@Faey Ich würde nun doch gerne mal wissen, warum ausgerechnet am 31.01.2017 jedem Spieler einmal Zufriedenheit ins Inventar gekippt wurde.
Und warum konnte man nicht einfach mal schnell das zweite Zufriedenheit bei den Spielern, die nun unter dem Bug leiden mußten und somit ihr volles Inventar nicht ausmisten konnten und sich bei der Verdopplungsaktion auch nix einlagern konnten, entfernen?
Gemeint ist diese Verdopplungsaktion beim letzten Event:
mbjzepnlr84.jpg
Und vor allem, warum war dieser Bug pünktlich zum 01.02.2017 ab 11 Uhr verschwunden, wenn er doch eigentlich erst noch behoben wird?
 

DeletedUser764

Gast
Dies wird auch im DevBlog nochmal ausdrücklich erwähnt. Es ist wohl in den letzten 14 Tagen verstärkt an den Performanceproblemen - natürlich an der Abschaffung dieser ;)- gearbeitet worden. Insbesondere die auftreten, wenn auf einen einzelnen Spieler besonders viele Bewegungen laufen.

Ich muss ehrlich sagen, der Wunsch ehrt Euch, allein mir fehlt der Glaube, dass das tatsächlich behoben werden kann, obwohl es früher tatsächlich nicht so gehäuft aufgetreten ist.

Naja, ich bin skeptisch und abwartend zu diesem Punkt!

Weiteres aus dem DevBlog sind Versprechungen, sich mehr um die Wünsche der Community zu kümmern o_O
WAS :O

Für die Miliz (wie für alle Einheiten in der Stadt) gilt dasselbe wie für Effekte/Zauber (denkbar wären ja auch Situationen mit gerade rekrutierten Einheiten), diese Informationen werden bei der Ankunftsverarbeitung "geladen". Wenn zu diesem Zeitpunkt Miliz/Effekte/Zauber laufen (das könnte theoretisch auch bedeuten, dass deren Auslaufen genauso verzögert ist - allerdings geschieht dies auf verschiedenen Ebenen), werden sie berücksichtigt, ansonsten nicht. Insofern kann man hier schlecht eine allgemeingültigere Aussage treffen als "abgelaufene Modifikationen können nicht wiederhergestellt werden".
Hört sich so an als ob ihr im voraus prüfen solltet, ob die Miliz nicht wieder in die Belagerungstruppen hineinwandern können, nur so ein Tipp^^

Zu, Stevie2 Spoiler:
WTF noch mehr Belohnungen xD
 
Ich habe keine Ahnung, ob es mit einer der Änderungen von 2.132 zu tun hat, aber nach einem doch wieder recht angriffsreichen WE auf zz5 hat mich die Verzweiflung
ziemlich im Griff. Am WE war kein Event, das für zusätzliche Performance-Probleme verantwortlich gemacht werden kann - allerdings müssen die Eventbelohnungen wohl umgehend unters Volk gebracht werden (^^) - aber dafür kam mal wieder alles an Performance- und Aktualisierungsbugs aus den Löchern gekrochen, was irgend Beinchen hatte.

Es macht einfach keinen Spaß, auf die Suche nach den Truppen gehen zu müssen, die man gerade in einer Stadt vermutet, und die man vor dem nächsten Angriff in die nächste Stadt verschieben will, weil sie weder im UI noch unterwegs angezeigt werden, nach dem Angriff aber mausetot sind, weil sie doch in ihrer Heimatstadt standen. Neu ist dabei die Variante, dass man Truppen, die man bereits aus ihrer Heimatstadt geschickt zu haben glaubte, noch im UI sieht - aber nicht rausschicken kann, da sie im Unterstützungsfenster nicht angezeigt werden. Ich weiß außerdem nicht, wie oft ich am WE wieder die Meldung hatte "nicht genügend Truppen", "nicht genügend Ressourcen", etc... Man wird einfach kirre nach ein paar Stunden. Spaß sieht anders aus, ich bin massivst genervt vom Zustand des Spiels.

Und wenn ich dann noch darüber nachdenke, wie oft ich allein in den letzten Wochen das "Geisterkolo-Fenster" hatte, in allen erdenklichen Varianten, einschließlich eines Eroberungsfensters in einer gar nicht belagerten/angegriffenen Stadt, und wie stark man durch das Ding behindert wird, wenn man unmittelbar nach dem Kolokick die stadteigene Off vor Nachfolgeangriffen wieder in Sicherheit bringen muss, könnte ich die Wände hochgehen, wenn ich lesen muss, dass Inno diesen Fehler seit Jahr und Tag aussitzt und nun noch mit einem "wird nicht behoben"-Schild versehen hat.

---

Die konkrete Änderung an dieser Stelle wird bewirken, dass Start- und Enddaten von Belagerungen bzw. Revolten "zurückgerechnet" werden - sie werden also beginnen, als wären sie zum richtigen Zeitpunkt angekommen und verarbeitet worden.
So wird dann zum Beispiel auch der Nachtbonus korrekt berücksichtigt für alle diese Befehle. Was wir allerdings leider nicht zurückberechnen können, sind Zauber oder Effekte. Wenn diese zwischen ursprünglicher Ankunftszeit und tatsächlicher Abarbeitungszeit ausgelaufen sind, wirken diese leider nicht mehr - dies ist in unserem aktuellen System leider auch nicht lösbar :(

Es mag Euch nicht so klar sein wie uns, aber das Ärgerliche ist nicht so sehr der verzögerte Beginn einer Belagerung oder ihr verzögertes Ende, sondern die schlichte Tatsache, dass alle Befehle, die einerseits dazu dienen, das Kolo zum Landen zu bringen, andererseits aber genau dieses Landen (oder Verweilen) verhindern sollen, weiterhin laggen, nun aber Frontend-Kosmetik betrieben werden soll, die dem User trotz der weiterhin bestehenden Lags vorgaukeln soll, dass die Belagerung zum avisierten Zeitpunkt begonnen hat. Da das System vorab ja nicht weiß, welche laufenden Befehle für das Zustandekommen oder Nicht-Zustandekommen einer Belagerung relevant sind, befürchte ich eine Vielzahl möglicher Fehler und nicht berücksichtigter Konstellationen.

Es ist schlimm genug, dass im Changelog und in Adlers Erläuterung tatsächlich nur von Start und Ende von Belagerungen (und Revolten) die Rede ist, und der Eindruck erweckt wird, als würden alle sonstigen Truppenbewegungen nicht neu berechnet - was Koloabwehr endgültig zu einem reinen Glücksspiel werden ließe. Woran macht Ihr denn fest, welche Befehle/Truppenbewegungen vor/bei/nach Einschlag neu berechnet werden? Es wäre natürlich der GAU, wenn tatsächlich nur der Koloeinschlag/die Belagerung nachträglich oder parallel neu berechnet würde. während alle Truppenbewegungen "drum herum" unberücksichtigt blieben - insbesondere, wenn das Kolo gar nicht landet und somit keine Belagerungszeit neu berechnet werden muss.

Hinzu kommt, dass die Lags entstehen, weil zu bestimmten Zeiten eine nicht mehr zu bewältigende Zahl von Rechenoperationen anfällt (natürlich gefördert durch all die zusätzlich zu berechnenden Boni/Effekte, die sich in den letzten Jahren explosionsartig vermehrt haben). Diesen Teufel mit dem Beelzebub weiterer paralleler Rechenoperationen austreiben zu wollen (auch wenn diese eventuell auf einer anderen Ebene stattfinden und die Ergebnisse dann auf den Spielserver zurückgespielt werden) scheint mir auf Anhieb kein wirklich vertrauenerweckendes Vorgehen zu sein.

Deswegen markiere ich hier mal Justus, Marco und unsere CMin vielleicht trägt jemand die Fragen mal weiter....@Adler94 @dev-grepo @Faey... und es finden sich ein paar Antworten.

Marco/dev-grepo ist allem Anschein nach nicht mehr im Grepo-Team.
 

DeletedUser55768

Gast
@Stevie2 uns ist nur ein Spieler mit diesem Problem bekannt und ich glaube du weißt wer ;) Wir haben das Problem individuell untersucht. Zu Anfang wussten wir noch nicht, dass es an der Zufriedenheit lag. Nachdem wir das herausgefunden hatten, haben wir auch den fehlerhaften Effekt entfernt und später wieder (funktionierend) hinzugefügt.
Es taucht nun im Changelog auf, da dort immer dargestellt wird, woran unsere Entwickler in den letzten Wochen gearbeitet haben.
 

DeletedUser13650

Gast
ich finds schonmal nen anfang die balgerungszeit zurückzurechnen, aber wirklich ändern tut sich am problem ja nix.

auch das die zauber nciht zurückgerechnet werden können ist sicher ein problem was draba noch gar nicht weiter beleuchtet hat, klarr das scharfsinn mitlerweile ausgelaufen ist, und man dadruch ne menge kampfpunkte "verliert" ist sicher ärgerlich, aber überlegt mal wenn die ganzen andern kampfboni ablaufen, sei es nun verteidigungs oder angriffsboni und wegen den fehlenden prozenten nen kolo landet oder nciht landet, das ist doch mindestens genausoschlimm als wenn man es nicht schafft die miliz noch vors kolo zu bringen.
 
Was ist mit der Änderung des Textes zu Lager- und Gunstspeicherberechnung gemeint? Was ist geändert worden, und wo?
Der Gunstmalus der Inselquest hat nun nur Auswirkungen auf die ausgewählte Stadt? Wie ist das gemeint, wie soll das funktionieren?

...und natürlich insbesondere alle offenen Fragen zur anscheinend rein kosmetischen und das eigentliche Problem nicht einmal erfassenden "Lösung" bei Lags.

Sind hier nun noch irgendwelche Antworten oder nähere Erläuterungen zu erwarten?

Wurde zudem in irgendeiner Form wahrgenommen, dass sich im Zuge der Implementierung von 2.132 auf den Betas wieder teils uralte Aktualisierungsfehler zeigen?

---

Es taucht nun im Changelog auf, da dort immer dargestellt wird, woran unsere Entwickler in den letzten Wochen gearbeitet haben.

Nein, @Faey, im jeweils aktuellen Changelog sollten die jeweils zu dem fraglichen Update gehörenden Inhalte dargestellt werden, und nicht eine Mischung dessen, was irgendwann in den letzten Wochen getan worden ist. Wenn die Fehlerbehebung zum Thema "Zufriedenheit" zu einem früheren Update gehörte, sollte sie dem Changelog dieses früheren Updates hinzugefügt werden und dort deutlich als nachträgliche Ergänzung erkennbar sein.
 

DeletedUser55768

Gast
Nö, das passt schon von der Zeitspanne her. Ich habe es nur für Stevie2 erklärt, weil nachgefragt wurde warum es im zukünftigen Changelog auftaucht.
 
Ja, und es ist noch immer unklar, warum es im zukünftigen Changelog auftaucht.

---

Aber die übrigen offenen Fragen sind wahrlich wichtiger.
 
Oben