Quest flags for 5.2
 

If you cannot compile code and cant get quest flags working, you can use this plugin to allow for zone wide flags (the flags should be restored if the client re-enters the zone)
Pugin.plUse plugin::set_flag("flagname","flagvalue") to set a flag and plugin::get_flag("flagname") to return a flag. The flagnames and flagvalues can be anything.

This will work with any version of EQEmu that has Perl plugins enabled.

No offense, but this is pointless. The only need for a more formal flag system would be in cases where information needs to be passed back into the underlying game engine (I don't know how planar access works, but I have been working under the understanding that this is exactly what the flags were for). Perl alone is incapable of doing this. You either have to write some code to talk to the db or write some xs.

The code already exists and will be out soon in cvs.

http://www.eqemulator.net/forums/viewtopic.php?t=12773

Not only does it replace flags, but it allows for actual values to be passed and not just a true/false boolean values. It also has the advantage of setting the scope of availability to determine which NPCs get it, what zone and what players. Finally, it lets you set the amount of time the variable is available, after which it goes POOF.

I am surprised that this hasn't generated more excitement. The possibilities it opens up are incredible.

You can now make sure all 4 warders are dead in sleeper before spawning the sleeper. Want to know by whom and when sleeper was killed? Write a global variable.

Wandering mobs? This makes it possible for them to know where each other are (variable written at event waypoint). Want a mob to behave a certain way, even in another zone, based on what was done with another npc?

Then there are the adventures... you have 30 minutes to start. Guess what? Set the variable to a 30 min duration and if it isn't there they missed the window of opportunity....

And I am working on a little addition which will make it possible, among many other things, for mobs to have a conversation among themselves.

That sounds cool. While the sleeper thing, the waypoint thing, the conversation thing, et. al. could already be easily done w/ the existing perl quest routines, the ability to transparently store values into the db is very nice.

The problem with the current quest system is that each time an event is triggered, the event starts out new. Having no information about anything that has come before.

This has produced the classic and tiresome quests of taking something to someone, who gives you something else to take to someone else who then gives you something else... and on and on. Why? Because giving the item to the npc causes an event item. The event item can then check the item he has been given and react accordingly.

Now its possible to remember what came before. Instead of checking the item given, check the variable saved or sent by another npc. Now, an npc can tell a player to "go talk to Dogmouth", targlobal a value to Dogmouth and when the player gets there, Dogmouth looks at the variable and says "I've been expecting you, Eglin, take these perls [pun intended] to MollyMillions". If the variable isn't there, the player isn't on the quest and Dogmouth can say "Buzz off"

As far as the sleeper thing.. the closest I've seen possible is to spawn one at a time. Kill 1, spawn 2, kill 2 spawn 3, kill 3 spawn 4, kill 4 spawn sleeper... Now all four can be spawned in the zone, each checks and updates the global variables they share. The last one to die spawns sleeper.

The waypoint and conversation things... I have no clue how you would be able to do. Maybe you could post some examples.

And in many ways, it is a side benefit.

It's not advisable to post when you're excited about a topic.

-This- is the only exception i make. :D

It's more a case of surprise. I see people complain about spending their time doing nothing but killing mobs. The majority of quests are lame.

Now we can do something about it. It's the quest writers and serverops that should be excited.

i got the latest cvs, the source reflects changes, and should now allow targlobal, ...

i found no sql update in the repository. Should we excpect one, or did i miss something in the posts ? Tark says about quest_globals.sql.

Should have been included. I'll talk to Shawn.

Here is what it says:

thx

Although I have hinted about using DBI to connect to the db, I did not provide a default method for permanent data storage. There is nothing preventing storage of state between events, you just have to take care of serializing it on your own. I maintain that each

I maintain that the only new functionality is related to data storage and variable lifespan. In this case, data storage is probably unnecessary (since the spawns all respawn at zone reboot, don't they?). You add something like "sub event_spawn { $isalive = true; }" in each one of the spawn's scripts. You also add to each something like "sub event_death {$isalive = false; if(!$isalive && !$qstxxx1::isalive && !$qstxxx2::isalive ... ) quest::spawn(sleeper); }" You'll have to forgive me for not remembering the correct syntax of some of the commands. I don't have much practice writing quests.

You do them in the same way as the sleeper globals, above. I am wondering if you're having the same confusion that Molly had regarding packages and global variables. Variables declared with global scope will retain their state, much the way that static variables work within function scope in C. You can save an arbitrary amount of state info, there just wasn't a default method for data serialization (db storage, tied hashes, whatever). If you want to have a variable remember a value between events, just declare it w/o "my" or "local" To access it outside of the current package, just prefix the name with something like qstxxxx where xxxx is the npcid in question. Granted, such vars don't persist across hard zone reboots, but it should still be sufficient for stuff like spawning creatures, moving them around, making them talk to each other, whatever. Obviously, these global vars are only zone-wide - another reason that serializing to the db is handy.

Oh? That is by far the part that I think is the coolest addition. I've hinted many times about caching a DBI connection in a global var. An XS interface to Quagmire's excellent db classes is even better.

alright... nobody asked my opinion on the matter, but I just looked at the code for the first time and I have to say that I think it has some issues. The most important is that you're making two database queries EVERY time the event loop runs. This is insanity, man. Think of how often the event loop runs: every time any mob hits a waypoint, every time any mob spawns, every time any mob dies, every time any mob gets hailed, etc etc... This bad boy is getting called _constantly_. Also, consider the size of the table you're creating... it is going to grow _very_ fast. You do _not_ want to search through a table of _every_ variable stored for _every_ character ever created _every_ time the event loop runs. The DB call is going to block the entire thread. You just can't do it willy-nilly. It doesn't make sense.

Choosing to key your data around values that you have to query seperately doesn't make any sense, either. Why would you query for a charid? You have enough data avaliable to generate a unique key, so why tolerate the expense of the charid queries?

OK. Sorry for ranting about your work. You actually wrote some code, and I'm pragmatic enough to know that 1 diff is worth 1000 forum posts. OTOH, it is 100% clear to me that caching a global DBI connection for variable storage and only using it when variables actually need to be queried/written is going to be _WAY_ more efficient than making a minimum of 2 queries _EVERY_ single time the event loop runs.

Read it again.

This time pay attention to the fact it will ONLY do it if the NPC has been specifically flagged in the npc_types to use this feature.

You are correct to assume that I misinterpreted the semantics of that check. But.... what if I want to create a situation where, say, a pc is flagged for killing a townie and the default quest would check a given flag under some circumstances? Which npc do we flag in the db? How do I set it up so that everyone in the plane of love is extra nice if you've been to the plane of destiny before? How, in general, do we know from a script whether or not we have access to player flags, if not all scripts would? Granted, the check may prevent unnecessary db access, but it opens up a whole new set of problems instead (or am I still missing something?).

The appropriate thing to use in this case would be factions. IMO, this feature has no place in in a default quest.

Factions again.

It's a matter of design. If you need it, then you set the flag. From the script, you might put a comment in if you are worried about knowing whether or not the feature is used (and can't figure it out when you see the commands used).

The only problem for some may be that thought and planning has to be done.