Zuerst habe ich die icons (2stk) in den icons ordner gepackt unter Items.
Dannach habe ich bei items (da wo man den Pfad zu den icons reinschreibt) die 2 Items hinzugefügt.
Dannach habe ich die irem proto entpackt und bei Item_Name u. Item_List die 2 Items eingetragen.
Anschließend habe ich dann in Navicat in der item_proto die 2 Items erstellt.
MFG
Laufen alle cores?
Das waeren aber viele std:strings :o
Meinte nicht für jeden c string in der Game, nur bei Sachen, wie diesen.
Wie kann man die Beschreibung im Yang (einzahl/auszahl) Fenster ändern?
Da steht ProfEnte dran.
Wahrscheinlich in der Python Datei
Hab den Source gerade nicht hier aber würde beim ersten Code die prob dann nicht nur gesetzt werden, wenn das VIP System "aktiviert" ist?
Beim zweiten Code deklarierst du die neue Chance als lokale Variable im conditional scope
Einfach das int entfernen.
Außerdem könntest du einfach "success_prob += BONUS_REFINE_VIP" nutzen, da die Variable ja schon den Wert von prt->prob hat
Dann kommst du mit 8 Gb Easy hin ich denke mal Fun Pvp right ? da kannste an sich alle Maps auf ein Core Packen dann Denke mal Ox Map auf einem Game 99 Core und gut ist da kommste max mit db und auth core auf ca 8 GB Auslastung sollte lafuen falls du nicht weißt wo du hosten möchtest ich kann dir soyoustart bzw das Richtige Ovh echt ans Herz legen der Laden ist geil
8 GB reichen locker aus
Hatten 1.5k Spieler auf 8 GB RAM und es gab überhaupt keine Probleme.
Man könnte auch einfach den source umschreiben, dass std::string genutzt wird.
Ist nicht mal schwer, bei der Deklaration usw std::string nutzen, wenn es als char pointer gebraucht wird einfach die c_str Methode nehmen.
Dann hätte es oberflächlich zumindest eine dynamische Länge.
ist das nicht schon seit jahren pub?
Ist doch aber ein Bug drine oder nicht ?
wenn dann ist es einfach zu fixen
einfach an der entsprechenden stelle checken ob pc.can_warp false ist (in den letzten 10 sekunden gehandelt)
ist nur provisorisch aber so geht es halt auch ohne source
Yo, keine Ahnung, was ich als Einleitung schreiben soll.
Was ist das D-Pointer Pattern?
Das D-Pointer Pattern (auch "Pimpl Idiom" genannt) ist ein Design-Pattern für Klassen.
Vorteile
Was ist binäre Kompatibilität?
Wenn ihr die Memberattribute einer Klasse in der Header-Datei deklariert, wird diese immer wieder neu compilet, wenn ein Attribut geändert/hinzugefügt/entfernt wird (inkl. includes etc).
Das wird durch das D-Pointer Pattern "verhindert", da die Attribute nicht direkt in der Header-Datei deklariert werden.
Wie es genutzt wird
Kurze Erklärung für den Anfang:
Man forward-declared eine neue Klasse in der Header-Datei, deklariert diese in der Source-Datei, packt die eigentlichen Attribute da rein, erstellt in der Klasse einen Pointer auf die neu erstellte Klasse und greift auf die Attribute über den Pointer zu.
Diese neu erstellten Klassen heißen normaler Weise "...Data"
Wenn eure Klasse "Person" heißt, wäre der Name der D-Pointer Klasse also "PersonData".
Daher auch der Name D-Pointer Pattern - d steht für data
Nun zum praktischen Beispiel.
Dafür nutze ich einfach mal diese Klasse:
Wie ihr sehen könnt, wurden alle Attribute einfach als private Member in der Klasse deklariert.
Würde man eine davon nun ändern, würde der Compiler die ganze Header-Datei neu compilen, alle includes neu linken, etc.
Wenn man dann noch Frameworks, wie Qt, nutzt, kann das schon einen großen Zeitunterschied machen.
Der erste Schritt wäre nun die forward-declaration der Data Klasse:
Wer wissen will, was eine forward-declaration ist, sollte sich das hier durchlesen: Bitte melden Sie sich an, um diesen Link zu sehen.
Man könnte theoretisch auch eine nested-class erstellen, ist aber unnötig.
Im Source-File sollte dann die Deklaration der neuen Klasse sein:
(habe für die Attribute einfach mal standardmäßig get/set Methoden gemacht)
Im nächsten Schritt "löscht" ihr die Memberattribute aus der eigentliche Klasse und deklariert sie als public-Attribute in der Data-Klasse:
(ich habe dem Industrie-Standard befolgt und die m_ Notation entfernt)
Die Attribute müssen als public member deklariert werden, da ihr sonst nicht über einen Pointer drauf zugreifen könntet.
Als nächstes deklariert ihr einen PersonData-Pointer in der Person-Klasse:
Am Ende initialisiert ihr den PersonData-Pointer im Konstruktor, ruft die Attribute über den Pointer auf und erstellt einen Dekonstruktor um Memory Leaks zu vermeiden:
Schlusswort
Habe für die Benennung der Klassen, Attribute usw den herrschenden Standard befolgt. Im Grunde ist es eigentlich völlig egal und beeinflusst die eigentliche Methode nicht.
MfG Remix
jeder ist geldgeil
würde alles für geld machen
Hi,
hatte diesen Guide schon mal in einem amerikanischen Forum geposted, aber ich denke, dass diese Methode ziemlich nützlich sein kann.
Einleitung
Wie viele andere Versionskontrollsysteme bietet Git auch eine Methode an, um eigene Scripts bei pre-triggered actions auszuführen.
Dies wird "Hooks" genannt.
Es gibt zwei Arten von Hooks: client-side und server-side
Die trigger für die client-side Hooks sind z.B. commit, merge, push, etc
Die trigger für die server-side Hooks sind pre-receive, update und post-receive
Client-side Hooks
Die client-side hooks werden im .git/hooks Ordner gespeichert.
Wenn ein neues Repository initialisiert wird, werden einige Beispiel-Scripts erstellt, welche so genutzt oder angepasst werden können.
Die Beispiel-Scripts sind shell Scripts, jedoch könnt ihr jede ausführbare Sprache nutzen (z.B. Python oder C++).
Um die Scripts nutzen zu können, muss lediglich die file extension "sample" entfernt werden - die Namen müssen für die Erkennung erhalten bleiben.
Ein kleines Beispiel für eine commit message:
Wie es dann in der Konsole aussieht:
Bitte melden Sie sich an, um dieses Bild zu sehen.
Die Befehls-Parameter werden in den Standard-Parametern der jeweiligen Sprache gespeichert (Parameter der main-Funktionen).
Server-side Hooks
Server-side Hooks funktionieren wie Client-side Hook.
Jedoch müssen sie im Remote-Repository festgelegt werden.
Schlusswort
Falls ihr noch mehr zu diesem Thema durchlesen wollt, empfehle ich euch diesen Link: Bitte melden Sie sich an, um diesen Link zu sehen.
MfG Remix
freut mich dass es euch gefällt
Hi,
ich habe Langweile deswegen schreibe ich einfach mal diesen Guide, da viele nicht die Vorteile der Versionskontrolle kennen.
Außerdem helfe ich gerne Leuten, falls ich gerade Lust drauf habe (obwohl viele wahrscheinlich einen anderen Eindruck haben).
Wieso Versionskontrolle?
Versionskontrolle wird euer Leben leichter machen.
Stellt euch vor, ihr wollt mit mehreren am Source arbeiten. Aber wie tauscht ihr die Änderungen aus? Dateien hin und her schicken?
Ihr bearbeitet es alle auf einem Server, wobei es Probleme geben kann, wenn mehrere gleichzeitig die gleiche Datei bearbeitet?
Jemand snitcht und löscht den ganzen Source und ihr habt kein aktuelles Backup?
Ihr wollt einen Überblick darüber, was geändert wurde?
Ohne Versionskontrolle ist es fast unmöglich all diese Probleme zuverlässig zu lösen.
Versionskontrollsysteme (bzw. Git) hat keinen zentralen Dateispeicher, wodurch es sich von anderen Versionskontrollsystemen (z.B. SVN) unterscheidet.
Die Dateien werden bei jedem einzelnen Client gespeichert, im sogenannten "Repository" werden nur Änderungen gespeichert.
Das macht es auch einfach Änderungen rückgängig zu machen (z.B. wenn eine Fotze alles gelöscht hat).
Durch Git könnt ihr auch (auf Basis der normalen Dateien) in verschiedenen "Branches" arbeiten, um z.B. Features, Fixes oder sonst was einzubauen.
Dieses kleine Modell sollte es für jeden einigermaßen verdeutlichen:
Was ihr braucht
Optional könnt ihr auch Explorererweiterungen, wie z.B. TortoiseGit, installieren.
Dadurch kann man über das Kontextmenü die lokalen Repositories verwalten, ist ganz cool.
Wir hatten damals bei WoM2 immer bitbucket Repositories, glaube hat da niemanden gejuckt.
Deswegen würde ich bitbucket empfehlen.
Zum Guide
Nachdem ihr alles besorgt habt, geht es mit dem clonen los.
Dazu könnt ihr euch einen neuen Ordner erstellen. Geht in den Ordner (oder irgendeinen anderen), macht einen Rechtsklick und wählt "Git Bash here" aus.
Das Git Bash ist ein kleiner Unix Terminal Emulator, dort könnt ihr also normale Unix Befehle benutzen.
Bevor ihr etwas commiten ("Speichern" von Änderungen) könnt, müsst ihr jedoch zuerst einen Namen und eine Email für den Git log festlegen.
Dies könnt ihr mit folgendem Code machen:
Zum "clonen" (lokales Speichern eines Repositorys) benötigt ihr einen HTTPS oder SSH Link zu eurem Repository.
Github/bitbucket stellen euch diese bereit. Welchen ihr davon nutzt ist eigentlich ziemlich egal.
Git Befehle laufen immer über den Interpreter "git". Zum clonen wäre es also der Befehl "git clone <link>".
Beispiel: "git clone Bitte melden Sie sich an, um diesen Link zu sehen.".
Nachdem ihr das Repository geclont habt, werdet ihr einen neuen Ordner mit dem Namen des Repositorys sehen.
In diesem Ordner ist der Inhalt des Remote-Repositorys und die dotfiles (interne Git Dateien im ".git" Ordner)
Nun habt ihr ein neues lokales Repository erstellt und könnt euren Source reinkopieren.
Ihr könntet auch ein neues Repository in dem Source Ordner erstellen.
Dies würde jedoch mehr Erklärungen erfordern (remote origin hinzufügen, usw) und da habe ich gerade keinen Bock drauf.
Wer sich dafür interessiert kann es ja immer noch nachlesen.
Wenn ihr in einer Datei etwas geändert habt, eine Datei hinzugefügt habt, eine Datei gelöscht habt, oder was auch immer, könnt ihr den Befehl "git status" benutzen um zu sehen, welche Datei verändert wurde.
Wenn Dateien hinzugefügt wurden, müsst ihr diese erst "adden" um sie commiten zu können.
Dies geschieht mit dem "git add <datei>" Befehl.
Wenn es mehrere Dateien sind, könnt ihr alternativ auch "git add ." nutzen. Durch den "." als Parameter werden alle neuen Datei automatisch geadded.
Das könnt ihr natürlich auch nutzen, wenn es nur eine neue Datei gibt.
Wenn ihr Änderungen vorgenommen und ggf. die Dateien geadded habt, müsst ihr den "git commit" Befehl nutzen, um die Änderungen im lokalen Repository zu übernehmen.
Der commit Befehl braucht eine commit message für den Git log. Diese Nachricht könnt ihr über den -m Parameter übergeben.
Beispiel: git commit -m "test"
Um die Änderungen nun im Remote-Repository zu übernehmen müsst ihr den Befehl "git push" Befehl benutzen.
Dieser Befehl benötigt keinen standardmäßig keine Parameter, kann also einfach so genutzt werden.
Jedoch ist es wahrscheinlich, dass Git euch auffordert, euch wenigstens ein mal mit euren Github/bitbucket Anmeldedaten einzuloggen.
Nachdem ihr den push Befehl genutzt habt, können andere Leute, die Zugriff auf das Remote-Repository haben, mit dem "git pull" Befehl auf ihrem PC übernehmen.
Der pull Befehl benötigt ebenfalls standardmäßig keine Parameter und kann einfach so genutzt werden.
Für die, die sich dazu entschlossen haben, TortoiseGit zu nutzen: ihr müsst diese Befehle nicht in der Git Bash nutzen.
Ihr habt alles als Menüpunkte im Windows-Kontextmenü. Dazu einfach einen Rechtsklick auf die Ordner/Dateien machen.
Schlusswort
Keine Ahnung ob jemand von euch es nutzen wird oder sich dafür interessiert, wollte es aber wenigstens probieren, etwas Professionalität durchzusetzen.
Wenn ihr euch wirklich dafür interessiert, empfehle ich euch wenigstens den Starterguide von Github durchzugehen (Bitte melden Sie sich an, um diesen Link zu sehen.)
Dort werden euch grundlegende Befehle etc beigebracht.
Zu eurer Info: dieser Guide war nicht dazu gedacht, in-depth Git beizubringen. Viel mehr lag der Sinn darin, die Möglichkeiten/Vorteile von Git und einen kurzen Weg um Git für den Source nutzen zu können zu beschreiben.
MfG Remix
für code sharing bitte immer github benutzen!
von mir aus auch bitbucket wenn es nicht anders geht
Bitte melden Sie sich an, um dieses Bild zu sehen.
gestern nachmittag erst ne low level formatierung gemacht deswegen noch nicht so viel drauf
(bin gerade auf meinem laptop)
wow bin beeindruckt
wo warst du nur all die jahre?
nicht ganz. In der Accountdb fehlen defaults.
dann ist es nicht der komplette code
jesus maria und joseph
was ist das für ein code
$sqlServ existiert nicht
hast wohl vergessen was zu includen
int ChangeGold(long gold = 0);
sollte dann ggf angepasst werden falls die yanggrenze nicht erweitert wurde
if (false == item->IsEquipped())
if (!item->IsEquipped())
Alles anzeigenswitch (item->GetVnum())
{
case 80003: // 50k
case 80004: // 100k
case 80005: // 500k
case 80006: // 1kk
case 80007: // 2kk
int idx[5];
idx[0] = 50000;
idx[1] = 100000;
idx[2] = 500000;
idx[3] = 1000000;
idx[4] = 2000000;
int idax;
if (item->GetVnum() == 80003)
idax = 0;
if (item->GetVnum() == 80004)
idax = 1;
if (item->GetVnum() == 80005)
idax = 2;
if (item->GetVnum() == 80006)
idax = 3;
if (item->GetVnum() == 80007)
idax = 4;
long val;
val = idx[idax];
if (ChangeGold(val))
{
//ChatPacket(CHAT_TYPE_INFO, "Du hast %ld Yang erhalten.", val); // {0}
item->SetCount(item->GetCount() - 1);
}
else
{
ChatPacket(CHAT_TYPE_INFO, "Es ist ein Fehler aufgetreten. Bitte wenden sie sich an den Admin.");
}
return 1;
break;
default:
break;
}
wozu der case fallthrough wenn man dann checkt welcher wert vorhanden ist?
man könnte im case einfach die yang value setzen und dann breaken
i would create a new table/log file for the whisper log
the syslog will be very messy
