kuba90

eksartate apo tin sxoli pou tha pas. Oi klasikes sxoles pou den sxetizonte me ipologistes/pliroforiki den xriazontai dinata mixanimata. Ena word na anoigei kai eisai ok. Ego apo tin diki mou empiria stin sxoli mou , xreiastike polles fores na trekso eksomoioseis pou den mporousan na treksoun stin sxoli giati ta pc itan aparxiomena ( blepe CUDA clustering ).

O wait, now i noticed it. Why are the handlers inside the core in your pack ? Shouldnt they be in the datapack and loaded with scriptengines ?

import net.sf.l2j.gameserver.handler.voicedcommandhandlers.Record; In which universe should you ever import a handler in the core , when the core has no dependancy on the datapack ? From what i recall the handlers implement as a group an interface and are stored casted as interface in the core when reloading the handlers.

All you have to do is edit the trade request packet implementation. But beware, the client does not display the augmentation. So in the trade window, you will see the weapon without augmentation.

Well since i started my own extension on l2j, there was a plan to make it cross-chronicle. That means the extension should work on any project with a minor wrapping and interfacing. When we started today testing the compatibility we bumped into a serious problem coming out from dev stupidity. Our extension is a seperate java project that adds two-way dependancies with L2Jserver and one-way dependancies with datapack. The problem is that , each l2jserver pack ( fork ) has different package names. For example: com.l2jserver. ...... com.l2jarchid. ...... coml.l2jbrazil. ..... So i would request if possible all devs to stop changing the names of the packages. Keep it default, it will add more compatibility and will allow custom code to be migrated easier. After all what makes your pack cool is not that it has a different svn name but stability/bug fixes/performance and custom cool features. Time to get serious with the packs , right ?

1) Na mou lipei 2) Oti goustaro tha apantao giati rotas blakeies :).

giati einai oso xalia einai to diko sou pack :)

The topic is a circus. There is now way to compare two languages that are made for different things. And GC does not prevent memory leaks ...

gia na leme kai tin alithia pantos, den iparxei periptosi na agoraseis kodika kai na kaneis kai petiximeno server. Ayta ta dio den pane mazi. An deis tous megaliterous server tou l2j, oloi oi admins einai kai foberoi developers taytoxrona. Kanenas den agorazei kodika gia na kanei kalo server. Ton grafei monos tou.

Lol ? 75 ? Pos bgazoun lefta pantos kapioi re paidi mou ...

Niiiiiiiiiiiiiiiiiiiiiiiiice . :)

Bump. Από αύριο σιγά σιγά ξεκινάμε να σχεδιάζουμε features/buffers/gatekeepers ktl. Άν κάποιος θέλει να συμμετέχει, ας μου στείλει ένα PM με το καλύτερο share που έχει κάνει , ή έστω κάτι να καταλάβω οτι ξέρει τα βασικά από Java. --Το pack μας είναι ξεχωριστό Project , 100% αποδεσμευμένο από το datapack και 90% αποδεσμευμένο από τον Core. --Συνδέεται απλά με διεπαφές. Δηλαδή μία σειρά κώδικα το πολύ μέσα στον Core για κάθε feature/sub. --Είναι πλήρως reloadable, που σημένει οτι μπορείς να γράφεις κώδικα χωρίς να κάνεις restart τον server. Πριν λίγο έγραψα από το μηδέν ένα killing spree system χωρίς να κάνω ούτε ένα restart στον server. --Μπορείς να σχεδιάσεις buffers, gatekeepers, events, custom features, color systems, killing sprees, gve engines ότι θές γρήγορα χωρίς να μπερδεύετε μέσα στον Core ή στα Html του datapack. --Το pack είναι ανεξάρτητο chronicle. Δηλαδή με ένα μικρό patchaki κολάει σε Interlude, Epilogue και ότι άλλο θές. Άν έχεις server ή είσαι developer που ασχολείται με servers ( και δεν πουλάει κώδικα ! ) και μπορείς να προχωρήσεις την Java σου λίγο παραπάνω ( Reflection, Design patterns, ScriptEngines ) έλα να κάνουμε ένα καλό Highrate pack.

Parolo pou eisai xazos pou agorazeis packs apo akirous xoris na psakseis, blepo oti to paleyeis arketa. Kane me add msn na sto fix, giati ayta pou sou lene edo peri mysql einai pipes den exoun idea :) kuba90ssj@hotmail.com

sigoura 86 bit ? ego nomiza einai 85 bit .... :) Kane post screen apo ton gameserver kai ase tis malakies pou prospatheis na eksigiseis me ta logia giati den exeis idea. No screen, no help.

Hmm, the image decompression is a bit heavy isnt it ? That thing is run for every crest.

Its himself.

How many years of developing all that in off files :) ? hehehe.

Why use tortoiseSVN while you can use eclipse plugins ?

Hmm, isnt javolution already thread-safe ?

Τι λέγαμε περι συννενόησης ... Άλλα λέμε , άλλα βλέπετε ...

Μου φαίνεται άλλα λέω άλλα ακούτε. Δεν είπα να δουλέψουν στο project, είπα να μαζευτούμε 5-6 άτομα που έχουμε Server ή που τέλος πάντων κάνουμε servers και που μας συμφέρει να μοιράζουμε μεταξύ μας κώδικα για τους server μας. Εδώ μέσα υπάρχουν άτομα που γράφουν κώδικα για το server τους. Άν αυτοί γίνουν μία ομάδα, κάνουν share μεταξύ τους και όχι public share, έχουν αμέσως συμφέρον. Η τέλος πάντων στην χειρότερη περίπτωση ένα private forum section μόνο για άτομα που κάνουν share. Να μην τα βλέπουν όλοι. Τρίτον, δεν μπορούν όλοι να πάρουν ένα share και να το τροποποιήσουν και δεν υπάρχουν καλά custom shares. Προσωπικά ότι έχω στον server μου δεν το έχω δεί πουθενά shared. Τέταρτον είναι κώδικας και όχι κωδικοποίηση, καμιά σχέση το ένα με το άλλο ...

it would have been surelly better, if you had another 20 devs providing you with fixes. As someone would do if he was using epilgoue client. When you develop epilogue, you know that there are 2 major projects out there ( l2j/l2jfree) that will provide you with updates and fixes. Thats why epilogue pack is easier than interlude. In interlude, you must rely only on your own powers, and not in other projects.

Καλά αυτοί που προτείνατε C++ είστε τελείως εκτός τόπου και χρόνου. Αφου σε java είναι γραμμένο το L2J, τι θα κάνουμε θα το ξαναγράψουμε όλο από την αρχή σε C++ ? Δεν θέλει γνώσεις για να το καταλάβει κανείς αυτό , λιγη λογική χρειάζεται ... Τί μαλακίες είναι αυτές " εγω σου προτείνω C++ " ? :) Όσο για το Java vs C++ ασφαλώς και έχει καλύτερη απόδωση η C++ αφού γίνεται γλώσσα μηχανής στο compile και την διαβάζει κατευθείαν η αρχιτεκτονική του υπολογιστή. Η java τρέχει πάνω σε εικονική μηχανή που μεσολαβεί μεταξύ του κώδικα και της αρχιτεκτονικής. Αλλα η java είναι 100 φορές προτιμότερη γιατί δεν χρειάζεται διαχείρηση μνήμης, το ΝΙΟ Package έχει απίστευτη αφαίρεση στην σχεδίαση του συστήματος επικοινωνίας, και δεν χρειάζεται να ασχολείσαι ούτε με pointers. Έχει γενικά πολύ μικρότερο TTM.

Ακριβώς. Πιστεύω δεν είναι πρώτο μέλημα το να καθήσω να ψάξω γιατί δυό task lockaroun ή γιατί έχω ξεχάσει κάποιο referense και γεμίζει σιγά σιγά η μνήμη. Στον πρώτο μου server μια φορά ξέχνούσα ένα spawn σε μια δομή όταν το έκανα unspawn σε ένα event. Το βρήκα, αλλά δεν μπήκα κάν στον κόπο να το διορθώσω ... its just a memory leak of some kilobytes ... Ούτε κάν μπήκα στον κόπο να διαλέξω Garbage Collector, έδωσα λίγη παραπάνω μνήμη και καθάρισα. Επίσης ναι αν το kamaloka δεν δουλεύει σωστά δεν θα μπώ στον κόπο να το φτιάξω εκτός άν υπάρξει κάποιος ανταγωνιστής σε highrate που το έφτιαξε για τον απλό λόγο οτί είναι τέτοιο το επίπεδο των παικτών στους highrates που πιό πολύ τους αρέσουν τα killing spree και τα χρωματάκια στα ονόματα ή τα Zombie Events παρά το Kamaloka.

Έχω τρέξει server με 1000 άτομα, τα bugs ήταν τα κλασικά του L2JServer. Από τη στιγμή όμως που δεν υπάρχει ανταγωνιστής στην ζώνη highrate δεν θα έδινα και τόση σημασία σε bugs. Ίσως κάνω λάθος αλλά αυτή είναι η στρατιγική μου συνήθως. Οι highrate servers δεν έχουν την σοβαρότητα των lowrate καθώς δεν έχουν τον κατάλληλο κόσμο. Οπότε πιστεύω μπορεί να υπάρξει μια χαλαρότητα στα bugs.