Beiträge von Cheng

    Fair-Use ist meiner Meinung nach das Stichwort. Ich hätte kein Problem damit, wenn ein Käufer das Produkt mehrmals verwendet in eigenen Projekten. Wenn er sich jetzt als "Billig-Dev" anbietet und dann bei jedem X-beliebigen Server das ganze verbaut, dann ist das schlichtweg nicht mehr fair. Es gibt hier keine klare Grenze von wegen "auf 3 Servern darf das eingebaut werden" oder so, daher kann man das nicht definieren.

    Sobald jemand anfängt bei mehr als einem Server gegen Geld das System bereitzustellen, ist es schlichtweg reselling. So wie Señor Zynko es sagte, wenn die Person aktiv einen Teamposten besetzt, wäre das wohl kein Problem. Aber die Server abklappern als "Dienstleister", welcher gekaufte Sachen dann an diese Server weiter verkauft, geht auf keinen Fall.


    Dann natürlich die Sache, geht dir Person dann aus dem Team, hat der Serverbetreiber dann anrecht auf Support beim Systemersteller? Wohl eher auch nicht.

    Wie ich sagte, wäre das in meinen Augen auch "unfair" gegenüber dem Ersteller. Besetzt 1 Person aber bspw. nacheinander oder gleichzeitig in mehr als 1 Projekt aktiv den Posten des Developers/SA, also ein fester Bestandteil des Kern-Teams, dann sehe ich kein Problem, wenn das System oder was auch immer mehrfach genutzt wird. Ist er nur kurzzeitig aktiv in dem Projekt, wäre das, aus meiner Sicht, unfair.

    Fair-Use ist meiner Meinung nach das Stichwort. Ich hätte kein Problem damit, wenn ein Käufer das Produkt mehrmals verwendet in eigenen Projekten. Wenn er sich jetzt als "Billig-Dev" anbietet und dann bei jedem X-beliebigen Server das ganze verbaut, dann ist das schlichtweg nicht mehr fair. Es gibt hier keine klare Grenze von wegen "auf 3 Servern darf das eingebaut werden" oder so, daher kann man das nicht definieren.

    Hallo,


    ich suche nach einem Fix für den Hit-Bug von Schamanen bei > ~145 Angriffsgeschwindigkeit.


    Beschreibung: Ab ca. 145 Angriffsgeschwindigkeit treffen viele Schläge von Schamanen nicht mehr.

    Bitte melden Sie sich an, um diesen Link zu sehen.


    Der Bug tritt anscheinend auch bei Ninja auf, wäre gut, wenn das gleich mit gefixt wird.


    Wenn jemand den Fix dafür verkauft, bitte per PN melden! :)


    Vielen Dank im Voraus!

    You can check DestroyItem in ItemManager. Would so Something like

    Pseudo:

    If dwId == 0:

    return

    Wouldn't fix the issue but is just a workaround.


    Your issue is not at the deletion of the item but that your item got deleted already but apparently is still in any item container related to the player where it should be removed so it gets not deleted twice when your character instance is destroyed.


    If you are unable to debug that you can easily log the callstack (e.g. using boost::stacktrace library (Bitte melden Sie sich an, um diesen Link zu sehen.)) at the point of deletion so you'll see which function is calling the delete on that very pointer first. There you have to clear the item from the player's container, too.

    Seems like you're trying to delete the item pointer although it got deleted already.

    Maybe you coded or installed a system incorrectly and it does not clear the item from the player.

    Check your changes if possible or debug it.

    In which function can be problem? Because have much changes

    Cannot tell from the backtrace as this is the backrace from a simple disconnect (logging out) where the item seems to be deleted already. I think - if my assumption is correct - it will be deleted previously somewhere else.

    Lies dir den Fehler am besten noch einmal genau durch, du findest dort alle wichtigen Informationen :D


    "unindent does not match any outer indentation level": Fehler bei der Einrückung (bspw. Mix aus Leertasten/Tabs).

    "playerSettingModule.py": Dateiname

    "line 480": Zeile 480


    Guck also am besten in deiner playerSettingModule.py in Zeile 480, dort scheint deine Einrückung nicht zu passen.

    Seems like you're trying to delete the item pointer although it got deleted already.

    Maybe you coded or installed a system incorrectly and it does not clear the item from the player.

    Check your changes if possible or debug it.

    Natürlich werden Fehler entsprechend behoben, ist doch wohl logisch. Ich bin auch problemlos dazu in der Lage, dennoch rutscht halt hin und wieder mal der ein oder andere Fehler durch, bspw. wenn man ein komplett neues System hat und dann crasht halt mal ein Core, passiert und ist auch nicht weiter tragisch, Fehler fixen und gut ist.


    Dennoch möchte ich, im Fall der Fälle, eben keinen kompletten Reboot machen sondern diesen einzelnen gecrashten Core neu starten was ja auch immer möglich war! Nur inzwischen ist mir halt mal aufgefallen, dass dies nicht mehr geht und ich würde gerne rausfinden, warum.


    Selbst wenn ich keinen einzigen Core-Crash hätte, wäre das immer noch ein Bug und Problem (vlt. möchte man auch einfach mal so einen einzelnen Core neu starten, bspw. den Single-Core wo das OX-Event drauf läuft, weil man mal eben was geändert hat, dann könnte man den doch im Live-Betrieb neu starten und dafür keinen kompletten Reboot ankündigen), denn das einzelne neu starten funktioniert nicht. Ein Core kann sich dann nicht neu starten, wenn er schon einmal gestartet war. Erst, wenn alle Cores neu starten, funktioniert das wieder und genau dieses Problem möchte ich beheben.


    Der Core-Crash war dabei nur ein Beispiel und muss gar nicht auftreten, sondern man könnte auch einfach einen einzelnen Core versuchen neu zu starten, das funktioniert nicht.

    Ja und nein, du bist so halb richtig. Im Prinzip ja, ein Core crasht ab und zu mal (man kann halt leider nicht alles testen und Bugs entstehen halt beim Coden, passiert), ich fixe natürlich sofort den Fehler, möchte aber nicht um 18 Uhr zu Hochzeiten beispielsweise den kompletten Server neu starten (auch, wenn das nur ein paar Sekunden dauert, betrifft das dann doch auf einmal alle Spieler und ist unnötig nervig). Daher möchte ich also diesen einzelnen Core neu starten, was in der Regel auch kein Problem ist, da er sich problemlos wieder einklinken und erreichbar sein sollte.


    Nun ist mein Problem aber, dass er dies eben nicht ist. Nach dem erneuten Starten des einzelnen Cores passiert eben das, was ich oben beschrieben habe und nach dem LoginSuccess Packet geht es nicht mehr weiter (aus unerfindlichen Gründen).


    Ich kann leider nicht einfach die Änderungen durchgehen, da unser Git-Log sich bereits über Jahre erstreckt und tausende von Änderungen enthält, das würde viel zu lange dauern. Daher meine Frage, ob jemand ein ähnliches Phänomen erlebt hat und was davon der Auslöser war oder ob jemand eine Idee hat, was denn dazu führen könnte? :)

    Der Core crashed entweder bei zu hoher Auslastung oder wenn etwas gewisses im Server passiert.

    Das kann jetzt noch weniger Priorität haben, wird aber mit Sicherheit zu einer Plage in Zukunft.

    Das debuggen des Cores verrät dir, wo Fehler sitzen, sobald eine game.core erschaffen wird (was nur passiert, wenn der core crashed)

    Und viel Zeit kostet das auch nicht. Ich brauche etwa 1-2min, bis mir mein gbd sagt, was nicht stimmt.

    Ich glaube auch, dass du um einen Backtrace nicht herum kommst.

    Ich kann es dir per Any auch zeigen, wie man das macht

    Ich weiß sehr wohl, wie man mit GDB debuggt und mein Problem ist nicht, die Core-Crashes zu beheben, sondern dass sich ein Core nach einem Crash nicht mehr starten lässt. :D


    Selbstverständlich fixe ich immer sofort den jeweiligen Fehler, der den Core-Crash verursacht hat, aber danach muss ich den Server neu starten, denn das einzelne Restarten eines Cores sorgt eben dafür, dass dieser nicht mehr vollständig erreichbar ist.


    Ich möchte auch nicht um den Backtrace bei GDB herum sondern um das Debuggen, denn mein Problem ist nicht der Crash, sondern nach dem Crash das Neu Starten und hier läuft der Core ja ohne Exceptions, sprich ich müsste mich mit Breakpoints durch das gesamte Networking durchdebuggen, was halt leider ewig dauern kann, weil es eben Network-Debugging ist.

    Mir ist natürlich bewusst, dass ich das mit GDB debuggen könnte, allerdings weiß ich im Prinzip ja nicht genau, nach was ich suche. Network-Debugging ist grundsätzlich sehr mühsam und möchte ich daher eigentlich vermeiden. Wobei dazu kommt, dass sich das Problem bspw. unter Windows nicht nachstellen lässt (Debugging über Visual Studio wäre wesentlich einfacher) und daher zwingend mit GDB debuggt werden müsste.


    Ich hoffe hier, dass vlt. jemand mal ein ähnliches Problem hatte und/oder spontan eine Idee hat, woran das liegen könnte, damit ich mir das sehr zeitintensive debuggen sparen kann (zumal der Fehler keine hohe Priorität hat, da ein Core-Crash max. 1 mal pro Woche auftritt, wenn überhaupt).

    Hi,


    vielleicht hatte jemand mal ein ähnliches Problem oder kann mir einen Denkanstoß geben, was die Ursache für das folgende Problem ist.


    Hin und wieder kommt es mal aus unterschiedlichsten Gründen zu einem Core, der crasht. Nun ist das Problem, dass ich dieser zwar neu starten lässt, jedoch funktioniert dieser Core dann nicht richtig. Der Fehler äußert sich darin, dass ein Einloggen (Login, Warp, usw.) auf dem jeweiligen Core unmöglich wird. Das einzige was hilft ist, den gesamten Server neu zu starten.


    Folgendes konnte ich durch die Logs herausfinden:

    - Der Core verbindet sich mit dem DB Core

    - Das Setup-Packet an den DB Core wird gesendet und verarbeitet

    - Das Setup-Packet vom DB Core an den Core wird gesendet und verarbeitet

    - P2P Setup läuft korrekt ab (jegliche Game <-> Game Kommunikation funktioniert)

    - Der Client kann sich mit dem Core verbinden und die Verbindung wird angenommen (Log: SYSTEM: new connection from ...) und der Handshake wird durchgeführt (Log: Handshake ...)

    - Der Core erhält vom Auth das LoginByKey Packet (Log: LOGIN_BY_KEY: ...)

    - Der Core sendet den Login an den DB Core, welcher diesen korrekt verarbeitet bis hin zur Antwort an den Core (Log: RESULT_LOGIN: login success ...)

    - Problem: Der Core erhält das LoginSuccess Packet nie bzw. vearbeitet es nicht


    Nun konnte ich allerdings keine Ursache finden, die eben dazu führt, dass der Core dieses LoginSuccess Packet nie erhält oder verarbeitet, hierbei benötige ich nun Hilfe.


    LG

    Just releasing a little older stuff which I used to make the life of a coder easier, when using client-quest communication. Yes, this kind of communication is still useful sometimes as doing everything via packets is sometimes not worth it.


    Usage example:



    I think, it's quite useful for those who know how to use it properly ;)

    Could literally be any related line of code, no one will be able to help you like this.


    I can try to look with notepad++ and comparing each single files with the last backup and compiling in every single editing but i'm too busy and too lazy for doing that.

    You can simply do that with related stuff, shouldn't take longer than 30 minutes.

    Hallo,


    folgender Fehler tritt bei mir seit einiger Zeit auf. Wenn mein Charakter auf einem Mount sitzt und ich mich einlogge (Login oder Teleport), passiert es oftmals, dass mein Charakter am Boden der Map startet (also Z-Koordinate = 0), da der Client aus einem mir bisher unerfindlichen Grund sagt, dass die Map noch nicht initialisiert (vmtl. geladen?) ist. Weil eben die Map noch nicht initialisiert wurde, gibt die entsprechende GetHeight Funktion 0 zurück, was letztendlich für die Z-Position des Charakters verwendet wird.


    Genauer Fehler:

    Code
    1. CMapManager::GetHeight(X, Y) - Accessing in a not initialized map

    X, Y = Koordinaten des Spielers


    Da dies nur passiert, wenn der Spieler gemountet ist, nehme ich an, dass hier etwas anders gehandhabt wird.


    Leider konnte ich im Source jedoch keinen für den Fehler verantwortlichen Code finden und möchte nun fragen, ob jemand von euch eine Idee hierzu hat oder den Fehler bereits beheben konnte.


    LG

    Meiner Meinung nach too much für so eine Funktion, macht es nur unnötig komplex das sofort nachzuvollziehen.
    Das ist nur eine "Style"-Sache, da es hier schon keinen Performance-Unterschied mehr macht, ob man das nun so oder mit einem for-loop macht.


    Das "const" stimmt, sollte eig. hin.

    Macht schon einen Unterschied auch von der Performance her wenn auch nur gering.

    Außerdem ist es weniger Code, besser lesbar und besser wartbar imo

    Dein statement würde ca. folgendem entsprechen:

    Code
    1. auto pred = [](const SHOP_ITEM& val) { return val.pkItem; };
    2. auto first = m_itemVector.cbegin();
    3. const auto last = m_itemVector.cend();
    4. if (; first != last; ++first) {
    5. if (pred(*first))
    6. return false;
    7. }
    8. return true;


    Daher macht es wahrscheinlich bei moderneren Compilern keinen Unterschied.

    Meiner Meinung nach too much für so eine Funktion, macht es nur unnötig komplex das sofort nachzuvollziehen.
    Das ist nur eine "Style"-Sache, da es hier schon keinen Performance-Unterschied mehr macht, ob man das nun so oder mit einem for-loop macht.


    Das "const" stimmt, sollte eig. hin.

    It is a little unnecessary to count how many items are still in the shop. If there is 1 item in the shop, it is not sold out.


    You could still adjust it, otherwise small, but nice.

    Hallo,


    wir suchen nach tatkräftiger Unterstützung in der Entwicklung unserer Projekte.
    Hierzu benötigen wir weitere Entwickler im Bereich der Programmierung mit C++.


    Unsere Projekte stehen in Verbindung mit Metin2, ein Vorwissen in der Materie des Spiels ist daher von Nöten.


    Wir erwarten von interessierten Entwicklern/-innen:
    - Kenntnisse über das Spiel Metin2,
    - ausgereifte Erfahrungen mit C++,
    - Erfahrungen im Umgang mit Git und FreeBSD/Windows,
    - genügend Zeit
    - und Motivation.


    Weiterhin erwarten wir Sprachkenntnisse in Deutsch/Englisch.


    Wir bieten:
    - eine feste monatliche Bezahlung (verhandelbar),
    - ein kompetentes Team,
    - ein ausgearbeitetes Konzept
    - und eine fortgeschrittene Entwicklungsumgebung.


    Unser Source ist kompatibel mit Windows (Server & Client) und FreeBSD (Server).
    Dank CMake können Projektmappen sehr einfach für alle aktuellen IDEs erstellt werden.
    Außerdem können jegliche Versionen des Entwicklungsstandes durch Git einfach verwaltet und mit anderen Team-Mitgliedern synchronisiert werden.
    Unser Team kann mehrjährige Erfahrung und Kompetenz vorweisen, vor allem im technischen Bereich.


    Weitere Details können gerne privat besprochen werden.


    Mit freundlichen Grüßen
    Cheng


    ----------------------------------------------------------------------------------------------------


    Hello,


    we are looking for active support in the development of our projects.
    For this we need further developers in the area of programming with C++.


    Our projects are related to Metin2, a previous knowledge in the matter of the game is therefore necessary.


    We expect from interested developers:
    - Knowledge about the game Metin2,
    - mature experiences with C++,
    - expierience with Git and FreeBSD/Windows,
    - sufficient time
    - and motivation.


    Furthermore, we expect language skills in German/English.


    We offer:
    - a fixed monthly payment (negotiable),
    - a competent team,
    - an elaborated gaming concept
    - and an advanced development environment.


    Our source is compatible with Windows (Server & Client) and FreeBSD (Server).
    Thanks to CMake, project solutions can be created very easily for all current IDEs.
    In addition, any version of the development stage can be easily managed by Git and synchronized with other team members.
    Our team has several years of experience and competence, especially in the technical area.


    Further details can be discussed privately.


    Yours sincerely
    Cheng