[Source] [v83] MoopleDEV | Multi Worlds | Rev 120 | Rev121 Snapshot

[Basis]

Before Big Bang, MoopleDev was known as one of the best v83 sources publicly available. Today, it still is. Saying otherwise is kind of like saying

You must be registered to see links

. It's arguably true, but there's not much point in saying it because there's no better alternative. So what... there's LocalMS, a lackluster DelphiMS, and Vana? If we're just talking GMS-like, those are the names that come to my mind. Since MoopleDev is already in a playable state, I'm sure Kevin is primarily focused on efficiency and semantics. It inevitably breaks things up front, but the end result will be better code if it were to be completed.

 

[Twdtwd]

Edit: after a cursory glance over your MapleMap, there are also threading issues there and some things that don't make sense.

There are a lot of threading issues in MapleMap (Not to mention all over the place). One of the most common issues seen on servers is invincible monsters, which is caused by how OID's are not thread safe.

The only good fix is sql related. You should add more indexes in tables and make better relations between them.

Technically the fix is SQL query related. It was as easy as the following code change in ItemFactory.

query.append("DELETE `inventoryitems`, `inventoryequipment` FROM `inventoryitems` LEFT JOIN `inventoryequipment` USING(`inventoryitemid`) WHERE `type` = ? AND `");

 

[even]

Before Big Bang, MoopleDev was known as one of the best v83 sources publicly available. Today, it still is. Saying otherwise is kind of like saying

You must be registered to see links

. It's arguably true, but there's not much point in saying it because there's no better alternative. So what... there's LocalMS, a lackluster DelphiMS, and Vana? If we're just talking GMS-like, those are the names that come to my mind. Since MoopleDev is already in a playable state, I'm sure Kevin is primarily focused on efficiency and semantics. It inevitably breaks things up front, but the end result will be better code if it were to be completed.

When you have worked with it like some of us did, you will understand our frustration. Feature-wise it is the most complete, but that source is also unstable in many ways.

 

[ALotOfPosts]

There are a lot of threading issues in MapleMap (Not to mention all over the place). One of the most common issues seen on servers is invincible monsters, which is caused by how OID's are not thread safe.



Technically the fix is SQL query related. It was as easy as the following code change in ItemFactory.

query.append("DELETE `inventoryitems`, `inventoryequipment` FROM `inventoryitems` LEFT JOIN `inventoryequipment` USING(`inventoryitemid`) WHERE `type` = ? AND `");

There's a foreign key already set up so you don't have to do that query. Just deleting from inventoryitems will be enough.

 

[MatanStyle]

moopledev is great. you guys are getting worked up over nothing. you are definitely a sjw

 

[Zygon]

Before Big Bang, MoopleDev was known as one of the best v83 sources publicly available. Today, it still is. Saying otherwise is kind of like saying

You must be registered to see links

. It's arguably true, but there's not much point in saying it because there's no better alternative. So what... there's LocalMS, a lackluster DelphiMS, and Vana? If we're just talking GMS-like, those are the names that come to my mind. Since MoopleDev is already in a playable state, I'm sure Kevin is primarily focused on efficiency and semantics. It inevitably breaks things up front, but the end result will be better code if it were to be completed.

I would disagree strongly. LocalMS v83 as a fork is far better than Moople in nearly every aspect. The only difference would be random handlers/packet updates you need to make to the source: this is literally the only thing Moople has to offer compared to Local. There's a huge difference between decent packet work (what Kevin has) and actually good code fixes/revamps (what Kevin does not have). This is even aside from the fact there's still TONS of exploits that aren't even patched in this source and various other fun things that come with exclusively with Moople.

Also, people are just too lazy to actually make better alternatives work in the long run because that's how people are in this community. I would honestly rather pick up clean v55 OdinMS or a v62 fork over this any day. It would take less than half the time to fix all of the major problems with it compared to this atrocity of a fork.

It's "playable" for your friends or yourself when you want to goof around. I would never use this as my source when running a real server since it inherently scales terribly for more than 20 people actively as well as the numerous amounts of security problems this source intrinsically has (these aren't necessarily Kevin's fault alone).

To your last two sentences, being "playable" is only one small aspect of a MapleStory private server. The concept itself is so abstract you could even argue over what constitutes playability. I mean, look at HawtMaple: their packet work is horrid yet you could consider it "playable" since you can get into game and do basic things. Furthering this, packets abstract quite a lot of what actually happens in the emulator: most of this is completely ignored or needlessly tinkered with (and sometimes removed due to lack of understanding). Kevin is a violator of the latter where he needlessly tinkers with things since he doesn't actually know what's wrong with his fork. I know this because he actually has yet to FIX anything that was wrong/problematic with his source even in the snapshot he provided.

I wonder why I even bother anymore.

 

[MatanStyle]

Thanks for the neg rep. Keep tipping the fedoras :w00t:

 

[Borlea]

Thanks for the neg rep. Keep tipping the fedoras :w00t:

I don't get why you had the need to post this comment. Moopledev is far from great. It's the bare minimum of a v83 server.

 

[Basis]

I wonder why I even bother anymore.

I think I see what you're saying. If we are to judge it against Nexon's public server that hosts thousands of players, then just about any private server is comparatively pale. I don't delve too deeply into the logistics, as I just play it for fun occasionally. If I can quest a bit, max out my character, explore the MapleWorld, and have fun with equips, then that's really all I come for. And also, the music/art style of the game is excellent. That's my measuring stick for a good source, lol. If it lets me get in game and play it accordingly, then I'm pretty excited about it. And it's awesome to invite a few friends along for the ride too.

I'm glad to see Kevin work on the project, as I am with most any private server that allows me to do the things mentioned above close to an original GMS experience. In a small player environment, it's sufficient in my opinion.

 

[RevanOn3r]

I would disagree strongly. LocalMS v83 as a fork is far better than Moople in nearly every aspect. The only difference would be random handlers/packet updates you need to make to the source: this is literally the only thing Moople has to offer compared to Local. There's a huge difference between decent packet work (what Kevin has) and actually good code fixes/revamps (what Kevin does not have). This is even aside from the fact there's still TONS of exploits that aren't even patched in this source and various other fun things that come with exclusively with Moople.

Also, people are just too lazy to actually make better alternatives work in the long run because that's how people are in this community. I would honestly rather pick up clean v55 OdinMS or a v62 fork over this any day. It would take less than half the time to fix all of the major problems with it compared to this atrocity of a fork.

It's "playable" for your friends or yourself when you want to goof around. I would never use this as my source when running a real server since it inherently scales terribly for more than 20 people actively as well as the numerous amounts of security problems this source intrinsically has (these aren't necessarily Kevin's fault alone).

To your last two sentences, being "playable" is only one small aspect of a MapleStory private server. The concept itself is so abstract you could even argue over what constitutes playability. I mean, look at HawtMaple: their packet work is horrid yet you could consider it "playable" since you can get into game and do basic things. Furthering this, packets abstract quite a lot of what actually happens in the emulator: most of this is completely ignored or needlessly tinkered with (and sometimes removed due to lack of understanding). Kevin is a violator of the latter where he needlessly tinkers with things since he doesn't actually know what's wrong with his fork. I know this because he actually has yet to FIX anything that was wrong/problematic with his source even in the snapshot he provided.

I wonder why I even bother anymore.

Yeah you kept it real alright. Kevin has been really busy with school, but I'll be sponsoring his Test Server again soon. MoopleDev is the v83 standard, and LocalMS (shootsource) isn't getting the spotlight it deserves. But when I read posts like this, I'm glad I didn't release the MoongraMS files and the development we did on it. I'm lucky I've had the opportunity to use it and learn from it, and in fact a lot of work you did with David is in there.

You still bother because you know that a few people do appreciate your work, and you have years of experience to this particular game. I appreciate the work you've done (and everyone's), and would like to thank you for it. When I feel it's "playable" (lmfao), I'd like to give you a copy, and you can see just how much of your work has been built on!

 

[ALotOfPosts]

zygon didn't even work on localms. that was just localms simon and flav who dropped local's db T________________________T

 

[Thane Krios]

Weird, when I try logging in it simply cuts the connection with a message in the console noting "error in doDecode"

 

[lucaszno]

how do I change the hp of a mob?

 

[Cygnus]

how do I change the hp of a mob?

mob.wz

 

[ExtremeDevilz]

Strongly speaking removing of RMI was not a very smart move and yes the source has some thread issue which breaks a lot of stuff, localms was good but I doubt anyone uses it cause people only care about features rather then understanding the actually game play within itself. Which can be a very fun thing to do

 

[Syre]

Strongly speaking removing of RMI was not a very smart move and yes the source has some thread issue which breaks a lot of stuff, localms was good but I doubt anyone uses it cause people only care about features rather then understanding the actually game play within itself. Which can be a very fun thing to do

RMI is completely unnecessary for the people here. Now, if a server was running multiple tens of thousands of people, 10 years ago, that would've been one thing. But with todays technology and the amount of people your average server gets...
RMI is completely unnecessary.

 

[Zygon]

RMI is completely unnecessary for the people here. Now, if a server was running multiple tens of thousands of people, 10 years ago, that would've been one thing. But with todays technology and the amount of people your average server gets...
RMI is completely unnecessary.

Ability to scale is fairly important for software such as this. The main point was that it was completely pointless to remove RMI since it really doesn't even matter whether or not you do so. There was some large, meaningless crusade against RMI back in the day that pretty much sparked this direction to be taken. Albeit that I was also a person who implemented a non-RMI communication approach, but it was not at the expense of scaling (see Valhalla Albion -> completely TCP based interop for all the servers : the RMI version is arguably better than this implementation still). The footprint (memory/CPU) generated by RMI used in Odin-based software is also fairly minimal even compared to just combining everything into one process or segregation via TCP/UDP sockets. The latency is nearly nonexistent either since nearly all private servers host all servers locally anyways.

So what's the inherent design problem, then? There is still segregation between server threads and you also lose the ability to scale across multiple JVMs by using Moople over a default OdinMS-based source. Less memory able to be assigned to the single JVM versus multiple JVMs on Windows systems (which, to be frank, is what 99% of people host their servers on) and you leave yourself with some fun competition for resources, Garbage Collection problems, and even quicker TimerManager hell.

Today's technology is still running code from over 7 years ago regardless of whether or not you're using Moople, so how exactly is that relevant? I think the only struggle to keep your server stocked with resources is due to the creation of memory leaks via the negligence of people who thinker with code unnecessarily instead of fixing actual problems.

I think the message I am trying to convey is that you immediately shoot yourself in the foot by choosing to limit your growth potential by picking a source that cannot scale for anything without at least double the work a plain Odin-based fork like Local would bring to the table.

 

[Syre]

Ability to scale is fairly important for software such as this. The main point was that it was completely pointless to remove RMI since it really doesn't even matter whether or not you do so. There was some large, meaningless crusade against RMI back in the day that pretty much sparked this direction to be taken. Albeit that I was also a person who implemented a non-RMI communication approach, but it was not at the expense of scaling (see Valhalla Albion -> completely TCP based interop for all the servers : the RMI version is arguably better than this implementation still). The footprint (memory/CPU) generated by RMI used in Odin-based software is also fairly minimal even compared to just combining everything into one process or segregation via TCP/UDP sockets. The latency is nearly nonexistent either since nearly all private servers host all servers locally anyways.

So what's the inherent design problem, then? There is still segregation between server threads and you also lose the ability to scale across multiple JVMs by using Moople over a default OdinMS-based source. Less memory able to be assigned to the single JVM versus multiple JVMs on Windows systems (which, to be frank, is what 99% of people host their servers on) and you leave yourself with some fun competition for resources, Garbage Collection problems, and even quicker TimerManager hell.

Today's technology is still running code from over 7 years ago regardless of whether or not you're using Moople, so how exactly is that relevant? I think the only struggle to keep your server stocked with resources is due to the creation of memory leaks via the negligence of people who thinker with code unnecessarily instead of fixing actual problems.

I think the message I am trying to convey is that you immediately shoot yourself in the foot by choosing to limit your growth potential by picking a source that cannot scale for anything without at least double the work a plain Odin-based fork like Local would bring to the table.

The relevance to today's technology is the fact that it is indeed stronger; and can handle bigger loads.

I don't use moople anymore; but with that said you are correct; kevin didn't do a very good job of implementing tcp/udp. It was a positive direction; just not a positive outcome.

 

[Zygon]

The relevance to today's technology is the fact that it is indeed stronger; and can handle bigger loads.

I don't use moople anymore; but with that said you are correct; kevin didn't do a very good job of implementing tcp/udp. It was a positive direction; just not a positive outcome.

I don't think it is relevant since the intentional design of this software was to be ran on a computer 7 years ago. Correct me if I am wrong, but my interpretation of what you meant as technology was "better specs for my computer" versus something like "Java language and JVM improvements."

Computer specifications are incredibly less relevant than the amount of progress Java has made as a language and the improvement of the JVM that runs the code. Even then, I emphasized in my last post that the specification aspect is only relevant in terms of the negligence of those developers who ended up creating memory leaks or long term problems due to ignorance. In these cases, more resources are needed to run the software than intended since no one can fix the web of mess Odin-based forks are. This is even ignoring the fact that Odin code is deprecated to extremes now due to Java language advancements since the software was originally built.

I think that if you isolate the major problems with Odin Rev 988 and actually fix them (primarily a better way of doing scheduling which kills sustainability not scaling), you would be fine to use that as a base source without making drastic changes to most of the other code and it would scale pretty well on a 1-2 GB RAM computer setup with like 3 channels hosting something like 200 online without crashing/latency. Odin-based servers have never really been CPU intensive either, so that isn't really a commodity that is required aside from when you desire faster throughput: this being the only thing that computer specifications over time have definitely made more noticeable; but, this doesn't impact scaling at all since CPU usage is not a tight resource for this software. So essentially both of these elements were something you could easily find in a SINGLE server computer 7 years ago. This primarily means that technological advancements the way of hardware improvements are irrelevant if your software is littered with problems propagated by basically everyone under the private server developer rainbow.

Also, the interop between the "servers" in Moople isn't even using networking. It's all hardcoded together now into one single mass of mess. I'm not sure if that was unclear in my post, but that's the issue here.

 

[ExtremeDevilz]

I don't think it is relevant since the intentional design of this software was to be ran on a computer 7 years ago. Correct me if I am wrong, but my interpretation of what you meant as technology was "better specs for my computer" versus something like "Java language and JVM improvements."

Computer specifications are incredibly less relevant than the amount of progress Java has made as a language and the improvement of the JVM that runs the code. Even then, I emphasized in my last post that the specification aspect is only relevant in terms of the negligence of those developers who ended up creating memory leaks or long term problems due to ignorance. In these cases, more resources are needed to run the software than intended since no one can fix the web of mess Odin-based forks are. This is even ignoring the fact that Odin code is deprecated to extremes now due to Java language advancements since the software was originally built.

I think that if you isolate the major problems with Odin Rev 988 and actually fix them (primarily a better way of doing scheduling which kills sustainability not scaling), you would be fine to use that as a base source without making drastic changes to most of the other code and it would scale pretty well on a 1-2 GB RAM computer setup with like 3 channels hosting something like 200 online without crashing/latency. Odin-based servers have never really been CPU intensive either, so that isn't really a commodity that is required aside from when you desire faster throughput: this being the only thing that computer specifications over time have definitely made more noticeable; but, this doesn't impact scaling at all since CPU usage is not a tight resource for this software. So essentially both of these elements were something you could easily find in a SINGLE server computer 7 years ago. This primarily means that technological advancements the way of hardware improvements are irrelevant if your software is littered with problems propagated by basically everyone under the private server developer rainbow.

Also, the interop between the "servers" in Moople isn't even using networking. It's all hardcoded together now into one single mass of mess. I'm not sure if that was unclear in my post, but that's the issue here.

I don't think people here understand how does Java works in general I take it as a new version is released the code is deprecated, Please don't forget that Odin Rev 988 was force to close down, certain things that was planned were never done. for the case of interop I don't see the reason why did this people remove RMI given that even Lithium as pretty much the same, and probably broke the whole source and made it super ugly and hard to debug. also no one here wants to even learn Java or bother how does maplestory works in general they would rather go straight length to decompile source (zakurams) and use it as long as the features are in it. how disgusting and most of the people we have known they actually did some work are long gone or have move on to something else better.

I don't see this game to be properly even emulated other then what Vana which happens to be C++, even it does it is just based on rubbish code quality