EQClassic's Source Code

Yeahlight@EQC · #1 10-07-2009, 08:12 AM

Earlier today I found out that some of our very old, very inactive developers (that I recently re-granted SVN access) were colluding to take our current work and publish it under a separate, open-source project. They were swiftly removed and unfortunately dragged some good people down with them. Fortunately for you all, though, I am positive that there is at least one aspect of our work that may help you. I have decided to publish our current work, beating those who planned on stabbing me in the back to the chase.

Our work is based on an earlier client, yes, but you guys probably know better than I do that packet structures only changed over time when it was absolutely necessary. I do not think you would have too much trouble porting our structures into your source. The download link is here --> HERE

My pathing work is probably not too useful to your projects anymore, mostly because I see you guys started your own solution, and I am positive our approaches to NPC movement are vastly different, making a port of my work to yours a bit difficult. If you are interested, you would probably have success porting the A* preprocessing system, though. In my testing, A* alone was not sufficient for an enjoyable experience.

At the very least, I recently spent roughly two hundred hours getting spell bolts to function (most of that time was spent getting them to appear) and my solution is fairly good at this point, but still requires a bit of tweaking. The packet structure for your client is most likely different, but I have identified all the magic numbers that are required to spawn a spell projectile. I sincerely doubt these numbers changed over time.

Secrets · #2 10-07-2009, 10:52 AM

Quote:

Originally Posted by Yeahlight@EQC

Earlier today I found out that some of our very old, very inactive developers (that I recently re-granted SVN access) were colluding to take our current work and publish it under a separate, open-source project. They were swiftly removed and unfortunately dragged some good people down with them. Fortunately for you all, though, I am positive that there is at least one aspect of our work that may help you. I have decided to publish our current work, beating those who planned on stabbing me in the back to the chase.

Our work is based on an earlier client, yes, but you guys probably know better than I do that packet structures only changed over time when it was absolutely necessary. I do not think you would have too much trouble porting our structures into your source. The download link is here --> HERE

My pathing work is probably not too useful to your projects anymore, mostly because I see you guys started your own solution, and I am positive our approaches to NPC movement are vastly different, making a port of my work to yours a bit difficult. If you are interested, you would probably have success porting the A* preprocessing system, though. In my testing, A* alone was not sufficient for an enjoyable experience.

At the very least, I recently spent roughly two hundred hours getting spell bolts to function (most of that time was spent getting them to appear) and my solution is fairly good at this point, but still requires a bit of tweaking. The packet structure for your client is most likely different, but I have identified all the magic numbers that are required to spawn a spell projectile. I sincerely doubt these numbers changed over time.

Yeahlight, thank you. You just avoided a hell of a lot of drama for everyone at EQClassic, but at the same time, I feel like you gave into their demands.

I'm worried to go see eqclassic.org now...

Thatkid · #3 10-07-2009, 01:28 PM

Can someone translate this for me, I need you to turn a division question into a simple 2 + 2 = 4 for me

So_1337 · #4 10-07-2009, 02:04 PM

Translate it? Okay. Take all of these changes (and more), and then zip the source code that results from those changes. That's what's being given by Yeahlight.

Many of them are things that are already fixed in our current clients (Titanium and SoF), but some of them could probably be ported over and used here, depending.

Yeahlight: What client were these made against? I didn't see it listed anywhere. It lists when you switched clients and for your dev team to grab the required files and so forth, but it never explicitly said so from what I read. I'm only recently beginning to delve into the source and learn my way around it, but I'd imagine this is a real gem for anyone who knows what they're doing. Just like when TheLieka released TZ/VZ's source code, I imagine this is going to spur a lot of development.

Thanks for this, and sorry to hear you were getting grief from your own development team. From what I read over on your main page, though, it sounds like you took a stand and maintained a heck of a positive attitude about it. I wish you continued success.

Yeahlight@EQC · #5 10-07-2009, 02:37 PM

It is based on the EQTrilogy 2001 stock distribution

Dibalamin · #6 10-07-2009, 07:50 PM

Sorry this happened to you guys.

Getting screwed over like this is never cool.

**trevius** · #7 10-07-2009, 09:51 PM

Yeahlight,

Sorry to hear about the drama with some of your devs who decided to steal work that they had not contributed much into at all.

I haven't looked at your source yet, but it sounds like it wouldn't be hard to use the opcodes and structure you have identified and add them to the EQEmu source to allow your client to run with the current EQEmu source. If so, maybe by combining the work of you and your team with the EQEmu open source project, it can work out to your benefit.

Personally, I see little reason to have multiple closed source projects all based on an open source one, especially when the community isn't very large to begin with. Some have split off in the past to push a very customized world, such as SoD, but even they are considering rejoining the open source project, at least to an extent. By being able to combine the work of multiple separate projects/teams, I think it will be a better over-all experience for everyone from Server Admin/Devs to Players.

Probably one of the bigger problems I see with closed source projects is that sometimes a ton of work/fixes/improvements can be put into the closed source that is based on our Open Source code, and for no specific reason, the closed source project comes to a halt or just never gets completed. And, by the time the source is released (if ever), both the Open Source code and the closed source have deviated so much that it would be a ton of work to attempt a proper code merge.

The EQEmu Open Source project might not be open to every single custom code submission or idea that people come up with, but I do think we can be pretty flexible as long as it something that multiple servers could make use of and isn't impacting to any current setups. I am pretty sure that much of the work you have done on EQC would be things that could probably been added directly into the EQEmu source to improve the emu for your client and in some cases probably all clients.

I know that submitting code through the forums isn't the most fun or efficient way to do it, but I also think that the EQEmu team keeps a close eye on people who do submit code and if they meet the right criteria, they can be added to the team to have direct SVN access to make it much easier to do updates. Then, as long as the updates are good and not breaking other clients or causing crashes (at least not too often), we are pretty flexible about what can be added.

BTW, I saw a video of those bolt spells you got working on Youtube and they looked quite amazing. Nice work!

Sakrateri · #8 10-08-2009, 01:26 AM

There is a bonus to working strictly alone.

Never trust anyone except yourself.

I have learned to do everything totally solo , once its completely finished then it will be released to all to do with what they will.

Harakiri23 · #9 10-08-2009, 08:50 PM

Offtopic:
Since this thread is already here, i think its a good idea to show my (our) gratitude to the former and still existing developers of eqemu, you have done an amazing job so far (my favorites are the hacking of the water/lava files from s3d zone files and the perl quest system - although you got quite a mess with this one atm eh, refactoring ftw), without your work, eqc development couldnt possibly advance this steady and fast as it is currently

Ontopic:

Quote:

Originally Posted by trevius

Personally, I see little reason to have multiple closed source projects all based on an open source one, especially when the community isn't very large to begin with.

you actually gave the reason yourself why it is in the best interest of all that there is NO open source - the community isnt large - there is no point opening dozens servers - this is the fate eqemu currently has - dozens of servers with maybe a 100-200 players at once (still doesnt get close to SoD community - why? its closed source). also i wouldnt worry about a second closed eqc project, to be blunt one of the "returning" developers hasnt added anything at all ever to the project except useless comments and empty class files, the basic knowledge of programming did not exist.

also some people say, open source will attract more developers - this is wrong actually for this kind of project, there were multiple chances to join eqc so far - its not like opening the source will attract more now - people think "hey i may have 1-2 hours and im curious maybe i can add something" - this actually doesnt work in a project of this scale, setting up your dev envirenment and grasping the basics of the code takes far more then 2 hours.

finally, security is an even bigger issue now - with the opcodes and packet structs identified it gets very easy for the average hacker to get programs like showeq running

what this all means is, that we will have to add an additional layer of encryption right before the first release (more work client and server side), i did not think we have to worry about this now because there arent that many people who would try to sniff the packets - but now its all open, there is virtually no work needed to write any hacks

A final note about using opcodes from the triology - given the current state of the eqemu - i find it doubtful that you will find a good way to integrate this old client into the base code. You will have to realize that our structs are alot smaller then yours, there is no augmentation, no aa, the player profile is alot smaller - disciplines are not spells, spells work totally different now etc - the opcodes wont help you - you would have to virtually modify each function which sents outs the structs - even more - the whole inventory handling, there is no shared bank, no guild bank etc... the only thing that now works with "live" data are the item tables because i found a way to map the new item data to the old item structs (we no longer need the binary blob tables).

**Shin Noir** · #10 10-08-2009, 09:35 PM

I may not contribute a lot, but I wouldn't contribute at all if this was a closed source project.

I have no idea what the state of EQ Classic is, as I haven't really seen any demonstrations of it yet, nor do I own a trilogy copy. I've heard of the project for a long time, but until I can get my hands on it, I keep shrugging it off as a "project that will fruit to tuition one day..". I would love to see how it's going though to find where I may contribute if there is places I can discover this. I love the triology expansions, which is why I'm enjoying Project 1999, even if it has limitations on what it can imitate in times of old.

Security has always been an issue, and no matter what is revealed will remain such. Open or closed, you will have them. Live EQ and the battle with ShowEQ is a forever battle, and the ShowEQ team I don't think has access to live EQ's source (I would hope not). I think measuring security of a hacker who can reverse engineer a struct from packets vs. someone who can read source and develop a struct disassemble of packets is not leaps and bounds in difference of skill, it's more just a question of desire and patience. The exploitation of bugs is usually a keen eye and debugging... Open and closed source systems are prone to security flaws.

Not saying one is better than the other, but I am saying I prefer open so I can see what I can do to help.

**KLS** · #11 10-08-2009, 10:09 PM

SoD isn't popular because the source is closed, to the contrary it has more to do with their well developed database and rabidly loyal developers / community than anything else. They're also not completely closed, they've added a lot of things to the project over time, and nothing stops them from adding more.

As stated security by obscurity doesn't really work, give people long enough and they'll destroy it and you'll be screwed cause you planned on it staying secure.

I also would not of joined if the project was closed.

Harakiri23 · #12 10-09-2009, 04:57 AM

Quote:

Originally Posted by Shin Noir

I think measuring security of a hacker who can reverse engineer a struct from packets vs. someone who can read source and develop a struct disassemble of packets is not leaps and bounds in difference of skill, it's more just a question of desire and patience.

the skill difference is enormous, not only do you need more experience in reverse engineering and assembler, but you have to have an idea where you start filtering the netcode

did you ever had to figure out packet structs/opcodes on the current eqemu code? if so, you should know how hard it is, you even got the server source to try out new parameters - but without it the a hacker would just have the packet dump and the client binary

the majority of time currently is still going into discovering what unknown bits are left, not on the actual coding (tho most have been discovered by now).

i did not say anything that hiding the code will help in the long way (i said something similar to security by obscurity a half year ago on eqc when i was not a dev), the point is tho - an initial release could have been done without an additional security layer because the chance on hacking was minimal (not enough people, why should they hack it at all etc) - now with the source all you have todo is tune the showeq parameters from 2001 and you are ready to go - dont tell me that isnt a freaking huge skill difference between one who changes a few parameters in a c/c++ program and somebody who needs to reverse engineer the opcode/struct

**KLS** · #13 10-09-2009, 12:23 PM

You're overestimating the difficulty of finding structs/opcodes, even without source it isn't too hard to figure them out. I have figured out quite a few structs from packet collects myself. Would it be easier to just look at the source and take them? Sure it would but that's not a very good reason to keep things completely closed.

Harakiri23 · #14 10-09-2009, 02:25 PM

Quote:

Originally Posted by KLS

You're overestimating the difficulty of finding structs/opcodes, even without source it isn't too hard to figure them out. I have figured out quite a few structs from packet collects myself. Would it be easier to just look at the source and take them? Sure it would but that's not a very good reason to keep things completely closed.

believe what you want, you have live data and real dumps - those do not exist for the old client - furthermore you cant tell me it *isnt* to hard to find structs with 20-30 members when you know NOTHING of them

seriously, what you have is totally different from what eqc has - you have live server packet dumps - you can login to live and check what the client does when the server sents X - eqc cant do that

dont try to belittle this, this is one of the good reason why to keep things closed

pfyon · #15 10-09-2009, 02:39 PM

Security by obscurity isn't security at all. If someone wants to break into your software, they'll do it (and probably post the details online so others can do it too). The fact that EQEmu exists at all is proof that keeping your software closed won't protect it from being reverse-engineered.

This isn't to say that closed source is all bad, but there's a time and a place for it.

Ultimately the reasons given for keeping the eq classic source closed (showeq) are problems inherent with eq and can't exactly be solved by the server (the solution would could be like WoW's method of sending object updates). Personally, I don't think you would have anything to gain from keeping the eqc source closed.