Some pets in Plane of Sky

[Secrets]

Originally Posted by Congdar

What other things would you like to have a rule to turn off?

http://www.google.com/codesearch/p?h...e%5C.com&l=413

Stuff like that. No reason for having that AA hardcoded like that other than to have it on PEQ working with the PEQ Database, which is why a few of the IRC folks are making fun of the project and calling it PEQEmulator, because, it is essentially becoming properitary to PEQ.

I would much rather it have some kind of space we can put these AAs in, and build up ourselves and have ProjectEQ as a branch on SVN instead of it being the main code. That's just my 2 cents.

[Congdar]

that link doesn't work for me... blank googlecode page.

[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

[Secrets]

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.

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

[Secrets]

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.

[cavedude]

Originally Posted by Secrets

http://www.google.com/codesearch/p?h...e%5C.com&l=413

Stuff like that. No reason for having that AA hardcoded like that other than to have it on PEQ working with the PEQ Database, which is why a few of the IRC folks are making fun of the project and calling it PEQEmulator, because, it is essentially becoming properitary to PEQ.

I would much rather it have some kind of space we can put these AAs in, and build up ourselves and have ProjectEQ as a branch on SVN instead of it being the main code. That's just my 2 cents.

Wrong, try again. The changes in the code are made first and THEN ProjectEQ changes its database to make it compatible, just like everybody else. I have no fucking clue why people claim PEQ is taking over EQEmu but please for my sanity stop it! We only handle the DB and quests, and ultimately are at the mercy of whatever code is put into SVN!

[Secrets]

Originally Posted by cavedude

Wrong, try again. The changes in the code are made first and THEN ProjectEQ changes its database to make it compatible, just like everybody else. I have no fucking clue why people claim PEQ is taking over EQEmu but please for my sanity stop it! We only handle the DB and quests, and ultimately are at the mercy of whatever code is put into SVN!

No idea on why they think that; I never claimed it, just people on IRC are thinking that. Sorry if I offended you, but it's just the IRC crowd presently that are thinking that (and it's because of the fact that people implement the AAs hardcoded in code, amongst other things. I know you guys are innocent bystanders.)

I know we are talking about code that gets in, and most of that is related to making the server work torwards live, which ironically is what PEQ is doing database wise. I just think the *code* needs to take a different direction than it currently is, not the database and quests.

I seriously like the idea of emulating live. It's a wonderful idea. I just don't want this project to *only* do that.

[Congdar]

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
Timestamp: Sun, 17 May 2009 01:12:31 UTC


Message: Not implemented

Line: 277
Char: 259
Code: 0
URI: http://www.google.com/codesearch/js/com.google.codesearch.CachedFile/312B5123B5D57B37203A9F425BE4F703.cache.js

Must be ie8... it says that link sucks.

[cavedude]

Originally Posted by Secrets

No idea on why they think that; I never claimed it, just people on IRC are thinking that. Sorry if I offended you, but it's just the IRC crowd presently that are thinking that (and it's because of the fact that people implement the AAs hardcoded in code, amongst other things. I know you guys are innocent bystanders.)

I know we are talking about code that gets in, and most of that is related to making the server work torwards live, which ironically is what PEQ is doing database wise. I just think the *code* needs to take a different direction than it currently is, not the database and quests.

I seriously like the idea of emulating live. It's a wonderful idea. I just don't want this project to *only* do that.

Sorry if I overreacted. Not a great day here for me, and I don't like people misusing the PEQ name.

AAs and spells, you know I would love to see a database or script based system for those, so the effects can be changed on the fly. I think EQ2Emu has a system like that using LUA and it could be pretty nifty. But, the thing is somebody has to write it! That's all it takes, really.

As for the code, I agree that it should be customizable but not to the point where the main focus of this project (emulating EverQuest) is lost. I think the community is doing a great deal to allow this. We have bots in the code, TONS of rules, and just about everything is open source around here allowing anybody to change stuff as they wish. If just emulating EverQuest was what happens here, then we would have no need for rules, and things like the bots would never ever see SVN.

[ChaosSlayerZ]

Originally Posted by cavedude

As for the code, I agree that it should be customizable but not to the point where the main focus of this project (emulating EverQuest) is lost. .

Cavedude, Emulating Everquest so it allows us to play everquest is the goal of everyone here. The diffirence is HOW we want to play everquest.
The main purpose of the server code is to allow us utilize the client resourses - such as the game engine and graphics. Everything else is secondary.

MANY people who have quit EQ and now here is because they could not stand the way SONY was handlign things INCLUDING how they handled the content given resources they have.

Why did project started in the first place? Cuase someone was not happy with the original.

Look which servers have top popularity among emu players:

Stormhaven - custom content
Scars of Amerous - custom content
Raid Addicts - very custom content
Shards of Delaya - ok given not part of this community- but LARGEST population of any eq-emulation - ultra custom content

Do people realy want to play the same old game over and over and over, the same zones and kill the same exact orc pawn in crushbone for zillionth time?

Think why games like StarCrat and warCraft 3 have outlived themselves? Cuase they came with EDITORS so powerful that allowed people to make their game and complitly diffirent from original.
If those game would not have those editors - they would die out and be forgotten in 5-6 month after release once the hype was over - which has happened with every other game in history.
Learn from this lesson.

Now think what would have happened if SONy had never made Kunark expansion - most of peopel here would never even herd of eq1 cuase it would have been long dead and forgotten.
And the only reason eq1 stil active today (despite loosing majority of its population when eq2/wow came out) - is cuase sony keeps poping out NEW content every 8 month.

Essentialy what I want to do - is to give people NEW content (and I am sure that MANY custom server devs want the same thing), but if dreadful spirit of "how things were on live" keeps hanging around, I will eventualy fail.

Now If we could please get back to the original topic- I want to once again point out that hardcoding somethign like this (pets in Sky) is like hardcoding "no leviation" for dungeons. The feature is a "zone content" - and not a part of the global gameplay, and should be handled via zone script. And I think that Trev has shown as a direction of how to do it.

Think about dozens of things a user of the Emu WON'T be able to do if this fetaure is hard coded, just becuase it was one little special on LIVE.
Yet it will ruin the options of doing what we want with the game for the rest of us.

[drakelord]

Well now, this thread got hijacked sideways. As someone who has played through over 12 MMO's and has had plenty of experience, I'll add in my two cents for whoever cares.

The way I see it, Everquest is a program developed by Sony Online Entertainment that contains maps, models, a GUI, and a basic set of functional rules that the client is governed by. Everything else that exists in the "live" Everquest world is simply an arrangement of the content provided in the client.

I am fairly certain based on my programming classes and discussions with game devs that the server code that SoE uses is designed to be highly variable. Just as an example that is not an MMO, take the source engine and half-life 2. If you open up say, a file for the weapons, you will see about 3 pages worth of #define 's that allow for quick changing of stats such as weapon speed, damage, etc. Albeit this is not in the database, and is in the actual code, it is designed in a way that allows for a quick change if needed.

This is how I feel the server code for EqEmu should be handled. Everything should be designed in a way that makes it fast and powerful, but also fluid. Not only would this help individuals who are not masters at C++/programming, but it would allow for quick changes to emulate events that happen on places such as EQLive. I wouldn't mind 1000 "rules" as long as they are properly arranged and designed with proper documentation to make them effective, if it meant that entire functions would not have to be adjusted if something changed on live.

[Secrets]

Originally Posted by drakelord

Well now, this thread got hijacked sideways.

I wouldn't say it got hijacked... maybe brutally mauled now and there.

I think it's nice we can have civil discussion like this. I think there's a bit of existing tension over the matter of what gets into code, and it's nice that we discuss the future of the project... it just so happens that it was in this thread.