Maybe not an issues but i send it anyways

Logs

[00:02:16] [Server thread/WARN]: [MythicMobs] Invalid math operation on PlaceholderFloat: 0.5to-0.5
[00:02:16] [Server thread/WARN]: [MythicMobs] Invalid math operation on PlaceholderFloat: 1to-1
[00:02:16] [Server thread/WARN]: [MythicMobs] Invalid math operation on PlaceholderFloat: 2to-2
[00:02:16] [Server thread/WARN]: [MythicMobs] Invalid math operation on PlaceholderFloat: 3to-3
[00:06:33] [Server thread/WARN]: [MythicMobs] Invalid math operation on PlaceholderFloat: -8to-2
[00:06:35] [Server thread/WARN]: [MythicMobs] Invalid math operation on PlaceholderFloat: -32to-16
[00:06:48] [Server thread/WARN]: [MythicMobs] Invalid math operation on PlaceholderFloat: -3to-2

Config that triggers it

- recoil{r=0.5to-0.5;pitch=-0.5to0.5} @PlayersInRadius{r=32}
- recoil{r=1to-1;pitch=-1to1} @PlayersInRadius{r=24}
- recoil{r=2to-2;pitch=-2to2} @PlayersInRadius{r=16}
- recoil{r=3to-3;pitch=-3to3} @PlayersInRadius{r=8}
- recoil{r=4;pitch=-8to-2;yaw=3to8}
- recoil{r=12;pitch=0to4;yaw=-32to-16}
- recoil{r=6;pitch=-3to-2;yaw=16to32}

In the older build, pitch and yaw use a separate parser, while the logged -8to-2, -32to-16 and -3to-2 values only exist as pitch and yaw in our config. Those fields may therefore go through PlaceholderFloat in 5.14. This part should be confirmed in the 5.14 source.

Problem

The range pattern rejects a negative upper bound. RandomFloat.PATTERN allows a minus sign on the lower bound only. I tested the pattern from the 5.13 jar against these values:

Every rejected value is a value from the logs, and every accepted form is absent from them.

The value is treated as an expression, which fails on every cast. PlaceholderFloatImpl.of does not create a random range for these strings, so they fall through to the general placeholder path. Math evaluation then fails at runtime and logs one warning per evaluation. There is no rate limit, which is why a single skill can produce millions of lines.

The range is lost. In the older build, the value falls back to 1.0 after the failure. If 5.14 does the same, these mechanics use a fixed value and never apply the configured range.

Swapping the bounds is only a partial workaround. 1to-1 can be rewritten as -1to1, but this does not work for -8to-2, where both bounds are negative.

Solution

1. Accept a negative upper bound in RandomFloat.PATTERN, so these values become random ranges at load time.
2. Check that the RandomFloat string constructor still splits such values correctly once they reach it.
3. Check the matching integer and double range parsers for the same limitation.
4. If an invalid numeric value still reaches runtime, report it once at load time with the skill and file, rather than on every evaluation.