Dungeon Bug

Kurze Frage in einigen Threads wurden ja schon gefragt was die Worldcrashes bei Kalgas / Behe auslöst. Also die wenn man einfach geht.

Hat einer eine Ahnung woran das liegt ?
.lua Eintrag ist drin und die map ist auch komplett
einträge sind alles drin

Bei mir Crasht der in

Quote:

void CLinkMap::Init( int nLandWidth, int nLandHeight, int nView, int nMPU )

Darf ich dein Coreserver.ini sehen?

Bin mir nicht ganz sicher, aber bei mir lag es an der Map Größe oder am Rande des Maps waren Objekte.

Schau mit dem Map editor nach.
Bei den mittleren Grids, dürfen am Rand je 3x3 Felder keine Objekte stehen.
Kannst ja gerne mal versuchen dich an ein solchen Bereich zu teleportieren, der server bringt dich dann an die nächst gelegene Position zurück.

Quote:

Originally Posted by Sedrika Schau mit dem Map editor nach. Bei den mittleren Grids, dürfen am Rand je 3x3 Felder keine Objekte stehen. Kannst ja gerne mal versuchen dich an ein solchen Bereich zu teleportieren, der server bringt dich dann an die nächst gelegene Position zurück.

Naja der Server stürzt aber direkt ab wenn ich auf die Map gehe. Irgendwie kann der den layer nicht erstellen

Kannst ja testweise Error Meldungen einbauen und somit eingrenzen nach welchem Befehl er Bye bye sagt.

Naja ich versuch gerade was anderes
Weil es nicht bei alles Dungeons ist

Edit: Hab gerade mal etwas getestet und es Crasht wenn mehr als 48 Maps drin sind in der Coreserver.ini

Einer eine Idee wo das im Source gemacht ist?

Was sagt der Speicherverbrauch vom Worldserver?An welcher Stelle crasht er genau? Nur der Methodenname ist etwas unausreichend.

Zumal Runtimefehler nicht "im Source gemacht" sind, sondern Fehler sind, wo keine Exception richtig abgefangen wird oder ein Problem in Verbindung mit z.B. dem .NET Framework, C++ Redis, etc. auftaucht. Auch Probleme mit dem Speicher können eine Ursache sein. Deshalb ist auch vernünftiges Error-Handling das A und O in der Programmierung - Runtime Exceptions sind ziemlich nichts aussagend, da es nun mal fast alles sein kann.

Ich weiß nicht, wie man im Flyff Sourcecode mit (std:: )-Exceptions umgehen kann, aber try & catch Blöcke und damit abgefangene Exceptions können dir mehr Aufschluss über die Problemursache geben ( catch(std::runtime_error& e) {} ).

Wenn du um die genaue Crashstelle einen Try-Block machst und darunter die Exception abfängst (catch), dann solltest du mit dem e Objekt auch eine Messagebox mit der Fehlerursache ausgeben können oder sie loggen lassen ( mit std::runtime_error wäre das e.what() ).

Quote:

Originally Posted by xTwiLightx Was sagt der Speicherverbrauch vom Worldserver?An welcher Stelle crasht er genau? Nur der Methodenname ist etwas unausreichend. Zumal Runtimefehler nicht "im Source gemacht" sind, sondern Fehler sind, wo keine Exception richtig abgefangen wird oder ein Problem in Verbindung mit z.B. dem .NET Framework, C++ Redis, etc. auftaucht. Auch Probleme mit dem Speicher können eine Ursache sein. Deshalb ist auch vernünftiges Error-Handling das A und O in der Programmierung - Runtime Exceptions sind ziemlich nichts aussagend, da es nun mal fast alles sein kann. Ich weiß nicht, wie man im Flyff Sourcecode mit (std:: )-Exceptions umgehen kann, aber try & catch Blöcke und damit abgefangene Exceptions können dir mehr Aufschluss über die Problemursache geben ( catch(std::runtime_error& e) {} ). Wenn du um die genaue Crashstelle einen Try-Block machst und darunter die Exception abfängst (catch), dann solltest du mit dem e Objekt auch eine Messagebox mit der Fehlerursache ausgeben können oder sie loggen lassen ( mit std::runtime_error wäre das e.what() ).

Danke für die Hilfe. Es kommt jedoch kein Runtime Error. Ich habs soweit eigentlich gefunden nur da ich ansich von C++ absolut keine Ahnung habe, weiß ich nicht was das Problem ist.
Da soll er ja ein neue CObj Klasse erstellen und das geht scheinbar nicht bei über 48 Maps. Aber in dem Integer nCount gehen bis 21000 oder sowas.

Keine Ahnung, wie ich auf Runtime kam. :(

Mal in der Initialisierung von CObj* geschaut, wo es dort crasht?

sry das ich das hier ncohmal auskrame aber hast du nun rausgefunden woran es liegt das der worldserver crasht bei betretten des dungeon ? würde mich auf eine antwort freuen habe auch das problem

nö habs nie rausgefunden hatte nur den workaround maps rauszunehmen damit nicht so viele da sind.

Das Problem ist eher die 2GB (oder eher 1.85GB) grenze bei 32-Bit programmen. Du könntest zwar Largeadresses aktivieren um dieses limit auf 4GB anzuheben ABER ab 2GB verbrauch spinnt der WorldServer massiv, es kommt zu ghost DC's und sonstigem.

Bei uns mussten wir mega auf Performance setzen und haben so einige Systeme neu schreiben dürfen. Bei guter Leistung kommst du auf 1.16GB WS verbrauch bei 58 aktiven maps (gerade nochmal nachgesehen).

RAM unten halten durch sauberes coding und nichts stresst mehr.

Quote:

Originally Posted by Sedrika Das Problem ist eher die 2GB (oder eher 1.85GB) grenze bei 32-Bit programmen. Du könntest zwar Largeadresses aktivieren um dieses limit auf 4GB anzuheben ABER ab 2GB verbrauch spinnt der WorldServer massiv, es kommt zu ghost DC's und sonstigem. Bei uns mussten wir mega auf Performance setzen und haben so einige Systeme neu schreiben dürfen. Bei guter Leistung kommst du auf 1.16GB WS verbrauch bei 58 aktiven maps (gerade nochmal nachgesehen). RAM unten halten durch sauberes coding und nichts stresst mehr.

... oder ein wenig Mühe geben und auf 64bit umsteigen. Sollte man heutzutage sowieso :pimp:

Quote:

Originally Posted by xTwiLightx ... oder ein wenig Mühe geben und auf 64bit umsteigen. Sollte man heutzutage sowieso :pimp:

Auch eine Möglichkeit wobei ich immernoch sauberes Programmieren vorziehe.

Quote:

Originally Posted by Sedrika Auch eine Möglichkeit wobei ich immernoch sauberes Programmieren vorziehe.

Das heißt im Flyff Sourcecode 100% refactoring ( ͡° ͜ʖ ͡°)