[Question]Most stable base source?

[xphire]

Hello, I'm looking for the most stable source out at the moment (v83+).

I'm looking for
1) Stability
2) Efficiency (No memory leaks, etc)
3) No Major bugs (Even if not all features are in the source, it doesn't crash players, server, or give a packet error)

Also a plus would be it being as close to base gms as possible so when I want to customize my server I don't have to delete a bunch of custom stuff somebody made.

Thanks for the help

Edit: Must be java (That's why I'm posting in the java section) because it will be ran on a linux system (A debian flavor to be exact)



bump?

 

[sunnyboy]

Stable? No major Bugs? I do not know of any for v83.

Efficiency? No idea also.

Close as gms as possible for v83? That would be moople, but I wouldn't be so sure about moople for the other 3 things you listed. Seems stable enough tho

 

[buttocks]

You're not going to find any source that is 100% stable. You'll have to fix and modify things in every source.

 

[Tsundere]

My suggestion is to use MoopleDEV v83. As stated above, you won't find any source that is fully stable. All public sources have issues or bugs that cause problems with it.

 

[xphire]

I don't mind missing features, just stability. Bugs vary.

Last year I played with moopledev and it had a lot of packet errors, I don't know how it is now.


And celino v82 msea is the definition of stable and efficiant. Uses barely any CPU or memory and the source I've released based off it does the same (but it's maplesea)

 

[retep998]

If you're willing to downgrade to v75 and use C++ instead of Java (C++ is cross-platform and most of linux is built on C/C++), you can get Vana which offers unprecedented efficiency, and is pretty stable and free of major bugs compared to most of the java sources. Also Vana strives to be as accurate to GMS as possible.
Source:

You must be registered to see links

Documentation:

You must be registered to see links

 

[oxysoft]

You're not going to find any source that is 100% stable. You'll have to fix and modify things in every source.

no false you are uninformed vana is the best sors 10/10 sors

My suggestion is to use MoopleDEV v83. As stated above, youu won't find any source that is fully stable. All public sources have issues or bugs that cause problems with it.

what a blast from the past to see you here

 

[Tsundere]

what a blast from the past to see you here

Same same. Glad you're doing well. Been awhile since we last talked man.

I don't mind missing features, just stability. Bugs vary.

Last year I played with moopledev and it had a lot of packet errors, I don't know how it is now.


And celino v82 msea is the definition of stable and efficiant. Uses barely any CPU or memory and the source I've released based off it does the same (but it's maplesea)

Also, I forgot to suggest LocalMS v83. That's a sound alternative if you don't like Moople. Though I'm pretty sure LocalMS has less working.

 

[xphire]

Vana is viable? That's new. Trust me I'm not a nooblord -- I'm just shocked that c++ sources actually got somewhere; but java is #juan to run servers on.

Check out v82 celino or the v92 steadymaple built on top of celino; like 10% cpu and no ram used and would have 50-100 players because of the optimization.

 

[Fraysa]

Vana is viable? That's new. Trust me I'm not a nooblord -- I'm just shocked that c++ sources actually got somewhere; but java is #juan to run servers on.

Check out v82 celino or the v92 steadymaple built on top of celino; like 10% cpu and no ram used and would have 50-100 players because of the optimization.

Well, Vana is based off TitanMS, Although other team members have completed revamped it. Currently, LazyBui has been implementing a lot of cool features as well, so you should check it out.
It's pretty easy to run/mainten using the documentation. I wouldn't suggest using Java, it's total crap. Also, a "viable source"... what exactly do you mean by that? Low CPU or RAM usage? Vana beats everyone in that aspect.

 

[Shmoconut]

I wouldn't suggest using Java, it's total crap.

...
LOL what?
Are you trying to troll, or are you actually serious?

 

[Fraysa]

...
LOL what?
Are you trying to troll, or are you actually serious?

Nah, I was just kidding. It's my personal opinion.

 

[retep998]

...
LOL what?
Are you trying to troll, or are you actually serious?

Java is a terrible language, and the JVM has rather poor performance. In Java everything (except primitives) is a boxed value and has to go through virtual interfaces. This means a massive amount of garbage collection pressure, and tons of virtual call overhead. It is a design feature of JVM that you leak all your memory into the massive space it allocates and then spends forever cleaning up after you.
Imagine a simple abstraction such as instead of passing int x and int y to a function, you now pass an IntPos object. Suddenly you're doing heap allocations everytime you work with an IntPos causing more pressure on the garbage collector (so it runs more often and takes longer), plus everything you do with the IntPos goes through virtual calls. In any decent language IntPos would be a regular by-value object that doesn't have to be heap-allocated and because it's exact type is definitely known there's no virtual call overhead.
Sure it is possible to write Java that performs reasonably and doesn't use too much memory and yes it can even be quite stable, but it still performs significantly worse than the equivalent native code. However little memory and CPU your Java server is using, a server like Vana will be using way less than that.

 

[sunnyboy]

Java is a terrible language, and the JVM has rather poor performance. In Java everything (except primitives) is a boxed value and has to go through virtual interfaces. This means a massive amount of garbage collection pressure, and tons of virtual call overhead. It is a design feature of JVM that you leak all your memory into the massive space it allocates and then spends forever cleaning up after you.
Imagine a simple abstraction such as instead of passing int x and int y to a function, you now pass an IntPos object. Suddenly you're doing heap allocations everytime you work with an IntPos causing more pressure on the garbage collector (so it runs more often and takes longer), plus everything you do with the IntPos goes through virtual calls. In any decent language IntPos would be a regular by-value object that doesn't have to be heap-allocated and because it's exact type is definitely known there's no virtual call overhead.
Sure it is possible to write Java that performs reasonably and doesn't use too much memory and yes it can even be quite stable, but it still performs significantly worse than the equivalent native code. However little memory and CPU your Java server is using, a server like Vana will be using way less than that.

make a vana setup tutorial for people jvm hater
inb4oxytalksaboutgroovy

 

[Fraysa]

make a vana setup tutorial for people jvm hater
inb4oxytalksaboutgroovy

Take a look at the

You must be registered to see links

 

[Shmoconut]

Java is a terrible language, and the JVM has rather poor performance. In Java everything (except primitives) is a boxed value and has to go through virtual interfaces. This means a massive amount of garbage collection pressure, and tons of virtual call overhead. It is a design feature of JVM that you leak all your memory into the massive space it allocates and then spends forever cleaning up after you.
Imagine a simple abstraction such as instead of passing int x and int y to a function, you now pass an IntPos object. Suddenly you're doing heap allocations everytime you work with an IntPos causing more pressure on the garbage collector (so it runs more often and takes longer), plus everything you do with the IntPos goes through virtual calls. In any decent language IntPos would be a regular by-value object that doesn't have to be heap-allocated and because it's exact type is definitely known there's no virtual call overhead.

You wrote a lot of words here, and I am not sure if I am fully understanding what you're saying, or if you don't understand how Java and its garbage collector works. Either way, there are definitely some massive exaggerations in here, and it seems like the only criterion you're using to claim that "Java is a terrible language" is performance. In that vein, we might as well trash all managed languages and all interpreted languages in favor of high-level native languages. Let's throw in some assembly as well; it will be fast!
Surely you must have heard of using the right language for the job. There are reasons why python/ruby is used for automation scripts, Java is used for backend development and applications, and C++ is used for game client development. Performance is not everything; actually, depending on what you are writing, performance is not even worth considering over other things.

For example, take League of Legends. Almost all of our backend services are in Java. The only software that is not in Java is our game client (C++), game server (C++), and our PVP.net client (adobe flex).
Some of our backend services are:

• The entire PVP.net Platform
• Our in-house storage libraries to interface with NoSQL engines
• Our in-house Rest server library
• Tournament code server
• Leagues
• Loyalty
• Loyaty 2.0
• Tribunal 2.0

If we had made the decision to write all of those in C++ for optimal performance, more than half of those features would not exist right now because our developers would be busy meticulously testing every component to ensure there are no leaks or problems. Instead of being able to slap a few hundred dollars for better hardware or for another box (since all of our systems scale horizontally), we would've lost a few hundred thousand dollars to developer time.

And by the way, our Java systems support over half a million concurrent users. The best part? Most of our production hardware is underutilized.

Sure it is possible to write Java that performs reasonably and doesn't use too much memory and yes it can even be quite stable, but it still performs significantly worse than the equivalent native code. However little memory and CPU your Java server is using, a server like Vana will be using way less than that.

So a managed language that runs in a VM is going to perform worse than native code? Well, that's obvious. And actually, Java performance is not as terrible as it seems, because of JIT compilation (which actually compiles Java bytecode to native code). Nevertheless, you seem to solely discount Java's viability on its performance, which is extremely shallow and baseless.
Java is one of, if not the most popular languages in the world and has been used in countless companies and projects with massive traffic, from Google to Riot to companies like AT&T. You do not have to doubt its scalability.

At the end of the day, though, no one cares how well your C++ server performs. At Riot, almost all of our hardware is underutilized, and we serve hundreds of thousands of concurrent users. For a MapleStory server that very likely won't even serve a thousand players, it really doesn't matter what language your server is written in.
Actually, I have enough confidence to say that a modern Java base (which currently does not exist) can handle 1,000 players on the same (or similar) hardware as a Vana base -- sure, memory usage will be more, cpu usage will be more, but nothing that the box can't handle. At that point, nothing matters. Actually, the only thing that matters is that my Java source would've taken a year or less to develop, while yours has taken 5.

 

[Fraysa]

You wrote a lot of words here, and I am not sure if I am fully understanding what you're saying, or if you don't understand how Java and its garbage collector works. Either way, there are definitely some massive exaggerations in here, and it seems like the only criterion you're using to claim that "Java is a terrible language" is performance. In that vein, we might as well trash all managed languages and all interpreted languages in favor of high-level native languages. Let's throw in some assembly as well; it will be fast!
Surely you must have heard of using the right language for the job. There are reasons why python/ruby is used for automation scripts, Java is used for backend development and applications, and C++ is used for game client development. Performance is not everything; actually, depending on what you are writing, performance is not even worth considering over other things.

For example, take League of Legends. Almost all of our backend services are in Java. The only software that is not in Java is our game client (C++), game server (C++), and our PVP.net client (adobe flex).
Some of our backend services are:

• The entire PVP.net Platform
• Our in-house storage libraries to interface with NoSQL engines
• Our in-house Rest server library
• Tournament code server
• Leagues
• Loyalty
• Loyaty 2.0
• Tribunal 2.0

If we had made the decision to write all of those in C++ for optimal performance, more than half of those features would not exist right now because our developers would be busy meticulously testing every component to ensure there are no leaks or problems. Instead of being able to slap a few hundred dollars for better hardware or for another box (since all of our systems scale horizontally), we would've lost a few hundred thousand dollars to developer time.

And by the way, our Java systems support over half a million concurrent users. The best part? Most of our production hardware is underutilized.


So a managed language that runs in a VM is going to perform worse than native code? Well, that's obvious. And actually, Java performance is not as terrible as it seems, because of JIT compilation (which actually compiles Java bytecode to native code). Nevertheless, you seem to solely discount Java's viability on its performance, which is extremely shallow and baseless.
Java is one of, if not the most popular languages in the world and has been used in countless companies and projects with massive traffic, from Google to Riot to companies like AT&T. You do not have to doubt its scalability.

At the end of the day, though, no one cares how well your C++ server performs. At Riot, almost all of our hardware is underutilized, and we serve hundreds of thousands of concurrent users. For a MapleStory server that very likely won't even serve a thousand players, it really doesn't matter what language your server is written in.
Actually, I have enough confidence to say that a modern Java base (which currently does not exist) can handle 1,000 players on the same (or similar) hardware as a Vana base -- sure, memory usage will be more, cpu usage will be more, but nothing that the box can't handle. At that point, nothing matters. Actually, the only thing that matters is that my Java source would've taken a year or less to develop, while yours has taken 5.

Why do you keep saying "our" when referring to Riot Games? Are you actually a Rioter?

 

[retep998]

*snip*

At no point in my post did I mention C++ or even recommend C++ (the primary reason I recommend Vana is because it is accurate and stable compared to Java servers, the performance is a bonus). I am well aware that C++ is a difficult language to learn and that writing an application in C++ may take significantly more time than an equivalent program in Java. As you said, it would take a lot of time to meticulously test your C++ code to make sure it has no leaks or problems. Granted, there are defensive ways to program in C++ taking advantage of RAII to minimize the occurrence of leaks and problems. But I can totally understand people not wanting to use C++ for a maplestory server because of the complexity.

What I am recommending is using a better language than Java, not for performance reasons, but for safety reasons.
Java isn't much safer than C++, it merely has a GC running to cleanup all your leaks after you, and gives you pretty Java exceptions instead of crashing when you do something stupid. I'd rather have a language that stops either of those issues from occurring in the first place, something like Rust perhaps?
When I'm iterating over a container I want a guarantee that the container won't resize while I'm working with it, C++ doesn't guarantee that, and neither does Java. Rust meanwhile provides those guarantees (and as a bonus no runtime overhead for that safety).
When I get a pointer to an object, in both C++ and Java I have to check for null pointers otherwise I get segfaults or null pointer exceptions. In fact, there is no way in Java to guarantee that I won't get a null pointer. Meanwhile in Rust I am guaranteed that pointers are never null and if something does want to be able to provide nothing sometimes, I just wrap the pointer in an Option, and then it is clear from the type signature that it could be null, and I have to explicitly handle the null case.
I could go on and on about all the different cases where Rust beats both C++ and Java at safety.
My point is that there are languages which are significantly safer than Java, and can even perform significantly better.
Sure you can write stuff that performs well enough in Java, hardware is cheap after all compared to developer time, but if you have the choice, why not use a language that is safer and faster?

 

[SuperLol]

Why do you keep saying "our" when referring to Riot Games? Are you actually a Rioter?

Yeah, see you can go from MS servers to more! It's not completely useless hanging around here.

 

[LazyBui]

At that point, nothing matters. Actually, the only thing that matters is that my Java source would've taken a year or less to develop, while yours has taken 5.

He hasn't written a server source.

Also, I take exception to "yours has taken 5." It existing for 6 years doesn't mean anything about how much it's actively been worked on.

This might be to-may-to vs to-mah-to, but I wouldn't really call this 6 years of development. Even if it was, most of the work these days is undoing poor design decisions and research into things that nobody else has bothered to look into. Those things are language-agnostic, you can make bad decisions and have poor accuracy in any language.

Not that I'd be a stalwart defender of C++, but ya. I really dislike the logical leap made here.