Some pets in Plane of Sky

[ChaosSlayerZ]

Originally Posted by Congdar

If it is no longer like this on Live then I guess there's no need for this, but it certainly doesn't change anything about RP if it is still this way on Live.

this is EXACTLY the problem with this kind of approach towards "LIVE"
You trying to mimic what LIVE had or has now, with no regard that LIVE is in fact dymanic. LIVE has an option to create and disable things as they please - we don't. (speicaly those of us who don't know the source that well to manipulate it at will like you do)

Think about crap laod of things which were "live-like" 2 years ago, which no longer are. Suposly you were one of the people who hard-coded all that in back them. TODAY you, been true to live, would have to go and delete all that code cuase its no longer live-like.

My final point is: its complitly POINTLESS to hard code details like that which may only exist for a fraction of a time frame in a game which timespawn has allready exeed a decade.

[Dibalamin]

You can handle the lack of fire, water and earth pets through blocked spells table in sky so they shouldn't need a hard code in the source.

Consequently, this was true as last as 2k6 and Sky has never gone through a wide scale revamp due to it's extremely unique nature.

[Congdar]

Originally Posted by ChaosSlayerZ

My final point is: its complitly POINTLESS to hard code details like that which may only exist for a fraction of a time frame in a game which timespawn has allready exeed a decade.

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.

Thanks Dibalamin, i'll look into that blocked spells table.

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

[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

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