New Perl System -> Requests
 

Hello,

In light of the newly revamped perl system I am putting together, I would like to ask the people who actually write quests what kinds of functions they think are missing from the current perl implementation.

The new perl stuff I am doing will preserve old behaviors, but greatly enhance the system as a whole. One of the biggest things that I am introducing is the ability to return values from quest functions. The first thing I have implemented with this, as an example of what can be done, is this:
quest::ChooseRandom(1001, 1002, 1003, ...)

which will pick one thing out of the list of things supplied to it, and return that value., for an example use:
quest::summonitem(quest::ChooseRandom(1001, 1002, 1003));
would give you a random cloth thing..

I plan to add entire objects for the NPC and Client involved soon, so you can do almost anything in perl that you can do in C++ right now, like $client->GetLevelCon($npc->GetLevel());

im not looking for big dynamics changes, just little functions that would be useful.

anyways, ideas?

-Disregard-

FNW,

i think there's some work to do on making available internal PC structs data to perl context (like $currenthp, $currentmana, $whatever).

Also, allowing to update (change) these values from perl should be nice. i guess simple perl wrapper for C functions that already exist would be nice.

On the other hand .. please do not try to rewrite perl language or libraries. Quest ::ChooseRandom(1001,1002,1003) has no reason to be anything else than a perl plugin imho.

this is already possible in the new system from what i understand. i beleive it's one of the main reasons for the revamp

I have a question about the new revamp itself. Will old commands be backward compatible or will the syntax have to be reformatted?

Should we be adding things that are already possible with perl?

possible, yes... simple for non-perl people... no. iv seen numerous posts about it, and been asked on irc countless times how to do it... if it were inherintly easy, people wouldent need to ask about it.

on the same token, sure it could be put into a plugin, but
1. I have yet to see people release any standard useful plugins
2. why require a plugin for something that is such a frequent operation
3. It makes the quests that use it (many, many quests) standardized, so they work anywhere without having to track down the right plugin.

Perl is a language .. nothing more, nothing less.

You can substitute perl for a new language, still people have to learn it and how to use it. I believe it is what pple have trouble with :/
At least, perl is bug free, there are zillions tutorials, and it's very easily extensible, and ...

As for releasing plugins / recipes / snippets, here's the code for quest::RandomChoice(a,b,c) :

or, inlined :
Was it worth a post ?

Getting such a EQEMu 'library' can be usefull, if people what plugins then they have to work for it.

Now, if you want to build wizards that generate quests out of couple clicks, it might very much help some people. Just like Visual studio helps writting C or C++ :(. It does not define a new language (or if it does, you wouldn't say it's better, would you ?)

An EVENT_TIMEOFDAY would be useful. Some NPC scripts start when a certain in-game hour of the day hits.

Smogo, a lot of us dont know perl like the back of our hands like you apparently do, don't put this down just because you are above it. We need this. It will be very helpful and increase the quest creation overall, something we sorely need.

i would love to see somehow a way to tag players...

let me explain..

im not really good at perl so pls bare with me..

tag.posion=1
if (<playera.tag.poison>>=1)
then whatever


im not sure if this is possible. but heres why i would love this..

it could set variables to players.. in certain situations.. still im so new to perl and maybe this is already possible... but i think this would be good..

also is there a way to call an enviroment change

meaning if player a was in zone..
and it starts raining
then a sub event would happen but only when it rains..

hmm why? well then you could say.. player is freezing to death..
player is soak and wet..

i know it sounds kinda stupid.. but hey.. the more flexiability i can get .. the better the coding could be

You can flag players with the qglobals system that scorp2k added a while back.

FYI, i didn't know much of perl before i registered these boards. Then i used google and read a few books to learn it.

i believe the actual system can be improved. But just to be clear : you could make it C++ like, or VB like ... it wouldn't make the creation of quests instant. XS was a big improvement tool to the perl quest system. It's been underused. Still people need to program ... that's the problem imo.

i won't judge before i know what FNW want's to do, this was just a contribution, not trying to show i'm 'above' anything.

I was kind of curious about this. By new system is it meant that much of the code is going over to XS?

And I'd have to agree with adding simplified methods/wrappers for accomplishing things that are already possible in perl. This not only makes it easier for those newer to perl to get things done, but quicker/cleaner for everyone else. This is why libraries are a good thing.

yes, everything is moving to XS, command queue is going away completely. This is in fact due to you making me aware of the command queue.... which is a total hack. Im keeping the old system around for whatever reason... I even converted the .qst system to use the new methods... no idea why, i doubt it even compiles (: