|
|
 |
 |
 |
 |
|
 |
 |
|
 |
 |
|
 |
|
Development::Development Forum for development topics and for those interested in EQEMu development. (Not a support forum) |

05-16-2009, 08:28 PM
|
 |
Demi-God
|
|
Join Date: Mar 2009
Location: Umm
Posts: 1,492
|
|
the link works for me- just takes a WHILE to load
Yes, Secrets is right on - the server code should only be the means to conect to the client - everything else should be in a custom DB entry adjusteable on the fly at a whim of the server admin
|
 |
|
 |

05-16-2009, 09:26 PM
|
 |
Demi-God
|
|
Join Date: May 2007
Location: b
Posts: 1,449
|
|
Quote:
Originally Posted by ChaosSlayerZ
the link works for me- just takes a WHILE to load
Yes, Secrets is right on - the server code should only be the means to conect to the client - everything else should be in a custom DB entry adjusteable on the fly at a whim of the server admin
|
No, this is not what I suggested. If you had a thousand rules that were loaded every time, you'd have to tweak them and basically overload MySQL all the time. I am suggesting the code should be customizable in the regards that there should be 2 branches: One for emulating live, and one that is blank that you can build your own systems off of, whether that means stealing code from the emulation of live, or creating your own ground-up framework. It really saddens me that I see people in our community try and make a server and get completely lost while doing so. I have a strong feeling that's due to the server setup being too user friendly. If you have a person relying on just a server setup auto-install, they don't get to make Perl quests, they don't get to do any form of compiling in C++... and they don't learn. Granted, the option is nice for those who are playing LAN servers, but I would rather see the option available for those who wish to create their own custom ground-up servers.
Obviously it's going to be faster to process rules in C rather than loading them and then processing them from MySQL into C. And no one is going to be able to do that while we have a ton of rules stating what you can tweak, thus resulting in more CPU on MySQL, amongst other things related to the actual process waiting back and forth from MySQL for results on things. I could be misunderstanding the rules (they may be loaded in to memory first, but, still -- stuff like loading NPC spawn timers, I'm sure if I looked hard enough I could find about 10-20 cases of this, sometimes involving entire tables.)
Ultimately, I see it this way. If people want to do custom servers, they should be able to start from a base and build up their server rather than always having the skills, spells, and whatever else there may be from live. If people want to have a live-like server, there is a codebase for that. I just want a little more freedom, I don't want war with anyone, and I don't mean to insult anyone's work -- I just want easy options.
|
 |
|
 |
 |
|
 |

05-16-2009, 10:34 PM
|
 |
Developer
|
|
Join Date: Aug 2006
Location: USA
Posts: 5,946
|
|
Honestly, Secrets, what you are talking about is forking the entire project, because if we have to maintain separate trunks all of the time, there is no way both will be equal and eventually, people will work on either one or the other. I hope that never happens.
A large amount of what we can do is limited by the client. And for stuff that is not limited by the client, most things would require giving out patch files to anyone wanting to play on that server, which is something we try to avoid if/when possible.
Keep in mind that we have limited resources for development of the code, and it is ever evolving. If you look at how customizable servers are now compared to a year or 2 ago, I think you will find that it is becoming much more customizable, not less customizable. Sure, some things have to be hard coded, but if anyone can come up with a reasonable way to do it better with minimal impact on all server types, then they are welcome to make suggestions or submit the code themselves. It is rare that changes are turned down.
|
 |
|
 |
 |
|
 |

05-16-2009, 11:09 PM
|
 |
Demi-God
|
|
Join Date: May 2007
Location: b
Posts: 1,449
|
|
Quote:
Originally Posted by trevius
Honestly, Secrets, what you are talking about is forking the entire project, because if we have to maintain separate trunks all of the time, there is no way both will be equal and eventually, people will work on either one or the other. I hope that never happens.
A large amount of what we can do is limited by the client. And for stuff that is not limited by the client, most things would require giving out patch files to anyone wanting to play on that server, which is something we try to avoid if/when possible.
Keep in mind that we have limited resources for development of the code, and it is ever evolving. If you look at how customizable servers are now compared to a year or 2 ago, I think you will find that it is becoming much more customizable, not less customizable. Sure, some things have to be hard coded, but if anyone can come up with a reasonable way to do it better with minimal impact on all server types, then they are welcome to make suggestions or submit the code themselves. It is rare that changes are turned down.
|
Well -- if no one wants to do it, and someone comes along and make their own server, they'll have to merge all the live-like code out, and I guess that's fair enough, you get what you put in work-wise.
I think i've been looking over too many other projects recently, and I wanted to see how this idea would be received. I guess not so well.
Granted, I don't plan on doing it anytime soon, I just wanted to see more customization available for everyone. I haven't actually touched the emulator in a while, but still, I am noticing a trend here, and apparently I was mistaken.
Sorry for bringing this up in a negative light, then.
|
 |
|
 |
Thread Tools |
|
Display Modes |
Hybrid Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -4. The time now is 09:44 AM.
|
|
 |
|
 |
|
|
|
 |
|
 |
|
 |