Tags
Creators
Details
0.1.5
Compatibility
Required content
Changes
[0.1.5] - 2026-08-05
-
Added
/sktrace loops, a live view of the loop andwhilesections running right now: what each one is, where it lives (script:line), the iteration it's on, how fast that number is climbing, how long it has been going, and how many copies of it are running at once. It's built for the loop that "just keeps going" - the one you'd otherwise hunt down by scattering broadcasts through your code. A counter that keeps climbing and never clears is your runaway, and the row turns amber, then red, as it starts to look like one. -
Added a Loops panel to HTML reports, listing every loop seen running during the capture with its peak iteration count, peak concurrency, and whether it was still going when the report was written. The panel stays hidden when no loops were observed.
-
Added frozen-server detection for the case the loops view cannot cover. A loop with no wait inside never yields, so an infinite one pins the server's main thread and nothing in-game - not even
/sktrace loops- can run. skTrace now watches for that from its own background thread and, once the server has stopped ticking forloop-hang-seconds(10 by default), logs the responsible loop'sscript:lineto the console, the one surface still alive during a freeze. It is detection only: it never stops, kills, or interrupts anything. Turn it off withloop-hang-detection: false. -
Loop watching is on by default and safe to leave on: unlike
line-level-profiling, it only reads the iteration counter Skript already keeps for every loop and never rewrites how a script runs. Loops are found once, when profiling starts, and sampled about once a second on skTrace's existing tick task, so there's no new scheduler task and no per-iteration cost. Only loops that span ticks (that is, contain a wait) can be observed - a no-delay loop finishes inside a single tick, leaving nothing to see. Disable the whole feature, including the startup scan that finds loops, withloop-watching: false. -
Fixed skTrace claiming per-trigger timing was unavailable on your Skript version when it was working fine. If a capture ever started at a moment when no event triggers were loaded (every script is commands or
every N seconds, or scripts had not finished loading yet), the warning latched on and stayed on for the rest of the server's life: every later/sktrace startrepeated it, and every report was stamped with it, including reports whose Triggers table was fully populated. An empty registry is now recognised for what it is, "nothing to hook yet", and the check is re-run on each capture instead of being decided once. -
Fixed every Skript command collapsing into a single report row called
simple event "simple event". Skript builds a command's trigger on a generic event whose own label is that placeholder text, so all of them shared one name, and sharing a name meant sharing one set of timings: three commands showed up as one row, at the line number of whichever unrelated trigger happened to be registered first. Each command is now its own row, named after the command (command /home), and other triggers that use the same generic event fall back to the event line you actually wrote. -
Fixed
/sktrace resetquietly ending per-trigger and per-function collection for the rest of the capture. Only event-level timings kept recording afterwards, so the Triggers and Functions tables stayed empty until the next script reload or profiler restart, with nothing to indicate why. Collection now resumes immediately. -
Fixed
/sktrace resetnot clearing function times, so after a reset the Functions table showed lifetime totals next to a freshly reset window. -
Changed the console output of
/sktrace start. The hook-install detail (registry scan, per-field dump, hooked counts) is now off by default, since it repeats on every capture and every/sk reloadand says nothing an operator can act on. Setdebug-logging: truein config.yml to bring it back, or run/sktrace diag, which dumps the same Skript internals on demand. Genuine problems are still logged as warnings either way.
All Verified against Minecraft 26.2 on Skript 2.16.1
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:OJPsLCzf:gJc2tuii"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:OJPsLCzf:gJc2tuii"
}

