Okay, so I have an alternative solution that supports gravity and things.
It's a little bit of a hack, but it works.
This method requires two SMBX events, one called "DisablePlayerMovement" and one called "EnablePlayerMovement".
DisablePlayerMovement should consist solely of the forced button press "Drop". EnablePlayerMovement should be a blank event.
Now, we can use exactly the same code as before in the functions to enable and disable player movement:
Code: Select all
local freezePlayer=false;
function cinematX.freezePlayerInput()
freezePlayer = true;
end
function cinematX.unfreezePlayerInput()
freezePlayer = false;
end
And now, we need to handle actually freezing the player in the update loop. Unfortunately, using these events will freeze the player, but also disable progressing the text in cinematX cutscenes, so there's some extra code to handle that (note: This "progress text" code should probably be put into a function that both handles call. Duplicated code is very rarely a good idea). Some of this code is identical to the input code in cinematX already:
Code: Select all
if(freezePlayer) then
triggerEvent("DisablePlayerMovement");
-- Skip dialog if allowed
if (getInput().str:find("x") and cinematX.dialogOn == true) then
if (cinematX.dialogNumCharsCurrent < string.len (cinematX.dialogTextFull)
and cinematX.dialogSkippable == true) then
cinematX.dialogNumCharsCurrent = string.len (cinematX.dialogTextFull)
cinematX.dialogTextTime = 0
cinematX.dialogSpeakerTime = 0
elseif cinematX.dialogEndWithInput == true then
playSFX(23) -- 10 = skid, 14 = coin, 23 = shckwup
cinematX.endDialogLine ()
end
getInput():clear();
end
else
triggerEvent("EnablePlayerMovement");
end
This causes an additional piece of text progression code to run when the player is frozen, which uses the custom cheats system, rather than the player's button presses, to handle input. The character can no longer move when frozen, but is still affected by gravity, and if key presses are done via SMBX events, can also be animated.
EDIT: If it were possible to set forced inputs directly from LunaLua, then this setup could be a lot neater, I think.
EDIT EDIT: Okay, so there is one drawback to this system - holding X will skip through the cutscene. This could be made to look like intended behaviour, but the reason it occurs is that the getInput system doesn't make a distinction between holding a button down (causing it to be typed repeatedly) and pressing it a number of times. I believe it should be possible to determine, from C++, whether or not a key is released or not, which, coupled with the current system, could allow for an entire input system to be built, separately from the SMBX one. Of course, if you're going to do that, you might as well bypass custom cheats entirely for this and just create raw event hooks in Lua which look at C++ key presses, outside the SMBX engine.
EDIT AGAIN: Okay, so a quick look at the source and some C++ event handling suggests that this might only be strictly possible with an extended library. It may be worth the effort, at some point, to attach something like SDL as a separate library, to allow for proper input event handling. I think it's far from #1 priority at the moment, but it's something to think about, at least.