New Perl System -> Requests

[fathernitwit]

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?

[Malignus Wingnut]

-Disregard-

[smogo]

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.

[sotonin]

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


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

[Cisyouc]

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

[Scorpious2k]

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

[fathernitwit]

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.

[smogo]

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) :

sub RandomChoice{
@values=shift;
$choice=$values[int(rand(length @values))];
return $choice;
}

or, inlined :
$values=(1001,1002,1003);
...
$choice=$values[int(rand(3))];
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 ?)

[RangerDown]

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

[sotonin]

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.

[Cutter]

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

[killspree]

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

[smogo]

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.

[m0oni9]

XS was a big improvement tool to the perl quest system. It's been underused.
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.

[fathernitwit]

By new system is it meant that much of the code is going over to XS?

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 (:

[m0oni9]

yes, everything is moving to XS
Awesome. I wanted to devote some time to converting stuff over, but it never happened. Keep up the good work, FNW.

[Sarepean]

Okay--- question. After the revamp, will the old perl quests that are already in existence work with little to no changes?

The reason I'm asking is because I spent all morning spitting up code in order to get the newbie armor quests for Ak'anon working (still working on the tradeskill thing... can't get the container to combine and trying to figure out what dictates which containers can combine the recipes when the recipes aren't tradeskill specific). I was planning on hitting this stuff every weekend until I had everything from EQ Classic (that I could get my hands on) done. Unfortunately, I don't have an EQ account, so some things are a little cheesy or not quite complete yet. =/ Which reminds me, when I do faction changes in a perl quest file, it apparently does the faction changes, but it doesn't give the messages that they changed. Is there a way to do that???

-Sarepean

[killspree]

I'd like to see a quest::message("text") added which only sends the message to the person triggering it. Sort of like a way to give that person the basic objective of the quest, without having to spam everyone with the message like emote does.

[cofruben]

you can use mob->CastToClient()->Message(0,"...."); for that

[fathernitwit]

you can use mob->CastToClient()->Message(0,"...."); for that

not anymore, I wouldent advise using it, its not gunna be around long.... thats a total hack of a sub name, and I took it out. There will be several, more appropriate ways to do this when im done.

[Cans]

Sorry for not being too quick on this XS thing, but I'm just confused on something.

Does this change mean the whole quest::say(), etc, system is gone and no longer usable?

And if so, what exactly, besides the general XS term, is replacing it? I've been looking into XS and what it is generally, and what I found was not too good on my part:

Learning XS is very difficult, for two reasons.

The first is that the core Perl docs, such as perlxs and perlguts, tacitly assume that you already understand XS. Accordingly, they omit or gloss over crucial assumptions and background information. This sounds bad, but it is actually rather common in the Unix world.

The second is that you can't learn XS. Not as such. Not from the top down. This problem is much more profound than the first, and it stems not from any inadequacy in the documentation, but from what XS is -- and isn't.

The Perl docs refer to XS as a language, but it isn't. XS is a collection of macros. The XS langauge processor is a program called xsubpp, where pp is short for PreProcessor, and PreProcessor is a polite term for macro expander. xsubpp expands XS macros into the bits of C code necessary to connect the Perl interpreter to your C-language subroutines.

Because XS isn't a language, it lacks structure. The underlying C code has structure, but you can't see it, because it is hidden behind the macros. This makes it virtually impossible to learn XS on its own terms.

That's only one of the many things I've read about XS :(

And as a person who is struggling to learn C++ in the first place, does this mean everyone who is not fluent in that language can no longer write quests for their server?

I certainly hope this isn't the case, and if it is, then maybe someone who is XS savvy could guide us who aren't too quick on this on how to do basic functions?

This is just me voicing my opinion and concern on the matter, though, and I might just be confused. Any clearing up on this would be greatly appreciated.

[fathernitwit]

Does this change mean the whole quest::say(), etc, system is gone and no longer usable?



please read the thread before posting:

The new perl stuff I am doing will preserve old behaviors, but greatly enhance the system as a whole.

[sdabbs65]

XS is a (phonetic?) acronym for eXternal Subroutine,
where external means external to Perl, i.e. written in some other language, such as C or C++.

so we can think of it as an add on to the Existing perl system.

[Cans]

Does this change mean the whole quest::say(), etc, system is gone and no longer usable?



please read the thread before posting:

The new perl stuff I am doing will preserve old behaviors, but greatly enhance the system as a whole.


Yes, I read that...but then I read this:

yes, everything is moving to XS, command queue is going away completely

So, I wasn't sure what was going away or what was staying. Thank you for clearing it up.