Serverwartung 21.11

  • Morgen scheint es ja wieder eine Serverwartung wg dem ausgefallenen Merge (Svidur/Gaia) zu geben. Ist dann Kadmos/Kerub auch betroffen?

    Und heisst 'später Nachmittag' wieder 'nächster Morgen' ? :D


    und Bitte eines Gärtners: könnt ihr sowas nicht 36 Std oder so vorher ansagen. Dann würde man sich das neu anpflanzen sparen, bis Abend sind die Pflanzen hinüber...

  • Ich weiß nicht so wirklich, wie man deinen Beitrag deuten soll ... sarkastisch oder doch ernstgemeint?

    Ich denke, dass die Kollegen sich letzte Woche ihren Arbend anders vorgestellt haben. Aber egal ...


    Das mit den Pflanzen ist natürlich doof, sollte aber doch seit letzte Woche bekannt sein,

    dass der Merge der verbliebenen Servern nachgeholt wird - sogar mehr oder weniger mit Zeitangabe (morgen) siehe hier.


    Von der längeren Downtime sollen dann lediglich Svidur (EU27) und Gaia (EU1) betroffen sein.

  • also so eine Portion Sarkasmus/Ironie/Frotzelei ist immer dabei

    die Ankündigung von letzter Woche sagt irgendwann diese Woche, nicht notwendigerweise wieder Dienstags (wobei 'normale' Serverwartungen ja auch Donnerstags sind) und ist eh schon Geschichte (und somit vergessen).

    Aber (ganz ernst gemeint) wenn ihr das schon seit letzter Woche wisst sollte eine frühere (exakte) Ankündigung doch möglich sein....

  • Also ich lese aus der Wartungsankündigung das nur der US Server zur Regulären Zeit wieder online sein soll.

  • Von der längeren Downtime sollen dann lediglich Svidur (EU27) und Gaia (EU1) betroffen sein.

    Bist du dir da sicher? ö.ö
    In der Ankündigung steht:

    Quote

    Die Wartung wird deutlich länger dauern als üblich. Wir gehen davon aus, am frühen Abend wieder online zu sein. Die vom Merge nicht betroffenen Server (Ayvenas) sollten zu den sonst üblichen Zeiten wieder hochgefahren werden.

    Für mich liest sich das so, dass nur der US Server normal on sein wird und alle anderen dann später mit Gaia

  • Auch wenn die anderen Server (Aynara und Kadmos) morgen von der längeren Wartung betroffen sind, dann ist es so.

    Lieber so, als wenn irgendwas größerers schief geht und dann gibt es einfach nur noch mehr zu tun.


    Es ist natürlich wahnsinnig schade, dass die Pflanzen dabei eingehen - allerdings muss ich sagen wären die Pflanzen duchaus das kleinste Übel, was bei einem Merge in die Hose gehen kann ;-)


    Wie Zhirelia schon schrieb, haben sämtliche betroffenen Personen letzte Woche Nachts auch sicherlich besseres vorgehabt .... Aber dennoch blieb jeder einzelne davon da um die Server wieder online zu holen und/oder für die Spieler da zu sein (egal, ob es ehrenamtliche oder GF Mitarbeiter sind)


    Demnach bleibt uns eh nichts anderes übrig als hier abzuwarten, was morgen passieren wird

                  v23mlTl.png

    (12:15:19)<SaitoHajime>steht doch dran, kineila ist voll super.

  • 86opi4.gif?ex=656e1030&is=655b9b30&hm=c8105294c2ae958247c78fc35e284ff2c4fb7e08ca64679eefc7acc9f7d45cd5&

  • stehlt auf 64 bit um das macht vieles leichter kan ja nicht sein das gf alles verschläft und zur Nachtarbeit bessere Vorbereitung bring manchmal was

  • Ellina Ich glaube hier wird nicht beachtet, was es überhaupt für ein riesen Arbeitsaufwand es ist, wenn man den Client von 32 auf 64-Bit umprogrammiert. Das ist kein Haken, der einfach so gesetzt wird und ab geht die Post.

    Das ist ein Aufwand von mehreren Monaten und einen gewiss 6 bis 7-stelligen Betrag. Zumal GF nur Publisher ist - d.h. das werden die gewiss nicht können/dürfen.

    Also ja, das Spiel wird bis Ende mit 32-Bit Client gespielt und gut ist. Denn auch wenn man mitbekommt, wieviel so manch einer einzahlt.

    Der zusätzliche Gewinn den GF erwirtschaften müsste wäre so immens, dass GF vermutlich mindestens 1k+ mehr neue Spieler braucht, um das ansatzweise zu erwirtschaften.

  • ClimateEmergency Ahh, also meinst du das 1x ein Knopf drücken ausreicht für so ein komplexes Programm wie ein über 14 Jahre altes Spiel mit Abermillionen Zeilen an Code. Sehr gut.

    Wenn in 5 Minuten alles getan wird um alte Programme auf den neusten Stand zu bringen oder deren gesamten Architektur, auf die das Programm aufbaut, wozu dann noch Programmierer? Ach ja, warte...

    Wieviel eigentlich hinter sowas steckt wird irgendwie vollkommen außer acht gelassen. Ich arbeite i.d.R. mit Programmierern zusammen für verschiedene Projekte, teste ggf. auch Produkte/Projekte (presales) und weiß, wieviel Arbeit hinter den Sachen steckt mit QM.


    Außerdem gibt es Sachen, die man nicht 1 zu 1 ändern kann oder vorher anpassen muss oder direkt mit überprüfen darf. Abhängigkeiten, Speicheradressierung, Datentypen, API´s, Compiler unterschiede,....

    Meinst du, wenn das in 5 Minuten gemacht wäre und Gameforge den Umsatz sofort ver-x-fachen könnte, würden die das tun?

  • das Halbwissen zu c++ 32/64 bit is echt faszinierend XD


    ums mal komplett runterzubrechen:

    • 32bit -> pointer haben 32bit/4byte -> du kannst 2^32 bit Arbeitsspeicher addressieren (~4GB)
    • 64bit -> pointer haben 64bit/8byte -> du kannst 2^64 bit Arbeitsspeicher addressieren (~16EB)


    und jetzt der etwas ausführlichere Teil (aber immer noch vereinfacht):


    Nebenwirkungen von einer solchen Umstellung:

    • jegliche Bibliotheken müssen in derselben Architektur kompiliert sein, das betrifft sowohl statische Bibliotheken (aka zur Compilezeit gelinkt) als auch dynamische Libraries (DLLs).
      • Bei uralt Programmen kann das ein Problem sein, da die Bibliotheken nicht immer als x64 existieren.
      • => API/ABI Kompatibilität
    • Pointer haben 8 Byte statt 4 Byte
      • Für RoM -> jegliche Object.db kann nicht geladen werden (einige Felder da drin sind eigentlich pointer -.-)
      • typecasts können Pointer töten (pointer -> int -> pointer Umwandlung ist bei manchen Entwicklern sehr beliebt -.-)

    Probleme, die durch eine solche Umstellung nicht behoben werden:

    • Use after free -> mit Glück Crash
    • Double free -> mit Glück Crash
    • Out of bounds error -> mit Glück Crash
    • nullpointer error -> crash
      • Diverse Lua funktionen
    • integer overflow -> Wert abgezogen statt hinzugefügt, endlosschleifen ...
      • GipfelEP von der NoM Quest
      • TP
      • GipfelEP in der romwelten db (ja ich bin zu faul das zu fixen)
    • divide by 0 error
    • race conditions
    • Memory leaks

    Probleme, die behoben werden

    • Out of Memory... stattdessen gibts nen Speicherfresser for free (memory leaks) :D


    Ja, für kleine / neue Projekte ist es meist nur eine Änderung eines Flags des Compilers.

    Für größere / alte Projekte: siehe oben.


    Wer Fehler findet kann sie gerne sezieren ;)

  • Kann eigentlich nicht so schwer sein RoM auf 64bit umzumoddeln...

    es gibt genug lizensierte Runes Clone im Netz die unter 64bit laufen!


    Wie haben die das gemacht?

  • Kann eigentlich nicht so schwer sein RoM auf 64bit umzumoddeln...

    es gibt genug lizensierte Runes Clone im Netz die unter 64bit laufen!


    Wie haben die das gemacht?

    Die Entwicklung des Clients einer der bekanntesten Vertreter hat, trotz geleaktem Quellcode des RW-Clients mehrere Jahre gedauert und gänzlich Bugfrei läuft er immer noch nicht. Und glaub mir, da waren mehr Entwickler beteiligt als komplett RW beschäftigt.


    Da du ja aber scheinbar mehr Ahnung hast, als professionelle Entwickler und es so einfach ist, bau den Client doch mal neu auf 64 bit, aber ohne dem RW Code (weil wegen Copyright und Eigentumsrechte) und schick es an GF. Dann profitieren wir ja alle davon :)


    Wie schön wäre eine Welt, in der Meinung und Wissen äquivalent wären.

    Edited 2 times, last by Ainz ().

  • Oh und keiner dieser "clone" ist lizensiert. Es gibt nur eine weitere RoM Version die legal ist und das ist Runes of Magic von TD22 im asiatischen Raum und die haben keinen 64er^^

  • Moin Moin,


    Bevor hier weiter in das Thema zu Spielclienten von anderen potenziell existierenden Spielen mit visuellen, inhaltlichen und namenstechnischen Ähnlichkeiten kleinerer/größer Art zu RoM eingegangen wird und unsere Forenfeen die Moderationsaxt auspacken:


    Wie in den Beiträgen von Ainz, Pyrr und Royals ausgeführt, ist eine Umstellung der Architektur von 32 auf 64bit leider nicht mal eben mit ein paar Compiler Flags getan. -.-


    Wir geben die Themen Clientstabilität und 32/64bit regelmäßig weiter, da man auch ohne eine Änderung der Architektur eine Reihe von Problemen/Löchern des Clienten schließen könnte. :)


    Viele Grüße

    Raky

    announcement_runesofmagic_de_647aa79b6164c45a61cae9043e5b7772.png

  • So ihr Lieben ...


    ich mag hier nochmal alles zusammenfassen:


    Es ist nicht einfach mal so einfach ein Programm von 32-Bit auf 64-Bit umzuschreiben.


    Der Wunsch nach einem 64-Bit Client kennen wir schon sehr lange und dieses Feedback wird auch immer weitergegeben.


    Falls es eines Tages mal soweit sein sollte, dass ein 64-Bit Client zur Verfügung steht, dann werden wir euch dies natürlich nicht vorenthalten.


    Bis dahin seht bitte davon ab, andere 64-Bit Clients zu nutzen, so nervig Krits und vieles mehr sind.

    Diese Clients sind alles andere als 'legal' bzw. 'genehmigt'.

    P-Server sind ebenfalls nicht 'legal' oder 'genehmigt' und man spielt mit seinen Daten (hier: Datenschutz).



    Im übrigen sind die Serverwartungen ja schon beendet. Dann mache ich den Thread hier auch mal zu :D


    - Geschlossen -

  • Zhirelia

    Closed the thread.