log_tools: option to start encounter offset by a chosen value

[jacob-keller]

Feature(s) Requested

While working on making timelines, it would be convenient if the make_timeline.ts script could offset the starting time for the generated log by a fixed offset. This is useful for fights like dungeons and CEs in field content where there are often many different timelines in the same zone file. I saw that there is --adjust but this appears to be for modifying an existing timeline file. There is also phase, but I want an option to set the starting offset so that I don't have to then immediately adjust the resulting generated lines by the chosen offset value.

[JLGarber]

Off the top of my head I want to say this should be relatively simple. The initial start time is hardcoded within assembleTimelineStrings(), so 3 AM brain says it should be easy to instead dynamically initialize this value if needed. I'll look at it over the holidays.

[xiashtra]

What I'd really like to see is named blocks, like was discussed here: quisquous#5619 (comment) and then we could get rid of the whole offsetting additional encounters within the same zone thing.

[jacob-keller]

Agreed blocks would be a much better solution

…

On Fri, Dec 19, 2025, 3:01 AM xiashtra ***@***.***> wrote: *xiashtra* left a comment (OverlayPlugin/cactbot#850) <#850 (comment)> What I'd really like to see is named blocks, like was discussed here: quisquous#5619 (comment) <quisquous#5619 (comment)> and then we could get rid of the whole offsetting additional encounters within the same zone thing. — Reply to this email directly, view it on GitHub <#850 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGVRX3LFXRCH64UMGPW55L4CPLJ7AVCNFSM6AAAAACPQPT2N6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZUGYYTSNRQGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jacob-keller]

Looking through those comments, blocks is definitely a bit more work. I think even blocks for phases/splits in the timeline would also be useful. I'm not sure what all actually has to be modified to implement blocks though, where as an offset value would be relatively simple.

I do think blocks would be a much better use of time spent developing, but I am unsure where to start. I may try to take a deeper look into this when I get some time.

[jacob-keller]

I'm a bit at a loss how to implement blocks, since right now TimelineParser keeps everything in lists of syncs. If I try to separate it into a map of blocks by name to its own syncs, it seems very messy and a lot of refactor required. There is also the issue of timeline config being available, and wanting to make sure we're somehow backwards compatible with existing configs.

I also looked at trying to change things to store events as both a block and a time, but this is also very messy and probably the wrong approach for handling this, since we really want the timeline logic to be able to tell which blocks are active. I'm really not sure I have enough knowledge for how to implement this within a reasonable scope.

[jacob-keller]

Actually, I came up with a potential solution: Have the TimelineParser detect blocks and automatically adjust the timings for entries within the block. Combine this with making blockend automatically stop the timeline if it reaches the end of a block without a jump.

This is probably the most "ugly" or "hacky" way to resolve this, but I think it would make things a lot simpler to implement.

Basically the parser would be "unrolling" blocks into our existing timeline format, so that we don't need to modify the timeline player at all, and only need to modify the parser.

@xiashtra thoughts?

[jacob-keller]

#853 might work, if we are ok with the hacky "unrolling" solution. I think its acceptable since its really just a prettier and automatic way of doing what timeline files already do by hand.