What it does:
Helps you quickly locate sections in your script that fall outside a defined speed range.
How it works:
Set a Minimum Speed and a Maximum Speed in the extension window.
Click “Find and Go To Matching Section”.
The script will scan for pairs of actions (pos) creating a speed that is either below your Min or above your Max.
When found, OFS will jump the video playhead to the first of the two actions causing this off-speed segment. Press the button again to find the next instance.
Purpose:
Useful for quickly reviewing and identifying potentially problematic or unintended speed spikes/lulls in very long scripts during editing or QC passes.
Extract the main.lua file from the ZIP archive.
2.(Alternatively, if you’re familiar with Git, you can clone the repository.)*
Place the .lua file in your OFS extensions folder:
The typical path is: C:\Users\[YOUR_USERNAME]\AppData\Roaming\OFS\OFS3_data\extensions\
You can optionally create a subfolder within extensions (e.g., SpeedBasedNavigator) to keep things organized and place the main.lua file there.
Quick Tip to find the folder: In OFS, go to Extensions > Extension directory. This will usually open a folder one level above where the extensions folder is located or directly into a script folder. Navigate to the extensions subfolder within OFS3_data.
Load in OFS:
The extension should appear in your Extensions menu in OFS after placing it in the folder. You might need to restart OFS if it doesn’t show up immediately.
Notes:
Enable “Debug Prints” in the extension’s code (or if it has a UI checkbox) to see detailed logs in the OFS Extension Show Logs window.
Hope this helps your QC process!
Version 1.9.2 (Compared to v1.9.1 where search always started from the beginning)
Enhanced Search Functionality: Cycle Through Matches
The “Find and Go To Matching Section” button now intelligently searches for the next matching section from the script’s current playback position or the last found match.
If no further matches are found towards the end of the script, the search will automatically wrap around and continue from the beginning of the script up to the point where the last search began.
This allows users to cycle through all matching sections in the script sequentially.
If a full search cycle (including wrap-around) does not find any new matching sections, a message will indicate this, and the next search will restart from the beginning of the script.
This addresses user feedback requesting a more intuitive way to navigate multiple matching speed segments without always returning to the first one.
The extension seems to work really well!
A quality of life feature would be to have it cycle through points, so that it goes to the next matching section from your current position (and wrap around if no matching section is ahead) rather than always going to the first matching section in the script.
Like, this is only true if you actually edit the first instance before pressing the button again.
Oh, just noticed it cycles through but not based on the timeline position.
It’d be great if it started searching from your current time at the moment you press the button.
A new checkbox, “Scan from current timeline,” has been added to the Extension Window. This feature provides more flexible control over where the script begins its search for speed-defined segments.
How it works:
When “Scan from current timeline” is CHECKED:
Initial Scan: The script will start scanning for matching segments directly from the video player’s current timeline position.
Consecutive Scans (No Manual Time Change): If you press “Find and Go To Matching Section” again without manually changing the player’s timeline, the script will automatically search for the next matching segment that occurs after the one previously found. This allows you to quickly step through multiple matching sections from your current viewing point.
Scan After Manual Time Change: If you manually move the video player’s timeline to a new position and then press “Find and Go To Matching Section,” the script will reset its search and begin scanning afresh from this new current timeline position.
Wrap-around Logic: If a matching segment is not found from the current timeline position to the end of the script, the search will wrap around and scan from the beginning of the script up to the point where the timeline scan initially started (or just before the current player time if it was manually moved to a later point).
When “Scan from current timeline” is UNCHECKED:
The script will use its default behavior:
If a previous match was found in the same script, it will search from the action immediately following the last found segment.
Otherwise (or if it’s a new script), it will search from the beginning of the script.
This enhancement aims to provide a more intuitive and efficient workflow, especially when you want to focus your search on a specific portion of the video or quickly iterate through segments starting from your current playback position.
I’m always a bit skeptical about vibe coding, but if it works it works.
Not sure if or how much manual code review you’ve done on this, especially as you’ve copied the LLM’s description of the code in this topic. So like, I’d prefer if someone with experience could provide feedback and maybe contribute to the GitHub repo in case something’s off with it.
Yep, this is “Vibe coding” with an LLM and some agent tools. You’re looking at a project where the LLM was busy creating the tool for me, self-critiquing, checking its own functionality, and finally committing the repo to GitHub. All while I was on my other desktop, actually making funscripts!
Manual review from my side was minimal – just a quick pass. The LLM wrote most of this post too.
AI is a fantastic tool, saves me about 90% of my time.
And, I work with LLMs professionally at a data center. Love 'em, good at 'em.
Installation 