Strange Quest Behavior

[ProphetSword]

Sorry, I guess "broken" was probably the wrong word.

I guess what I'm trying to say is that, even for an inexperienced designer, it would be frustrating to have the quest stages fire out of order, which is what I see happening here (unless I misunderstood the description).

So, for example, if my party already has passed "Quest 1 - Stage 1" and then gotten to "Quest 1 - Stage 2," wouldn't it be wrong for them to then encounter something that fires as "Quest 1 - Stage 1?"  And wouldn't that reset the Quest Stage back to 1?  Which means if they had to get to "Quest 1 - Stage 3" to complete the quest, then they've pretty much ended any chance of that.

Again, this is just my logic at work here.  After this, I'll shut up.  I'm just trying to understand how this would work.

[Olivier Leroux]

To help clarify if I understand the two of you, let me try to give some examples (you'll probably find better ones, it's just an attempt to make the discussion a bit more demonstrative):


CASE #1

The party has overheard the evil plans of a tanuki (quest1=1) and wants to warn someone about it so that they can do something about it. They have the choice between two NPCs, both will propose the same thing (quest stage 2) but react differently to it (so each one gets their own quest stage 2 event). The party then takes action, is successful (quest1=3) and tells the NPC in question about it (quest stage 4).

Let's suppose the party got the assignment from NPC#1 and after they succeeded (so quest1 is set to 3) they decide to stop by at NPC#2's house on the way back to him/her. If I understood everything you said, now the quest stage 2 event will fire (even if it was set to "DO ONLY ONCE", because it's the first time the party meets with NPC#2 after they got quest1). In consequence quest1 will be advanced by 1 and therefor be set to 4. When they arrive at NPC#1's house will the quest stage 4 event still be triggered like it should be? And is it not a problem that NPC#2 will react as if the party just told him/her about the plans although the party already prevented them?

[Olivier Leroux]

CASE #2

There's a funfair in town and one of the showmen promises a reward for anyone who succeeds in accomplishing three difficult tasks in a row. If the party agrees to try it, quest2 is set to 1. After task 1 is accomplished (quest2=2) they have to tell the showman (quest stage 3) so they can proceed with the next. This goes on and on (quest2=4, quest stage 5, quest2=6, quest stage 7) until they get the reward. The designer has to set the quest stages to "DO ONLY ONCE" for them to work properly, in a row. But what if the designer intended to reset quest2 after that because he/she wanted to give the party the option to try it again and again and let them get a reward EACH time they succeeded?

I know these examples are a bit flawed and both problems could also be solved without using quest stages, or in a different way. I just want to make sure the new way quest stages are handled isn't causing both newbies and quest stage veterans any trouble.

[ProphetSword]

CASE #1:
This is easily accomplished by checking the NPC events for "Only Happens If = Party Has Special Item = Quest 1," which means the quest is in progress.  Why not save yourself a stage?

CASE #2
In Case #2, your quest wouldn't work; because you have set all your Quest events to "DO ONLY ONCE."  As a result, you are left with "Quest 1 - Stage 1" firing only once (the first time) or firing EVERY TIME.  How would that work?  Either way, you cannot reset it if it won't fire, or you cannot do anything with it if it fires EVERY TIME they talk to him.

In standard UA, you can pull off this trick by just using standard Quest Stages (no option for DO ONLY ONCE, it isn't needed), and at the end of the Quest, use the UTILITIES option to "Subtract" from your quest and set it back to 0.

So, in this case, we'd use the UTILITIES function to SUBTRACT 7 from our Quest and set it back to Stage 0, which would cause "Quest 1 - Stage 1" to fire again, allowing the quest to be redone.

[Olivier Leroux]

CASE #1:
This is easily accomplished by checking the NPC events for "Only Happens If = Party Has Special Item = Quest 1," which means the quest is in progress.  Why not save yourself a stage?

I'm not quite with you there, Ben, what are you referring to in particular? 

Like I said, my examples are flawed, I usually don't have problems with quest stages even if my "programming" might be a bit more complicated than necessary sometimes. I just tried to grasp and illustrate your criticism of how the quest stages work in OAUA so that Darius could either defend or question the decision the OAUA team made.

The second case was to show "DO ONLY ONCE" could curtail the freedom of designers, like you said before. The first was a probably failed attempt to support your statement that

it would be frustrating to have the quest stages fire out of order, which is what I see happening here (unless I misunderstood the description).

Perhaps you can give a better example for that yourself.   

I'm not sure my posts really help to clarify, I fear they only cause more confusion.. 
Still, I'm giving it another try:

So, for example, if my party already has passed "Quest 1 - Stage 1" and then gotten to "Quest 1 - Stage 2," wouldn't it be wrong for them to then encounter something that fires as "Quest 1 - Stage 1?"  And wouldn't that reset the Quest Stage back to 1?  Which means if they had to get to "Quest 1 - Stage 3" to complete the quest, then they've pretty much ended any chance of that.

Repeated quest stages in OAUA don't reset the quest but advance it, so triggering a Quest Stage 1 two times would result in a quest value of 2, three times in 3 etc. So if a quest is at stage 3 and the party triggers a Quest Stage 1 event, I think the quest value will be 4 not 1. Just like Merlin wrote in his first post, describing what we at first took for a bug in OAUA:

Code: [Select]

Event happens if: Always Happens
Accept: Automatic
Which Quest: Quest 1
Stage: 1

What this should do is fire if Quest 1 has a value of 0, and only then. (Since the Quest Stage event is only supposed to happen when the Quest is actually at Stage - 1).  Except it's firing every single time the party enters the square with the event.  Each time, it increments the value of Quest 1 by 1 and chains to the sequence of Accept events.  The Quest goes from 1 to 2 to 3, etc.

[ProphetSword]

I'm not quite with you there, Ben, what are you referring to in particular? 

To explain:
In the example given, a player trips "Quest 1 - Stage 1" when they see something happening.  You are then suggesting that they can talk to either NPC about it.

Set the NPC events to "Event Only Happens If - Party Has Special Item - Quest 1" (This means that Quest 1 is in progress, and will only happen if the Quest = Stage 1 or higher).

Since you only had three events in your example, I assume that you finish the quest at Stage 3, so all you have to do is remove it, and those NPC events won't fire.

Repeated quest stages in OAUA don't reset the quest but advance it, so triggering a Quest Stage 1 two times would result in a quest value of 2, three times in 3 etc. So if a quest is at stage 3 and the party triggers a Quest Stage 1 event, I think the quest value will be 4 not 1. Just like Merlin wrote in his first post, describing what we at first took for a bug in OAUA:

Okay...

But, given the nature of quests and the fact that they are triggered in order, what happens if you step on them in this order:

Quest 1 - Stage 1
Quest 1 - Stage 2
Quest 1 - Stage 1 (because you backtracked)
Quest 1 - Stage 2
Quest 1 - Stage 4 (because you went the wrong direction)
Quest 1 - Stage 1 (beacuse you backtracked from going the wrong direction)
Quest 1 - Stage 3 (finally found it...but will it fire now?)
Quest 1 - Stage 1 (man, screwed up again, which way were we supposed to go?)
Quest 1 - Stage 4 (found it!  will it fire?)

If each on adds 1 each time, by the time you hit Quest 1 - Stage 4, you'd be at Stage 9.  If only the Stage 1 fires, you'd be at 5 by the time you hit 4, which means it never fires (and neither does 3).

Again...what is the advantage of this?

[Olivier Leroux]

Ah, okay, I got that now about case #1. But in my example quest1 would be in progress all the time after the party discovered the tanuki's plans, so your suggestion wouldn't solve the issue that if the party already got the assignment from NPC#1, prevented the tanuki's plan and then went to NPC#2, NPC#2 would act as if they weren't victorious yet but had just discovered the tanuki's plan and then he/she's would try to give them the assignment another time (because quest1 would still be in progress and that equals party has special item quest1).


But forget about the tanuki, let's talk about your example:

My guess would be that if the quest stages are set to "Do only once" it will work like in UA, everything would be fine.
If not, the player wouldn't miss Quest Stage 4 either, it would still fire even if the quest value was higher than 3.

Because, as I understand it, even in OAUA a Quest Stage 4 will only be triggered (and thereby advance the quest by 1) if the quest value is at least 3 (or above), not before.

BUT - if that's the case that also means if a quest already has the value 9, all quest stages below 11 will fire regardless of the order the designer had in mind.

I admit I don't see the advantage in this either. 

And what I wanted to explain with the tanuki example was that even if you use "do only once" to make it work like in UA, you can't use two quest stages of the same sort anymore (like two different Quest Stages 4), at least not without trouble. In UA only one of them would fire (depending on which the party chooses to trigger first), but in OAUA both would fire, even if they're both set to "do only once".

[ProphetSword]

Okay, then, forgetting Case #1 (as I misunderstood what you wanted to do there):

Case #2:
I think you're starting to see my point.

A "Do Only Once" setting isn't needed in UA because that stage will not fire unless it's the current one.  That allows you to run them more than once if you need to by backing the numbers up.

In the description given here, you can have it set to "Do Only Once," but that means that you can't do them again, which I accept (standard UA would work that way too).

But when you have the "Do Only Once" setting turned off, they fire every time?  Why not just make them standard events and add an extra event at the end that adds +1 to the Quest?  It would come out the same and use the same number of events (if you count the Quest Event you're chaining from).

So, even though I fully intended to leave this conversation alone (you keep dragging me in...lol), I have to ask what the benefit of this is?

It doesn't make it easier for new designers.  It makes it harder.

[Olivier Leroux]

So, even though I fully intended to leave this conversation alone (you keep dragging me in...lol)

He he, sorry, I will hand over to Darius now. 

[ProphetSword]

That's okay, we've hijacked the thread enough anyway.   

[Merle]

Thanks, Darius!!

I have the Step Zone events all fixed now.

I think I'm also confused by the way OAUA handles quest stages.    I did want to add one thing to want Ben & Olivier have said.

The point of it was, in FRUA, if you stepped on Quest 1 Stage 1 but already had Quest 1 Stage 2, that event wouldn't fire

The one thing I like about FRUA doing it like this is that it's the only way you can actually track the specific value of a quest.  Normally, you can only test to see if the party has it (Q > 0) or they don't (Q == 0).  But with the Quest Stage event, you can actually look for a particular value by forcing the "quest" to be accepted, and using a Utility event to decrement it afterward.

[Darius]

Guys, I don't have time available to respond to every post that's been made here.  But what I would say is that the change to the Quest Stage handling wasn't even noticed until a couple of days ago and it's been there for years.  I'm certainly open to discussing, I just don't think you should discount it completely only because it is different than what you are used to. 

In OAUA, the function is that the quest fires if Quest Stage >= N, versus FRUA's handling as Quest Stage == N.  What they have in common is that the Quest Stage will not fire if Quest Stage is < N.  Also, remember that the Quest Stage does not have to be set to automatically advance the stage.  It could be set to keep the stage at the same value, or (more commonly) it could link to Text Statements which may have other event conditions and may or may not have additional Utility events to further manipulate the quest value.

So one of the tricks I'm using in the TTD series when I have a high-traffic event square and need to be able to identify which stage the player has reached, is work backwards.  I have a Quest Stage event set to trigger at the highest possible value for that square, and if it fires, then the chain ends there and the quest is completed.  If it doesn't fire, it chains to another Quest Stage with one value less.  This repeats until the party satisfies one of those conditions, and by that time I know exactly where they are in the quest.  Merle, this is how I accomplish what you are looking to do.  In FRUA you could work forwards, but it took the same number of events.

Admittedly, this would be pretty cumbersome in the Case #2 example, and then FRUA's handling would seem to have the advantage.  Otherwise, Case #2 would be a breeze to handle if not for leaving the option open to repeat the whole thing ad nauseum. 

To be fair, can anyone think of a Case Study that would illustrate how OAUA's system would have an advantage?

[Merle]

Admittedly, I probably should have been making designs with OAUA years ago instead of just starting a few days ago.

I don't think OAUA's Quest Stage event is a bad way to handle quests... it's just different.  And it'll take time to get used to it.  I'm used to working forwards in UA, so working backwards just means I have to think about it a bit more.

[Darius]

Hi Merle,
Yes, that's the point I've been trying to make -- it's just a different approach to how Quests work and requires a different mode of thinking.  If FRUA were originally set up the same way, we would have found creative advantages to the system and come up with all sorts of clever ways to manipulate it, just as we did with the FRUA system. 

I'm pretty certain that the change is a simple, one-byte relation hack in CKIT.  I'm not opposed to changing it back to the standard behavior, but it seems only fair that both sides be considered first.  The very best argument I've heard so far is that asking designers to learn two ways of working with Quest Stages (I assume all potential OAUA modders also work in FRUA) is quite possibly a form of cruel and unusual punishment.  For newer designers, it's hard enough to master FRUA quest stage operation, and then come to find out some of what you've learned is backwards in OAUA. 

Can anyone think of any good examples where it would be beneficial to have the OAUA method in place? 

[ProphetSword]

Can anyone think of any good examples where it would be beneficial to have the OAUA method in place?

I can't, which is why I gave so many examples of how it would *not* be beneficial.