PDA

View Full Version : Quest System


Deimos
10-12-2004, 12:05 PM
Quest System should be updated. I have an idea of what new things should be in it as well. If you are willing to program a new quest system based off of PERL to make quests easier to create, send me a PM =).

I will work on the new Quest System commands and such when u send it to me, kk. One thing is that there needs to be more identifiers for things, I have kept wanting to use ones that aren't there, checking for certain things that you can't do with what is given. I am not talking about Variables or anything, normal identifiers like the one to check race, or class, and such.

Cisyouc
10-12-2004, 12:56 PM
Clarify?
What exactly cant you do with the current PerlQuest system that couldnt be fixed by the means of adding quest:: functions?

-edit-
if($class eq 'Dark Elf')
{
#insert what to do if you're a dark elf
}

should work fine, but this may not be what you were talking about?

Deimos
10-13-2004, 12:21 PM
I was using those as examples if you read it properly.

I have run into problems where I needed new identifiers that I did not have. I know all the PERL default functions and such. We just need new identifiers, seriously. I don't remember what I was trying to do, but it required new events and identifiers. If anyone is interested, I will work on the new quest system that will include identifiers, events, and functions.

I just remembered one of the identifiers. We need one to check GM Rank. There are probably 15-20 new identifiers that we should have enabled in the PERL Language for quests. The update would include these identifiers, the new events, and new functions (all to make life easier). Some of the functions will include GM Commands, so NPC's can perma change race, which is ez, and such. They will be used in the same context as a normal gm command. This would be a major* update to the PERL Quest System.

sdabbs65
10-13-2004, 01:06 PM
None of the new NPC id's match the old quest files.

m0oni9
10-13-2004, 01:14 PM
I am also confused on what you are proposing. How is a "new identifier" different than a variable? Do you mean adding functions? I am certain that whatever you are proposing does not require any sort of rewrite.

Here's the rundown of current perl capabilities:Call perl subs from server
Set variables for perl modules
Enter commands into queue via perl, later to be processed by server
Call C functions from perl
How would you modify this?

sdabbs65
10-13-2004, 01:15 PM
here is something I found that might help out a bit...
search around maybe theres a link to it...
after I ran it all my quest started working.

EQEmu Quest File Re-Processor


Notes:
Use this app at your own risk.
This processor is designed to modify EQEmu quest files to synchronise NPCID's with the database specified and fix some common syntax problems. This process will not modify the source quest files but will create new copies in the destination directory specified.


Requirements:
-MDAC 2.6
-MyODBC 3.51

Deimos
10-13-2004, 02:57 PM
Guys, I know how to write PERL. Dang, you all are thinking I am having problem with $race, I am not. Listen to me carefully everyone, That Was An *Example Of An Identifier* that is used by many.

Cisyouc
10-13-2004, 03:31 PM
Guys, I know how to write PERL. Dang, you all are thinking I am having problem with $race, I am not. Listen to me carefully everyone, That Was An *Example Of An Identifier* that is used by many.I dont understand why you would want it to be written. In the other example you used, you can use $status. Please give more examples of what 'identifiers' you would need that arent already in perl quest? I would assume that these can be added and an overhaul of the system wouldn't really be necessary.

x-scythe
10-13-2004, 03:51 PM
if your going to try and write a new quest system(which i dont see why you would...) why not do it in something other than perl?

but there isnt much the current perl system cant do..and if there is something it cant do it can easily be added in

m0oni9
10-14-2004, 11:39 AM
Guys, I know how to write PERL. Dang, you all are thinking I am having problem with $race, I am not. Listen to me carefully everyone, That Was An *Example Of An Identifier* that is used by many.
I am listening carefully. How about this: write a script that would be used in the new system, and describe what it does. That may be the best way to get your ideas across. The way things are being expressed now is not making much sense. Also, could you define "identifier?" An identifier to me is a label name for a variable, function, etc.

Deimos
10-14-2004, 01:59 PM
Talking to killspree atm about it. New Event names exc, as well as a system that makes more sense to newcomers. I personally know how to use the current system already and am very good at it, want to develop something easier though and that makes more sense, and in this sense I mean things like changing $status to $gmrank and such.

An Identifier that is not currently in the EQGame PERL Quest System is one that checks for HP % and or HP Amount. This will be fairly easy to add in, but, for a new PERL user, these options would not be open to them. Was thinking of something like if($hppercent) and or if($hpamount). I have not seen the brand new and most updated quest system yet, so I do not know if these were already added, but they would be of great help to newcomers of PERL. Other things might include Text Color options, such as, quest::text(Color), which would set it to a color for its text, which is fairly ok to add in. Using these, people could change text from one thing to annother. Advanced PERL Users like myself, Cisyouc, and a few others, know how to add these in and how to use them already, but, for new PERL users, they can't do it. Would be better to present a quest system that doens't require you to add in functions to make it do what you want to do, that doesn't require new Identifiers or Events. We should include everything, this way, more people will learn how to use it. Atm, people are having to make lots of their own functions to do what they truly want to do. I am one of them...

Developers need to work with Advanced PERL Users to create a better quest system that *all* people will be able to use for the most part.

Thank you

sotonin
10-14-2004, 02:06 PM
I mean things like changing $status to $gmrank and such

Status is status because it's called status in the database.

And you really haven't given any reasons yet as to why there should be a new system created. You can add anything and everything in the system we have. Somebody just needs too.

Deimos
10-14-2004, 03:19 PM
Sotonin, you kinda repeated what I said with you can add anything you want to the PERL, it is just a hassle. People would rather have it there all done and ready for them to use. With a new, better, and easier to use quest system that includes all the functions anyone will ever need, people will be happier, because they can do more without making tons of new functions. I thought this would be a good idea. I seem to be the only one that is for it atm.

Listen, I personally think this will attract more people to Emu, but, if people don't want to do it, that is alright. We can always all keep coding in our own functions, which is what a lot of people might like to do. Not sure, this might be a lousy idea, because EverQuest Emulator is supposed to encourage creativity for someone running their own server, as well as Creator in the staff that are working for those servers. Maybe updating the quest system is bad because it takes away from this creativity. People might want to name all of these functions by their own names. Some people I know will probably like it, but not enough of the population to where it will even be worth it. You guys are right and I see this now, it is not worth it, because it takes away some of the creativeness of EverQuest Emulator.

Ty all, when I come up with maybe an entire new layout if I can ever think of one that is better, then I will bring this up again. Until then, this is all good and fine because it allows people to be creative enough to do what they want to do and name things what they want them to be named.

sotonin
10-14-2004, 03:27 PM
Im not even going to read all that repeated stuff heh.

You can add anything you want in the eqemu source you can add in premade functions just like the ones that are there now. There no reason to use anything but perl. What you are truely requesting is somebody make functions that are useful to you.

Instead of this thread make a new one. I want a function that does this. And that and this and that and this. Then somebody might make it, and a developer might put it into source. Or you could share the functions YOU have so greatly boasted you've made and then a developer could add it to the source as a real permanent function.

m0oni9
10-15-2004, 08:27 AM
Instead of this thread make a new one. I want a function that does this. And that and this and that and this. Then somebody might make it, and a developer might put it into source. Or you could share the functions YOU have so greatly boasted you've made and then a developer could add it to the source as a real permanent function.
Yes. There is no need for a new system.

Deimos, you are describing additions or modifications to current functionality -- it has nothing to do with identifier naming. The interpreter already gets about as much mileage as possible, though some of the functions and things should be redone (IMO), it is not the fault of the current interpreter implementation. Rather, those functions (or variables, as the case may be) should be redesigned. I pose the same question as sotonin: If you want something implemented, and are capable of writing it, why not write it and contribute your code?

Since you are an Advanced PERL User, perhaps you could help with the current code some, for instance: hide various info passed during function calls via the perl stack. Or, if you have any ideas beyond changing identifier names, and creating already-existing events, like an actual design spec, please post them.

Deimos
10-15-2004, 12:06 PM
, but, if people don't want to do it, that is alright. We can always all keep coding in our own functions, which is what a lot of people might like to do. Not sure, this might be a lousy idea, because EverQuest Emulator is supposed to encourage creativity for someone running their own server, as well as Creator in the staff that are working for those servers. Maybe updating the quest system is bad because it takes away from this creativity. People might want to name all of these functions by their own names. Some people I know will probably like it, but not enough of the population to where it will even be worth it. You guys are right and I see this now, it is not worth it, because it takes away some of the creativeness of EverQuest Emulator.

Cisyouc
10-16-2004, 12:39 PM
...and we appreciate your input. However, if someone cannot understand the Perl system and find it a hassle, should they really be running a server?

Also, for quest::color("blah");, you can use this:

embparser.cpp line 500, add after:
"sub coloremote{push(@cmd_queue,{func=>'coloremote',args=>join(',',@_)});}"

parser.cpp line 960, add after:
else if (!strcmp(strlwr(command),"coloremote")) {
if(mob)mob->Message(atoi(arglist[0]),atoi(arglist[1]));
}
*crosses that one off the list*

Syntax:
quest::coloremote(15, "Hail, $name");
Will Produce:
Hail, Laeiin.

Cisyouc
10-16-2004, 12:42 PM
Also, if($hppercent) and or if($hpamount) could be easily written. I just came back from a party so I dont have the energy to go through it and write it, but its easily possible.

m0oni9
10-16-2004, 04:11 PM
Also, if($hppercent) and or if($hpamount) could be easily written. I just came back from a party so I dont have the energy to go through it and write it, but its easily possible.
sandy was doing something with HP events a while back. At a glance, it looks like there is an EVENT_HP event. There is also a variable named $hpratio. I think that you have to call setnexthpevent(hp) in your perl script (in EVENT_SPAWN maybe?), and that will call EVENT_HP at the specified hp ratio. Not sure on this. Maybe it is in the docs.

Cisyouc
10-16-2004, 04:27 PM
Also, if($hppercent) and or if($hpamount) could be easily written. I just came back from a party so I dont have the energy to go through it and write it, but its easily possible.
sandy was doing something with HP events a while back. At a glance, it looks like there is an EVENT_HP event. There is also a variable named $hpratio. I think that you have to call setnexthpevent(hp) in your perl script (in EVENT_SPAWN maybe?), and that will call EVENT_HP at the specified hp ratio. Not sure on this. Maybe it is in the docs.If Im not mistaken thats for the mobs hps not the clients.

Scorpx725
10-17-2004, 03:40 AM
I dont really see the point in writing a new system. As the others have said, adding more perl functions is easy. Theres no need to write a new system. Someone just adding them in would be easier, and less time consuming then writing an entire new system.

And as someone else said, if your having trouble with perl, Im not too sure you should be working on a server.

Deimos
10-18-2004, 01:29 AM
Guys, once again, I know how to add them in, exc. Also, above, if you read the comment, I said I agree with you all... There is no need to keep replying or posting how to do certain things =|.

Lurker_005
10-18-2004, 06:42 PM
Deimos, If you really want a new quest system, write it. If it is better I'm sure it will get added to the code and used.

But, what I think, and gather from the others posts is that they are at least content, if not happy with the perl system. That being so they would be happier if you put your tallents toward extending the existing system instead of writing a new one. If something can't be done or is not easy, identify it and if possible propose a way to get it done/make it easier.

RangerDown
10-19-2004, 02:12 AM
Lurker said it best.

The two arguments you give for a redo are: (1) some functions aren't there you believe should be there, and you aren't happy with the what some variables are named, and (2) you believe it is too complicated for some server ops to use.

(1) It's unreasonable to expect to predict everything a server op might want to do in quests. If you find some quest functionality in EQlive quests/encounters that we don't have Perl functions for, then point them out. Perhaps write the hooks in yourself and submit them for CVS consideration. Wanting to flag GM rank via quest is the first time I've heard of that, and for obvious security reasons there is no quest to do that in EQlive. But since our goal is to emulate EQlive, I'm quite certain that objective carries over into the quest system -- if EQlive does it, then eventually our quest system will do it too.

Nobody is going to want to overhaul the system based purely on semantics. You want $gmrank, I want it kept at $status. Either way, I don't think any variable names are worth overhauling. Too many quests have been written among the various servers to up and change variable names at this point and break all those quests.

(2) Perl was chosen because we wanted the flexibility and power of a scripting engine. We need to be able to evaluate complex conditions, take an indefinite number of actions, and be triggered from a variety of events. That's a pretty powerful scripting engine that would have to do that... and we have it, and best of all, we didn't have to mess around with the scripting engine itself, Larry Wall did that work for us :)

There are quest editors out there whose design is to present a more friendly interface to the user, and allow the user to design quests with said friendly interface, while the editor does the dirty work of making perl code behind the scenes. Having these editors is a great way to make quests easy enough for the perl-unsavvy, without compromising the power of the underlying quest engine. If you attempt to dumb down the quest engine itself, I guarantee what you're proposing will not be accepted by the user base.

Deimos
10-19-2004, 09:30 AM
Last time I am going to say this, you all seem not to be reading what I am saying at all....


I do not see it necessary anymore to make a new quest system. You are all still commenting like I think what I first thuoght, but if you read what I am typing, you will see that I am agreeing with you all....

Jeezes, tx.

(Doesn't want anymore posts where people think I see that this is necessary. Told you all a long time ago and am still getting posts.)


You guys are right and I see this now, it is not worth it, because it takes away some of the creativeness of EverQuest Emulator.

sotonin
10-19-2004, 09:38 AM
You opened the pandora's box. It's too late to close it :lol:

Deimos
10-19-2004, 11:32 AM
lol

killspree
10-19-2004, 05:18 PM
Lets not get sidetracked. I'll agree that some aspects of the perl system are...odd, to new users(mainly the names of variables, etc).

The guide could also use an update, which I'll try to do soon since I don't think monrezz is around anymore to keep it updated.