Some pets in Plane of Sky

[trevius]

Personally, I don't really care either way, as I have never been too interested in the zone. Code would be fine, but I certainly wouldn't want to see a rule get added for a specific zone just to have special pets there or not. We already have well over 100 rules, and I think we should try to have some restraint when adding them. I would be fine with this going into the code, but I am still sure that it could be handled in perl very close to as well as it would be in the code. The race change thing where it can't change it at spawn time kinda sucks, but I don't think it is all that bad.

One thing that could probably stop you from having to create dozens of script files or blocked spell entries would be to simply use a default.pl in there and have it check the race and texture of the NPC when it spawns. If it is one of the pet classes that shouldn't be allowed, it can just depop it and echo the message you want. I never really did PoAir much on Live, so I don't know if there are NPCs that are pet classes that might summon those same pet races that players aren't allowed to summon. If so, then that would be bad, because it would be depoping NPC's pets. But, if players can't use them, I think it is unlikely that NPCs would there.

That should be a very simple script and would probably cover most or all scenarios. Then, the only problem left is that you see a normal air pet for a second before it changes it's race.

I am sure there are probably more advanced ways to handle this through perl without having to do much more work than adding the source. I am just thinking simple.

Again, I don't really care either way, but I do think perl could handle this fairly well.

poair/default.pl

sub EVENT_SPAWN {

#75 Elemental
#209 Earth Elemental
#210 Air Elemental
#211 Water Elemental
#212 Fire Elemental

  if ($race == 75 && $texture != 3 || $race == 209 || $race == 211 || $race == 212)
    quest::echo(15,"You can only summon Air pets here");
    quest::depop();
  }

  if ($race == 75 && $texture == 3 || $race == 210) {
    #set your timer and do the race change stuff
  }

}

[So_1337]

I think Congdar made a pretty reasoned argument of why it makes more sense to do this with the code rather than dozens of perl files and lines of database queries. He's shown to know his stuff between both the code and perl scripting with all he's done with the bots, so I'm inclined to believe him when he says it's the best way to code it. If Kayen or anyone else can come along and show a proven, cleaner way of doing it, code or perl or otherwise, then I'm sure he'd be open to it.

I also think Trevius makes a good point that adding code to the source just to support one zone might not be worth all the effort. However, the zone was unique for many reasons, and the behavior of pets there was one of them, and I have to admit I was very excited to see someone wanting to make this the way it should be (per Live; sorry ChaosSlayer). If he's going to take the time to do all the work of coding it simply for the nostalgia factor, I'm going to applaud his effort.

As for making it a rule, I'm sorry, but I don't think one is needed. I realize that many people play on fully customized servers, but I think it's fair to say that the majority of them have played EQ Live before and wouldn't be surprised to see things happening to their pets in that zone, since it's the same thing that happened on Live. If they ask, explain to them that it's hard-coded and you can't change it. I really doubt they're going to want to put your head on a pike for it.

[ChaosSlayerZ]

Trev you are my only hope to save the emu =)

As a final statement, I like to point out that Trev is correct that whatever specials this zone may have, it i posible that some other zone may have some other kind of special (keep in mind 100+ new zones coming soon in SoF)and its better to design a single system to handle any zone in this, rather than hard code them each individualy.

Think what would have happened if all our quests would be hard coded into source code...

Think would would have happened if all our npcs and items would be hard coded in code.

Think what it was like before people invented DBs - evrything was hard coded, and what a nightmare it was to change anything...

[Secrets]

Originally Posted by Congdar

Well, i did post here for input. I didn't realize this would turn into a debate over the source being for EQemulator or CUSTOMemulator.

Actually, this is a really good point. I would rather it not be CUSTOMEmulator or EQEmulator. I would much rather it be a handler for the EverQuest client connecting to an EverQuest server, and what everyone does at the server & client level is up to them. Think of it this way,

We have a lot of AA stuff from PEQ already built into the database. We also have the EverQuest combat formulas hardcoded in the database. Give people a framework on which to build off of, and people will do that. I personally think that we're scaring people off and making it too user friendly by giving everyone their cake and letting them devour it. When people look at the EQEmulator codebase, we don't see a base framework, we instead see the EverQuest Live servers being emulated, instead of the EverQuest client interacting with a server.

I really think, and this might be a bit harsh, that we should rip out everything properitary to ProjectEQ and allow for more customization, while keeping the ProjectEQ codebase as a branch. It would give people who want to keep up-to-date with ProjectEQ and their development and want to contribute to their project a chance to do so, and allow those who want a fully custom server to be able to do so without having to merge all of the PEQ changes out of server code. Yes, I am suggesting we go barebones with the emulator, but keep ProjectEQ in its own branch as an example for people learning how to code and then they can learn what to do and what not to do in the server itself. Ultimately, it's to allow those who want a custom server able to do so, and those who want to make a live-like server still able to. Documentation would be key, as people would be lost if we went barebones with this. This means we would have to document the eqstr_us.txt etc (all of the client files) to be able to do this, instead of alienating (and I use this term lightly, because we don't really alienate people, but instead not give information) people who want to learn how to make their own AA lines, people who want to see how the server source works and communicates with other parts, etc.

I really see it as a learning experience with the potential to have some really great and creative projects come out as a result. I just have been feeling recently as well, that because ProjectEQ is the only thing out there database-wise, that people feel alienated to do anything other than it.

[Congdar]

Originally Posted by ChaosSlayerZ

...but this little thing is one of the many on a very large list of live-like things which damage the ability to do a clean customization...

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

[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

[ChaosSlayerZ]

Originally Posted by Congdar

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

if I actualy start makign a list- it may get sizeable
Few months ago we allready had a discussion about hard coded weapon bonus dmg
Overall things like unique AA handling, build-in racial/class bonuses, combat formulas- all that should be controllable from DB rather than sit inside the source code. (thankfuly as of recent times many thinngs are and it pleases me)

BUt I am always on guard versus evil atempts at hard coding

[trevius]

While I see points on both sides of the argument, I still think PEQ and EQLive should be the priority for code in EQEmu. Custom servers should still be custom EQ servers, and the more generic the server gets, the more this project becomes like a generic MMO engine. If that is what you want, you can get some for free or for a decent price that can be as general or specific as you want them.

I think we currently give plenty of customization options, but within reason. The more and more options that get added, the harder and harder the source is going to get to manage and the more database hits you will be getting for rule checks and what-not, which could build up to be some serious performance hits. This project wasn't designed from the ground up to be a generic MMO server, so it would take almost a complete rewrite to make it into one. I think we need to pick and chose our battles for customization. Anything within reason will not be turned down. But at the same time, I don't want to see 1000+ rules ever, and if ChaosSlayer had his way evertime, we would already be exceeding that amount :P

[ChaosSlayerZ]

Originally Posted by trevius

Anything within reason will not be turned down. But at the same time, I don't want to see 1000+ rules ever, and if ChaosSlayer had his way evertime, we would already be exceeding that amount :P

oh Trev don't scare people off like that. I think i REALY stick out for custom rule like total of 2 times before

In in this specific case with Sky - I am VERY firm- the feature which about to be implemented feels like a zone script event and should realy be handled as one.
Afterall- we didn't hardcoded "no levitation" into all the dungeons - there was better way around which didn't step on anyones toes

The major diffirent betwin doing everything LIVE way and doing it the custom way is that, if its done the LIVE way - this feature is dead locked for all eternity. If its done custom way - you can stil produce same result as LIVE, but it also gives FREEDOM to everyone of doing it difirently or not doing at all.

Customization - is freedom for everyone. LIVE- only benefits LIVE

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

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