psremu, ideas?

[Shadow_Soul]

**** no one saw my cool reply when i was making jmerlin proud at the end of thread 3 ^^
ohhh guess i'm just a low level jm3tard
KTNXBAI !

[Eckoro]

Originally Posted by Shadow_Soul

**** no one saw my cool reply when i was making jmerlin proud at the end of thread 3 ^^
ohhh guess i'm just a low level jm3tard
KTNXBAI !

@Shadow_Soul
Well I read it in response to the benefit you suggest I/eSRO would gain from it, we would not really get much out of it, since I got probably around 80% of the packets, which are all the ones that are gonna be on the public wiki.

@Yo123
The packets dont vary to much there is slight differences, not anything significant, opcodes should not be a problem if you have some reverse skills and can create an opcode parser, so you can match the different locales.

@jM3
If you keep up that approach of 'other people', you wont finish emu, just reverse them yourself, you will do a far greater job since this is your area of expertise, why leave it up to inexperience people?

[Yo123]

Originally Posted by Eckoro

@Shadow_Soul

@Yo123
The packets dont vary to much there is slight differences, not anything significant, opcodes should not be a problem if you have some reverse skills and can create an opcode parser, so you can match the different locales.

i dunno, since i basically work between swsro and csro, they have the same opcodes but different (reaaaaally different) packet structures.
opcodes yea pretty much it's just about to find out what others are for that do not exist in your own version ^-^

[Eckoro]

Originally Posted by Yo123

i dunno, since i basically work between swsro and csro, they have the same opcodes but different (reaaaaally different) packet structures.
opcodes yea pretty much it's just about to find out what others are for that do not exist in your own version ^-^

swSRO is like a pre-historic version of silkroad, where as cSRO is up to date, so there are gonna be some variations, like with new functions, new bytes may need to be implemented into packets etc etc.

[jM3]

Originally Posted by Eckoro

@jM3
If you keep up that approach of 'other people', you wont finish emu, just reverse them yourself, you will do a far greater job since this is your area of expertise, why leave it up to inexperience people?

Well for one, reversing is a shitload of work when a lot of people already have most of the packets figured out.

It seems absurd we should all have to do it over and over for each project because nobody shares.

There are things in some of these packets people haven't figured out yet, but they never seem to change so we just hard-code those bytes, and some packets we don't know wtf they do or are for. If you guys weren't so selfish with packet shit, I would gladly reverse the packet handlers and tell you exactly what those fields are. As it stands, the most I do is hook their binary buffer api which gives me an output like the old sremu loader (which doesn't work anymore, because they changed it -.-), so you see each field in the packet and its proper size (dword is 4 bytes on a line by itself, a string is the entire string on a line by itself, etc).

I don't know if you have a tool like that but I'd give you that too in exchange for information, I just don't see why you want to justify "it took me a long time" to not share information. It took us many many centuries as a race to figure out a lot of shit but that information is widely available to anyone who cares to learn about it. Math for example, early on, was kept "secret" because with proprietary knowledge and algorithms, one could pretty much guarantee he'd have a job doing something. Now, there's very little math that isn't published openly, you could say that field has reached enlightenment where everyone realizes the power of openness in information vs keeping it private, the first leads to dramatic growth, the latter leads to stagnation and eventual death.

Which do you think represents better the silkroad emulator community over the past.. oh.. 4-6 YEARS whereas games with far more complex netcodes, encryptions, and protection schemes have almost complete emulators running within 2-3 months after the game's launch? Seems like something's wrong here, and there is, ALL OF THOSE ARE COMPLETELY OPEN-INFORMATION. Seriously, within the first 2 weeks of Aion's launch, I could get every packet structure and the encryption code right there, easy, it's no wonder someone picked that info up and made a fully functional emu.

I don't know what you possibly hope to gain by being such a tight-ass about packets, but you're fucking up the entire community by doing so. It took cls, myself, and drew some weeks of difficult reversing to give you guys the netcode protections reversed, and for all that "hard work" (and yes, it wasn't easy), we get from you a "lol, go figure them out yourself."

Hypocritical ingrate is the only term I can think that would appropriately describe you.

[Eckoro]

All ready got an auto-parser analyzer, thanks to Klevre.

Well if I used more of YOUR releases or information jMerliN, I may be inclined to sharing some of my research, however so far I have not, so I am not inclined to give away my WHOLE packet archive which I spent months on in an instant, just so it can fuel your necesity for them. Windrius has already given you packets and you cannot even say thank you for them, just response "more."

I have offered to give knowledge and insight into any analysis you do, but I am not commiting myself, (above ^) to giving my whole archive, as I do not get any benefit from it. Free entry into a closed beta, how appealing.

I don't know what you possibly hope to gain by being such a tight-*** about packets, but you're ******* up the entire community by doing so.

So just me not sharing my packets for reasons I have explained on many occassions, I personally am ******* up the ENTIRE community, that makes sense, lol, everything does not revolve around me, there are plenty of other people with resources you can look to.

[jM3]

Originally Posted by Eckoro

All ready got an auto-parser analyzer, thanks to Klevre.

An analyzer is worthless once you already have packet structures. It's like creating a device to determine whether or not water is wet when you already know water is wet. What's the point?

Originally Posted by Eckoro

Well if I used more of YOUR releases or information jMerliN, I may be inclined to sharing some of my research, however so far I have not, so I am not inclined to give away my WHOLE packet archive which I spent months on in an instant, just so it can fuel your necesity for them. Windrius has already given you packets and you cannot even say thank you for them, just response "more."

I did say thanks when he gave them to me. The point isn't to help someone else ONLY when they help you, if you read what I said, that's exactly the same as keeping information proprietary and secret. The only reason these other games have communities that make this one look like a fucking shithole is because every last bit of information is easily available to anyone.. ANYONE.. even the goddamn leechers who haven't done a damn thing for anyone at all, can download it all for nothing. I've shared everything I've figured out about the game with the community, and still planned to, just not the code I wrote as my specific implementation. Very few of you deserved that openness, and those who did, didn't need it because they already knew it anyway. Like I said, selfish to the core.

Originally Posted by Eckoro

I have offered to give knowledge and insight into any analysis you do, but I am not commiting myself, (above ^) to giving my whole archive, as I do not get any benefit from it. Free entry into a closed beta, how appealing.

I already told you there would be plenty of benefit. I never once offered free entry into the closed beta (it only costs $10). I'll laugh if eventually I compute what I said I'd give you to be some astronomical amount of money, since you're so driven by "gimme gimme gimme" in return for any information from you, it'd be a hilarious level of irony.

Originally Posted by Eckoro

So just me not sharing my packets for reasons I have explained on many occassions, I personally am fucking up the ENTIRE community, that makes sense, lol, everything does not revolve around me, there are plenty of other people with resources you can look to.

When you're one of a handful with the information but nobody cares to share it with anyone, not even those capable of actually writing decent software, you most definitely are PERSONALLY responsible for the state of this place.

In the real world, which I hope you reach one day, two different groups create two different pieces to a puzzle, if they didn't share their work in some way, that puzzle would NEVER be completed, or each would have to try to reproduce the other's piece and you'd end up with some shitty awkward pile of garbage nobody wants. What you're arguing for here, is that you want us to have a.. a shitty awkward pile of garbage as an emulator. If you care about the game so much as to spend months to figure out the packets in the slowest way possible, surely you don't want such a shitty outcome, but again, you won't do anything that doesn't benefit you in some way. That's just pathetic.




If anyone here who isn't someone in esro or klevre can give me a large majority of the packets completely parsed right now, I will release sremu's binary completely unlocked so anyone can use it.

I'll make that promise to this community right now. I would've done that in the beginning but nobody who can help ever offers it. But if I'm really going to have to sit here and deal with assholes like these, there's no fucking way I'm ever releasing anything more than the most gimped pathetic emulator ever publicly.

[Eckoro]

Well least we figured out what the topics purpose summed down to now, but I just wish good luck in continuing your project, also please dont call me selfish, I have shared plenty of packets and knowledge with other people, one being CSREmu, other people in general. But I am not giving away my whole archive or large quantities which you only desire, so farewell.

[jM3]

Originally Posted by Eckoro

Well least we figured out what the topics purpose summed down to now, but I just wish good luck in continuing your project, also please dont call me selfish, I have shared plenty of packets and knowledge with other people, one being CSREmu, other people in general. But I am not giving away my whole archive or large quantities which you only desire, so farewell.

Ask anyone working on an emulator if they "desire" the packet structures here. There's no way in hell you can find one who doesn't want them all.

The core I've written is around 40,000 lines of code that rivals and beats corporate level software developed for extreme performance. Without someone showing an act of kindness to this community, I'm not willing to share that with anyone but myself, because that code has NOTHING to do with SRO.

[supertrilo]

well this thread isn't going any where any time soon

[Windrius]

Originally Posted by Maciupka

***

Originally Posted by Eckoro

also please dont call me selfish

Your selfish. xD hahaha that was fun. I wanna do it again! selfish. Selfish! SELFISH! wow. Add a few more Sel to that fish and it'll really be fun to say.

[Shadow_Soul]

i'm approving jmerlin, we should start helping each other , as community , together we can reach somewhere , just like he sayid , other game emulator has been made in 2 - 3 months , and fully working , we can do this in sro if we stick together , and work as a team , and eckoro , is not selfish , he just worked a lot for those packets , and its very hard to gave them away to someone that hasn't work at all for them, it would be hard for me aswell , but jmerlin promise that he'l give something in return ...
Eckoro you should team up with jmerlin and stop being such a proudass
I understand that you worked hard for those packets but you're project will just die like the others did .... think about someone else then you're self !
Wait actually think only about you're self give jmerlin the data he needs and think how fast you're emu will be done , with his help , you're working on esro for how long ? 1-2 years i'm not sure , but i think jmerlin can help you guys just give him the data he needs, he is not selfish after hes done with his project iam pretty sure he will remember ho helped him get there , and he will help you finish yours , or jsut do it for the greater good we need you're help eckoro , don't leave us

[Windrius]

btw people. You know why other game emulators are built in a few weeks/months or w.e.? Because in other communitys people actually have brains, work together and not just leech. But SRO community is really much more diffrent. I'd say there aren't more than 20 people in this community who actually do something. So anyway. :P The idea of this community achieving anything together, is just a dream

[Shadowz75]

Originally Posted by Maciupka

fuck you and get the fuck out

@jmerlin,eckoro i will quote a post from drew:

There's a lot in this thread I could probably write essay length responses too, but instead I just want to quickly address the recurring point of open source development and getting a community active with a project:

It all boils down to the design.

Over the years, I've released a lot of code and have even more that I had never released. While I had good intentions in releasing all that code, I'd honestly say, looking back at it now, most of it poorly designed. To put more bluntly, most of my code is crap. I look at my source code nowadays and just go bleh, it's not pleasant.

Of course, I was learning a lot of stuff when I had coded it (and still am), so it's expected to not be above average quality. Programming is no easy task in itself, especially when you are working with ASM/C/C++, so it's something you do have to spend a lot of time on to get better at and then reevaluate the way you go about coding things.

All of my frameworks were C++ driven and utilized DLL plugins. This design requires any end users to also know C++ and be able to work with a low level API to implement what they need to. Needless to say, there were not that many people who actually used and developed with that stuff. After all this time, I see now that I could redesign the code over and over and release new stuff, but I'd always end up with the same results.

Why? Because the majority of the intended audience of end users aren't going to have the necessary background, resources, or time to fully utilize such things. The people who could actually make use of it, were more than capable of doing it themselves, they just might have gotten a few ideas and then went their own direction.

The same thing happens with emu projects. You get these huge monolithic programs that are poorly designed and as a result, no one contributes to them. It's not that it is anyone's fault, because that's just the nature of programming. A lot of paid professionals can't write well designed code, so how can we expected anyone doing it for free who is learning along the way to?

What's needed is a radical change of development methodology.

I think most community based emu projects try to solve the wrong problems using the wrong methods. They are trying to figure out how to code a SRO emu by simply handling opcodes and using simple network code (I've been guilty of this myself). Then, they upload that base to some version control system online and expect people to download it and contribute to it. This just doesn't work out.

Instead, what they need to be doing is trying to figure out how to design an emu framework that will:
1) provide developers the means to easily (and freely) program the system without having to install or download tons of stuff
2) allow developers to work from a common unmodifiable base that they can use to develop their own additions that won't conflict with other people's work
3) establish a set of coding guidelines, support, ethical practices, documentation, resources, and tutorials so new users want to join and get working without having to figure out things on their own.

Those things aren't easy, but the point is most projects aren't developed with community support in mind in the first place, even if it's desired. As a result, you get little to no contributed work or other people taking the project and making their own branches of it so they can do things their way.

I don't have an answer to the problem, but I've been looking for one on and off over the years. Right now, I think the most ideal design would be like this:
(Networking)
4 Layer Server:
Layer 1 (lowest) - Uses the core networking library (in my case, boost::asio, no more custom tcp code). It manages connections and handles reads/writes of raw data. This layer has no concept of "packets" and just works with raw data.
Layer 2 - Implements the game specific network protocol. Handles encryption and decryption as well as security of the packets. It gets data ready for layer 3 or takes data from layer 3 and passes it to 1.
Layer 3 - Packet processing layer. This layer serializes and deserializes packets into game objects. For me, this would all be done in a scripting language to allow easy modification and development.
Layer 4 - High level game object processing. This layer is connected to the non-network game logic of the emu. It passes the higher level objects to the simulation for processing. This too would all be done in scripting.

(Logic)
Purely script driven. A predefined API would need to be developed first to handle sending events, modifying data, or registering new modules. This can get really tricky and messy, so it must be thought out ahead of time or the project will face setbacks on major changes that require code rewrites.

Resource loading would take place and reside on the C++ side of things, but all of the data would be exposed to the scripting interface for easy access. Likewise, for more advanced modules, a DLL based plugin system could be implemented to allow more performance and power for tasks that are not best suited in a scripting language.

That's it really. You get your main packet parsing done via scripts, which parse into higher level objects first. Those scripts can easily be shared with other people and dropped into the system. Then, those objects get passed to the simulation logic, which is also scripted. Core code is never touched or modified and the scripts should be setup to allow runtime changes without having to restart (barring crashes or desynchronization errors).

The hardest part in that, is coming up with an internal scripting interface for users to adhere to when developing stuff that won't have to be redesigned down the line. It needs to be easy to use and for users to write their own documentation for their code so others can use it. This is where I'll probably spend a lot of time brainstorming.

I had some simple PoC code done a while back using Lua and was able to implement a complete login server in like a day tops. Going on to the world server, I was able to easily add new packet processing logic on the fly and it was really fun. However, things quickly became messy, unmanageable, and eventually unmaintainable due to the initial design, so a rework was needed in the Lua interface. Trying to code something like this with so many unknowns is very much trial and error.

If such a system were to be done though, then I think more people would want to join and contribute because they actually could do something. Scripting is pretty easy and a lot of games use it nowadays so more people have access to it than they would say something like C++ or Java. I've not touched on enough specifics to go more in depth about the community aspects of the project, but hopefully I've made the point clear: if you want to develop a community based emu, then design for a community based emu.

I'll probably post some PoC code later on after I get some more stuff done. I've been working on figuring out how to implement the 4 layer server approach using boost::asio and I think I almost have layer 1 working right now. Layer 2 is easy since I have my security api, but 3 is what will take some thinking out. Layer 4 has been the biggest problem for me always since you have to think in terms of game design, which I'm not terribly good at all.

I should note that I'm not going to be trying to code an emu server for SRO. I've just come to accept the magnitude of the task and my inability to commit to such a huge project and will only work on "concepts" related to emu development. Hopefully, I'll learn some more stuff to be used in other games where I might be interested in an emu project, just not for SRO.

I think we need something like Drews concept to get the community help each other, otherwise it wont be sucessfull.e.g. Eckoro could contribute to the project without publishing all of his work.

[Shadow_Soul]

Originally Posted by Windrius

btw people. You know why other game emulators are built in a few weeks/months or w.e.? Because in other communitys people actually have brains, work together and not just leech. But SRO community is really much more diffrent. I'd say there aren't more than 20 people in this community who actually do something. So anyway. :P The idea of this community achieving anything together, is just a dream

yea ur right...
but many people will want to help iam sure of it
we just need some tuts on "how to" and we can be pretty good slaves for someones emulator if we would know how to sniff and so on ...
just make some tutorials and il give you packets , but it seems that no one is willing to teach a bunch of newbies how to sniff even if we can help a lot , for example if we sniff 1 -3 packets per day , per person, imagine how many you would get for 200-300 persons that are sniffing and reversing it if thats how its called sorry i'm a noob but i am willing to help you guys , i just want you guys to make a recruiting thread for this , and a video tutorial on youtube with links to the needed programs , in that video you just have to sniff a packet and we'l see , and catch things realy quick, and baaam new server emulator in a couple of weeks watch say ?