Im Source Code
game/Belt_inventory_helper.h?
Im Source Code
game/Belt_inventory_helper.h?
belt_inventory_helper.h
static bool CanMoveIntoBeltInventory(LPITEM item)
{
bool canMove = false;
if (item->GetType() == ITEM_USE)
{
switch (item->GetSubType())
{
case USE_POTION:
case USE_POTION_NODELAY:
case USE_ABILITY_UP:
canMove = true;
break;
}
}
return canMove;
}
Ändern dann sollte das klappen.
du kannst auch als CASE die Item Vnum nutzen um zu vermeiden das Andere Items die da nix zu Suchen haben solln nicht verschoben werden können.
Thank you it works!
Please set the state from this thread on finish.
Change the Filename into the critical.mse
Suchen 148
Von dem Header das Packet suchen und vergleichen
Mehr ist das nicht.
Temp.txt im Verzeichnis der EXE anlegen da du kein Pfad hast im error log wird das normale Verzeichnis gemeint sein.
Er meint alle Steine in Rot etc einfach Paint.net/Gip Laden und selbst hand anlegen fertig sind vlt 5 min
Proble ist das man Memory fehler schlecht einschätzen kann deswegen bin ich einfach noch durch gegangen, aber alles erachtens kommt wohl die Game nicht mit der ItemAttr klar weil wie gesagt sie löst backtrace die loop etc aus daher schließe ich darauf das du ein fehler hast in der Tabbele Nicht DB seitig sondern eher Game seitig weil wenn du sagst andere Game läuft und die Nicht und beides die Selbe Datenbank nutzen würde ich sagen "TItemAttrTable" ist futsch in der Source vlt compailt sie aber löst erst beim Abrufen etc die fehler aus leider gottes ist das öfters mal, es kann aber auch sein das die Source nicht die Count nutz sondern fest defenierte Namen für Bonis so wie es die gmlist bei GM Class und dragon_soul_table bei Bonis wieder rum.
Also Laut fehler
input_db Load MAX_HP
gibt über an Analyze (First size Out) das gibt weiter an Process (Denke mal DG_HEADER) der geht an die ProcessInput der Main die geht weiter in idle wo dr io_loop schon passiert und ausschlags Punkt wird die attr Tabelle genommen.
Lösch doch mal die Quest aus der quest_list und versuchs nochmal?
Weil deine Quest callt wohl irgendwo was nirgends bekannt ist
#7 0x0827e4b1 in main (argc=1, argv=Cannot access memory at address 0x5
Da geht was in die Main.cpp rein aber diese kann es dann wieder rum nicht verarbeiten weil da nen Stück Code fehlt was da fehlt ka aber der Input läuft nicht Sauber.
Das kannste knicken, das lässt der Client nicht mehr zu wozu wohl damals die mc.exe ? weil die exe mit argumente startete das klappt heute nicht mehr Hamashi kannst nur noch local nutzen .
Weil der Client stark Aufgeräumt werden da es der alte Arkosia2 Client ist damals gepup von Ocelett mitlerweile schwer zu finden für leute die gerne etwas mehr Zeit Investieren wollen und evt den ein oder anderen Bug kennen lernen wollen um zu lernen wie man den Fixt ist der Test Client mit der Binary Version 1.0.28249.0 eine angebrachte Lösung, meiner Meinung nach weil ich damals mit den Selben Client alles neu aufgebaut habe aus faulheit den ganzen alten python mist anzupassen wo ich heute sage sind auch nur 10-20 Minuten mehr aufwand
Lesen Bildet, so der fehler schreit er nach falschen Login Daten für die cores ganz neben bei aber pscht kam nicht von mir
Was wenn es ein lib braucht, was für 2.2 geschrieben ist und das lib aber was er hat 2.7 ist? Oder gehen 2.2 libs auch auf 2.7?
Warte nen Moment ich werde hier die py Libs Posten nicht die pyc muss nur wieder 7zip bla und bla machen
@Update Libs sind nun da Ps ne rar inner Zip
Das Problem hatte ich auch damals bei einem Loginterface, was für Python 2.2 gecodet wurde. Entweder source vom Interface updaten oder andere Interface nehmen
Weder noch. Wenn es einfach Richtig geschrieben ist Funktonier 2.2 auch auf 2.7 kann hier gerne nen 2.2 Script rein werfen was auch 2.7 läuft, aber wie schon erwähnt Libs machen viel aus.
Fehlende Libarys für den Client? Eventuell die Py2.2 Libs gelösht, weil Du geupdatet hast? Klingt für mich danach
Oder falsche Libs meine Stammen auch aus 2.2 sind aber gegenseatzt zu anderen Libs alles .py und werden Auto vom Client conventiert damit .
Hmmm mal Logisch denken..
Soweit ich weiss stammt das Interface aus Zeiten wo die 34k Game noch was war und der Client nichtmal Python 2.7 kannte, Ich habe auch keine Ahnung woher ihr die Python2.7 Lib Traces ausgrabt.
Ich vermute so ein bisschen doll das der Code irgendwo ne Stelle haben wird wo er nicht mehr mit Python 2.7 Funktoniert, ScreW&Ich habe vor längerer Zeit Files gepupt wo du ein Login Interface findest was erfolgreich von eine 34k Game Client auf die Neue rev exportiert wurde da unter sind auch paar fixes bei weil die PAEX schon nervige Login lücken dicht macht wo durch diese ebenfalls in der Intrologin enthalten sind weil ich sonst nie den Client starten hätte können (Script Seitig) Ich werde denke mal gleich das Login Interface seperat Puplic mach mit dazugehöriger PSD.
Ich möchte an der Stelle auch abraten von dem Interface weil es A die Logininfo.py Lücke zu lässt und B. Für leute ohne das nötige Wissen nur Probleme bereitet.
Ich habe es aus und bei mir wird der Name des Spielers angezeigt
Bitte melden Sie sich an, um dieses Bild zu sehen.
Okay also ist das System sich da manchmal nicht einig so wie es wirkt weil bei nen Kollegen klappt das mit Define
Irgendwie wirkt es Laut code so als wäre das define da um den DB namen zu Hiden eher weil if ohne darauf folgende aussage wäre doch eher Sinn frei finde ich jetzt, kann auch sein das ich was Falsch ein ordne ich werde mal selbst in den Offlineshop da rein gucken was das ist.
So habe mir jetzt mal angeschaut und Jemanden gefragt der den Shop nutz bei sind Spieler Namen da und er hat den define an.