Some pets in Plane of Sky

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

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