Quote:
Originally Posted by Harakiri23
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
|
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.
~Shin Noir
.
Linear Mode
