Some pets in Plane of Sky

[ChaosSlayerZ]

Originally Posted by Congdar

It has been like this on Live in the Plane of Sky for nearly a decade, no fractions. It should be in the source, hard coded. I was only askin' if anyone kows if it has been updated on Live to include other pets. It probably hasn't and you don't know. It sounds like you really care though. If you are able to find out for sure, I welcome any real data you can supply.

Well I have to be honest here - the thing I care for foremost - is HIGH level of customization freedom for Emu software. Despite the fact that project started as "live-clone", a SIGNIFICANT portion of ist current admins and players using it for totaly custom content unrelated to live or significantly altered. Most of them also are not people who can code and compile - which means they complitly depedant of actions of peopel who do - such as yourself.

To me as a develovers of fully custom server which has almost no relation to live content wise, a hard coding of a feature like this essentialy means a zone which I will have to throw out, since I have absolutly no reason why in plane of sky pets would be turned into soemthign else, and it will totaly violate my RP content. I am sure there are some people who will agree with me.

If this fetaure is something I can do TURN OFF - I don't mind it, but if its hard coded I am forced to live with it.

This may sounds like my entire plea here is only to accomidate my needs, 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 wihout parts of "live" dangling from all over the place.

I would realy wish that people see Emu project as a global ENGINE for some great custom development which anyoen can turn into difirent direction using a single source, rather than just a clone copy of eq1.

Anyway - once again- why not use perl script file to put illusions on pets and put into quest folder for Sky? Trev on his server has created a perl script which turns anything into anything. I bet you $100 that actual live devs didn't had to hard code this thing =P

[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. I'm really one to talk with all the bots code, but you aren't required to use it so it must be ok with you. It takes a lot of custimization to even get it working. What I have posted in this thread, though, is definitely like EQ Live. I think the underlying vision here is that the source be for emulation of Everquest as this website designates in its name.

What about it Trevius? Maybe with the blocked_spells table and your script, this EQ feature can be less intrusive on those that use the EQemulator for Non-EQness.

BTW, I could RP up any number of reasons why a certain zone changes pets on a custom server and not thow away a whole zone, but your argument for the openness of an emulator is interesting.

[ChaosSlayerZ]

Originally Posted by Congdar

BTW, I could RP up any number of reasons why a certain zone changes pets on a custom server and not thow away a whole zone, but your argument for the openness of an emulator is interesting.

true- so could I . But I will do it better when I will have an option to turn sceletons into batterflies on fridays and into orcs on sundays AT WILL.

Lets look realisticly into what you actualy trying to achive and realise that there is simpler way of doing it wihout ever touching the source.

With perl script in place like is run on Trevs server - ANYONE can change appearnce of ANYTHING in any zone with a NOTEPAD editor - you want all Troll SKs to look like rats - no problem. You can do this in ANY zone with any model.

But once you hard code this - we stock with it exactly this way

In otherwords- don't use the code to make ONE single detail. Use the code to make an ENGINE which can be adjusted with a couple EXTERNALY controlled variables to create ANY detail.

An thankfully for what you trying to do - the engine is allready in place

Here is Trevs code for his Illusionist script. Thsi can be used as a base

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

[trevius]

LOL, my name is all over this thread, I guess I should have been keeping up with it!

I see good points from both sides of the debate here. Yes, ultimately, this is EQEmu, and the source should try to emulate live as closely as possible, because that gives everyone a base to work towards. But, on the other hand, many things can be done with perl and the database that don't require making special exceptions in the source. And, I think we try to cater to everyone as much as possible.

As mentioned, this could probably be handled pretty easily with some basic perl scripting and the blocked spells table. Though, you would probably have to list quite a few spells in the table to block all levels of the other pets, which could stack up to be quite a few if other classes need similar blocks made.

Really, Kayen is the Pet script master lol. That guy has some pretty amazing pet scripts coming out of him lately I bet he could write something up for this in about 5 seconds if he sees the thread.

You could probably even avoid the blocked spells stuff if you just create files for ever pet type from the pets table and put them in the poair quest folder like this:

SumAirR17.pl

And so on. Then, just do:

sub EVENT_SPAWN {
quest::echo(15,"You can only summon Air pets here");
quest::depop();
}

For each one you don't want to allow.

Then, for the rest, you could spawn them and just do a simple race and size change with the quest::npcsize and quest::npcrace commands.

That zone is so customized that you would probably want to handle as much as possible with perl, otherwise, you might find that you are wanting to add more and more to the source just to support this one zone.

[Congdar]

Well, EVENT_SPAWN doesn't work for summoned pets because the script runs before the pet is actually popped so it still looks like the original pet model even though #showstats has the correct id's for race etc. I set a timer in EVENT_SPAWN for 0 and in EVENT_TIMER did the quest::npcrace() stuff and that worked but it was kind of ugly with the original model spawning and then changing.

So it would require almost 40 perl files with 8 lines of code each and 54 database entries in the blocked_spells table to accomplish what 12 lines of C++ code can do, and does better without the spawn glitch. I don't see the perl way as a win, even if it makes the EQemulator more generic.

[ChaosSlayerZ]

Congdar, if you do ultimately decide to go with those 12 lines of C code, please do a me favor and add a 13th line which will have a Rule to turn this thing OFF

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

[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

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