More advanced instance timer for possible use in timing GWSCR second based records

[HiImFlo]

Hello, I had a short talk with Jon yesterday and he is generally open to having a feature like this in toolbox. There currently is a debate on GWSCR about second based records, and one option to track achieved times would be via instance times. There are other options of measuring this, but I do not think this discussion belongs here. So dear GWSCR users, if you feel like you want to argue about this topic please do not do it here but instead in the thread over on the GWSCR forums. This issue should only discuss the most reasonable technical implementation of instance times.

---

Now, about the actual content of the desired feature: There is already a good implementation of instance times for dungeons, and I feel like it is not too much of a leap from that to a general implementation that covers more use-cases.

In general I think the idea would be to have a window that tracks the x (10?) last instance end times on map change. So however you leave an area, either by walking through a portal, resigning or travelling, it should create an entry in that list.

Maybe this list could incorporate both the map end times as well as other events, like dungeon timing events. E.g. (2 level dungeon): 1st event: End time dungeon level 1 (current implementation) 2nd event: Time dungeon chest spawn (current implementation) 3rd event: End time when 2nd level map is left by traveling to an outpost, should propbably incorporate map ID

---

Optional additional ideas Trust in records is great, but I do not see any downside in incorporating some additional measures to discourage malicious behaviour. For example, there could be a "record mode" for the objective/instance timer that prints a Hash code that incorporates some time data (system time / instance time) and some ingame data (inventory info, enemy proximity...). While of course not perfect, as TB is open source anyways and this could be manipulated, I think every step helps. A hash like this could be generated whenever a new entry is created in the objective/instance timer or maybe even cyclical every x (30?) instance seconds.

A tool like this might also be of interest to people that do not necessarily want to use toolbox. Maybe a standalone is worth considering.

[RiftLurker]

I'm not quite sure what exactly your goal with this is. Is it posting a timing file with the record instead of relying on on-screen display of the current objective window/instance timer?

I can see very little use for tracking instance times on map change. I thought about allowing for configurable objectives (such as missions or custom splits) but decided against putting in the effort for very low value. What exactly is the purpose of adding map change events? Frankly I'm not sure what exactly the issue with the current implementation of the objective timer is in your opinion.

Additionally I'm not convinced your suggested hash makes any sense. It can not only be easily forged, there is almost no way for us to confirm the truthfulness of such a hash.

[HiImFlo]

The current objective timer works very well for dungeons and most elite areas.

It does not work well for anything where you have multiple chained together maps without an event recognized by the objective timer. Missions, running, Sorrows Furnace fullruns. Not sure if that list is exhaustive. An entry to that list of objectives on map change seems to cover pretty much all the missing use cases that are not yet covered with the current implementation.

The goal would be to have the objective timer open over the whole duration of a multi level run and then in the end just taking the times in seconds and adding them up.

And again, there is a reason why I listed the hash thing as optional That being said, I do not think it is too hard to come up with something that most people wont be able to manipulate. You could make a super simple hash, for example consisting only of system time in minutes and of player hp rounded to the nearest 100 and energy rounded to nearst 10. It could be so simply that you can even calculate it in your head. And of course you could manipulate that by setting a fixed value for system time and compiling your own local version of TB, but honestly that is not within 90% of peoples capability.

[RiftLurker]

I can't currently think of a nice way to integrate a list of past visited maps into the current objective timer. However I'd be happy to work on a feature that allows for customizable objectives based on certain events. This would allow players to create and share custom objective timers for stuff like Droks runs

Currently imagining it like this:

Event Types Each of these requires different parameters (e.g. mapID for Map load, doorID for Door event)

• Map load
• Door event
• Dungeon chest spawned
• Cinematic
• DoA Area opened
• Mission Bonus
• Quest updated
• NPC Dialog
• Agent spawned
• Agent died
• Agent allegiance update (I believe this is used for Dhuum)

Objective

{
    name,
    start: Event, // used to determine whether this objective should be used - likely to be a map load event
    partySize, // optional
    objectives: {
        name,
        start: Event,
        end: Event,
    }[],
}

The objectives could either be configured via file (more advanced, some things like doorIDs or NPC dialogs are impossible to find out for non-programmers anyways at the moment) or with some UI if we really feel like it. All of the current areas will obviously be transferred to the default configuration.

[3vcloud]

This is a good set of ideas (and would be perfect for setting up livesplit for example), but should be a new project with a separate dll to inject away from toolbox if thats the route we go down,

[HasKha]

Many good suggestions in this thread!

However, I think the first step is to just change the timer itself. Implemented in #556. I wanted to keep it simple to make it natural for tb users to use, and consistent with a simple timer overlay (as to not make it difficult for non-tb users).

I think more fancy livesplit-like functionality of timing the different segments of the run should belong in the objective timer in toolbox, and/or in a separate tool.

[RiftLurker]

I actually completely missed @HiImFlo talked about the instance timer, even though it's clearly visible in the title. My suggestions were indeed for the objective timer, the changes in your PR look really good for the purpose of this issue.