ColexDev (re-coding Lithium, cuz it sucks)

[Five]

I've implemented netty a while back, but after some discussion with a friend i'm going to re-write it again. Trying to follow Eric 's advice removing the need for mapleclient and client_key attributes. I'm not 100% sure how i'm going to do that yet So far i only know the basics of netty/mina but I'm progressing I'm here to learn!

There is already no need for that stupid variable 'Client_Key' that odinms uses, there never has been.
Also MapleClient has never been needed, it was simply there to hold any functions related to the user and client. I don't think removing it is necessarily good because there is probably about 200 lines of useful code that you wold have to move somewhere else.

Also by now I got a little question: What would you prefer? I've been chatting with some people and they all told me their experience with RMI was that it was pretty slow. I'm thinking of splitting the server into loose instances using Netty instead. Idk how that would play out, but maybe it's a bit more interesting then just plain RMI. But I know for sure I want to split things, since i'd like to be able to run Servers seperately.

If executed properly, RMI can be very useful and successful. Don't go copying odinms and their keys like every repack over the last 7 years.

I've also started re-organising skills, not focussing too much on how they are handled yet. Why? Well i find it hard to find structure in the chaos that is MapleStatEffect. I want to organise that before I look into handling.

Incase you need ideas, this is how I do it. I removed what odinms called ifbuffstatisnotzero or something along those lines because my source has skill changes and it is more organized this way, but if you want hella less lines, make use of that function.

case EVAN8:
                      switch (sourceid) {
                            case Evan8.ONYX_SHROUD:
                                ret.statups.put(BuffStats.ONYX_SHROUD, ret.info.get(StatInfo.x));
                                break;
                            case Evan8.TELEPORT_MASTERY:
                                ret.statups.put(BuffStats.TELEPORT_MASTERY, ret.info.get(StatInfo.x));
                                break;
                            default:
                                break;
                        }
                        break;

 

[Zygon]

There is already no need for that stupid variable 'Client_Key' that odinms uses, there never has been.
Also MapleClient has never been needed, it was simply there to hold any functions related to the user and client. I don't think removing it is necessarily good because there is probably about 200 lines of useful code that you wold have to move somewhere else.

That variable is used for a reference to a specific attribute of the session. In this case, it is referencing the MapleClient to be associated with the session. This is important since it gives the programmer the ability to change the key throughout with one line edit if for some reason the key needed to be changed to something else. Also, not using objects to represent and contain information creates another problem of overly complicated design. If you have something that can be represented in the simplest, more straight-forward terms, you should do it that way.

If executed properly, RMI can be very useful and successful. Don't go copying odinms and their keys like every repack over the last 7 years.

There isn't really much overhead with regards to using RMI; you just use it. There's no really exceptional way to implement it because the backing libraries do nearly all of the work. It should be about as effective in information transport as a TCP socket and only slightly less efficient assuming fundamentally equal amounts of information are being transported. I will completely agree with the latter half: you definitely want to change your SSL certificate information simply because it is a huge security vulnerability if you choose to use RMI in the configuration it came in with Odin.

 

[xStr0nGx]

Sup? For those still following this (lemme guess: Nobody? xD), here's the next tiny-update. (Bigger updates soon! Almost done with my last exams!)

I've implemented netty a while back, but after some discussion with a friend i'm going to re-write it again. Trying to follow @Eric 's advice removing the need for mapleclient and client_key attributes. I'm not 100% sure how i'm going to do that yet So far i only know the basics of netty/mina but I'm progressing I'm here to learn!

Also by now I got a little question: What would you prefer? I've been chatting with some people and they all told me their experience with RMI was that it was pretty slow. I'm thinking of splitting the server into loose instances using Netty instead. Idk how that would play out, but maybe it's a bit more interesting then just plain RMI. But I know for sure I want to split things, since i'd like to be able to run Servers seperately.

I've also started re-organising skills, not focussing too much on how they are handled yet. Why? Well i find it hard to find structure in the chaos that is MapleStatEffect. I want to organise that before I look into handling.

I'm putting the git on in a month or so, after I got netty and skills done.

Also dw people! I'm putting credits in where it's due! (from people who guided me in this learning process and snippets of code i've used made by others, so far for example solaxia has been quite the inspirition, i really like it! so have ideas from people like fraysa, eric, dynamik, etc! they got some good tips all the damn time!)

Separating them would be nice, but I really don't see the reason for working on a MS source when you can play the original GMS for free, of both price and bugs.

In addition, don't go and recode released sources, just make your own.
Would be much faster and will give you more credibility.

 

[Five]

That variable is used for a reference to a specific attribute of the session. In this case, it is referencing the MapleClient to be associated with the session. This is important since it gives the programmer the ability to change the key throughout with one line edit if for some reason the key needed to be changed to something else. Also, not using objects to represent and contain information creates another problem of overly complicated design. If you have something that can be represented in the simplest, more straight-forward terms, you should do it that way.

You are right, it was more of ease of change and reference with its usage in odinms. I don't know how he is using it in his netty implementation, but it was strictly used as a mina attribute key previously.

There isn't really much overhead with regards to using RMI; you just use it. There's no really exceptional way to implement it because the backing libraries do nearly all of the work. It should be about as effective in information transport as a TCP socket and only slightly less efficient assuming fundamentally equal amounts of information are being transported. I will completely agree with the latter half: you definitely want to change your SSL certificate information simply because it is a huge security vulnerability if you choose to use RMI in the configuration it came in with Odin.

I may of incorrectly worded what I meant. I didn't mean recode RMI or code it differently to achieve some extraordinary result that didn't get achieved in odinms. Just that implemented correctly and securely, his server scalability will be 'useful and successful'. He should change the keys (however this is a future release so it really may not matter in his case and will fall to the downloaders). Every implementation realistically will get the same result as long as it works properly.

 

[eshays]

I think change buffstats (bitshift), skills, and attacks to more like the nexon

I really don't see the reason for working on a MS source when you can play the original GMS for free, of both price..

GMS is pay to win like all nexon games..
the only time they were free was beta - before v28 (exp coupons), when nexon changed the rules about cash items only affecting appearance.
Though the main reason is educational.

 

[Novak]

Don't go and recode released sources, just make your own.
Would be much faster and will give you more credibility.

I like to know how everything works before I try to make something from scratch. I assume it's clear by now that I'm starting to gain understand of some more advanced programming things, but I'm still far from mastering them. Hell, what to be expected from someone that has never done anything programming related and definitely doesn't follow a study in the field? I started learning programming in java back in februari this year.. (You'll see my RZ activity spike around that time..)

I'd absolutely love to make a source from scratch, but i'd like it to not be "another crappy source made by a know-it-all coder who literally can't do poop", which is why I'm pulling together things from multiple sources, try to gain understanding off how to do thing, and how to not do things. Whilst consulting with multiple coders better then me throughout this thread.

They're sharing opinions in this thread in a way I haven't seen for quite a while on RZ, and I'm able to grow my knowledge and understanding very quickly using their input, thank you insanely much Five and Zygon ! Next thing I'll do is look into the security issues when using RMI! Not 100% sold on using RMI at all yet, but I'd like to at least research more before making a decision

Anyway, the main goal of this thread (ohgod this is like the fifth time i'm typing this out?) is for me to learn, and in the end to hopefully leave behind a source that's just a tad better and easier to use then the insane shitload of weird lithium sources being used right now. Hopefully make some newcommers to ragezone use this, a most likely v145 source, instead of pulling out "ourstory because it was mentioned in a how to setup a server guide".

So yeah sory for writing such a slab of text, but i'd just like to point it out before you comment it again. (this is like the 3rd time you say "go do from scratch"?, or at least people tell me this all the damn time..)

 

[SYJourney]

Not sure if this is included in your "Re-structure the entire thing" but I'd suggest slicing up the huge files like MapleCharacter.java. Most concepts in there just beg to be their own class anyway, just move variables and methods belonging to one concept into their own class and then make a variable of that class in MapleCharacter.
I think that you can improve the overall structure alot that way, and it's also going to help new people navigate the source more easily.

 

[Novak]

Not sure if this is included in your "Re-structure the entire thing" but I'd suggest slicing up the huge files like MapleCharacter.java. Most concepts in there just beg to be their own class anyway, just move variables and methods belonging to one concept into their own class and then make a variable of that class in MapleCharacter.
I think that you can improve the overall structure alot that way, and it's also going to help new people navigate the source more easily.

That's the main goal of the re-structure. I hate the way most things are just thrown into one file and i find it waaay to difficult to navigate sources these days. Again, this is one of the resons for me to return to the packet processor for now too. (might actually switch to annotations later, might be easy to put some handlers together, not all, but some)

 

[SYJourney]

That's the main goal of the re-structure. I hate the way most things are just thrown into one file and i find it waaay to difficult to navigate sources these days. Again, this is one of the resons for me to return to the packet processor for now too. (might actually switch to annotations later, might be easy to put some handlers together, not all, but some)

For the packet processor, I think the way Odin did it was fine, just group the handlers together instead of having each in one file. I think it was also mentioned that a linear array would best, so you could just do that. As for the also huge MaplePacketCreator, that's another file that you should split up, I'm not sure how you would do this in java but for my project I just subclassed my outpackets so that I can group them as classes into smaller files.

Edit: Let me just add, I really appreciate that someone is actually trying to make a good go-to source people can try first for once. You could even improve most smaller servers out there just by giving owners an easier to use and good source to work with.

 

[Borlea]

Cleanup how skills are handled.
- Don't use a billion switch cases of skill ids that are all around the source and need to be updated each version.
RMI

If you get this.. the source would already be beautiful.

 

[Novak]

Cleanup how skills are handled.
- Don't use a billion switch cases of skill ids that are all around the source and need to be updated each version.
RMI

If you get this.. the source would already be beautiful.

consider it done.

 

[Five]

Cleanup how skills are handled.

Example?

- Don't use a billion switch cases of skill ids that are all around the source and need to be updated each version.

What does that even mean? Is this suppose to mean make one big enum with names and ids?

 

[SYJourney]

I took a look at a lithium-based source and it seems that they do have constants for their skills, but they don't actually use them... If you're restructuring this pay alot of attention to keeping things consistent and integrating things that make sense.
As for skills I'd say instead of using a switch case make a skill base class and subclasses with whatever functionality is needed and grant each (buff) skill it's own small class. Sort those by job and create a class for each job that has an enum with the skillids and an enummap with the skills in it. Make this hierachical too so that you can access a 1st job from 4th job and etc. Then when you need to apply buffs or similiar access the job class by the characters job id and retrieve the skill from there.
Sounds like alot of work and I'm not sure how this will compare perfomance-wise but it'll be alot more structured.

 

[Novak]

I took a look at a lithium-based source and it seems that they do have constants for their skills, but they don't actually use them... If you're restructuring this pay alot of attention to keeping things consistent and integrating things that make sense.
As for skills I'd say instead of using a switch case make a skill base class and subclasses with whatever functionality is needed and grant each (buff) skill it's own small class. Sort those by job and create a class for each job that has an enum with the skillids and an enummap with the skills in it. Make this hierachical too so that you can access a 1st job from 4th job and etc. Then when you need to apply buffs or similiar access the job class by the characters job id and retrieve the skill from there.
Sounds like alot of work and I'm not sure how this will compare perfomance-wise but it'll be alot more structured.

That's pretty damn close to what I had in mind yes. I guess you'll have to wait and see I'm gonna do my first idea first, which should be a tad better performance wise aswell, but i'm going to test it first obviously.

 

[klyster]

Well when i study Computer Science i learn the moduling is a the best way of developing, so RMI, having login server, world server and channel servers on diferents instance allow you use even differents servers to comunicate btw then and if you fall the others still working, and even you can easy debug which one need to be more optimized because you can check which one is using more or less memory and so.

 

[Novak]

Well when i study Computer Science i learn the moduling is a the best way of developing, so RMI, having login server, world server and channel servers on diferents instance allow you use even differents servers to comunicate btw then and if you fall the others still working, and even you can easy debug which one need to be more optimized because you can check which one is using more or less memory and so.

I agree. My current layout i'm working towards is Login Server, Game Server (channels) and Center Server (world? this does DB calls). This thread is pretty old but the project is still a thing. It's been abandoned multiple times by now and restarted multiple times again. Usually because i got stuck at something or didn't like where it was going and started over again. I still don't know when this'll see the light of day but it will, someday. And I promise it won't be another obsolete v14x source.

 

[br1337]

I'm doing the same thing with a v90 source.
For now i'm just fixing gameplay bugs, but near i wil refactor the codebase.

Good luck!