Posts by alavela

Mir persönlich würde Transparenz darüber helfen, wie genau intern am Projekt OGame gearbeitet wird.

Das muss kein großes Firmengeheimnis sein. ↝ Hier ↜ wurde ja schon ein Arbeitsplatz gezeigt, mit dessen Output wir alle täglich konfrontiert sind. Das könnte man durchaus communitytauglich darstellen.

Mir würde es helfen, das besser einordnen zu können:

• Läuft das Projekt als deprecatete Cashcow auf Sparflamme?
• Sitzt ein einzelner armer Tropf am alten Codemoloch und muss das irgendwie in Schuss halten?
• Gibt es eine ganze Reihe von Software-Entwicklern, die Arbeitszeit für OGame-Entwicklung bezahlt bekommen, aber eine schlechte Qualifikation oder ein noch schlechteres Management haben?
• Wer verantwortet als wirtschaftlich und sozial Vorgesetzte z. B. die hier kritisierten schlechten Updates, die ungetestet Bestehendes kaputt machen und zahlreiche Kunden völlig unnötig verärgern?
• Was können wir organisatorisch oder wirtschaftlich tun, um aus dem Schlamassel herauszukommen, one way or another?

Ich weiß leider ein bisschen, wie das ist.

Meine DM-Käufe – die ich seit neulich eingestellt habe und aufgrund des schlechten Service nicht wieder tätigen werde – habe ich mit ähnlichen Problemen erwirtschaftet.

Ich würde gerne helfen können.

AterBalbi wrote:

bitte nicht so einen Quatsch behaupten. Du kannst Dir sicher sein, dass die Devs glücklicher wären, wenn dieser Mist nicht passieren würde.

Was soll daran Quatsch sein? Kannst Du nicht verstehen, wie man auf diese Vermutung kommen kann? Könnt ihr (als Admins und Betreiber) uns gegenüber (als Spieler und Kunden) wirklich behaupten, dass das Update getestet wurde, bevor es heute ausgerollt wurde, und der Bug dabei nicht aufgefallen ist?

Katastrophe ey … Dass gar kein Start mehr möglich ist habe ich so noch nicht erlebt. Was kommt als nächstes? Bei den Leuten, die Zugriff auf Codebase und Deployment haben, ist echt alles steigerungsfähig. Wer lässt das zu, wer bezahlt sie?

Sanjin wrote:

Und wird das behoben?

SirsSchwester wrote:

Es ist gemeldet.

… und gibt es eine Erklärung, wieso so ein offensichtlicher Bug committed und deployed wurde? Oder anders gefragt, hat OGAME-9547 irgendeine Priorität, wo dieser Bug schon einen halben Monat live ist und in eurer #resourcesbarcomponent span.value > span:first-of-type-Regel in 10s gefixt ist wäre?

Der Bug hat auch nichts mit mobiler Ansicht zu tun, weil das Problem auch in der Desktop-Variante ohne aktivierte ~ auftritt.

Zusammenführen mit Nicht genug Laderaum = kein versenden mehr möglich?

Mantis 0094572 / OGAME-7743

Gemeldet vor fast 1 Jahr und auch in 8.1.0-pl1 noch live.

Zusammenführen mit Versand von Schiffen seit Update mit Max. Ress nicht mehr möglich?

Mantis 0094572 / OGAME-7743

Gemeldet vor fast 1 Jahr und auch in 8.1.0-pl1 noch live.

Ich dachte mal wieder, ich hätte es mit den Augen, aber es ist evident:

Seit spätestens 8.1.0-pl1, vielleicht auch schon seit 8.1.0, kommt es wieder zu doppelt versandten Flotten (gab es vor Ewigkeiten schon und damals lange, war dann irgendwann für eine ganze Weile behoben).

Reproduzierbarkeit ist schwierig, mir ist es nun aber schon einige Male passiert, beim Versand von Angriffen.

Die duplizierten Flotten habe identische Zusammensetzungen und sind sekundengenau gleich.

Jemand anderes mit der Beobachtung? Ideen zur Reproduzierbarkeit? Interne Ticket-Nummer?

(In »Plötzlich neue TOP3...« wird über diesen Bug diskutiert.)

SirsSchwester wrote:

Warten wir mal ab wie es nach dem Hotfix heute dann morgen ausschaut.

SirsSchwester wrote:

Die Highscore braucht etwas Zeit für die Berechnung, also es kann sein das dort nicht sofort alles wieder perfekt dargestellt wird.

8.1.0-pl1 ist ja schon eine Weile online (aktuell ca. 23h), und die Rangverschiebungen/Platzierungsänderungen werden weiterhin falsch dargestellt.

Wieso genau „braucht die Highscore etwas Zeit“ bzw. wird „nicht sofort perfekt dargestellt“? Sie ist kein fehlerbehaftetes Wesen, sondern Teil einer Datenbank, die zu jedem Zeitpunkt Spieler+Punkte+Deltas kennt, berechnet, zwischenspeichert und ausgibt. Eine Stunde „um sich zu kramen“ wäre schon enorm lang. Wenn einen Tag später das Problem weiterhin besteht, ist es schlichtweg nicht behoben, oder?

Mit 8.1.0-pl1 dauert der Abruf bei mir nur noch 3–4 Sekunden und passt somit zur generellen Responsiveness. Wenn es so bleibt, ist das Thema aus meiner Sicht erledigt/behoben.

Ist 0094580 in Mantis intern als erledigt markiert? Haben andere weiterhin Probleme (die mit den 600+ Items )?

Das Folgende ist eigentlich ein alter Hut, der aber seit einigen Hauptversionen nicht angefasst wurde, obwohl das ein Leichtes wäre. (Stattdessen wird es auch bei Neutwicklungen fortgeführt, was argumentativ wahrscheinlich nicht sein sollte.) Es richtet sich an Entwickler bzw. Professionelle, die JSON-APIs bauen und implementieren. Den Ausführenden bei der GF werden sich des ungünstigen Designs bereits bewusst sein.

Verschiedene APIs übertragen schlichtweg viel zu viele Daten, von denen das absolute Gros redundant ist (z. B. da der Client sie schon kennt oder es sich um generische Inhalte wie Texte handelt, die für alles gleich bleiben). Viele APIs übertragen komplette Strukturen statt nur Inhalte.

Beispiel component=galaxyContent&galaxy=…&system=…: Der Inspektor bemängelt lange Ladezeiten bei jedem Systemwechsel. Beim Durchgehen von Systemen (z. B. beim Scannen) werden pro System (!) ca. 70 KB umgewälzt. (Gzipped nur ca. ⅒, aber die Ausgangsgröße ist einfach viel zu groß.) Ankommen tut in der galaxy-Eigenschaft also soetwas:

Sieht das richtig und sauber aus? Muss das alles für jedes System erzeugt und übertragen werden?

(Das Foren-Limit reicht nicht für diese Daten aus; hier sind die vollständigen Daten, die pro System übertragen werden: https://pastebin.com/YTbgPYiN)

Beispiel action=getDetails: Das Öffnen von Details bei Forschungen/Gebäuden dauert bei mir ca. 2–3 Sekunden. Ich vermute, das liegt u. a. daran, dass in den technologydetails jedes Mal soetwas übertragen wird:

Ist es wirklich nötig, für jede Details die selben Lokalisierungen zu übertragen? Das ganze HTML ist schon auf dem Client und müsste nur mit ein paar neuen Daten befüllt werden.

Das sind nur zwei offensichtliche Beispiele, die aufgrund der ungewöhnlichen Verzögerung ein Nachschauen provozieren. Es gibt natürlich noch andere Stellen, an denen jeder Spieler oft vorbei kommt (Beispiel page=messages&ajax=1, wo der Browser auch die langsame Übertragung von ~2500ms statt empfohlenem Maximum von 500ms bemängelt). Vom Shop/Inventar ganz zu schweigen, was bei mir 30+s (!) und 48+ KB (gzipped!!) braucht. Teilweise werden die ‚betroffenen‘ Seiten u. U. hunderte Male täglich aufgerufen, was die Sache betrachtenswürdiger macht (als wenn es nur 1× tgl. wäre).

Hier geht es nicht um neue Features oder Bugfixes, sondern um Architekturentscheidungen, die keine Vorteile bringen außer vielleicht Bequemlichkeit. Das Verschlanken des Overheads und Abwälzen auf den Client (mit seinen gewaltigen Ressourcen) bedeuten auch keine monatelangen Umbauarbeiten, weil Gerüste und Rahmen ja schon da sind. Ob PHP das HTML zusammenschreibt und man es dann einhängt, oder ob der Präprozessor nur Daten durchreicht und man die dann vor Ort zusammenpackt und einhängt ist gehüpft wie gesprungen, nur dass die Performance extrem auseinanderklafft. (Der Server muss sich den Stress auch gar nicht machen, wenn der Client die Zusatzarbeit nichtmals merken würde.) Anpassungen dieser Art klappen auch im laufenden Betrieb und tun gar nicht weh.

Also, Kritik: APIs sind unökonomisch und ungepflegt, und sie kosten unnütz Ressourcen und vor allem Kunden unnötig Zeit.

Obwohl das Update schon eine Weile her ist, bleibt die Verschiebung der Platzierungen auch Tage später noch bestehen (eigentlich müsste diese tgl. um 3 Uhr zurückgesetzt werden):

(In Highscoreplazierung falsch geht es um Darstellung gleicher Punktzahlen.)

Oder ich habe hoffentlich etwas falsch verstanden.

Die Idee an sich, das zusammenzulegen, ist super. Wurde nur leider nicht von Leuten gemacht, die OGame spielen oder sich verantworten müssen.

Tanne wrote:

funktioniert (derzeit) sehr flüssig und man spart wirklich etwas Zeit

Wo genau spielst Du mit welchem Setup? Das will ich nämlich auch sagen können. Es funktioniert überhaupt nicht flüssig und durch die künstlichen Verzögerungen kostet es zusätzlich Zeit (bei mir dauert es spürbar länger als noch zu Flotte-3-Zeiten).

McLane u14 wrote:

3 sanduhren gleichzeitig

Das ist für mich auch ein wichtiger, subtiler Punkt. Erwartungskonform ist 1 Activity-Indicator/Loading-Spinner. Ich krieg’ jedes Mal einen Schreck. Ein einziges Overlay über alle 3 Bereiche wäre völlig ausreichend.

Mit 8.1.0 kommt es (erstmals seit einigen Versionen) wieder vor, dass eine Flotte doppelt verschickt wird. Kann es noch nicht reproduzieren (daher hier statt eigener Thread), ist aber schon oft aufgetreten.

Roderick wrote:

Auf dem langen und steinigen Weg zur Unspielbarkeit scheint OGame wieder ein gutes Stück weitergekommen zu sein.

Schön ausgedrückt.

Roderick wrote:

Flottenversand per Entertaste

Roderick wrote:

Plani/Mond direkt anwählen

Roderick wrote:

direkt über den Auftrag auswählen

Das Allerschlimmste ist dabei für mich, dass das alles in kürzester Zeit mit den vorhandenen Sachen zusammenhackbar ist. Anders gesagt: Für einen Addon-Entwickler ist das überhaupt kein Hexenwerk, höchstens ätzendes Zusammensuchen. Noch anders ausgedrückt: Selbst für einen nur mäßig oder auch gar nicht talentierten Entwickler wäre das sehr einfach in die Retail-Version zu übernehmen. Wäre geil, wenn die GF mal ein Codecamp mit den besten Frontend-Technikern der Community machen würde. Freibier in Karlsruhe im Austausch für Community-Wunschknaller wie »Standardmission« oder »Laderaumrechner«.

SirsSchwester wrote:

Kann es sein das ihr viele Items im Inventar liegen habt?

Ich habe 200+ Items und es lädt 30+ Sekunden.

Die Anzahl ist aber allenfalls Ausgangspunkt für den Fix (als Referenz zum Performance-Testen sollte also bspw. der Account mit den global meisten Items genommen werden). Es muss auch mit einem Vielfachen vernünftig funktionieren (da normales Spielverhalten), oder es muss ein Schild dran, bis wohin es OK ist.

NiNN , der Titel ist eindeutig, aber die Informationen unzureichend um zu helfen. Das Problem ist nicht global (zumindest bin ich nicht betroffen, danke), daher braucht es mehr Informationen.

Der Titel könnte auch »Planeten-/Mond-/TF-Symbol fehlt im Flottenversand« sein, korrekt?

Hast Du das bei jedem Flottenversand? Welcher Browser? Fehlt es auch noch nach einem [Strg]+[Shift]+[R]? Falls ja, hast Du vlt. noch alte Addons [für OG] im Browser installiert?

Sind immer doofe Fragen, aber wenn nicht jeder betroffen ist, ist Reproduzierbarkeit am wichtigsten, um Probleme zu beheben.

Alastair wrote:

Lustigerweise komme ich jetzt schneller in den Shop bzw. ins Inventar als vor dem Update.

Bist Du sicher? Ist es wirklich schnell bei dir? Hast Du viele Items und auch Resspakete? Ich glaube es dir ja und wünsche es dir auch, aber bei mir ist es noch (!) viel schlechter geworden seit 8.1.0, siehe Inventar-Abruf seit Ressourcenpaketen deutlich zu langsam (Mantis ID: 0094580).

Mit 8.1.0 ist es noch schlechter geworden – kaum möglich eigentlich! 🤮

Die 450+ KB sind zwar (API-programmier-mäßig) extrem hässlich, ließen sich aber schnell übertragen.

Aber 22 Sekunden zum Seitenabruf??

Ist das wirklich so gewollt vom Entwickler und seinem Chef??

Ich denke immer noch, dass die Abfrage einfach total schlecht ist bzw. mit einfachsten Mitteln optimiert werden kann, und dass es mit vorhandenen Resspaketen und deren Berechnung zu tun hat.

Die für 8.1.0 angekündigte „signifikante Verbesserung der Ladezeiten“ muss jedenfalls an einem unbekannten Ort liegengeblieben sein, schaut man sich Threads an wie Seiten lade Zeiten sehr lang oder Version 8.1.0 - Flotten verschicken mit "Enter" nicht mehr möglich, dazu ewig lange Ladezeiten für das Aufrufen der Spionage.

lol Blizzard? WTF!!1

Bleibt es dabei? Super, endlich wieder eine Gelegenheit, die 16er TFs abzugrasen.

m0sT.Tarazed wrote:

Wirkt in meinen Augen überhaupt nicht so wie Du es beschrieben hast......

Wie kommst Du darauf !? Unsinn ^^

Ein bisschen behindert, eine andere Meinung als „Unsinn“ zu bezeichnen, und das nachgestellt der Nachfrage und der offensichtlich subjektiven anderen Einschätzung.

SirsSchwester wrote:

hat nichts mit dem Belohnungs-Event zu tun, wir benutzen nur die gleiche Funktion

Naja, es ist offensichtlich eine Abwandlung des Belohnungsevents; der Menüpunkt heißt gleich, und es gibt Belohnungen für’s Einloggen; es ist also ein Modus des Belohnungsevents.

Ist das ein Bug? Nach dem Doppelpunkt steht bei mir nichts:

Gibt es Zusatzbelohnungen, wenn der Kommandostab aktiv ist?

.:: Edit by Lunati: Verwarnung wg Beleidigung | 09.07.2021 | 18:22 ::.