A Land Far Away

We don't always think about it in quest design, but sometimes a PC is going to bite off more than he or she can chew. Sometimes this will be seeing the defenses at a camp you signed on to scout, and realizing there's no way to get close enough to complete the quest without being flattened. Other times it's a raid quest, and the bounty creature wins. What next?

For the former, we could add a script/function to Remove Quest, which could be added to questgiver dialog options as an alternative path for an active, but incomplete quest. No reward, but freedom from the persistent nagging reminder of a quest incomplete that comes with journal persistency. Could be up to the builder to decide if the questgiver would re-offer the quest- they might even decide questgiver X would think highly of an adventurer who knew when to turn back from a dubious job gone sour.

For Raid quests especially though- we have the question of what happens to the triumphant bounty-creature (we'll use the catchy "Doomboar" as an example). So sure, you didn't like the looks of his bloodied tusks (or the bones of ten and forty men strewn about his lair) and fled the scene before Doombear caught your scent. What happens for the next PC who tries to do the quest? Will they end up facing Doomboar and Friend(s)?

I know these quests stretch IC believability in the best of cases, but for logistical reasons we should devise some sort of handling for aborted/failed raid quests.

-Timed Despawn via DelayCommand()? Not sure what amount of time from quest triggering is an appropriate window- could test to see if the quest trigger PC is still in the area after 5 minutes, if so, give it another 5 min, etc- we just really don't want to end up with a situation where the party finally fights their way through the Triad defenders only to find out the third and final boss has despawned because they took too long RPing through binding their wounds and such in the dungeon.

-Death of triggering PC? Could put a pointer on the PC to the mob at time of spawning, and dereference it to start a 5-min despawn timer on the mob, though this can be a bit OOC as well, if friends go in to try to recover the body- Doomboar is there defending his kill for a while, but then wanders off?

-Quest reported as failed? If we do set that pointer on the triggering PC, we could use it to clear the spawn if/when they return to apologise to the questgiver- though if there was a party doing the quest, they're likely not going to know who triggered the spawn, ideally anyone who was there when it spawned should be able to report failure and get it to despawn- but adding pointers for each and every party member with the quest active seems excessive.

-Quest trigger controls? We could add a ACR_QUEST_SPAWNED integer for TRUE/FALSE on the trigger, updated to synchronize with the spawn state, such that a new mob will never spawn if a prior one is already there- this would have to update pointers so whatever doomboar is there will "work" for the most recent party. I can see some potential for this getting tangled as well, though. Despawn or spawn death would set it back to FALSE, naturally.

Other ideas?

In order to try to minimize the amount of extra work needed for implementation, I'd figure the timeout system would be the best. If the current dialogs were adjusted to say something akin to 'OOC: You have 30 minutes to complete this quest before it needs to be restarted'

Starting a despawn countdown when the PC leaves the area or dies seems like the best option. Not likely that a boar would guard the body of a PC until the end of times anyway. Eventually he wanders off to go find more food or whatever. As long as it isn't possible for a PC to sit nearby and wait until teh boar disappears in his plain view it doesn't really affect immersion anymore than doomboars spawning again 5 minutes after someone else kills it.

I took a brief peek at the acr_quests_i source, and I noticed the quest spawns are being activated with a CreateObject() call- so even if the area despawns generally for inactivity, the proverbial Doorboar will remain, biding its time... until module reset or death in glorious battle.

I'd agree that the simplest solution is a timed despawn- I might go generous with it by starting a 10 minute timer on tripping of the quest trigger, at the end of which the system checks to see if the quest triggering PC is still in the same area as the spawn or no. If so, it'll wait another 5 min and try again- if not, it'll despawn the mob. This should sort out the "got distracted" and "chickened out" contingencies in most cases, even for a busy area like High Hold which may otherwise go hours between despawns.

For triggering PC death, I'll probably go with an unconditional despawn after 5 minutes or so- gives co-questers of the unfortunate victim plenty of chance to finish off the Doomboar for quest closure, but cleans it up before a new party is likely to happen along.

The good news about these despawn solutions is, they still allow the PCs to try again at the quest later with others after a module reset.

I think we're better off waiting on the quest rejection options and one-spawn-per-trigger enforcement in the near-term, as those are both implementations with more capacity for critical system failure.

As player, I would just like to say I am glad you all are looking at this. My first time into the "Trident Caves" my party and I ended up facing THREE bugbear shamans. It was very nearly the death of us (we had no idea there was only supposed to be one). Anyway, despawning so that you don't get such a build up is great, and some way to "throw away" or "reject" quests you have taken would be awesome too. Thanks for the hard work guys.

Just to put a lid on any unnecessary concern- the multispawns of the first few days of Live which Mikayla and others remember well were due to a separate and far more acute issue- they would, at the time, happen every time you tried a quest with a party. Those critical bugs are long since gone- the current patching is just to address a distant echo of those sort of problems, which only really becomes likely when the server has been up a long time without restart (and quite a few players have been active on the statics in the meantime).

I've committed a minor revision to the quest system include. It adds a new local float a builder can add to the quest triggers, to define how long a spawned quest creature should stick around before a despawn check.

ACR_QST_CUSTOM_DESPAWN

If a float value is set for this, in seconds, it will control how long a PC has to defeat the quest creature. Even if the time runs out, and the PC is still logged in and in the same area as the creature, it will switch to re-checking every 5 minutes.

Default, if no value is defined, will be 10 minutes (600.0 seconds)

Alternatively, a builder can set this to -1.0 if they want the mob not to despawn over any amount of time.

This should be in place on TSM alongside the update.

Having fought doomboar and his evil twin last night, I must say.. thanks for this.

If the mob despawns will it respawn if the character still has the quest and re-enters the area?

Quest triggers can be a bit finicky in that regard- we've got controls on them to make it extremely unlikely that it will fire twice for the same PC under normal circumstances, so the way it will generally work is, if your quest beastie despawns before you can get back to it, try it again another (RL) day. A mod reset should allow a fresh shot at the quest.

Does this mean it will remove the quest from your journal once the time is up? And only if you are no longer in the same area?

The quest will remain in your journal until completed. That way, the server knows that you still haven't finished the quest, so it knows to give you another shot at it after next module reset.

I'd like to also set up an option that lets you return to the questgiver and cancel a quest (if you decide IC that it's not for you) since some players have reported being bothered by having lingering entries in their journals. That's a low priority for me now, though.