Exceed v153

[Exceeds]

given that today no one gives how maplestory works in general rather some stupid game playing and features I thought this may do good to the people here given that it is based on v144 source which is beyond any hopes or working up and everything is thrown to one bat file, there is internal issues and memory leaks everywhere

and who in hell wrote final keyword everywhere in the source, and the packetprocessor is quite frustrating to work with seriously a switch statement?

source is ugly and beyond any hopes of fixing and we still have servers like ellinia,astralms,hawtmaple lol

and yet we have people blame java for the root cause of our private server.

TODO 

CLEAN UP THE SOURCE 
REMOVE USELESS FILES
RECODE CERTAIN FUNCTIONS TO WORK BETTER

MAJOR IMPROVEMENT NEEDED.

IMPROVEMENT TO THE XML SYSTEM AND SCRAP AWAY WZ TO SQL SHIT ! SO WE DONT REDUMP ON NEW VERSIONS.
MAPSCRIPTS SHOULD BE IN JAVASCRIPT AND NOT HARDCODED 
POSSIBLE RESTRUCT THE SERVER WITH WORLD, LOGIN, CHANNEL RATHER THEN ONE STUPID FILE RUNNING EVERYTHING!
PACKETHANDLER NEEDS A RECODE TO HANDLE RECV OPCODE BETTER ODIN PACKETPROCESSOR WAS GOOD WHO THE DID THE SWITCH

BUGS

[-] ATTACK SEEMS TO THROW NULLPOINTEREXCEPTION -> OTHER ATTACK OPCODE ARE MISSING
[-] COOLDOWN DONT WORK EVEN OPCODE IS UPDATED
[-] POTIONS DONT WORK UNABLE TO USE THEM
[-] CHANGE KEY MAP RESULTS IN KEY NOT SAVED UPON SERVER RESTART
[-] AP STATS (?)

src link : ( build it yourself)

https://www.sendspace.com/file/2864x1

have fun kids.

[MentaL]

[frank863]

No lib

[Novak]

No lib

That's the deal with the "src link" you just grab some lib files yourself.
And wz xmls/nx files,
And some sql's,
And some scripts (optional i guess)

[frank863]

That's the deal with the "src link" you just grab some lib files yourself.
And wz xmls/nx files,
And some sql's,
And some scripts (optional i guess)

i use you 144 lib but it Compile error

[anhtanh95]

In my opinion,switch statement isn't so bad. You can search and access to any method of each opcode you want to, just in 1 file: MapleServerHandler.java. i love it :p

[Eric]

In my opinion,switch statement isn't so bad. You can search and access to any method of each opcode you want to, just in 1 file: MapleServerHandler.java. i love it :p

well, the switch in Lithium isn't really the problem, it's the fact that every packet processed in Lithium iterates over every opcode every time and again and again. compare that to the packetprocessor from v83 and you'll notice it just checks from a Map and if not null it handles it.

but besides that, i agree, i prefer to have all of my handlers located within 1 file rather than 123 or 163 (forgot which one it was, but it was at least one hundred files worth)

also, i could've sworn I converted to XML parsing again and it was way slower than DB loading (infact it probably is just by assumption). There was a reason for loading all the data from DB, and that was for speed of server startup time and it cached everything right there.

and as for using final, the compiler actually suggests you to use final where possible. it's just as much style as it is using the Diamond Operator which was also used everywhere in Lithium, and not really a "problem" as far as I'm aware.

[Novak]

In my opinion,switch statement isn't so bad. You can search and access to any method of each opcode you want to, just in 1 file: MapleServerHandler.java. i love it :p

Which is exactly the same with the odin method. But instead of serverhandler you go to the packetprocessor. From there it works basically the same navigation wise, (in netbeans: crtl+click the handler) and there's actually less distance between op's making it (in my opinion) easier to read. Also having a loose handler for more or less every op is more easy to navigate in my opinion as well instead of scrolling through a hughe file called "XxxHandler" which is filled with an uncountable ammount of handlers.

The biggest difference is the fact that you are doing uneccesary operations with the switch statement.

Hence I prefer the packet processor over the switch statement.

[Hilia]

well, the switch in Lithium isn't really the problem, it's the fact that every packet processed in Lithium iterates over every opcode every time and again and again. compare that to the packetprocessor from v83 and you'll notice it just checks from a Map and if not null it handles it.

Actually switches with many cases (18+ to be exact in java 1.7) will be optimized to a lookup table (an "array of pointers'), where as the value of the current switch will be the index, resulting in only a view steps of assembly to find the correct handler. Where as an if else on the other hand has to check for every case.

Also this is definitely not something you want to optimize,it is more about , what do you prefer/ is the easiest to maintain. A HashMap in my opinion is cleaner than a lot of switches, especially if you have a good way to set it up. But if you like a switch ,just go for it , there is nothing wrong with it.
You can also go for a plain array where the opcode is the index and if you implement this on a "smart" way, you can even eliminate the boundary checks resulting in the fastest look up time possible. Although we are talking about premature optimizing and therefor i would simply go for what is the most readable/best maintainable/ what you prefer.

[SuperLol]

FIRST QUESTION: IS THIS EXTREMEDEVILZ?

What Hilia said is correct. However, the way in odin is with an array with the index as the opcode and not with a map at all (which even with constant time lookup contains overhead and many instructions). The optimal way is the one in odinms. In cases where this is not possible then the "proper" way is to use a map. All of these issues were added in Celino which someone thought it was a good idea to copy later on. It is unmaintainable code that take a lot of developer time to go through. It's easier to go through a list of lined up code than a bunch of if statements.

It's not just map scripts that are wrong. Map scripts and item scripts should be scripted and not hard coded into the source. There's many item scripts that should be done properly and not in one NPC either (one mistake I made when I worked on them). Basically Tetra developers coded the source with no intention of making it actually follow programming style and planned design but rather just to get things done which is why it has this stuff.

and as for using final, the compiler actually suggests you to use final where possible. it's just as much style as it is using the Diamond Operator which was also used everywhere in Lithium, and not really a "problem" as far as I'm aware.

This is not the issue at hand. It's not a style thing either like the diamond operator. It's misunderstanding what final does. Final is good for local variables (even though I think the compiler already optimizes this so it's unneeded). There's also final methods and final classes which do nothing for optimization (which apparently Celino thought was a good idea).

In my opinion,switch statement isn't so bad. You can search and access to any method of each opcode you want to, just in 1 file: MapleServerHandler.java. i love it :p

You can do that in shorter steps if you just remembered your handler name. Ctrl-O and type in the name of the class. You would have to know the name of the class if you searched it in the file anyway. Actually I recommend Ctrl-O for daily programming. Also ctrl-left and ctrl-right which works in pretty much any IDE.

[SharpAceX]

This source is near useless. It does practically nothing, with so many critical opcodes not updated at all. My broken v155 is a lot better than this in terms of playability, which actually says a lot about this source. Probably can't even rip anything useful whatsoever from this.

FIRST QUESTION: IS THIS EXTREMEDEVILZ?

Yes.

[ExtremeDevilz]

uh Exceed, yeah me and my friend was working on it for sometime but we decided to scrap the project, no idea how it ended up here as far as I could remember I did not wanted to work on it due to various issue, where random stuff of nullpointerexpection and I dont wish to debug and fix those, the source is clearly ugly and there is no practical of OOP, anyway I dont wish to say much, I would let this thread die over here, this was updated from v148 HelisumDev or whatever the name was. honestly there is nothing much to learn from this, It would be much better to write a source from scratch with proper support of RMI and properly written.

It is either you take odin/shootsource and update it like what Extalia did
or
write from scratch
or
simply don't work on it
@SuperLol

this release was not made by me, but I help to update the source.

[Fraysa]

this release was not made by me, but I help to update the source.

Your IP address says otherwise.

[Rakeda]

Your IP address says otherwise.

Aw shit :O

[ALotOfPosts]

this release was not made by me, but I help to update the source.

but you talk like him though and you talk a certain way :(

[frank863]

this is bad i can not run server because this could not be loaded