0.7.2: Quest timings

Discuss coding questions, pull requests, and implementation details.
User avatar
pango
Posts: 886
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

0.7.2: Quest timings

Post by pango » Wed Dec 26, 2018 11:59 am

We probably all know that time-based tutorial is not great, but after watching people receive Lesson 4 message ("open the secret door, kill the rat") when arriving in Daggerfall, I suspected something fishy.
Looking at _TUTOR__ quest, it uses timers of a few in-game minutes, for the most part. With 12x time compression, this should result in at most a few minutes real time.
However in quest debugger I see in-game day + few in-game minute delays.
It seems the "range 0 1" is interpreted as inclusive, and a whole in-game day is randomly added to delays. That doesn't look right.
Last edited by pango on Mon Dec 31, 2018 8:45 pm, edited 1 time in total.
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
Interkarma
Posts: 4132
Joined: Sun Mar 22, 2015 1:51 am

Re: Dev build/Linux: tutorial timings misinterpretation

Post by Interkarma » Wed Dec 26, 2018 12:51 pm

Clock resource params are not well known. I've erred on the side of being too generous with timing so that majority of quests can be completed normally. If you have a look through the Clock.cs file, it's filled with stuff like "hack" and "todo". There's more work to be done here later.

Going back to older builds in 2017, the tutorial quest did not have this issue. I'm happy to accept this as a bug with the tutorial quest, just keep in mind Clock resource itself it still a "best effort" kind of situation. :)

User avatar
pango
Posts: 886
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Dev build/Linux: tutorial timings misinterpretation

Post by pango » Wed Dec 26, 2018 2:30 pm

Yes, I've seen the timers section of quests described as "the less understood section" in the UESP too. This is certainly hard (and literally time consuming) to reverse engineer just by observation.
However, in this specific case it seems rather obvious that this "range 0 1" cannot add any delay, those messages are supposed to appear just minutes apart. They're other quest cases where a "real" range is used with "flag 1", so I don't think the range is disabled because of some flag either. That's why I suspect the range upper bound is exclusive (either that, or range is not random extra time but a constraint on computed result, but I doubt that):

Code: Select all

diff --git a/Assets/Scripts/Game/Questing/Clock.cs b/Assets/Scripts/Game/Questing/Clock.cs
index 5c2881b8..26947cfa 100644
--- a/Assets/Scripts/Game/Questing/Clock.cs
+++ b/Assets/Scripts/Game/Questing/Clock.cs
@@ -237,7 +237,7 @@ namespace DaggerfallWorkshop.Game.Questing
                         clockTimeInSeconds = GetTravelTimeInSeconds();
 
                     // Add range
-                    int randomDays = UnityEngine.Random.Range(minRange, maxRange + 1);
+                    int randomDays = UnityEngine.Random.Range(minRange, maxRange);
                     clockTimeInSeconds += randomDays * DaggerfallDateTime.SecondsPerDay;
                 }
 
I tested the tutorial with that change, it's certainly still a bit slow, but is otherwise working again
I created a PR
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
Interkarma
Posts: 4132
Joined: Sun Mar 22, 2015 1:51 am

Re: Dev build/Linux: tutorial timings misinterpretation

Post by Interkarma » Wed Dec 26, 2018 9:32 pm

pango wrote:
Wed Dec 26, 2018 2:30 pm
I tested the tutorial with that change, it's certainly still a bit slow, but is otherwise working again
I created a PR
Did you also regression test that fix with a few dozen other quests to ensure they are still granted enough time to complete? Are there now cases where other quests could end up with nearly zero time to complete in some situations? I added that +1 hack on purpose, you know. :) It's not an misinterpretation exactly, I'm quite aware that I'm working with unknowns here. This change is a concession made on partial data that happens to break tutorial quest.

I'm happy to accept this as a bug in tutorial quest execution specifically. But I'm not going to remove a workaround that I made intentionally for other quests just for sake of the tutorial quest alone. I'll take another look at Clock resource and how it affects tutorial quest when I can. Thanks for the report!

User avatar
Interkarma
Posts: 4132
Joined: Sun Mar 22, 2015 1:51 am

Re: 0.7.2: Tutorial quest timings

Post by Interkarma » Wed Dec 26, 2018 11:31 pm

Another workaround just for tutorial quest would be to remove "flag 1 range 0 1" from those timers in _TUTOR__. This will restore function to work more like it was before I made that concession for commoner quests earlier this year.

I'd love to know what those range values are meant to represent, as well as all the possible flag settings. That's definitely more of a refinement issue than a critical one however. Quest emulation still works very well for the most part, even with these unknowns.

User avatar
pango
Posts: 886
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: Dev build/Linux: tutorial timings misinterpretation

Post by pango » Wed Dec 26, 2018 11:32 pm

Since it's only modifying the time upper bound, it's not creating impossible situations that couldn't occur before, only changing the odds. In other words, that +1 cannot be what saves the day.
But I agree, there's a need for more reverse-engineering on the timers before deeper modifications.

The safest way to fix tutorials would be to remove the "range 0 1" from _TUTOR__.txt
Ah, you beat me to it
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
Interkarma
Posts: 4132
Joined: Sun Mar 22, 2015 1:51 am

Re: Dev build/Linux: tutorial timings misinterpretation

Post by Interkarma » Wed Dec 26, 2018 11:52 pm

pango wrote:
Wed Dec 26, 2018 11:32 pm
Since it's only modifying the time upper bound, it's not creating impossible situations that didn't occur before, only changing the odds.
Don't be so sure. :) The +1 is there specifically to ensure certain timers always get at least 1 day. For example, this timer in A0C00Y17.

Code: Select all

Clock _traveltime_ 00:00 0 flag 1 range 0 2
The timer itself is zero and the range (whatever that is) is 0-2. Without my hacky +1, it's possible for a bad random roll to result in literally 0 hours on that timer. In some quests, this can lead to quest ending instantly, which obviously isn't intended. That's what I mean when I say that I added that +1 as a concession for other quests. If I merged your PR, those quests would end up breaking again just to fix tutorial. I much prefer the current behaviour, even though it's still not 100% correct.

If we did remove the +1, then I'd need at least some other concession to ensure timers didn't roll a 0. The problem is we end up in the same situation not knowing if this is or isn't intended for that quest. One workaround based on partial information is just as good as another at this stage, and the tutorial quest is already a lost cause as far as I'm concerned. :)

User avatar
pango
Posts: 886
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: 0.7.2: Tutorial quest timings

Post by pango » Wed Dec 26, 2018 11:56 pm

But the code you linked doesn't do that; Those would:

Code: Select all

int randomDays = UnityEngine.Random.Range(minRange, maxRange) + 1;
or

Code: Select all

int randomDays = UnityEngine.Random.Range(minRange + 1, maxRange);
Last edited by pango on Thu Dec 27, 2018 12:06 am, edited 1 time in total.
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

User avatar
Interkarma
Posts: 4132
Joined: Sun Mar 22, 2015 1:51 am

Re: 0.7.2: Tutorial quest timings

Post by Interkarma » Thu Dec 27, 2018 12:05 am

Yep, you're right. I've made an error there and I see what you were getting at earlier about changing the odds. As you say:

Code: Select all

int randomDays = 1 + UnityEngine.Random.Range(minRange, maxRange);
Would correctly fit my intention. It still doesn't help tutorial quest though, but I'm happy just to chuck those flag values for now until we can look at the Clock resource again and puzzle out those flags and ranges further.

But not today. I'm on leave, and the quest system has already soaked up way too much of my life. :)

User avatar
pango
Posts: 886
Joined: Wed Jul 18, 2018 6:14 pm
Location: France
Contact:

Re: 0.7.2: Tutorial quest timings

Post by pango » Thu Dec 27, 2018 12:08 am

Interkarma wrote:
Thu Dec 27, 2018 12:05 am
Would correctly fit my intention. It still doesn't help tutorial quest though, but I'm happy just to chuck those flag values for now until we can look at the Clock resource again and puzzle out those flags and ranges further.

But not today. I'm on leave, and the quest system has already soaked up way too much of my life. :)
More than fair enough :)
When a measure becomes a target, it ceases to be a good measure.
-- Charles Goodhart

Post Reply