[Development/Frage] FlyFF C# Source Files auf den aktuellen Stand

Quote:

Originally Posted by Wanetrain Trible-Des (DES3) wovon der 2. Key in der Config "+JlI¯Íê!" ist, für die Packete wird kein Trible Des verwendet, würde zuviel Performance ziehen.

hmm könnte sein - käme auf nen versuch an .
Symetrische Verschlüsselungen werden generell deswegen so gern genutzt weil sie halt recht schnell sind .

Kommt aber halt auf den Typ an .

Quote:

Originally Posted by Wanetrain Die Packet Liste von FlyFF wurde seit V16 auch geändert, Snapshot Packet ist 34603192, nichtmehr 0x....

Daher meine Vermutung bzw. Frage wann die Verschlüsselung eingeführt wurde, da im V15 Source keine CryptoPP Library gefunden wurde.

Quote:

Originally Posted by Wanetrain Nun zum Window Interface was du grad angesprochen hast, dir sollte klar sein dass ich dass Window Manage im Client meinte, dies sehr gut geschrieben ist.

Ja ich war halt verwirrt was der Server mit dem Window Managment im Client zu tun hat. Habe das Protol von "Pre-V15" halt nur überflogen :)

Quote:

Originally Posted by Wanetrain Die V15 Source wo Released ist hat keine Packet Verschlüsselung, nur diesen Checksum Schrott Namens CRC32, was man aber auch weg kicken kann

CRC32 ist sehr gängig - aber ich sag mal so : wir könnten es theretisch nicht wegkicken da wir keinen Source vom Client haben oder seh ich das falsch ? ;)

Dennoch mal vielen Dank..ich werd die Tage mir das mal genauer anschauen. Denke zwar das ich mitm Debugger nicht weit komme (da die Neuz.exe ja geschützt ist), aber gibt ja noch paar andere Methoden^^

Meine Vermutung ist halt nach wievor : symetrische Verschlüsselung und pro Session wird der Key generiert.
Nur wie der ausgetauscht wird und wer den Key generiert (ob Server oder Client) ist noch nicht ganz raus - da aber das initial Login Packet schon verschlüsselte Daten enthält vermute ich das der Key da mit drin sein muss ..es sei denn es gibt keine Session Keys und es gibt einfach nur "einen hardcoded Key" - ist aber sehr unwahrscheinlich ;)

Quote:

Originally Posted by Wanetrain Config Keys, völlig nutzlos. :D

8 Byte Keysize ..auch selten :)
Sind das 3 unterschiedliche Keys für unterschiedliche Dateien ?

Sourcecode haben wir von allem. Was man zum spielen braucht. Also auch Client.

Quote:

Originally Posted by nikon2k hmm könnte sein - käme auf nen versuch an . Symetrische Verschlüsselungen werden generell deswegen so gern genutzt weil sie halt recht schnell sind . Kommt aber halt auf den Typ an . Daher meine Vermutung bzw. Frage wann die Verschlüsselung eingeführt wurde, da im V15 Source keine CryptoPP Library gefunden wurde. Ja ich war halt verwirrt was der Server mit dem Window Managment im Client zu tun hat. Habe das Protol von "Pre-V15" halt nur überflogen :) CRC32 ist sehr gängig - aber ich sag mal so : wir könnten es theretisch nicht wegkicken da wir keinen Source vom Client haben oder seh ich das falsch ? ;) Dennoch mal vielen Dank..ich werd die Tage mir das mal genauer anschauen. Denke zwar das ich mitm Debugger nicht weit komme (da die Neuz.exe ja geschützt ist), aber gibt ja noch paar andere Methoden^^ Meine Vermutung ist halt nach wievor : symetrische Verschlüsselung und pro Session wird der Key generiert. Nur wie der ausgetauscht wird und wer den Key generiert (ob Server oder Client) ist noch nicht ganz raus - da aber das initial Login Packet schon verschlüsselte Daten enthält vermute ich das der Key da mit drin sein muss ..es sei denn es gibt keine Session Keys und es gibt einfach nur "einen hardcoded Key" - ist aber sehr unwahrscheinlich ;) 8 Byte Keysize ..auch selten :) Sind das 3 unterschiedliche Keys für unterschiedliche Dateien ?

TribleDes ist relativ Easy aufgebaut, 3x8 Keys, man nehme ein Text, z.b. "TEST" nun geht Trible des hin und Encrypted es mit der 1. reihe, anschließend Decrypted er es mit der 2. reihe und was dort raus kommt wird mit der 3. Encrypted, relativ einfach.

Dass Login Packet ist bereits verschlüsselt weil die Key's static in der Neuz stehen und sich somit nicht abändern.

Quote:

Originally Posted by Wanetrain TribleDes ist relativ Easy aufgebaut, 3x8 Keys, man nehme ein Text, z.b. "TEST" nun geht Trible des hin und Encrypted es mit der 1. reihe, anschließend Decrypted er es mit der 2. reihe und was dort raus kommt wird mit der 3. Encrypted, relativ einfach. Dass Login Packet ist bereits verschlüsselt weil die Key's static in der Neuz stehen und sich somit nicht abändern.

Danke :)
Ich hab da auch son Beispiel gefunden. Okay also eigentlich müssen wir erstmal an die Keys kommen - vermutlich in der neuz.exe oder neuz.dll .

Ich bin mir halt im ersten Login Packet nicht sicher gewesen obs nur verschlüsselt ist oder ob es verschlüsselt ist und die keys da ebenfalls irgendwo mitauftauchen (wenn es 3x8 keysize ist hast du ja theoretisch immer den gleichen offset ).

Quote:

Originally Posted by nikon2k Danke :) Ich hab da auch son Beispiel gefunden. Okay also eigentlich müssen wir erstmal an die Keys kommen - vermutlich in der neuz.exe oder neuz.dll . Ich bin mir halt im ersten Login Packet nicht sicher gewesen obs nur verschlüsselt ist oder ob es verschlüsselt ist und die keys da ebenfalls irgendwo mitauftauchen (wenn es 3x8 keysize ist hast du ja theoretisch immer den gleichen offset ).

NeuzD.dll ist lediglich ein MiniDumper den du Ignorieren kannst. :p

Quote:

Originally Posted by nikon2k Hallo zusammen, mich mögen noch nicht viele kennen aber dennoch bin ich in der Server Emulator Szene tätig. Unter anderem schreibe ich an einem Matrix Online Server Emulator in C#.

Hart gesagt: C# kannst du für einen Spieleserver in die Tonne treten. Da es wegen dem GC viel zu langsam wird.

Quote:

Originally Posted by nikon2k Dieser benutzt unter anderem Twofish und RSA Encryption (letzteres um diverse Daten zu signieren aber auch um den Initial Twofish Key zu verschlüsseln).

Ok am besten noch TrippleDes drüber wa^^. Währe besser einfach die Packete so zu coden das sie sicher sind.

Quote:

Originally Posted by nikon2k Ich hatte vor Jahren mal just4fun einen Caali pServer ausprobiert und finde immer noch Emulator Development besser als geleakte Offi Files (auch wenn diese wie der echte Server agieren). Der Grund bei FlyFF ist einfach:

Ich würde über Caali nichts sagen. Er hatte lediglich eine gute Resourceverwaltung. Die Server sind jedoch schlechter gecoded als die Offi Server in version 4 - 5.
Bei nachfrage kann ich gerne den Sourceteile bzw Bottleneck's posten.

Quote:

Originally Posted by nikon2k Koreaner sind schlechte Programmierer (Was man anhand des hohen Speicherbedarfs des Offi Worldservers feststellt - während Caali Files damals auf ne Uralt Kiste problemlos liefen :)).

Und wieder eine Aussage die nur von Intelligenz strotzt. Selber nicht besser Programmieren können aber erstmal die Koreaner dissen. Flyff kommt aus dem Jahr 2003, wo das Programmieren noch nicht so einfach war wie heute. Klar ist der Source an manchen stellen mies gebaut. Aber was viele vergessen: Wie viel haben die Koreaner mit diesem 'mist' eingenommen?

Außerdem warum der Worldserver so viel Arbeitsspeicher zieht liegt halt daran das er einfach nicht für kleine Home PC's programmiert wurde sonder für Server die mal eben 1k User tragen konnten. Wie viel konnte den Caali ab? achja...

Quote:

Originally Posted by nikon2k Da es nun 1000 Releases von Modifizierten offiziellen Sourcen mit Custom Content gibt, steig ich nicht mehr durch wo es denn nun einen Server gibt mit dem man einfach den offiziellen DE/EN Client nutzen kann :). Angeblich gibts basierend auf den offiziellen Sourcen auch V19 Server - aber wenn ich mir die Sourcen anschaue find ich kein CryptoPP und seit V15 wurden die Packete ja verschleiert.

Für was auch Crypto++? Crypto++ ist meiner meinung nach eh viel zu Performance lastig. Auch wenn nur geringfügig aber es ist bemerkbar.
Pakete verschleiert?

Quote:

Originally Posted by nikon2k Daher mal die Frage in den Raum : wäre noch jemand interessiert adishen Source upzugraden um auf den aktuellen Stand zu bringen ? :) Da ich im Netz nichts gefunden habe : weiss jemand aus dem Stehgreif welche Verschlüsselung nun bei FlyFF genutzt werden ? Ich hab mir ein paar Packets gesnifft...aber irgendwas passt da nicht. Entweder ist es keine richtige CBC Verschlüsselung (da die verschlüsselten Daten keine 16 Byte Blöcke groß sind) oder die nutzen ECB ohne IV.

Nein das macht keiner.

Flyff nutzt momentan XOR und AES.

Quote:

Originally Posted by xTwiLightx Die Serverfiles sind relativ OK gecodet, lediglich der Client ist völliger Mist, weil er uralten DirectX Sourcecode benutzt (DX8 glaub ich, dazu noch schlampig modifiziert) und auf VC6 Basis geblieben ist - zusätzlich die Verwendung von statischen Libs, was damals die einzige Option war, heute ist da einiges mehr rauszuholen.

1. Dll's gibts sicherlich schon seit Windows95.
2. Flyff nutzt DX8? Ja genau. Deswegen linken wir auch eine d3dx9.lib dazu.
3. Flyff stammt von dem DirectX SDK aus dem Jahre 2003 ab.

Quote:

Originally Posted by xTwiLightx Statt dich also mit der endlosen Erweiterung von Emulatoren zu beschäftigen, solltest du dir das bisschen Zeit nehmen, um den Aeonsoft Sourcecode auf aktuellen Stand zu bringen (ein "Upgrade" auf VC10 oder VC11 z.B. nimmt wenig Zeit in Anspruch), da hast du im Endeffekt viel mehr von.

Vergiss es. Es ist zu viel arbeit irgendwas am Flyff kernel zu updaten. Auf VC11 zu updaten ist hingegen kein Problem aber andere Optimierungen kannst du gleich vergessen.

Quote:

Originally Posted by xTwiLightx Die Tatsache, dass die OffiServer alle massig Probleme mit Ghost-DCs und co zu tun haben, dürfte unter anderem mit dem Pingpaket oder schlechter Verschlüsselung zu tun haben. Wissen tun wir es nicht, aber ein versifftes Pingpaket ist ein wahrscheinlicher Faktor.

Wie ich schon sagte. Das Ping Packet war kaputt.

Quote:

Originally Posted by xTwiLightx Such halt nach den 3 namensgebenden Keys. Problem ist, diese zu finden, da sie willkürlich auftauchen, wenn man sie sucht - selbst mit Diassembler ist es schwer, die ausfindig zu machen. ;) Einziger Trost: Sie tauchen nacheinander auf.

5 min mit IDA. ty.

Quote:

Originally Posted by nikon2k Ja da geb ich dir recht. Mir ist MySQL lieber - wobei Stored Procedures ja auch bei MySQL 5 zur Verfügung stehen (nur nutzt das kaum einer).

Du musst dir nur im klaren sein das du unter MySql einen enormen Performance verlust hast und das vereint mit C# kommt das nicht so besonders gut.
Auch ist die Sicherheit bei MySQL nicht so hoch.

Quote:

Originally Posted by Wanetrain NeuzD.dll ist lediglich ein MiniDumper den du Ignorieren kannst. :p

Nö die ist für den CrashStackDump.

Fatzit:
-> Es würde sich blos lohnen für ganz alte Versionen wie z.B v4 - v5 einen Emulator zu schreiben. Sonst würde sich das überhaupt nicht lohnen weil du wie gesagt gleich ein neues Projekt erstellen kannst. Bis du den Flyff Kernel wieder sauber hast vergehen Jahre und ob dann noch alles Läuft sei mal dahin gestellt.

Quote:

Originally Posted by cletite Hart gesagt: C# kannst du für einen Spieleserver in die Tonne treten. Da es wegen dem GC viel zu langsam wird.

Das kommt drauf an - ich hab mir da mal einen sehr ausführlichen Test C# vs C++ in allen möglichen Varianten und methoden durchgelesen.
In vielen Dingen ist c++ schneller und auch nicht so performance lastig.

Aber es gibt auch viele Aufgaben in denen C# ebenfalls ein guter Kandidat ist.

Einfach zu sagen "C# ist für einen Spieleserver ungeeignet" - da machst du es dir etwas zu leicht :)

Quote:

Originally Posted by cletite Ok am besten noch TrippleDes drüber wa^^. Währe besser einfach die Packete so zu coden das sie sicher sind.

Mit RSA wurden einmal signiert und der Twofish Key verschlüsselt und das in Server Bereichen die unkritisch sind (Account und Margin (Character) Server ). Der Worldserver hat nur Twofish und nutz dann den Key den der MarginServer übermittelt hat.
Twofish ist daher aber dennoch recht schnell und wenn man dann den Teil noch eine C++ Lib auslagert, gehts recht fix. Performance Probleme bzgl. der Verschlüsselung hatten wir noch nicht (und wir haben den Server vorher sogar auf Python testweise laufen gehabt ...selbst der hatte keine Performance Probleme bei der Verschlüsselung).

Quote:

Originally Posted by cletite Ich würde über Caali nichts sagen. Er hatte lediglich eine gute Resourceverwaltung. Die Server sind jedoch schlechter gecoded als die Offi Server in version 4 - 5. Bei nachfrage kann ich gerne den Sourceteile bzw Bottleneck's posten.

Caali war nicht perfekt - aber als ich das damals getestet hatte, hatte ich merkbar keinen unterschied zu den offiziellen festgestellt. Die gleichen Lags halt :D

Quote:

Originally Posted by cletite Und wieder eine Aussage die nur von Intelligenz strotzt. Selber nicht besser Programmieren können aber erstmal die Koreaner dissen. Flyff kommt aus dem Jahr 2003, wo das Programmieren noch nicht so einfach war wie heute. Klar ist der Source an manchen stellen mies gebaut. Aber was viele vergessen: Wie viel haben die Koreaner mit diesem 'mist' eingenommen?

Und dennoch waren sie zu bequem den Server einmal komplett neu zuschreiben. An zu wenig Geld kann es ja nicht gelegen haben ;)

Quote:

Originally Posted by cletite Außerdem warum der Worldserver so viel Arbeitsspeicher zieht liegt halt daran das er einfach nicht für kleine Home PC's programmiert wurde sonder für Server die mal eben 1k User tragen konnten. Wie viel konnte den Caali ab? achja...

Mit meiner uralt Kiste damals zumindest 2 :) Der aktuelle schafft nicht mal den einen vernünftig.
Ich mein ich hab das alles gestartet und allein für den Login braucht der Jahre..dann für einen Char erstellen (Button klick - ca. 5 min warten - weiter gehts), dauerts wieder länger.
Im World Server gehts dann wieder rasent schnell.

Das ist aber total unlogisch...wie kann ein Login Server so lange benötigen die Anfragen zu verarbeiten ?
Werde ich bei gelegenheit mal auf nem noch leistungsfähigerem System testen (vielleicht läuft auch was falsch).

Quote:

Originally Posted by cletite Du musst dir nur im klaren sein das du unter MySql einen enormen Performance verlust hast und das vereint mit C# kommt das nicht so besonders gut. Auch ist die Sicherheit bei MySQL nicht so hoch.

Inwiefern ? Generell ? Solange du klar trennst das statische Daten nie aus einer DB geladen werden in echtzeit und dynamische Daten periodisch (alle paar min. mal bzw. beim disconnect) in die Datenbank aktualisierst (EXP, Level, Position des Chars zum Beispiel), seh ich da wenig probleme.
Da haste dann aber auch mit jedem RDBS performance probleme.

Quote:

Originally Posted by cletite Für was auch Crypto++? Crypto++ ist meiner meinung nach eh viel zu Performance lastig. Auch wenn nur geringfügig aber es ist bemerkbar. Pakete verschleiert?

Hmm...also wie gesagt das kommt natürlich auf den Algorithmus an . Crypto++ wird in vielen MMO Servern verwendet (und damit mein ich eher sogar offiziellen). Gibt es da ne alternative in C++ ? Zumindest wären mir jetzt keine großen bekannt .

Quote:

Originally Posted by cletite Es würde sich blos lohnen für ganz alte Versionen wie z.B v4 - v5 einen Emulator zu schreiben. Sonst würde sich das überhaupt nicht lohnen weil du wie gesagt gleich ein neues Projekt erstellen kannst. Bis du den Flyff Kernel wieder sauber hast vergehen Jahre und ob dann noch alles Läuft sei mal dahin gestellt.

Ein Emulator simuliert hautpsächlich den Netzwerkverkehr . Der Emulator muss auch nicht perfekt sein. Du must erstmal nur verstehen wie das Protokol funktioniert und was sich die Entwickler dabei gedacht haben :).

Klar hast du dann noch ziemlich viele anderen Dinge wie zum Beispiel das du theoretisch natürlich auch wissen müsstest welche Areas "walk" und "flyable" sind (also bräuchstest du eine Art Map Loader) sowie das du viele Dinge berücksichtigen must in Hinsicht auf Performance , Daten Handling und und und.
Es ist natürlich keine leichte Aufgabe aber du must den Server nicht nachschreiben wie er 1:1 war sondern kannst ihn theoretisch sogar verbessern in dem du Aufgaben besser und anders löst :)
Wie gesagt - theoretisch.

Ich gebe dir recht daß der Server nie wie der offizielle funktionieren würde - dennoch ist es doch interessanter so etwas zu entwickeln .

Quote:

Originally Posted by nikon2k Das kommt drauf an - ich hab mir da mal einen sehr ausführlichen Test C# vs C++ in allen möglichen Varianten und methoden durchgelesen. In vielen Dingen ist c++ schneller und auch nicht so performance lastig. Aber es gibt auch viele Aufgaben in denen C# ebenfalls ein guter Kandidat ist. Einfach zu sagen "C# ist für einen Spieleserver ungeeignet" - da machst du es dir etwas zu leicht :)

Muss ich den .net Kernel wieder zerlegen?
Leider ist es traurig das zu sagen aber das beste bsp ist einfach der MinecraftServer. Das gleiche würde in C# zwar um die 30% schneller ablaufen aber... bei 1 sec delay sind das dann auch NUR 300 ms weniger.

Quote:

Originally Posted by nikon2k Mit RSA wurden einmal signiert und der Twofish Key verschlüsselt und das in Server Bereichen die unkritisch sind (Account und Margin (Character) Server ). Der Worldserver hat nur Twofish und nutz dann den Key den der MarginServer übermittelt hat. Twofish ist daher aber dennoch recht schnell und wenn man dann den Teil noch eine C++ Lib auslagert, gehts recht fix. Performance Probleme bzgl. der Verschlüsselung hatten wir noch nicht (und wir haben den Server vorher sogar auf Python testweise laufen gehabt ...selbst der hatte keine Performance Probleme bei der Verschlüsselung).

Kommt jedoch auf die Anzahl der User an. Ich denke schon das es sich bemerkbar macht wenn ihr um die 1k User habt und diese pro sec einen packet stream von 15 kb/s verursachen.

Quote:

Originally Posted by nikon2k Caali war nicht perfekt - aber als ich das damals getestet hatte, hatte ich merkbar keinen unterschied zu den offiziellen festgestellt. Die gleichen Lags halt :D

Wenn du alleine spielst sollte dir da auch nichts auffalen. Wie gesagt offi wurde darauf ausgelgt mehrere User zu tragen und nicht nur ein paar.

Quote:

Originally Posted by nikon2k Und dennoch waren sie zu bequem den Server einmal komplett neu zuschreiben. An zu wenig Geld kann es ja nicht gelegen haben ;)

Warum sollten sie DIE SERVER NEUSCHREIBEN?
wenn sie:

1. Funktionsfähig sind.
2. Sie alles umsetzten konnten was sie wollten.
3. Sicherheit auch ansatzweiße gegeben ist.

auch bekommen sie konstant genug Geld sonst würden sie mal eben alle PServer schließen.

Quote:

Originally Posted by nikon2k Mit meiner uralt Kiste damals zumindest 2 :) Der aktuelle schafft nicht mal den einen vernünftig. Ich mein ich hab das alles gestartet und allein für den Login braucht der Jahre..dann für einen Char erstellen (Button klick - ca. 5 min warten - weiter gehts), dauerts wieder länger. Im World Server gehts dann wieder rasent schnell. Das ist aber total unlogisch...wie kann ein Login Server so lange benötigen die Anfragen zu verarbeiten ? Werde ich bei gelegenheit mal auf nem noch leistungsfähigerem System testen (vielleicht läuft auch was falsch).

Das liegt zum größten Teil an deinem PC. Meine Files von AncientFlyff waren so krass optimiert das lags überhaupt nicht vorhanden wahren.

Quote:

Originally Posted by nikon2k Inwiefern ? Generell ? Solange du klar trennst das statische Daten nie aus einer DB geladen werden in echtzeit und dynamische Daten periodisch (alle paar min. mal bzw. beim disconnect) in die Datenbank aktualisierst (EXP, Level, Position des Chars zum Beispiel), seh ich da wenig probleme. Da haste dann aber auch mit jedem RDBS performance probleme.

Sicher solche Firmen wie Facebook, Microsoft usw. bekommen 'performance' Probleme. Es kommt größtenteils auf die Anbindung/Verarbeitung des DatenbankServers an. Paralell - Tasks sollten dir aus C# ein geläufiger begriff sein.

Quote:

Originally Posted by nikon2k Hmm...also wie gesagt das kommt natürlich auf den Algorithmus an . Crypto++ wird in vielen MMO Servern verwendet (und damit mein ich eher sogar offiziellen). Gibt es da ne alternative in C++ ? Zumindest wären mir jetzt keine großen bekannt .

Sage ich auch nichts dagegen. NUR für meinen geschmack ist es nichts. Eine Alternative gibt es nicht. Du müsstest das wenn dann in InlineASM oder einfach in C schreiben, sprich den ganzen C++ template kram wegschmeißen.

Quote:

Originally Posted by nikon2k Ein Emulator simuliert hautpsächlich den Netzwerkverkehr . Der Emulator muss auch nicht perfekt sein. Du must erstmal nur verstehen wie das Protokol funktioniert und was sich die Entwickler dabei gedacht haben :).

Danke, dass wusste ich nicht. Schau dir dir mal Minecraft an. Da frägst du dich was die dabei gedacht haben, denn das lässt dich größtenteils nichtmal mit drogeneinfluss rechtfertigen.

Quote:

Originally Posted by nikon2k Klar hast du dann noch ziemlich viele anderen Dinge wie zum Beispiel das du theoretisch natürlich auch wissen müsstest welche Areas "walk" und "flyable" sind (also bräuchstest du eine Art Map Loader) sowie das du viele Dinge berücksichtigen must in Hinsicht auf Performance , Daten Handling und und und. Es ist natürlich keine leichte Aufgabe aber du must den Server nicht nachschreiben wie er 1:1 war sondern kannst ihn theoretisch sogar verbessern in dem du Aufgaben besser und anders löst :) Wie gesagt - theoretisch. Ich gebe dir recht daß der Server nie wie der offizielle funktionieren würde - dennoch ist es doch interessanter so etwas zu entwickeln.

Du fässt am falschen Punkt an. Warum sollte irgendeiner deinen Server nutzten, wenn dieser langsamer, instabiler als der Offizielle Server läuft?
UND wenn dann noch wichtige FUNKTIONEN fehlen... sry aber vergiss es. Schreibe lieber einen Emulator für ein anderes Spiel, welches noch keinen SCR o.ä hat. Aber dafür müsste man halt assembly können.

Quote:

Originally Posted by cletite Du fässt am falschen Punkt an. Warum sollte irgendeiner deinen Server nutzten, wenn dieser langsamer, instabiler als der Offizielle Server läuft? UND wenn dann noch wichtige FUNKTIONEN fehlen... sry aber vergiss es. Schreibe lieber einen Emulator für ein anderes Spiel, welches noch keinen SCR o.ä hat. Aber dafür müsste man halt assembly können.

Hm ich würde dir da recht geben. Aber im Prinzip gibt es ja nur v15 offi Files. Sprich : alles was dadrüber genannt wird ist ja im Prinzip auch "simuliert" (mit Client und World Server Resourcen).
Oder sehe ich das falsch ? Kann mich da auch irren - aber wie sonst sollte das gehen ? Es sei denn der Client lagert jegliche Logik in den Resourcen aus - dann haste natürlich auch alle Freiheiten. Nur kann ich mir das beim besten Willen nicht so recht vorstellen (wäre zu leicht oder nicht?).

Quote:

Originally Posted by nikon2k Hm ich würde dir da recht geben. Aber im Prinzip gibt es ja nur v15 offi Files. Sprich : alles was dadrüber genannt wird ist ja im Prinzip auch "simuliert" (mit Client und World Server Resourcen). Oder sehe ich das falsch ? Kann mich da auch irren - aber wie sonst sollte das gehen ? Es sei denn der Client lagert jegliche Logik in den Resourcen aus - dann haste natürlich auch alle Freiheiten. Nur kann ich mir das beim besten Willen nicht so recht vorstellen (wäre zu leicht oder nicht?).

Ich weiß ja nicht was du geraucht hast, aber hier gibts genügend Leute die am Source arbeiten und das Spiel selbst erweitern, lol.

Ich wär dafür du liest dir erstmal die letzten 10 Seiten im Flyff-Forum durch, bevor du weiterhin hier schreibst.

Quote:

Originally Posted by nikon2k Hm ich würde dir da recht geben. Aber im Prinzip gibt es ja nur v15 offi Files. Sprich : alles was dadrüber genannt wird ist ja im Prinzip auch "simuliert" (mit Client und World Server Resourcen). Oder sehe ich das falsch ? Kann mich da auch irren - aber wie sonst sollte das gehen ? Es sei denn der Client lagert jegliche Logik in den Resourcen aus - dann haste natürlich auch alle Freiheiten. Nur kann ich mir das beim besten Willen nicht so recht vorstellen (wäre zu leicht oder nicht?).

Tatsache ist, FlyFF bietet dir sämtliche Funktionen die du nutzen kannst, um die ganze V15 bis 19 zu Upgraden braucht man lediglich etwas Hirn, Gala Lab selbst Arbeitet nicht anders, es gibt Systeme die selbst bei pServern besser geschrieben sind als bei Offi FlyFF, Beispiel: Sleep Skill (v16) dieser wird bei den pServern mit SetDestParam ganz normal wie Stun und co zum Client gesetzt, Offi hingegen sendet ein Snapshot (erweitertes Packet..) an den Client und wenn man diese Blockiert kann man nichtmehr gesleept werden.

Es gibt noch viel mehr sachen was bei pServern teils besser ist als Offi.

Dazu ist C# bei weitem nicht so leistungsfähig wie der derzeitige FlyFF Database Server, oder schaffst du 1k+ Querys in der min? ich denke wohl eher weniger, dazu gibts bei C++ etliche erweiterrungen, mit Intel XE (TBB erweiterrung aktiv) kannst du einiges an Performance raus ziehen was wiederrum bei C# nicht der fall ist.

C# ist eine Sprache die einfach ist, für APP Entwicklungen und klein Tools, allerdings ist C++ nach wie vor die Dominante Sprache, können allerdings nicht soviele weil es nicht so einfach wie C# ist, daher lernen viele C#, der RAM Verbrauch des WorldServer's von V15 liegt bei mir Local 500 MB, alle welten geladen, dazu hat er 900 Frame, ab und zu auch nur 800, und dass auf einem Home-PC, zuzüglich holen die meisten sich ein Root mit 16G Ram, diese du mit einem WorldServer und 1.000 Usern nicht voll bekommst, heißt: who dafuq cares? einzigste was du mit C# an dem WorldServer "verbessern" kannst bzw alg. besser machen kannst wäre ( evtl!! ) ein Plugin System damit man nicht immer die Source upgraden muss (like minecraft halt..) aber sonst..seh ich keine Zukunft für ein Emulator, was bringt dir sowas wenn du sowieso kein Source vom Client hast? und wenn du dann die Source vom Client nutzt sollte man schon die Server dazu nutzen, kreuzen war noch nie wirklich gut, wenn du dies nutzt nutzen willst also ohne Neuz Source sondern mit der Offi Source: Packet Encryption, Packets ansich sniffen, fehlerfrei auslesen, zum server x leiten, ansich erstmal die Neuz von GameGuard befreihen (was beim besten willen nicht alllll zu einfach ist für ein Neuling) und so weiter, da setz dich lieber an Offi Source rann, gib dort dein wissen rein und du erhälst ein guten Boost, dass hast du viel Schneller als ein vollständigen Emulator.

2. Vorteil von Offi Files: hat Offi ein update? who cares, ich kopier eben mal die dateien, dann hab ich dass zeug selbst. :p