Quest flags for 5.2

[Eglin]

Originally Posted by Scorpious2k

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.

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

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.

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.

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

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.

And in many ways, it is a side benefit.

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.