ACR Quest System

Teric neDhalir · Post by **Teric neDhalir** » Tue Mar 25, 2008 12:40 am

FYI, I have got around the XP issue with errands by adding an (int nXP) at the start, including acr_xp_i and adding a line for ACRGiveXPToPC(oPC, nXP). (Doing that from memory, syntax may not be perfect). I can now define XP on acr_quest_reward from the convo. acr_quest_reward also doesn't seem to delete the quest item from the PC inventory. Not looked any deeper into this yet.

Teric neDhalir · Post by **Teric neDhalir** » Tue Mar 25, 2008 2:07 pm

Some further rooting about:
In the acr_quest_errand script the item to be delivered is defined as;

SetLocalObject(oPC, sQuest + GetTag(oItem), oItem);

But in acr_quest_reward the item to be deleted is defined as;

object oItem = GetLocalObject(oPC, sQuest);

Am I right in thinking that the variable name of the item is different and explains why it's not deleted?

ç i p h é r · Post by **ç i p h é r** » Tue Mar 25, 2008 5:58 pm

I think there are several options:

1. setup a trigger to award the XP, but on reflection there are exploitability and disconnect issues with this approach.
2. pass in the XP reward via acr_quest_update (when updating the quest state)
3. grant the quest XP when removing the item (requires a little extra coding) - I think this is probably the best and most exploit proof way to do it. AL, you might be right. It doesn't feel like this part was finalized.

Thoughts/preferences?

p.s. Good catch, Teric. The variable names should be the same.

AcadiusLost · Post by **AcadiusLost** » Tue Mar 25, 2008 7:48 pm

I like the OnUnAcquire method- make sure acr_quest_rewards advances the QuestState before removing the item, check the item unacquired for matching quest variable and state- if they're present/finished, award XP and clear the quest (or advance it).

One warning though, might want to do that switch via local variables to make sure it doesn't miss the queststate advance due to database lag- especially if you're querying and writing again OnUnAcquire of the quest item that acr_quest_rewards just destroyed.

If all the operations are done on locals, can get it down to a single SQL DB read (to gather the quest state) on Rewards firing, then a single write (to advance/clear it) at the end of OnUnAcquire.

Cipher, will you have time to do this tonight? Was hoping to iterate the 2da.hak to incorporate Paazin's potions and the 003 PWC, so it'd be a convenient time to work such changes in (and Teric will be wanting them ASAP considering the looming Live target for the OAS2).

[edit: might be best to insert the Quest system hook in acr_items_i to keep mod_events tidier- I don't remember if I migrated the QuestItemOnAcquire there as well or not- if it's a bother, don't worry about it.]

Teric neDhalir · Post by **Teric neDhalir** » Tue Mar 25, 2008 10:22 pm

*emits a timid bleat* Please don't tell me I have to start again! Working out what I've done wrong is one thing, but testing this stuff means running from one side of the server to the other. And it takes 15 minutes to get the mod running on my machine.

You don't need to reply to this, it's just a bleat.
Sheepishly,
Teric

AcadiusLost · Post by **AcadiusLost** » Tue Mar 25, 2008 10:53 pm

The joy of the OAS2 (and it's curse, in other ways), is that it doesn't /have/ to update scripts as they come in, since it has those scripts in the module instead of in the alfa_acr.hak- if you've got a workaround that makes your quests functional, by all means- we'll leave it in place in the interest of not adding anything more to the "to-do" list for the next week. I'd just been thinking from the perspective of the hak'd servers, which need a multi-step process to get a core system fix like this into place.

ç i p h é r · Post by **ç i p h é r** » Tue Mar 25, 2008 11:32 pm

I've committed the changes. I opted for #3 since the item was already being removed there - seemed the easiest place to add this. As for OnUnaquire, I'm not sure that event fires when an object is destroyed by NWScript. It's definitely a more logical place to put it but it also introduces some potential decoupling issues as you pointed out. Something worth looking into, more time permitting.

As for acr_items_i, it's an interesting abstraction. Looks like you added this to clean up the module event code? The quest system hooks are still in mod events atm.

Teric neDhalir · Post by **Teric neDhalir** » Wed Mar 26, 2008 12:11 am

AcadiusLost wrote:The joy of the OAS2 (and it's curse, in other ways), is that it doesn't /have/ to update scripts as they come in, since it has those scripts in the module instead of in the alfa_acr.hak- if you've got a workaround that makes your quests functional, by all means- we'll leave it in place in the interest of not adding anything more to the "to-do" list for the next week. I'd just been thinking from the perspective of the hak'd servers, which need a multi-step process to get a core system fix like this into place.

Roger that. I have duplicated and renamed any scripts I'm changing, so a global update later would mean that new content could be added "properly".

AcadiusLost · Post by **AcadiusLost** » Wed Mar 26, 2008 12:22 am

ç i p h é r wrote:As for acr_items_i, it's an interesting abstraction. Looks like you added this to clean up the module event code? The quest system hooks are still in mod events atm.

Right- I think I began to migrate them, but stalled out on realizing we needed to #include acr_quests_i in mod_events still for the OnDeath event for bounties and such- so I left it for now.

The item tag-based scripting code and the bastardsword coding really didn't seem to belong in acr_mod_events_i, so I thought it was a fitting abstraction. I'd expect as more global systems are developed tied to items (camping supplies for resting, leash items for pets, subdual widgets), it'd be useful to have all those hooks in a common place (that's not as complex a tangle as mod_events_i).

I'll roll this change into the Worldgate later this evening.