ACR Quests - refinement

Scripted ALFA systems & related tech discussions (ACR)

Moderators: ALFA Administrators, Staff - Technical

Locked
User avatar
AcadiusLost
Chosen of Forumamus, God of Forums
Posts: 5061
Joined: Tue Oct 19, 2004 8:38 am
Location: Montara, CA [GMT -8]
Contact:

ACR Quests - refinement

Post by AcadiusLost »

Moving some of this discussion to core rules to keep the 003 bug thread on-track for module-specific bugs.
ç i p h é r wrote:The lower state is the entry state. If the bosses can be killed in any order, don't define one (ie 0). Otherwise, make sure you define the lower states in the correct sequence. Once a boss is killed, the quest state will increment. This might have something to do with the inability to trigger the last boss.

Also, we could omit upper state altogether on quest triggers that don't need them. So if they are 0 (ie undefined), they wouldn't award XP. Just an issue of simplification and/or convenience really, if it'll help.
As I understand it, LowerState=0 would mean the boss would spawn even if the PC stepping on the trigger hadn't yet been assigned the quest? Seems like we'd want to leave it with 1 as the entry state, so it only fires for PCs who have been assigned the quest. In this quest we want to leave the order of boss kills flexible, since we don't know (nor would we want to mandate) what path PCs would take through the area. Currently we're seeing the quest XP granted by each trigger though, both here and in multi-trigger scouting quests. If the "UpperState = 0" trick works around this, I can try using it for both, but the working theory currently is that the UpperState =2 was what was keeping our triple-kill quest from reaching the penultimate quest state.

I'll try to describe the setup using the linear, multitrigger scouting quest setup that I've tested personally. Here is the breakdown:

Code: Select all

1. PC is assigned scouting quest: Plantations (Queststate advanced to "1")

2. PC enters first scouting trigger (LowerState=1, UpperState=2)

3. Queststate advances to "2", PC receives quest XP ( this part shouldn't happen yet, but does)

4. PC enters second scouting trigger (LowerState=2, UpperState=3)

5. Queststate advances to "3", PC receives quest XP again (ideally this should the point of XP award).

6. PC returns to NPC questgiver, who recognises quest as complete. (Queststate =3)

7. PC reports success, Queststate advances to 4, gold is awarded.
Is the Quest system deciding whether or not to award the quest XP based on UpperState of the trigger, rather than that of the Module Journal? If so, would the double-award of XP be resolved by setting the UpperState on both scouting triggers to "3"?

I'll likely test this arrangement this evening, but wanted to know if I'm on the right track with this thinking.
User avatar
ç i p h é r
Retired
Posts: 2904
Joined: Fri Oct 21, 2005 4:12 pm
Location: US Central (GMT - 6)

Re: ACR Quests - refinement

Post by ç i p h é r »

AcadiusLost wrote:As I understand it, LowerState=0 would mean the boss would spawn even if the PC stepping on the trigger hadn't yet been assigned the quest? Seems like we'd want to leave it with 1 as the entry state, so it only fires for PCs who have been assigned the quest.
True and good point. No "entry" state wouldn't be appropriate for these kinds of quests.
In this quest we want to leave the order of boss kills flexible, since we don't know (nor would we want to mandate) what path PCs would take through the area. Currently we're seeing the quest XP granted by each trigger though, both here and in multi-trigger scouting quests. If the "UpperState = 0" trick works around this, I can try using it for both, but the working theory currently is that the UpperState =2 was what was keeping our triple-kill quest from reaching the penultimate quest state.
UpperState = 0 isn't a special case currently. It could be if we wanted it to be, but to set it to 0 would mean every trigger automatically awards XP. The upper state is what determines when XP should be awarded. As soon as that quest state is reached, XP is given. The reasoning behind this was to grant XP only for players who are actually present at the time a quest is completed, rather than those who might join the party on the way back to the quest giver. In other words, eliminate potential exploits.

Code: Select all

1. PC is assigned scouting quest: Plantations (Queststate advanced to "1")

2. PC enters first scouting trigger (LowerState=1, UpperState=2)

3. Queststate advances to "2", PC receives quest XP ( this part shouldn't happen yet, but does)

4. PC enters second scouting trigger (LowerState=2, UpperState=3)

5. Queststate advances to "3", PC receives quest XP again (ideally this should the point of XP award).

6. PC returns to NPC questgiver, who recognises quest as complete. (Queststate =3)

7. PC reports success, Queststate advances to 4, gold is awarded.
Is the Quest system deciding whether or not to award the quest XP based on UpperState of the trigger, rather than that of the Module Journal? If so, would the double-award of XP be resolved by setting the UpperState on both scouting triggers to "3"?

I'll likely test this arrangement this evening, but wanted to know if I'm on the right track with this thinking.
The quest system is determining *when* to award the XP defined in the module journal for the given quest based on the defined upper state. When the quest state advances where quest state = upper state, XP is awarded. So, changing the upper state on the first trigger to 2 would solve your double award problem.

Now I was suggesting using UpperState = 0 (ie not defined on a trigger) as a special case to mean that no XP reward would be given. This would eliminate having to define it on every trigger, just the one you need to award XP on. Might be more practical/expedient/simpler this way? Just an idea. I welcome any suggestions you have.

Also, would a different nomenclature help to clarify this?
Locked