EQClassic's Source Code
 

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...

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

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.

It is based on the EQTrilogy 2001 stock distribution

Sorry this happened to you guys. :mad: Getting screwed over like this is never cool.

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!

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.

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:
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).

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. ;)

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.

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

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. :rolleyes:

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

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.

This is not quite accurate. We can use collects from Live as a guideline, but they constantly change opcodes and structures, so even though the Live collects may be helpful in some cases, they are nearly useless in others. Take the client update packets for example; They completely re-arrange the order of that packet just about every year. I am sure that is partially to combat SEQ, but it also makes the collects for that type of info from Live useless to us. We don't keep EQEmu current with Live, so really Live collects aren't always as useful as you may think.

Also, just so you know, I had 0 (yes, zero!) experience in opcodes, structures and what-not when I first started trying to get SoF working with EQEmu. I also did not have a single packet collect from when the SoF client was released. Granted that it did take me a month or so before I could even figure out how to get logged in game all of the way, but I was able to figure it all out on my own to that point with 0 previous experience! Of course now I know structures and opcodes pretty-well, but it goes to show that someone with even basic skill in reading packet collects could make quick work of breaking down the key stuff needed. For ShowEQ to work, there are only a very minimal number of structs and opcodes needed. Considering how long SEQ has been around, there is probably 1 that will work almost right away with your client already available on their SVN. And if not, finding the closest one and adjusting a couple of opcodes and structs would be something that wouldn't require an expert.

Honestly, if you guys didn't use SEQ's source to help figure out structs and opcodes from that time, then you probably missed out on saving yourselves a ton of work.

If ShowEQ is your biggest concern, then consider yourselves lucky though. It doesn't take an expert to figure out how to run it, but it does require people to have an extra box and be able to actually load up Linux and figure out how to get it running from that point, which is probably above 95% of the skills of most players out there. Then, of that 5% that might have enough skill to do it, maybe only a few of them would have the extra box and extra time and actually care enough to set one up. In then end, you might have 1% of your players using SEQ. Considering that SEQ only enables them to see spawns on the Map, it definitely isn't one of the worst possible hacks. If you are lucky, SEQ is your biggest hack concern, because the real nasty one is MQ/MQ2, and if that wasn't created around the time of your client, then that one probably isn't a very big concern as it would be hard to get it working with a really old client I assume. Either way, SEQ, IMO, is a much better worry to have than MQ/MQ2.

I don't want to go into too many details on getting SEQ working with your project, but I would not be surprised at all if there wasn't a version of it out there that would work right off the bat without any modifications. And even if it did require modifications, I bet I could get it working within 1 day of your server being out even without the source. And, to be clear, no, that is something I would/will NOT do (in case anyone tries to ask)! If I can do it, then I am sure others can too. So really, SEQ is not a good excuse for closed source IMO. Even MQ isn't really a good reason for closed source as getting MQ to work is based on the client itself, not the server's source. The only closed source anti-hack I can see reason for would be a 3rd party program running on the client side required for logging in that watches for hacks like MQ, which is what Bane of Life has been working on. I can see good reason to keep that tool closed, but the server source really doesn't apply to that anti-hack stuff as far as I can see.

I too would have never gotten involved with developing on this project if it was closed source. Not because I would be against closed source necessarily, but because I wouldn't have been able to look at the source to learn it. I am not the most skilled coder, but I still try to contribute where I can and provide some useful stuff for the entire community. I think this project would have died long ago if it was closed source. Heck, without KLS, this project would have stopped over 2 years ago and been completely dead as far as development goes.

You mentioned SoD being popular because they are closed source and I have to disagree on that as well. Yes, their closed source and many customizations does help their popularity some, but the big thing in any EQEmu project is the content which is mostly database and quests. SoD has a ton of great custom content from years of development. Even if their source was open and other servers could try to duplicate their systems, it still wouldn't mean big impact to the SoD player-base. Maybe if SoD gave out their DB and quests as well as their source code, they might have some competition, but DB and Quests really should be server-specific and kept private in most cases IMO.

Look at PEQ and how they give out everything (Source, DB, and Quests) that they do on a regular basis so that anyone could run an exact copy of PEQ, and yet PEQ remains the most popular server by far. How do they do that? Because they have a great reputation, a great team, and a great player-base, and have been around for years. I am sure that SoD is in a similar situation where they have been around for a long time, have a great team, great player-base and so on.

All EQ Emulating Servers in total probably have a few thousand active members at any one time. It is no secret that a very large percentage of all EQ Emulator players will jump from server to server from time to time. So, the larger the community is as a whole, the larger the player-base will be on average for all decent servers. By having multiple projects all working towards the same goal, but separately, it is reducing the rate of potential improvement to the project as a whole. By doing that, I think it is slowing the player growth rate. The better the source is and the more features/fixes it has, the more players it will attract. Granted, EQEmu is in a really good state now, but compare what we have now to what we had 5 years ago and if we were still in that state now, we would be lucky to have even a small percentage of the total players we have now.

Sure, by having closed source with special features in it, you might be able to gain a large percentage of those players than if the source was open. But, if the over-all player-base of EQ Emulator servers in total is lower, then your larger percentage would probably amount to less total players than if the total player-base was considerably larger. Basically what I am saying is that by bettering the entire project instead of just a single server, you are increasing your potential player-base.

You may think that it would have been harder to implement the Trilogy into EQEmu's source than to do it into closed source, but I don't think that is the case either. Just by putting the structure file and opcode file into the EQEmu source, that would probably have the majority of what is needed. Then, for cases where structures and such don't match, you just need to add in encodes and decodes to make them work, which in most cases isn't a very hard process at all. For special cases like discs where they didn't used to be spells, I think in that particular case, the /discipline commands were used. So, in that case, we should just need to add the new opcodes for them and the packet handling for those commands. Since the /disc commands no longer exist in the newer clients, having packet handling in place for them just for Trilogy wouldn't be a problem at all and should be fairly easy to add. Even for cases where multiple clients may deal with things in different ways, we have stuff in place to differentiate between client versions and can handle each client differently when needed. There are already a few cases for SoF where we have special handling in place, so doing the same for Trilogy wouldn't be too bad either. And, if you wanted to run a server via EQEmu without allowing the newer clients, it would be as easy as not copying over the .conf files for the other clients so the server would not be able to identify them to allow them to connect.

Again, I just see little reason for having closed source on an emulator project. It isn't really hurting the project as a whole, but it also isn't helping it at all when it could be. Not only that, but closed source means 1 of 3 things for the closed source project:

1. The closed source project will branch off completely an start changing things so much that it would be extremely hard for them to ever use the open source to update their server in the future. This also assumes that the project has a good steady team to keep working on it over the years. This is the case with SoD, where their source is so vastly different from ours that their attempt to get a version of SoD running on current EQEmu based code is an extremely massive amount of work. They could benefit greatly by using a good amount of the updates we have provided, but implementing that with what they have is no easy task. Lucky for them, they have had a great team over the years to help them develop new features and fix some of the issues that plagued the version of source they based their server on. Even still, they are stuck with an older client and are still plagued with one very major bug that is hard on their players. They are also missing a considerable amount of features and fixes that EQEmu has added over the years and that they would be able to benefit from. I know that SoD does very well with what they have, but if there was a way to merge what we both have, it would benefit everyone. Unfortunately that is not a simple task and since their source must remained closed, it makes it that much harder.

Sorry, I don't mean to bring SoD into this discussion quite this much, but they are a prime example of a closed source branch from EQEmu. They are also by far the most successful one. But, I also think they could be even more successful if they were somehow able to merge what they have done with what we have currently. Also, Woldaff (if you see this), if you take any of what I am saying the wrong way, I apologize, as I mean no harm to you or SoD. I understand the basics of why things happened the way they did and cannot argue with how things worked out between the 2 projects. But, I also imagine the progress that could have happened if they had never split to begin with :)

2. The project has closed source, but continues to take updates from EQEmu open source when they see a change they want. This way helps to keep their project from missing out on new features, which is good for them. But, it also means a fair amount of work for their dev team to constantly pick and choose what they want to use and then do what is needed to merge the changes into their own closed source. It would be fairly easy for their project to start getting behind in updates, making it harder and harder to get the updates that they want to the open source. Also, over time, some systems get major overhauls, and if they don't make the same changes to their source, it will make doing merges considerably harder in some cases. One instance of this will be when WildcardX finishes rewriting how the whole entity system works. If a closed source project does not adopt that change, it will probably be hard for them to keep doing the regular merges they have in the past. At some point, it will probably be hard for them to attempt to keep up and they will eventually stop doing it. Or, if at any point, their dev team takes a break from the regular updates for a few months at a time, they may get so far behind that they give up on doing updates. So, after that point, they are stuck with whatever they have and whatever closed source work they can do and miss out on most of the great updates that comes from the open source project. This might not be too bad for a while, but after a year or 2 of updates for the open source, the closed source project might find itself far behind with many great new features missing and little chance of ever getting them on their project.


3. The closed source project decides to branch off without ever doing updates from the open source, but also don't have a good or large enough team to make a decent number of changes/fixes to their own code other than maybe adjusting a few key features or adding a couple of fixes. This type of project will quickly leave itself stuck at a certain version of source code and little to no updates. The game will be playable and everything, but the source isn't going to improve at nearly the rate of the open source project and they will soon find themselves outdated and lacking many new nice features from the open source. In this case, they could just run diffs and update to the latest code and just merge in their own small changes each time, but why add the extra work for every update if they could just submit their features or fixes and stay current at any time with little to no work? In most cases, this is going to just prevent this type of server from doing updates regularly if ever at all.


I am sure there are other closed source scenarios that I didn't cover, but those are the 3 main ones I can think of off the top of my head. In any case, I think all of them would benefit from working together with the open source so that all EQ Emulating servers run on the same source code. Sure, some adjustments may need to be made on specific servers for specific custom setups, but generally, most things can go into the source code as long as it doesn't affect the normal EQEmu servers.

It has been almost a year since the new Google SVN was added for EQEmu and we are already over 1000 revisions and a large number of those updates for for adding great new features and fixes. Imagine if the best devs of the closed source projects were instead members of the open source one. They could still be fixing or adding things that they want to have on their own server project, but would also be helping the entire project and allowing their server to stay current at the same time.

Ok, I have no idea where all this talk came from, but before you get up in arms, let's review here:

We're comparing keeping a project closed vs. open. We are saying, if the source is written for the server, and being served to a general population that can then be packet sniffed, the difficulty of doing this is not going to be HUGELY VASTLY MORE DIFFICULT than it is if you have access to the source. The server is broadcasting them after all, if you simply have the time to sit down and isolate what packets go where, you can figure it out. Eventually.

Doing this isn't going to be super easy. But it isn't going to be impossible either. If the source is open, you skip the boring task of sniffing packets and figuring out where the structs line up and such, so it is going to be quicker, but in both of the scenarios it isn't going to stop anyone who is determined to figure it out.

Now talking about eqclassic where the opcodes from the server are not sniffable from a pre-established server: This is a whole different story. I don't recall reading about this earlier, but if I did miss it: I'm sorry. I can see that's going to be pain stakingly hard since you don't have a server laying out the opcode structs on a platter, so it's going to take even more time to try to figure out what the client wants from this inexistant server.

However, even if your project is closed, the very moment you release any form of server any hacker with malicious intent can simply sniff the packets and get your hard work of figuring out op codes with relative ease. And this is where I say being closed vs being open is not going to really be a huge security difference.

If the information is available via open source or via a server, it's not going to take a lot of effort to eventually disassemble them. If the information is NOT available via open source or via a server, it's going to take a a whole lot more effort, but once that server is released anyone else wanting to infrige on that security can do so in the relative ease mentioned above.

Case and point: open vs closed for sake of opcodes != nill point.

Not to toot my own horn, but....well ok, I'm tooting my own horn. :-)

http://www.eqemulator.net/forums/showthread.php?t=29707

Took a few days to get that far, (and I only just started looking at this project!) and the only thing I'm using there is a disassemble of eqgame.exe, a debugger, and the encoder functions in EQemu. Not a single live packet, packet dump, no existing structure, whatever (though I *really* wish I had them right now).

It's a *different* skill set for sure, but I don't think it's entirely all that harder. I think what creates the perception that its harder is that the skill set is much more rare than the dime-a-dozen programmer.

Personally, I don't have any grandiose visions of running a server. I just want to learn and contribute. Can't do either with closed source. *shrug*

On the same note of closed/open source. We don't really have a closed source at 1999, we are just limited to what we can offer back in most cases. I mean, how many devs would explode if we dropped in our zoning kills pets code =D.

Special stuff like that can always be set as a rule to allow any server admin to decide whether or not to use it. The rule system is pretty nice and simple and allows for a considerable amount of customization all with using the same source.

Absolutely. I like to imagine a point where the EQEmu server code includes everything that almost every server type could ever want. Running a classic server with classic rules would be as simple as setting a few rule values in the database. The amount of customization available in the database currently is already vast and allows many, many choices for server operators to run their servers the way they wish without having to modify the source.

I love that things are open source around here, and especially with the PEQ database (where most of my work has been). Making a post and saying "such and such is broken", you could be waiting forever for someone on the project to get around to fix it. Having the ability to write a few queries and submit them myself gives a sense of pride, and it's one less thing that needs fixed.

Keeping EQC a closed source projected has very little to do with discouraging cheating. In fact, while it may sound completely ridiculous to most, there exists one party that may benefit greatly from our work and—at the same time—utterly undermine any plans we may have for the future.

The critical difference between our projects (EQEMU & EQC) is the end result. The derivative works generated here add very little value to the original works, while the derivative works created under EQC may add substantial value to the original works. Those at EQC are not continuously exerting effort to boost some firm’s bottom line.

Now if only I could find an EQ trilogy client for dirt cheap on ebay or something.. I may start working on a merger of EQC + EQEMU code.. :P But that'd be yet another project of mine i'd likely never finish. Sigh. haha.

Despite my prior comments, I would support your decision to close-source if you believe there are profiteers involved here. I had no idea that might be the case.

It's kind of moot anyway, since it's clear from this situation you can't completely close source GPL software. All it takes is one person to not want to keep it closed and there isn't anything you can do to stop them but try to beat them to the punch(such as in this case).

It's open source from the old devs now, They started the project they have the rights to release it if they want. If anyone wants to help in this project. Join eqemu irc channel eqc and come join :D.

Maybe I am misinterpreting this, but it sounds like you are saying that EQEmu has everything to gain by getting access to EQC's source, and that EQC has nothing to gain by having full-time access to EQEmu's source?

Honestly, I don't see how the end result of between EQEmu and EQC is different. Ultimately, the end result is that both of them play emulated EQ. EQC simply decided to work towards compatibility with only a single client and add special features and fixes to simulate a certain time period of EQ, where instead it could have been added to EQEmu as it supports multiple clients and multiple types of servers via rule sets and such.

Trevius don't worry about yeahlight, Hes someone that joined EQC back in 2008. The main devs from 2007 have decided to make it open source and bring it to the eqemu like they should of done from the start. They are in IRC eqemu channel EQC and i know some of them are trying to add it to the current eqemu source.

No, that is not what I am saying. I am not familiar with the policies of this forum, so I figured it would best if I did not drop any names.

What I was trying to say is that a finished product from this project (EQEMU) lends very little to SoE. I am not really sure about the state of their game, so I cannot really comment on what they may potentially take away from this project, but I cannot imagine that a mirrored work would grant them much.

On the other hand, a finished product from EQC would be everything they need to open a new server for the thousands of players that have been petitioning them for a classic experience. I have not been to their forums lately, but I believe I remember seeing a two hundred or more page thread requesting a classic server. They could have a server up and running with our work in about an hour and this is something I would really like to avoid.

Why would they want EQC code ? They admited not long ago they have the classic code from the iron man server they still got. The Iron man server was 2002 i think it was so they got all the code they need.

Theres no way in hell SOE would ever use even a portion of an emulator code for one of their own servers.

LOL yeah.
Its like Microsoft buying code from someone who created home-made replica of Win 3.1 =)

Yeah, if anything, it is the opposite of what you may think as far as SOE is concerned.

I am sure SOE is at least as organized as PEQ is in that they should have every single revision of Server Code they have ever created as well as every version of the Database they have ever ran. In addition, I am sure they have backups of the source for every Client version they have ever built, which is one up on what we have.

Even if they didn't have access to that stuff for some odd reason (who knows, it is SOE afterall lol), I am 100% certain they would never use an EQEmu based source code to run any of their servers. Even at our best, we would still never have everything 100% functional and set perfectly as they could do easily given that they have direct access to the their own code, formulas, database, and so-on. So, I think SOE would have very little if nothing to gain from EQC.

You mentioned them not having anything to gain from EQEmu due to it mirroring Live, but that isn't really true either. Even though one of the main goals of the EQEmu project is to be able to emulate EQLive, that is not the only thing we allow in our source. We have many customized features that SOE could implement to improve EQLive right now. I think it is commonly accepted that the relatively new Merc system on EQLive is a derivative of the BOT system from EQEmu, since we had them first.

We have quite a few nice features that I think EQLive could make nice use of. I will be laughing if I ever see Say Links in EQLive as that will be 100% proof that they follow our work. But their are quite a few other great features like armor tinting for NPCs from the database (vs having to equip items on them), tons of special script commands, and even dozens of awesome ideas from the custom servers out there for content, rewards, and events.

I think SOE would be missing out on utilizing a nice resource if they aren't taking advantage of seeing what EQEmu and the servers here have to offer. Personally, I bet that is one of the reasons why they haven't pushed to shut down EQEmu servers in quite a while; they realize that they have more to gain from it than they have to lose. At least that is what I hope :P They essentially have a huge team of dozens of people all doing creative work for them free of charge!

No, but they have been known to take "ideas" from MQ2 and others...

They don't. I remember a post on the EQ forums from a Dev saying they don't have any of the original files from PoP or earlier. They were lost. That's why instead of modifying poknowledge directly to add new portal stones, they had to add objects. This is also why they can't modify any old zones. The original data to build the s3d files is simply not around any longer. Also why they can't fix the graphical armor problems or add new armor texture... they just simply don't have the original source files.

that all sounds a little too far stretched. I am not working for a software company myself, but 3 of my friends do, and according to them each of the companies backing up data of their projects on DAILY bases regardless if anything was changed in the code or not, for last 15 years.

There could be many other reasons why SOE would do things one way or the other - can't add new armor textures? They simply do not want to spend time and money to do that! Can't modify old zones - there could be issues with intellectual property rights from original creators, so its easier for them to remake entire zone, not to mention to attract people with new graphics.

After all SOE/verant is well know to for YEARS to claim that something is completely not possible and will never happen, and 2-3 years later, they suddenly came up with with this new cool feature "on their own", which has been long suggested by the players. I, for one, gave them the complete technical layout for original Bazaar structure in the old days suggestions forum (back in 2000) - you know what they said? - NEVER GOING TO HAPPEN!
1.5 years later - what do you know - a Bazaar, and almost 90% exact to the specification I gave them.

Exactly, it was Verant before SOE bought them. Hence why those original files are nowhere to be found (either intentionally or unintentionally).

Anyway, we're going off-topic.

I'd hardly call classic eq a sudden "Idea"; Its been being requested by everyone all over their forums for a while now.

To be fair: Verant was always affiliated with Sony, they were a spin off from 989 which was owned by Sony... or did you always think Qeynos was a happy coincidence?

It's pretty silly to think that they would use anyone else's work if they actually wanted to make a classic server. Which I'm not convinced they do, a classic server would be nice for a while but it would eventually lose it's appeal as the nostalgia wore off. Really though, if they wanted to they have all the things in place and it's simply a matter of making another ruleset and turning off some server features and it's pretty much done aside from a bit of content tweaking.

Keep going though, this thread is pretty amusing.

Just to clear some of these theories up, I wanted to mention that most of the things mentioned in this quote that cannot be changed are all things that are included with the client and could be changed extremely easily!

They can't create new armor? The armor files are right in the client install folder. It would be relatively easy for them to create a decent variety of armor sets even if all they did was add new textures. Why this has never been done is far beyond my understanding, but it has nothing to do with them losing files at any point. All they would do is create another equipment file and then adjust the client to load the new equipment file when the client logs in like normal. Maybe they don't do it because it isn't in the budget (extremely ridiculous excuse), or maybe they don't do it because it would cause a heavy performance hit to the client (unlikely, but not as ridiculous of an excuse). I am fairly confident that if I was given the tools to edit the EQG files easily, I could make new armor set textures for all races and all armor types in a couple of weeks. My artistic skills are nothing compared to people who do it professionally, but I bet I could pull something decent off. If distributing those files wasn't a legal risk, I would probably make special sets just for my server right now!

They can't adjust old zones? How many zones have been re-textured over the years? A large amount of them have and some of them weren't even that long ago. I believe even we can adjust old zones by using a tool like Openzone. And, if we can do it, there is no doubt that SOE can.

I also don't think that the mentioned PoK changes are any proof that they don't have the old files. What do you think is easier; adding an object or 2 to an existing zone, or completely modify the zone file itself to expand/change it? The way that SOE does their zone files now is very heavy use of objects to be placed throughout the zone when/where needed, probably to reduce redundancy in most cases. Take a look at the S3DSpy info on the new Freeport zones and you will see that a large majority of the zone is from objects in that file.

There may be some truth in what you are saying about SOE not having everything from when Verant ran things, but I doubt they are missing anything critical. The examples you gave are not related to the source code anyway, as those would more likely to be issues with missing tools for editing old zones/models/equipment/textures/etc. I can see them possibly losing old obsolete tools, but I don't see them losing their old source for client or server or any of their database revisions. Millions of dollars of investment in software should ensure some pretty thorough backups.

KLS is right though; even if they didn't have backups, they would just need to change the rulesets slightly as well as some content and they could be running a Classic server in no time. They have already had progression servers, and Classic is part of progression.