What makes Celino so stable?

[JessVanity]

Okay so I don't know if this is.the right place to discuss this but what makes celino so stable versus other Odin based sources.

I know that celino uses switch statements in its packet processor, while other Odin based sources do not. Although I don't think it really makes a difference by using either or.

Celino uses safe-threading in player storage, maple map and for characters. It also has character transfer between channels, which reduces database load and speeds up the process of changing channels. While other Odin based sources does not.

Celino loads xml data during startup while other odinms sources don't.

So my question is are these the main factors that make Celino so stable, and the main differences between older Odin based sources? Maybe the way he wrote MapleMap?

I don't know if this would be a help thread or not, but yeah discuss, I guess?

 

[SuperLol]

No, the switch statements make it slower. I discussed this earlier in a previous thread. The odinms way is actually the fastest (as also discussed by Retep988 in the thread).
Safe-threading obviously is slower than non-threadsafe code. The way they do it is copying everything into a new list and iterating it (slower). This prevents concurrentmodificationexception, even though it's actually a bad way of doing it.
Celino's character transfer between channels actually should help a bit.
XML data during startup does nothing. If anything it makes the cache larger, which uses more memory.
There's a few other questionable things done by Celino that aren't actually good practices of programming either that don't appear in odinms. It also has some of the memory leaks that were added in by odinteh, and some odinms issues.

Celino does do spawn points a little better from what I've seen and I'm not sure maps are better, but it does seem that way. There's a few other optimizations that don't exist in odinms, but the stuff you listed is mostly actually the bad parts. I saw in another thread someone that said it was a vana copy, but that's also not true even though Celino tried to use some C constructs such as struct (very strange in Java). The RMI Removal is actually decently done and should help a little bit.

NemesisToKill has achieved more stability than I have and back when I ran MoongraMS we used 300 MB ram after weeks too for channels (which people didn't even believe) -- we allotted 8 GB for JVM so it wasn't because we only allotted 300MB. The reason it was up for weeks was due to the fact that I was getting tired of coding and got too lazy to update anything so I just left the server on for long periods of time
Server stability is achievable for anyone if they spent the time looking for memory leaks. NemesisToKill also has a guide for memory leaks somewhere but I'm not sure if it's on ragezone or not.

 

[Fraysa]

Okay so I don't know if this is.the right place to discuss this but what makes celino so stable versus other Odin based sources.

I know that celino uses switch statements in its packet processor, while other Odin based sources do not. Although I don't think it really makes a difference by using either or.

Celino uses safe-threading in player storage, maple map and for characters. It also has character transfer between channels, which reduces database load and speeds up the process of changing channels. While other Odin based sources does not.

Celino loads xml data during startup while other odinms sources don't.

So my question is are these the main factors that make Celino so stable, and the main differences between older Odin based sources? Maybe the way he wrote MapleMap?

I don't know if this would be a help thread or not, but yeah discuss, I guess?

Who said Celino what was stable? Any proof for it? I

1. Character transfer between channels... if database loading is done right, changing channels and reloading the character shouldn't be that slow. In my source, it doesn't delay anything at all, frankly. I'd rather not mess with interoperability packets just for reconstructing the character.
2. I'm pretty sure all Odin-based repacks are loading data during start up. This isn't a factor for a "good source", though. Sure, less data is loaded and cached - but still.

 

[SuperLol]

Who said Celino what was stable? Any proof for it? I

1. Character transfer between channels... if database loading is done right, changing channels and reloading the character shouldn't be that slow. In my source, it doesn't delay anything at all, frankly.
2. I'm pretty sure all Odin-based repacks are loading data during start up. This isn't a factor for a "good source", though.

It doesn't delay anything for me either, but if you think about it it should be faster by just sending over a byte stream. It's faster, but not really enough to talk about.

 

[Fraysa]

It doesn't delay anything for me either, but if you think about it it should be faster by just sending over a byte stream. It's faster, but not really enough to talk about.

I added up to my last reply. Yes, a byte stream would be faster but I think it's a matter of implementing interoperability character construction packet handling (if your server is split-up) to save up a couple of miliseconds. Also, SuperLol, Can I get exact details about that 300 MB RAM usage? I want to test the same on my files in the same period of time. I need to know how many game servers were hosted, etcetera. Please send me a Private Message, thank you.

 

[JessVanity]

Okay, so I did some testing, by spawning 2000 snails, in a v117 source, although my bat was being spammed with monster-movement packets, I encountered no lag, or a fps drop. On the other hand when I tried it on v62 source, there was a huge fps drop and tons of lag. The CPU usage and mem usage was about the same for both sources. I discussed this on the Vana IRC as well, and I was told it's because the client itself is bad, and nothing to due with the source code. Is this true?

I mean if alot of code done in celino is a bad way of doing it, why don't older sources last longer and hold more players. Also Celino doesn't use the class MaplePacket in there packet handlers, they use byte[] instead, they finalize almost everything as well, could this be a factor as well?

 

[Fraysa]

Spawning a huge amount of mobs has nothing to do with the server (well, expect for packet handling and how effectively it's done) but how the client renders it itself.

 

[SuperLol]

Finalize and final are completely different. Final only does stuff if it's a local variable and even then I believe the Java optimizes it anyway if you don't make it final as a local variable. Having methods and classes final is largely useless. Finalize is a method in Object that is called when the object goes out of scope (when garbage collector comes). For example in the finalize method for ResultSet, it closes the result set if it's open. I don't really think the MaplePacket does anything. Yes, calling another method to return an object instead of just returning the object makes it like 200 microseconds from slower from what I've read than not calling one, but that makes zero difference to a human.

Older Sources have more memory leaks. Celino doesn't get every leak and some code may be done worse, but it at least fixes some memory leaks that were present in odinms (actually the odinteh/valhalla... odinms v55 was actually generally fine). For the client thing, that's probably true too. The older clients aren't also meant to be compatible with windows 7+. I'm not sure why you were spammed with monster movement packets though... that means your monster movement is messed up hard.

 

[JessVanity]

I forgot to point out that I was logging packets, so that's why It was spamming them but made no difference. Also Celino uses iterator for map objects, instead of the for loop. Celino also has a separated cashshop sever.

Bui tried the same thing on Vana v75, and there was a good amount of lag as well.

 

[kevintjuh93]

Finalize and final are completely different. Final only does stuff if it's a local variable and even then I believe the Java optimizes it anyway if you don't make it final as a local variable. Having methods and classes final is largely useless. Finalize is a method in Object that is called when the object goes out of scope (when garbage collector comes). For example in the finalize method for ResultSet, it closes the result set if it's open. I don't really think the MaplePacket does anything. Yes, calling another method to return an object instead of just returning the object makes it like 200 microseconds from slower from what I've read than not calling one, but that makes zero difference to a human.

Older Sources have more memory leaks. Celino doesn't get every leak and some code may be done worse, but it at least fixes some memory leaks that were present in odinms (actually the odinteh/valhalla... odinms v55 was actually generally fine). For the client thing, that's probably true too. The older clients aren't also meant to be compatible with windows 7+. I'm not sure why you were spammed with monster movement packets though... that means your monster movement is messed up hard.

final on classes only means it cannot be subclassed. Same for final methods, it means it cannot be overriden by subclasses. Hooray for java class. Never thought I would learn some 'thing'.
JessVanity, there is zero to almost no difference between a loop and an iterator if it comes to performance. Only difference is in capability.

 

[SuperLol]

final on classes only means it cannot be subclassed. Same for final methods, it means it cannot be overriden by subclasses. Hooray for java class. Never thought I would learn some 'thing'.
JessVanity, there is zero to almost no difference between a loop and an iterator if it comes to performance. Only difference is in capability.

Yeah I've been trying to tell everyone here that final in class definition and methods do nothing to help performance. Actually this is the only coding community I've been to that completely thinks that it helps (so much that they laugh at it when I post this)

Also iterator and for loop is different. Only for each is the same as iterator. The other loops aren't:

You must be registered to see links

Also you have to know if you are iterating through what type of list. It is known that if you want to iterate a lot, use a linked list (this is due to the structure of how they are implemented)

 

[kevintjuh93]

Yeah I've been trying to tell everyone here that final in class definition and methods do nothing to help performance. Actually this is the only coding community I've been to that completely thinks that it helps (so much that they laugh at it when I post this)

Also iterator and for loop is different. Only for each is the same as iterator. The other loops aren't:

You must be registered to see links

Also you have to know if you are iterating through what type of list. It is known that if you want to iterate a lot, use a linked list (this is due to the structure of how they are implemented)

If I am not mistaken, if you only add items you should use an arraylist. So everything loaded on startup should be in an Arraylist. Everything else should be in a Linkedlist, because if we remove and add items the whole time a Linkedlist is way more effecient (especially when used in an Iterator), but then it still matters on what index you are removing it.

As for Maps, they should be used efficiently too. I remember when I just made a HashMap, because it was used everywhere, but it's not always efficient. Now I ask myself the question what I want to do with the map before I create the attribute.

Never thought that learning Java is actually fun by the way. I hope I can encourage people here to read tutorials, so they can work on performance and other things too.

 

[StripedCow]

Okay so I don't know if this is.the right place to discuss this but what makes celino so stable versus other Odin based sources.

I know that celino uses switch statements in its packet processor, while other Odin based sources do not. Although I don't think it really makes a difference by using either or.

Celino uses safe-threading in player storage, maple map and for characters. It also has character transfer between channels, which reduces database load and speeds up the process of changing channels. While other Odin based sources does not.

Celino loads xml data during startup while other odinms sources don't.

So my question is are these the main factors that make Celino so stable, and the main differences between older Odin based sources? Maybe the way he wrote MapleMap?

I don't know if this would be a help thread or not, but yeah discuss, I guess?

switch statements in a packet processor and you make a thread asking why it is stable? that has nothing to do with stability bro... loading poop at startup doesn't do anything either bro...

 

[NemesisToKill]

If I am not mistaken, if you only add items you should use an arraylist. So everything loaded on startup should be in an Arraylist. Everything else should be in a Linkedlist, because if we remove and add items the whole time a Linkedlist is way more effecient (especially when used in an Iterator), but then it still matters on what index you are removing it.

This isn't entirely true because there are cases where an ArrayList would be suboptimal, even when loading on startup. For example, say you want to load all items and you decide to use an ArrayList. ArrayLists grow by powers of 2 so if you assume that there are 16k items (16385 to be exact), then the array would grow to a size of 32768 but you would only be using 16385 of those spaces. That's like 64kb of wasted space along with the overhead of copying the data every time it grows.
Of course, this can be solved by knowing the size of the data beforehand and in most cases for MapleStory you wouldn't really use an ArrayList to load stuff at startup anyway, but the same resizing issues exist for HashMaps too. Once you know the implementation of Linked- structures (and why they are called that) it's pretty simple to identify which one you need.

Anyway most of the things OP listed are just minor improvements (or actually suboptimal replacements) and I don't think they contribute to the perceived stability that Celino has. I think one of the main things is LaiLai's redo of MapleMap with ReentrantLocks. Even though the difference between synchronized and ReentrantLocks isn't very big (probably not really noticeable in most situations), he redid the threadsafing and that probably fixed some of the random concurrency issues (like mobs stop spawning). Of course, when you fix memory leaks and don't have to restart the server every few hours because of some random concurrency problem, the server would look way more stable.

Loading XML data at startup really only affects how many times the server will have to read from disk (which is slow). It makes a big difference for Odin based sources though because Odin's parsing system is not very good and you will end up taking lots of memory from random parsing objects after every read existing until garbage collected. Caching at startup stops this, but it generally ends up wasting memory because there are some items/whatever that would never be cached in the first place, and now you have them sitting there forever just taking up memory. I think ideally you would want to design a Map implementation that prunes unpopular entries, so that you can load everything at startup and then automatically remove unnecessary things over time.

There are some things that are pretty good in Celino, but also bad things (like the CharacterTransfer is just so bad) and overall, I don't really like Celino. It threw away a lot of java conventions and things that would be considered good practice, like separate classes for each handler, and since every source now is based on it, it kind of created a downward spiral in terms of code quality in this section.

 

[ExtremeDevilz]

This isn't entirely true because there are cases where an ArrayList would be suboptimal, even when loading on startup. For example, say you want to load all items and you decide to use an ArrayList. ArrayLists grow by powers of 2 so if you assume that there are 16k items (16385 to be exact), then the array would grow to a size of 32768 but you would only be using 16385 of those spaces. That's like 64kb of wasted space along with the overhead of copying the data every time it grows.
Of course, this can be solved by knowing the size of the data beforehand and in most cases for MapleStory you wouldn't really use an ArrayList to load stuff at startup anyway, but the same resizing issues exist for HashMaps too. Once you know the implementation of Linked- structures (and why they are called that) it's pretty simple to identify which one you need.

Anyway most of the things OP listed are just minor improvements (or actually suboptimal replacements) and I don't think they contribute to the perceived stability that Celino has. I think one of the main things is LaiLai's redo of MapleMap with ReentrantLocks. Even though the difference between synchronized and ReentrantLocks isn't very big (probably not really noticeable in most situations), he redid the threadsafing and that probably fixed some of the random concurrency issues (like mobs stop spawning). Of course, when you fix memory leaks and don't have to restart the server every few hours because of some random concurrency problem, the server would look way more stable.

Loading XML data at startup really only affects how many times the server will have to read from disk (which is slow). It makes a big difference for Odin based sources though because Odin's parsing system is not very good and you will end up taking lots of memory from random parsing objects after every read existing until garbage collected. Caching at startup stops this, but it generally ends up wasting memory because there are some items/whatever that would never be cached in the first place, and now you have them sitting there forever just taking up memory. I think ideally you would want to design a Map implementation that prunes unpopular entries, so that you can load everything at startup and then automatically remove unnecessary things over time.

There are some things that are pretty good in Celino, but also bad things (like the CharacterTransfer is just so bad) and overall, I don't really like Celino. It threw away a lot of java conventions and things that would be considered good practice, like separate classes for each handler, and since every source now is based on it, it kind of created a downward spiral in terms of code quality in this section.

Celino was not that stable as what SuperLol have said

also it was it remove some key points of very important logs, I remember he wrote System.out.println() for everything he did and remove the the SLF4J logging also there was not a need to change the packetprocessor, odin packethandler was pretty decent done, unlike now it is pretty horrible and I don't know whose idea was it to put final keyword in basically everything

the logger class it terrible in the MapleServerHandler.. you meant no one could figure out how to log from SL4FJ ?

also there was other approach to fix the mobs stop spawning etc...

and It was me who said it was a rip of Vana, you can ask Bui that most of struct was a pretty much a copy of Vana back in the days and a terrible conversion destroying the Odin Version

not only did Celino had memory leaks it had some serious race condition which is still in today source

the coding quality is horrible and the removing of rmi and with some wztosql made it worst

you could do what Vana is doing on passing connection if you did not like rmi
wztosql when there is a mcdb all you need to do is code a sql reading parser if you found odin parsing system horrible
the coding quality is terrible

yeah it seems they redid the client after big bang and also screwed up the game pretty bad..

well if you could write a better one it would be great or get a fork team which is still dedicated to fork odin rev988

 

[Dynamik]

Celino was not that stable as what SuperLol have said

also it was it remove some key points of very important logs,I remember he wrote System.out.println() for everything he did and remove the the SLF4J logging also there was not a need to change the packetprocessor, odin packethandler was pretty decent done, unlike now it is pretty horrible and I don't know whose idea was it to put final keyword in basically everything

the logger class it terrible in the MapleServerHandler.. you meant no one could figure out how to log from SL4FJ ?

also there was other approach to fix the mobs stop spawning etc...

and It was me who said it was a rip of Vana, you can ask Bui that most of struct was a pretty much a copy of Vana back in the days and a terrible conversion destroying the Odin Version

not only did Celino had memory leaks it had some serious race condition which is still in today source

the coding quality is horrible and the removing of rmi and with some wztosql made it worst

you could do what Vana is doing on passing connection if you did not like rmi
wztosql when there is a mcdb all you need to do is code a sql reading parser if you found odin parsing system horrible
the coding quality is terrible

yeah it seems they redid the client after big bang and also screwed up the game pretty bad..

well if you could write a better one it would be great or get a fork team which is still dedicated to fork odin rev988

What's wrong with the bolded part? There is nothing wrong with helpful println() statements for debugging.

 

[Liv3]

Celino was not that stable as what SuperLol have said

also it was it remove some key points of very important logs, I remember he wrote System.out.println() for everything he did and remove the the SLF4J logging also there was not a need to change the packetprocessor, odin packethandler was pretty decent done, unlike now it is pretty horrible and I don't know whose idea was it to put final keyword in basically everything

the logger class it terrible in the MapleServerHandler.. you meant no one could figure out how to log from SL4FJ ?

also there was other approach to fix the mobs stop spawning etc...

and It was me who said it was a rip of Vana, you can ask Bui that most of struct was a pretty much a copy of Vana back in the days and a terrible conversion destroying the Odin Version

not only did Celino had memory leaks it had some serious race condition which is still in today source

the coding quality is horrible and the removing of rmi and with some wztosql made it worst

you could do what Vana is doing on passing connection if you did not like rmi
wztosql when there is a mcdb all you need to do is code a sql reading parser if you found odin parsing system horrible
the coding quality is terrible

yeah it seems they redid the client after big bang and also screwed up the game pretty bad..

well if you could write a better one it would be great or get a fork team which is still dedicated to fork odin rev988

Writing a println statement is completely fine. It is for debugging purposes. There are times when you need to see whether a method is reached or not. Also, the MapleServerHandler class was barely even changed in comparison to the original OdinMS one. If I remember correctly. Celino also was a lot better than the sources that are publicly released with like 10000 memory leaks.

 

[jon5477]

My 2 cents, in the time Celino was made I believe it was around Java 6 (before the optimizations made in Java 7). From what I know, Lai rarely (if ever) used synchronized blocks. He usually stuck with ReentrantLocks which would have been effective under moderate contention from what I know. Synchronized blocks usually rely on the OS to suspend threads under high contention. While this is being said, I did see some major issues with some of Celino's code, particularly the swallowing of ConcurrentModificationExceptions in some places. This overall, is bad practice (no offense to the programmer) but I'm sure he's learned from his mistakes. Compared to the older sources in OdinMS, I believe he replaced most of the synchronized blocks with ReentrantLock which would be perfect under moderate to high contention. At the same time, adding more locks reduced atomicity errors in usual OdinMS sources. I'm not exactly aware if Celino ever deadlocked though.

For inter-process communications, he did use RMI which is very slow compared to other forms of IPC.

And yes, he completely removed the WZ file parsing that OdinMS threw in. The only reason why OdinMS had image parsing in their WZ parsing library was simply because they wrote several tools (one of them was a shop creator tool) which required the images inside the WZ files.

Side Note: Why do people use System.out.println() vs SLF4J for debugging/logging? I feel like the latter is much more effective when debugging since you could put in thread and class information. Moreover, everything printed to the console can be configured to be saved to a file. Yes, I know SLF4J is slower (performance and disk IO wise) compared to println. But still, easier programming and debugging is worth it, isn't it?

 

[LightPepsi1]

To sum things up... honestly.

If you're the only programmer taking care of the whole damn server, and chasing after stability, performance, and being up to date with the official server which one would you choose?
I literally coded big bang, chaos all within weeks of the official server release with real MapleSEA like NPC scripts and tutorial.

Sure you guys could nitpick over the little changes that I did, but prior to that.... what is the stability of odin really like?
Also, my question is if you're looking at the leaked celino v82 source (when I first started) or v115?


As far as I can see, Lithium source of today was based on Celino v115 which was somehow leaked when it shut down on May 2012.
(Re-written quests/ checks, anticheats, PlayerStat, DamageParse, SEA like NPC script, Professions, Potentials )
Look into Lithium and you'll know what I mean.

These are SEA exclusive content which GMS never had, and somehow it was on GMS server? lol

handling.channel.handler.FishingHandler
events/2095_tokyo
events/AufHaven
events/CoreBlaze
events/Dunas
events/Dunas2
events/WitchTower_EASY
events/WitchTower_Med
events/WitchTower_Hard
events/Nibergen

and many more

I've been away for so long that I didn't realize that until recently

This isn't entirely true because there are cases where an ArrayList would be suboptimal, even when loading on startup. For example, say you want to load all items and you decide to use an ArrayList. ArrayLists grow by powers of 2 so if you assume that there are 16k items (16385 to be exact), then the array would grow to a size of 32768 but you would only be using 16385 of those spaces. That's like 64kb of wasted space along with the overhead of copying the data every time it grows.
Of course, this can be solved by knowing the size of the data beforehand and in most cases for MapleStory you wouldn't really use an ArrayList to load stuff at startup anyway, but the same resizing issues exist for HashMaps too. Once you know the implementation of Linked- structures (and why they are called that) it's pretty simple to identify which one you need.

Anyway most of the things OP listed are just minor improvements (or actually suboptimal replacements) and I don't think they contribute to the perceived stability that Celino has. I think one of the main things is LaiLai's redo of MapleMap with ReentrantLocks. Even though the difference between synchronized and ReentrantLocks isn't very big (probably not really noticeable in most situations), he redid the threadsafing and that probably fixed some of the random concurrency issues (like mobs stop spawning). Of course, when you fix memory leaks and don't have to restart the server every few hours because of some random concurrency problem, the server would look way more stable.

Loading XML data at startup really only affects how many times the server will have to read from disk (which is slow). It makes a big difference for Odin based sources though because Odin's parsing system is not very good and you will end up taking lots of memory from random parsing objects after every read existing until garbage collected. Caching at startup stops this, but it generally ends up wasting memory because there are some items/whatever that would never be cached in the first place, and now you have them sitting there forever just taking up memory. I think ideally you would want to design a Map implementation that prunes unpopular entries, so that you can load everything at startup and then automatically remove unnecessary things over time.

There are some things that are pretty good in Celino, but also bad things (like the CharacterTransfer is just so bad) and overall, I don't really like Celino. It threw away a lot of java conventions and things that would be considered good practice, like separate classes for each handler, and since every source now is based on it, it kind of created a downward spiral in terms of code quality in this section.

I've tested looping over objects in a synchronized block versus copying. Certain parts of the codes uses copying instead, and I believe the hit in memory is insignificant relative to speed and performance in today's computing context.

As for XML data loading at startup, no. I think you've mistaken the fact that I cached everything from a custom formatted binary WZ.

It was less than 50MB actually, and within 10 seconds.

What else do you suggest aside from CharacterTransfer then?
Of course I wouldn't want to be re-loading from the SQL database after changing channels again, it was slow as hell. Eventually my aim was to move those data over to world server but I simply don't have the time for that.

Writing a println statement is completely fine. It is for debugging purposes. There are times when you need to see whether a method is reached or not. Also, the MapleServerHandler class was barely even changed in comparison to the original OdinMS one. If I remember correctly. Celino also was a lot better than the sources that are publicly released with like 10000 memory leaks.

I wrote my own logger class for things happening within the game... it was still incomplete.
System.out.prints were never useful, and never seen anyway... it was only for debugging purpose

Celino was not that stable as what SuperLol have said

also it was it remove some key points of very important logs, I remember he wrote System.out.println() for everything he did and remove the the SLF4J logging also there was not a need to change the packetprocessor, odin packethandler was pretty decent done, unlike now it is pretty horrible and I don't know whose idea was it to put final keyword in basically everything

the logger class it terrible in the MapleServerHandler.. you meant no one could figure out how to log from SL4FJ ?

also there was other approach to fix the mobs stop spawning etc...

and It was me who said it was a rip of Vana, you can ask Bui that most of struct was a pretty much a copy of Vana back in the days and a terrible conversion destroying the Odin Version

not only did Celino had memory leaks it had some serious race condition which is still in today source

the coding quality is horrible and the removing of rmi and with some wztosql made it worst

you could do what Vana is doing on passing connection if you did not like rmi
wztosql when there is a mcdb all you need to do is code a sql reading parser if you found odin parsing system horrible
the coding quality is terrible

yeah it seems they redid the client after big bang and also screwed up the game pretty bad..

well if you could write a better one it would be great or get a fork team which is still dedicated to fork odin rev988

Reflect upon yourself, what have you done at all.

 

[JessVanity]

To sum things up... honestly.

If you're the only programmer taking care of the whole damn server, and chasing after stability, performance, and being up to date with the official server which one would you choose?
I literally coded big bang, chaos all within weeks of the official server release with real MapleSEA like NPC scripts and tutorial.

Sure you guys could nitpick over the little changes that I did, but prior to that.... what is the stability of odin really like?
Also, my question is if you're looking at the leaked celino v82 source (when I first started) or v115?


As far as I can see, Lithium source of today was based on Celino v115 which was somehow leaked when it shut down on May 2012.
(Re-written quests/ checks, anticheats, PlayerStat, DamageParse, SEA like NPC script, Professions, Potentials )
Look into Lithium and you'll know what I mean.

I'm not sure if lithium is Celino v115, Before lithium the source was TetraSEA which was v1.12.4 and before that it was AuraSEA which was v1.08 or something which were all based off of your v82 source. After TetraSEA it was later converted to GMS to be v1.11 and later on updated to numerous versions 117, 144 etc. so it makes sense to see Fishing handlers and things coded for the SEA server in lithium.

It's possible that maybe things were taken from your v115 but it wasn't the base source, the v82 release you did was.

Also, to add to that, didnt you finish coding stateless npcs in v115? you started it v82 but didn't finish it. It was similar to how Vana did it from what I saw but I did mine a bit differently but i'm still wondering if there are better script engines for JS atm.

Anyway I chose to use your v82 source at the end and happy with my choice. Another quick question is that your own binary format you used was that after you released the leaked source/fork or did you always use it? Why didn't you go with SQL loading like MCDB for the most part?