Apparently 2 months ago? https://github.com/npcdoom/eSRO
Apparently 2 months ago? https://github.com/npcdoom/eSRO
Yes...so? it's incomplete, and most of us don't have the ability to finish it ^^
Looks pretty crappy to me. Just re-write it, even if it's incomplete. Shit's easy.
Do i hear a toilet flush ?
There are better ways to waste time with.
regards
rogan12
justin-mbp:eSRO justin$ git diff HEAD~1 --shortstatOriginally Posted by rogan12
628 files changed, 94506 insertions(+), 0 deletions(-)
There's not much here, and it's extremely over-verbose C++ since as I predicted when they were working on it, none of them has a clue how to write software, so really this is ~10-15k LOC done properly. That's tiny. Maybe a weekend at most.Code:Language files blank comment code ------------------------------------------------------------------------------- C++ 231 11044 6751 36087 C/C++ Header 261 5005 7317 14280
It's still the best emulator written out there , I remember how were you wishing to have such a thing back then.
Mine was significantly better architecturally, only I didn't have the time to sit there and reverse packets, so it was very incomplete. When I got back around to working on it a second time, so much had changed that the prospect of doing all the same work over again made it a non-starter. I have even less time today.
The thing is, Eckoro is one of those people who would rather have a project fail miserably than collaborate and make something better. The end result is as I predicted it.
I hope you know that eckoro didn't take any real part in writing the actual emu except for gathering the packets.
Either way, weren't you the guy who wrote that vb6 emulator that is basically single player?
You should be more thankful for software like this. npcdoom wrote it a couple of years ago, basically on his own, I have yet to see anything that you released from all the things you told us (node.js epic emulator, oh mai gawdz!) I can inform you that npcdoom released this in public so that people can learn from it, and that people like you (if you didn't have this fucked up personality) would be able to help him finish it. Also, npcdoom recently (couple of months ago) started his second bachelor studies, in computer sciences, so give him a break on 'not knowing how to develop software' while he wrote this without any real "experience"
Either way, eSRO is obsolete, don't waste your time on it.
https://github.com/npcdoom/ZelosOnline is the latest version
Last edited by yorick671; 23-03-13 at 01:50 PM.
The packets were the only thing that mattered. Even the worst "programmers" would be able to make something that somewhat worked given packet data, as is evidenced by every SRO project.
No.
It doesn't matter. I shouldn't be thankful for any of it. The only valuable thing in these projects is packet data. It would've been infinitely more useful to just publish raw packet breakdowns. Just about everything in this source is worst practices, and I feel sorry for anyone who thinks they could or should learn anything from it. My work on an emulator for the community was contingent on someone getting packet information -- something no one ever bothered contributing, not even npcdoom even though I asked him. It's incredible to see people defending code that should be wholly featured on thedailywtf.com.
This is even worse. Once again, the only valuable information present here is the packet data. He's slowly devolving to: https://github.com/Mikkeren/FizzBuzzEnterpriseEdition
It's also nice to see the lack of attribution: https://github.com/npcdoom/ZelosOnli...master/libauth
Almost everything in here follows the reversing pushedx and I did to support encrypted communication and to understand the encryption flags, but neither of us is mentioned. This is why the contract for any emulator work from me was that all packet information be provided, because to spend my time reversing for the community ends up with everyone using it without attribution anyway.
Last edited by jMerliN; 23-03-13 at 08:32 PM.
I hope you know that pushedx was closely involved in the making of this emulator, if you would have checked the original post (which is even on this very forum) you would have seen that pushedx is credited, plus everybody else involved.
I find your attitude very disrespectful against people that actually try to help, while you have done nothing for this community at all, and are even too lazy to gather your own packets (do we really need to spoonfeed you information before you are able to make something decent? Take a look at pushedx, he knows that he has to do everything himself, and he will do it without hesitation). Either way, the complete packet archive is in the hands of most people (that can use it) in the sro community, I wonder why nobody has given you a copy
anyway, this is a pointless discussion. Either you help npcdoom out with his emulator, or you start writing your own epic 9001 l33t emulator, there is no real need to keep showing your "superiority" and gigantic ego (we all know you need to use 2 empty elevators to reach the top of a building) while nobody actually cares and while you can start doing something constructive with your time. We'll even help you out, as long as you show some respect
Doubtful. Also, he did not credit everyone, and there's a difference between crediting on a forum nobody will ever visit and on the source repository itself.
There's a reason we don't have a single decent emulator even to this day.I find your attitude very disrespectful against people that actually try to help, while you have done nothing for this community at all, and are even too lazy to gather your own packets (do we really need to spoonfeed you information before you are able to make something decent? Take a look at pushedx, he knows that he has to do everything himself, and he will do it without hesitation). Either way, the complete packet archive is in the hands of most people (that can use it) in the sro community, I wonder why nobody has given you a copy
Respect is earned, not assumed. If the community wants to continue backing amateurs that don't know how to write software, so be it. Again, not a single decent emulator exists. Why might that be?
Wow, this code is far worse than I gathered from a cursory glance. This belongs on TDWTF for sure. It's as if someone convinced npcdoom that having more daemons implies scalability, stability, quality, or any other useful metric. Yet it has 0 tests, 0 linting, and no metrics to measure performance which is always step #1 when you have a performance problem.
So much code is repeated all over the place. So much completely useless boilerplate. Unnecessary interfaces and abstraction. There seems to be a goal of keeping every file below some arbitrary file size limit, so things are unnecessarily spread around. About 65% of the code in the project is dedicated to dealing with inter-daemon communication, and that's done using some unnecessary handshaking, and then there's this complicated mess of state management and setting things up to appear to be evented rather than just using something like libev. The SSH protocol solved the security problems this attempts to solve a LONG time ago and much more elegantly -- if this multiplicity approach is desired, using libssh would've been SO much better. Although the abuse of OOP here wouldn't have meant that would've made much of an impact even though conceptually the idea would be drastically simpler (and much more secure). In reality, the daemons are split into their own projects/executables, and unnecessary packaging of not-necessarily-shared code into libs is happening. Really, nothing about this is even reasonable, and splitting things into daemons doesn't improve scalability at all, and has a net detrimental effect to system stability as evidenced by literally every cloud project ever made, ever.
Not to mention what's posted of ZelosOnline is, even with an absurdly unnecessary amount of complication, less complete than the original VB6 SREmu. eSRO is both significantly better in design (although far from "good") and substantially more complete. This "more advanced" project is wholly useless and will only confuse anyone. As a summary of what it is: it's basically a gigantic pile of unnecessary C++ trying to shoehorn ideas solved long ago in elegant and stable projects into abstract template-happy boost-loving misguided implementations. Done in C with the use of existing libraries and using a forking strategy over unnecessarily building N daemons, this would be about 1/10th the size and be much more stable.
As it stands, this code base is significantly trending towards an evented system and does a lot of unnecessary work to try and serialize anything responding to user actions but does so in a very rudimentary and naive manner. At the end of the day, what npcdoom is trying to implement here is something like an evented I/O framework like libuv + a layer of abstraction that would make it akin to Node.js or Twisted while being wholly inadequate in comparison given that both of these have rich and powerful runtimes available. Hence, I still believe as I did when I said I'd write an emulator, that an emulator in Node.js would be significantly simpler than any that anyone has ever made while being trivially made to outperform them all.
My old JS emulator built before Node existed had users in-game and running around able to spawn monsters and kill them in about 800 lines of code, and it was extremely simple to read and extend. I will still maintain my agreement with the community. Pick a client, provide me with up-to-date packet information, and I'll make an open source emulator that's completely functional, under the MIT license, not the AGPL, so anyone can use it for anything.
If you choose to believe that my making such an offer to the community at large is indicative of an attitude problem, then I must wish you good luck in finding a professional engineer who is both willing to and capable of building such a thing.
As for Eckoro's statements regarding packet gathering: what Eckoro did is largely based on the initial work done by people working on SREmu and doing a LOT of reversing work in the client, followed by pushedx using that and extending it a lot towards building proxies that would also identify calls to reading and writing utility functions used by SRO (things like pkt->readByte() or pkt->writeByte(), etc). With this, much like utilities we built to parse packets for SREmu, but made public, Eckoro managed to log most packets and spend enough time guessing to decode most of what was going on. The problem is that this isn't sustainable. Why isn't any emulator, PERIOD, up to date with any client release? It should be trivial to keep up to date within a week or month of releases -- why not? Because it's almost impossible to track down packet changes when you've reversed them from data. What Eckoro did was a lot of busy work, and that's fine, but it's only valid work for a given version frozen in time. What I planned to do (but didn't and still don't have the time for) was to build a basic framework for programmatic debugging and checksumming that would result in a tool that could allow a reverser to reverse individual packet building/parsing sites, do dataflow analysis to trace where data ends up within in-memory structures, and to mark code paths as completed to get an idea of packet coverage, and maintain this by checksums of basic blocks. When a client update happened, beyond doing basic things like re-running parsing tools on PK2 text resources to update the emulator, one would simply load the tool on the new client and see if any basic blocks involved in packet building/parsing have changed. If so, you get a nice display of those modified blocks in red and a new readout of packet coverage, and all you have to do is do a minimal amount of reversing to update the emulator to the latest version (something like a few hours, worst case, for any capable reverse engineer). This tool would take at least a few months to get working well and right, but would be usable on any game (not just SRO), which is why it'd still be a valuable tool to build, and I may get around to it one day but I'm far too busy these days. In absence of such a tool, the task of gathering packet information for an up to date version isn't a task someone can fully achieve in their spare time while building an emulator that is 100% functional. This is why I asked the community for packet data.
The time I have is spare time. I've made an agreement to build the emulator which appears to be what nobody else has ever been able to do, as that can be done in spare time since it follows a traditional software development cycle. If supported with packet data, the result would be something that could literally run on current clients and would be better in every way than the real servers. If no one is willing to share, then providing for this community isn't something worth my time, so I will continue to not build anything. If one day I get around to finishing my dataflow analysis and programmatic debugging engine, I might do it myself, but the odds of that being within even the next 5 years are extremely unlikely.
Last edited by jMerliN; 25-03-13 at 08:56 AM.
Hmmm.... the problem is, to build a perfect emulator, you need commitment. And since the sro industry is dieing, very slowly but dieing... i guess it is a waste of time to re-make an emulator from scratch!
I was part of Aion-Unique Emulator, the first aion emulator "the one every server is using atm", and it took amazing amount of commitment, and in the end they shutdown the project :S meh! Its why it is hard for me personally to get involved in emulators :P although i would of loved making a java or c# emulator :P
You are totally right, i've plans to get all developers together (xsense, jmerlin, pushedx, evestu and more) and make from scratch but i don't know which one will accept or decline it.
so jMerlin can consider it as an offer, i belive when i get 2-3 of them together others will accept too.
off topic:
may i get your skype Jangan? Thanks.
I hope you know that xsense and evestu's skillset isn't even close to that of jmerlin and pushedx. Either way, a project like this is way too complicated for a team on the current sro "level", and while pushedx has currently left sro, I guess jMerlin has to work on it on his own (and that is probably what he desires).
While I don't agree with every point he makes, I'd love to see a working emulator for silkroad, but I doubt the MIT license would be the way to go (if you see how greedy silkroad has become), I doubt even anybody would care about the license lol.
--
I talked with pushedx about your last emulator jmerlin, and he told me you had actual skill, so I will trust him on his word, but I'll have to see it before I believe it.
If you have a rough concept of how you are planning on starting this, I'm sure we can arrange you a copy of the packet archive
EDIT: RevoLand, please refrain from deleting my posts that actually bring value into the discussion. You are not the one to teach me about respect if you give me warning messages like this:
Next time, try to respect your fellow gaming communities, and don't interupt real interesting discussions with your logicless plans to conquer the sro scene (xsense & evestu epic c0d3rz 1337)
(if you plan on deleting this post too, I'm seriously gonna lol)
Last edited by yorick671; 25-03-13 at 05:08 PM.
