Mod commands not being applied correctly

In an attempt to convert this wonderful piece of art to Stepmania 5, I ran into a problem with mod commands. Essentially, this, for example:

GAMESTATE:ApplyGameCommand('mod,' .. '*0.1 200% dizzy');

...will work fine in builds prior to SM5 (I've only tested with OpenITG but I assume this is just an SM5 thing), and will slowly start to make the notes spin. In SM5, it ignores the mod application speed (*0.1) and will go to 200% dizzy immediately. The result of this in effect is somewhat hilarious but still incorrect. I tested, and GAMESTATE:ApplyStageMods() does the same.

Is this intentional? If so, then why, and is there another way? (that doesn't involve setting an update command to increment mods manually, please, thanks)

Solution 1: Use a new API that was made specifically to provide a way to set numbers directly instead of going through cumbersome strings.
The PlayerOptions API exists as an alternative to using ApplyGameCommand function because using strings for modifiers really bugged me. See the PlayerOptions section of Docs/Luadoc/Lua.xml for a list of functions and explanation.
GAMESTATE:GetPlayerState(pn):GetPlayerOptions("ModsLevel_Song"):Reverse(1, .1)
(store the object returned by GetPlayerOptions and reuse it for convenience)

Solution 2: Adapt this code I wrote when converting Iris almost a year ago.

local function iris_mod_internal(str, pn)

	local ps= GAMESTATE:GetPlayerState(pn)

	local pmods= ps:GetPlayerOptionsString('ModsLevel_Song')

	ps:SetPlayerOptions('ModsLevel_Song', pmods .. ', ' .. str)

end



local function iris_mod(str)

	for i=1,2 do

		if _G['iris_diffP'..i] == 4 then

			iris_mod_internal(str, 'PlayerNumber_P' .. i)

		end

	end

end



-- This chunk is from inside the function that walks a list of mod strings, picking which one should be applied at a given time.

-- Collect all the mods that will be applied in this frame into one string.

-- Mod tweening doesn't work correctly if the mods are in seperate commands.

local mods_this_frame= {}

local function add_mod(mod_str)

	mods_this_frame[#mods_this_frame+1]= mod_str

end

local function execute_mods()

	if #mods_this_frame <= 0 then return end

	local total_mod_str= table.concat(mods_this_frame, ", ")

	iris_mod(total_mod_str)

end

Thanks, it works great! I like these API changes, never actually looked into them. Great work on that.

Thanks. I wrote the PlayerOptions and SongOptions API because I made a completely custom options screen and it really bugged me to have to parse a bunch of strings to find out what options the player had set. It just seems so much better to work directly with numbers where possible and skip the unnecessary layers of conversion.

If you're converting more aids than just that one file, see if this zip file provides a better starting point than the xml files.
(I stripped out everything except the lua produced by my converter and didn't test anything at all, testing 200+ files isn't worth my time. Known problems are from API changes like enum values being strings ("GetDifficulty" returns "Difficulty_Challenge" instead of "4" for example), mod commands which I posted the solution for above, and input from the DivinEntity noteskin, which could be handled by an appropriate input callback broadcasting the messages.)