Beiträge von CHXRaupy

Sieht so aus als ist in deiner Instancebase.h der Header von deiner CItemData Klasse nicht included.

Oder du hast deine CItemData Klasse umbenannt.

(Vorausgesetzt der Fehler bezieht sich auf die 2 grünen Zeilen im Screen)

Its the name of the module you created in your client source.

So its located there, not in python like your usual ui files. It probaly has a name like PythonRenderTargetModule.cpp or something like that.

In Ymir naming convention these files always have a "Module" in their filename to indicate that.

So the SetEffect Function needs to be declared in that cpp file, which seems to not be the case.

I always do a comment on the imports so the future me has to think less when it opens the file some months later

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

Junge der Server verstößt doch im übertragenden Sinne sogar gegen die Genfer Konventionen

Du findest die Funktion in char_item.cpp und char.h.

Mit dem Empire ist kein Problem, da ändert sich einfach nur der Funktionsparameter, es wird also zu:Bitte melden Sie sich an, um diesen Anhang zu sehen.

Die Funktion ::IsEmpire ist aber nicht default vorhanden, die habe ich in meinem MapManager erstellt.

Sie gibt einfach einen bool zurück ob der Mapindex eine Empire Map ist oder nicht.

Bei mir sind da auch Map2 etc drinnen, also du solltest dir auch eine Funktion erstellen die zurückgibt ob ein Mapindex eine Empire Map ist. Beispielsweise ::IsMap1Map oder was du brauchst.

Du kannst die MapIndices auch hardcoden aber früher oder später brauchst die Funktion wieder also erstell sie lieber direkt.

Als Anhaltspunkt meine:Bitte melden Sie sich an, um diesen Anhang zu sehen.

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

Der Itemfunktion ::StartDestroyEvent kannst du die Zeit in Sekunden übergeben, wann es verschwindet.

::DropItem ist die Funktion in der du es anpassen musst.

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

Falls man bei dir auch Gold droppen kann musst du es in der Funktion ::DropGold ebenfalls anpassen. (Gleiches Prinzip)

Das sieht für mich einfach danach aus, dass er alle Itemslots aktiviert und nur das System selbst oder der Einbau fehlerhaft ist. (Python oder Serversource)

Also vorausgesetzt er ist beim Gif machen mit der Maus über die Slots die nicht aktiviert sind drüber gekommen und hat sie deaktiviert, weil das deaktivieren funktioniert ja.

Wie auch immer am besten die Funktionen aus uiinventory.py wo das System eingebaut ist (speziell wo ActivateSlot aufgerufen wird) überprüfen.

Serversource sollte man ebenso schauen, ob Items die in ::ItemLoad über ::AddToCharacter hinzugefügt werden nicht vielleicht einfach immer als "is_highlight" oder wie es dort heißt gesetzt werden. Das kann auch gut sein. Weil das passiert bei jedem Login und würde zur Beschreibung passen.

Ohne Code zum drüberschauen kann man auf jeden Fall nur mutmaßen.

Also am besten erstmal uiinventory.py posten, die Refresh Funktion ist ja default relativ undurchsichtig, vielleicht ist da beim Einbau was schief gelaufen, wäre auf jeden Fall ein Anfang.

Habe gerade auf jeden Fall meinen Spaß beim Map2 farmen, also wenn mir die WÜSTENschildkröte AUF MAP2 nicht gerade 1Hit und DK gibt

Das Fiech drückt save gleich noch auf Handeln wenn es mich wieder killt

I think your click event goes to the korean sign images instead of your buttons, which is normal behavior, because you could want to have an event on your images as well.

There are window flags which you can set to your korean signs to stop that.

You can set them like this:

Bei sowas am besten immer in locale_game.txt nach der Popup Text Konstante suchen.

Das ist in dem Fall:

SELECT_CHANGE_FAILURE_STRANGE_NAME

Dann suchst du nach der Konstante in Python und verfolgst die Funktionen die sie übergeben bis zum Ursprung.

Je nach Source kann das von der Datenbank kommen, oder schon vom Game Core bevor es an die Datenbank geht, es kann aber auch direkt aus Python kommen und gar nicht erst zum Server geschickt werden also so eine Art vorsorglicher Check.

Wie es bei dir ist findest du dann heraus wenn du SELECT_CHANGE_FAILURE_STRANGE_NAME zurückverfolgst.

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

Key Error 8 bedeutet das in dem Dict die Infos für die Race fehlen, und Race 8 ist Wolfman, dann müsste auf deinem Char Slot dort ein Wolfman Character sein, aber in der Python Datei ist der nicht supported, da musst du ihn noch hinzufügen in den Dicts.

Also FACE_IMAGE_DICT_1, 2, 3 überall noch den WolfmanM mit Key 8 bzw. der Konstante und dem Path zum Image hinzufügen, damit er weiß welches Gesicht er laden muss.

und bei RACE_NAME, DESCRIPTION_FILE_NAME, und überall sonst wo es noch sein muss musst du ihn auch hinzufügen, sonst kommt dann der nächste Crash.

Zitat von Omar Moro

??

Code

1. 0729 02:15:10927 :: Traceback (most recent call last):
3. 0729 02:15:10927 :: File "networkModule.py", line 236, in SetGamePhase
5. 0729 02:15:10927 :: File "game.py", line 95, in __init__
7. 0729 02:15:10927 :: File "interfaceModule.py", line 351, in MakeInterface
9. 0729 02:15:10927 :: File "interfaceModule.py", line 245, in __MakeDialogs
11. 0729 02:15:10927 :: File "system.py", line 177, in __hybrid_import
13. 0729 02:15:10927 :: File "system.py", line 142, in _process_result
15. 0729 02:15:10927 :: File "uiDungeonInfo.py", line 12, in <module>
17. 0729 02:15:10927 :: File "system.py", line 183, in __hybrid_import
19. 0729 02:15:10927 :: ImportError
20. 0729 02:15:10927 :: :
21. 0729 02:15:10927 :: No module named renderTarget
22. 0729 02:15:10927 ::

Alles anzeigen

You need to have a compatible Render Target System implemented which module is named "renderTarget". It is needed to visualize the boss mob in those systems.

Mhh das sieht ok aus. Probier mal das zu hardcoden um auszuschließen das es an irgendwas anderem an der locale liegt.

Also

Funktioniert es dann?

Ich hab auch noch sowas im Hinterkopf das früher in default Source der locale String abgeschnitten wurde wenn es der letzte war und keine weitere freie Zeile dadrunter war. Bin mir aber nicht mehr ganz sicher, das kannst du auf jeden Fall auch mal prüfen.

Wie sieht denn der INTRO_SELECT_LEVEL String in locale_game.txt bei dir aus? Hat der evt. kein %d oder %u?

Also wenn es nach Char Relog schon direkt weg ist, ist unabhängig von der DB schon was nicht in Ordnung. (Vorrausgesetzt das ist jetzt kein Hardcore Musel System was den Wert immer direkt per Direct Query speichert wenn er geändert wird)

Wird das bei dir überhaupt gespeichert in CHARACTER::CreatePlayerProto?

Und

Wird das bei dir überhaupt auf den Player gesetzt in CHARACTER::SetPlayerProto?

Weil wenn du ausloggst, geht über CreatePlayerProto dein neuer Gaya Wert an den DB Core und in die Cache und wenn du dann direkt wieder einloggst kommt deine Gaya aus der Cache vom DB Core zum Game Core und wird in SetPlayerProto auf deinen Char gesetzt, dann geht ein Packet mit diesen Infos an deinen Client und das ist was du siehst.

Du kannst deine Stellen auch mal mit 'gold' oder 'cheque' vergleichen, wenn du beim Gaya System nur die Währung betrachtest ist es das gleiche Prinzip wie bei den Standardwährungen.

Ja mit dem Code wird mit der Funktion immer das selbe image gesetzt. Der deutsche comment verrät mir das das nicht mehr originaler ymir code ist.

Also der der das geschrieben hat wollte anscheinend kein Over Image mehr.

Vergleich das mal mit dem originalen Code, dort wird das Over Image berücksichtigt.

Hab mal die Offi interfacemodule von Brazil März 2018 angehangen.

Ohne zu wissen was du vorher geändert hast ist das immer schwer.

Aber wenn du draufklicken kannst ist das Problem wahrscheinlich nur das Over Image vom Button.

Ich würde mal testen ob er nicht vielleicht genau das selbe Image als Over Image setzt, was er auch als Default image setzt. (interfacemodule in BINARY_RecvQuest ist das denk ich bei Ymir Questsystem) (btn.SetOverVisual)

Ich hab mal aus Interesse kurz reingeschaut und einen kleinen Test gemacht, ausführlich müsstest du selbst testen, weil ich persönlich brauche das jetzt nicht

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

uimessenger.py:

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

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

Zitat von Nives

Zitat von Natsu Dragneel

Magst du deinen Code denn nicht für die Community bereitstellen?

Das ganze ist schon von Vegas auf M2Dev public.

Kenne seine Variante nicht, aber so wie ich es gemacht habe ist praktisch das von den Pics. Kann es aber nochmal als Code einbinden.

Die ConstMob::TypeXY Konstanten müsst ihr natürlich auf eure bzw. die von Ymir anpassen.

ActorInstance.h

ActorInstanceCollisionDetection.cpp

Du erstellst jedes mal wenn die Funktion aufgerufen wird (und das wird sie sehr oft) ein neues Array mit deinen hardcoded vnums, was ziemlich unnötig ist. Außerdem kannst du bei Arrays auch mittlerweile range based for loops nutzen. Und für sowas solltest du zudem eine eigene Funktion erstellen, weil man die aktuelle nach deinem ifdef Block kaum noch lesen kann.

Ich weiß ja nicht was aktuell für fancy stuff bei Actor Collision erwünscht ist aber normal reichen dafür auch die Actortypes.

Ich hab das bei mir so gemacht:Bitte melden Sie sich an, um diesen Anhang zu sehen.

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

Ich hab das bei meinem Multilanguage System so gemacht das ich die localename in den Protos immer mit dem richtigen Namen der Sprache aus dem item_names.txt überschrieben habe. So kann man einfach die schon vorhandene Spalte der Item Proto auch für Multilanguage nutzen mit der gleichen Struktur wie sie auch vor Multilanguage war. Also die item_names_??.txt für die aktuelle Sprache wird gelesen nachdem die Item Proto geladen wurde, und die Namen werden dann in die Item Table (geladene Item Proto) gemerged (überschrieben). Für Mobs ist es genauso.

Wäre noch eine entspannte Alternative, wenn ich das Problem mit dem Multilanguage System das du nutzt richtig vertanden habe.

Also die korrekten Multilanguage Namen kommen dann aus den item/mob_names.txts die Offi immer netterweise für uns bereitstellt und landen dann in der Item/MobProto, wo sie sinngemäß auch hingehören. Deshalb bedarf es dann kaum Anpassungen.

Also die Verbesserung wäre, dass du die Namen aus deiner item_desc direkt in die Proto überschreibst, damit du deinen m_strName Code nicht mehr brauchst, weil m_ItemTable.szLocaleName dann den korrekten Namen in der gewählten Sprache hat.

Aber ich würde wärmstens empfehlen die Namen einfach aus den Offi item_names zu nehmen anstatt aus der item_desc.txt, damit das mit den dummys etc auch alles noch wegfällt.

Und dafür sind die Dateien ja auch gedacht.

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