PDA

View Full Version : hasitem available for perl quests


smogo
03-08-2004, 04:41 PM
This is an implementation of the hasitem() for perl quests.

mOoni9 had started to work on it in another post (http://www.eqemulator.net/forums/viewtopic.php?t=12393&highlight=hasitem&sid=ec7403 101db53e83194c4999c678cd72), while the code here does not call C++ back, instead it does push the hasitem variable when an event is triggered, ala itemcount.

in PerlembParser::Event, creates a variable that the perl interpreter makes available to the perl script in the quest. This variable is created (and reset) for each event where a character is involved (including EVENT_SLAY, EVENT_DEATH, ...)

The variable is a hash of array references. It may seem complicated at first, but usage in perl is easy. It complies to .qst behavior in most (if not all) ways, and extends it.

The following code is to be added to embparser.cpp, in PerlembParser::Event, at line 189 for example (0.5.3dr3, feb 2004).

#define HASITEM_FIRST 0
#define HASITEM_LAST 29 // this includes worn plus 8 base slots
#define HASITEM_ISNULLITEM(item) ((item==-1) || (item==0))
if(mob && mob->IsClient()){
string hashname = packagename + std::string("::hasitem");
LogFile->write(EQEMuLog::Debug, "starting hasitem, on : %s",hashname.c_str()
);

//start with an empty hash
perl->eval(std::string("%").append(hashname).append(" = ();").c_str());

for(int slot=HASITEM_FIRST; slot<=HASITEM_LAST;slot++){
char *hi_decl=NULL;
int itemid=mob->CastToClient()->GetItemIDAt(slot);
if(!HASITEM_ISNULLITEM(itemid)){
MakeAnyLenString(&hi_decl, "push (@{$%s{%d}},%d);",hashname.c_str(),itemid,slot);
LogFile->write(EQEMuLog::Debug, "declare hasitem : %s",hi_decl);
perl->eval(hi_decl);
}
}

}


This calls the GetItemIDAt of the character for all slots 0 to 29. To include the cursor, go up to 30. To also get what's inside containers, include higher numbers.

It builds a hash where item id is the key, and the value is a reference to an array containing the slots. This allows to test for existence (if the key exists), count number of slots occupied by this object type (size of array), and get the slots id from the array (for example to check if character is currently wielding a weapon, or just has it in his inventory).

Here is a sample perl quest, that leads to the screenshot (http://perso.wanadoo.fr/afou/khalzed-dur/tools/code/hasitem.jpg).


sub EVENT_SAY{
quest::say("i say 17005"); # there a glitch in NPCMessage's code

#if($hasitem{9990}) { quest::say("you have item 9990");}
#if($hasitem{9991}) { quest::say("you have item 9991");}
#if($hasitem{9997}) { quest::say("you have item 9997");}
#if($hasitem{17005}) { quest::say("you have item 17005");}


if($text =~/Hail/i){
quest::say("Hello $name, i'm an inspector, and can [inspect you] if you ask.");
return 1;
}

if($text =~ /inspect me/i){
quest::say("inspecting you");

#test for a cloth cap
if($hasitem{"1001"}){
quest::say("you have at least one cloth cap");
}
#test and count them
if($hasitem{"1001"}){
quest::say("you have ". scalar @{$hasitem{1001}} ." slots holding a cloth cap");
}
#test and tell what slot their' at
if($hasitem{"1001"}){
quest::say("you are holding cloth caps in slots [".join(",", @{$hasitem{1001}})."].");
}

#dump full %hasitem content
for $itemnum (keys %hasitem){
quest::say("you are wielding / carrying item id $itemnum .");
quest::say("in ". scalar @{$hasitem{$itemnum}} ." slot(s), [".join(",",@{$hasitem{$itemnum}})."].");
}
return 1;
}

return 0;
}


Any feedback is appreciated on this please :)

m0oni9
03-12-2004, 11:42 AM
I haven't really been looking at the emu at all lately :cry: .. the whole point of the hasitem thing was to call code from the server from the perl script. That was really just an example function. I was able to get fairly far on it I think (ie: no shared library needed, but still needed module.pm file, and I never figured out how to get around that). What you have looks workable, though.

The reason I was looking at calling code back from the server was so that all of these variables wouldn't have to be declared beforehand. It seems like a lot of unnecessary overhead, for the most part.

On another note, I was just looking at bugzilla again (http://www.bugzilla.org), and kind of wished the emu team had something more along these lines to keep track of bugs/feature requests. It may not seem necessary due to the volume of messages on the board, but I'm sure there are some good ideas being lost by the wayside.

smogo
03-12-2004, 02:48 PM
The reason I was looking at calling code back from the server was so that all of these variables wouldn't have to be declared beforehand. It seems like a lot of unnecessary overhead, for the most part

I think it's better too, yes that's overhead. And there's more to come, as there are more variables to be available to the perl quest when it grows popular.

Still switching from perl context back to EMU is not easy, as you noticed. It's a design issue to know whether to export exactly what is required (using export masks as the qglobal flag for example can be a solution), or allowing perl parser to switch back and access C structures.

i have no definite position on this.