EQEmu::Any question

[jdoran]

I am porting my quest generator to the newest code base, and see some changes in the last couple of years :)

The event handlers now accept a vector of EQEmu::Any pointers (modified Boost::Any), and I have no experience with these objects.

What I need: I need to pass in a couple of extra parameters to EventNPC et al. such as a quest-id which would be used to load the quest script. Previously I just added a couple of extra parameters and let EventCommon load the script if necessary. This worked fine for my purposes.

In order to allow the potential sharing of this code later, I would like to do things properly this time around. These "extra_pointers" sounds like they might be useful, but then I see that ExportEventVariables uses the entire vector as variables to export.

I'll look into ways of preloading the scripts elsewhere. But the package name is quest-specific. GetQuestPackageName is not going to be able to figure out the proper package name, since I base it on a quest-id. I really want to keep each quest in its own package.

Events for *my* quests know what quest-id they correspond to. I'm able to have the PERL parser load my package when a non-zero quest-id is used, which allows the pre-existing events to work without modification.

The Lua and PERL parsers do their own package-name logic, which assumes a different organization than I'm using.

Edit: I should add that I was previously using loadQuest to perform the loading, and that is now gone.

What is going to cause the least amount of disturbance?

[KLS]

Hey using the EQEmu::Any isn't hard, in the code there are some good examples of it (mostly in the lua parser).

In terms of how to pre-load quests we basically have QuestParserCollection now find the script's filenames to load based on quest ids and which files are available. Then passing it to one of these implemented by your parser implementation of these functions:


virtual void LoadNPCScript(std::string filename, int npc_id);
virtual void LoadGlobalNPCScript(std::string filename);
virtual void LoadPlayerScript(std::string filename);
virtual void LoadGlobalPlayerScript(std::string filename);
virtual void LoadItemScript(std::string filename, ItemInst *item);
virtual void LoadSpellScript(std::string filename, uint32 spell_id);
virtual void LoadEncounterScript(std::string filename, std::string encounter_name);


How you dispatch events is up to you. Perl and lua don't specifically give the underlying quest ids to the events but they do have specific quest ids and if they wanted they *could* pass them.

It sounds like you might have significant hurdles trying to update to the newer interface which is kind of unfortunate but it was important to standardize it when we added lua so we could have multiple parsers working well.

If you have more questions or concerns I'll check back from time to time.