FIX INPUT KEYS IN MARBLE BLAST GOLD

Administration please make this sticky!

Sometimes on certain computers, keys will end up disabling themselves. This is because of the fact that there is an engine variable that has been exposed through script that sometimes messes input up. However, because the platinum team had made a discovery on this, I will provide you how to fix this in any mod OTHER THAN marble blast platinum (You need .cs files which mbp don't provide and the new mbp update has it fixed.)

go to marble/client/scripts/playGui.cs

open it in notepad/wordpad if your on windows, text-edit if your on mac

find function PlayGui::onWake(%this)

find in the function where it has the following:

$enableDirectInput = 1;

replace that with this commented:

// $enableDirectInput = 1;

save the file and load marble blast.

If you have any problems, post here and I can help you out.

~Jeff

Notes:

- If you use a joystick, beware that the joystick may not work.
- As previously mentioned, this has been fixed in MBP for the new update that will be coming out soon. More details at the appropriate time on how to fix it in the new MBP update after its released....

Nice. If anyone is using MBP / doesn't have those files, a reasonable alternative would be to add this to main.cs:
Code:function fix() {$enableDirectInput = 0; schedule(1000, 0, fix);
fix();}


It's kinda hacky, but gets the job done.

you forgot a } to close the function. fix it nao.

Apr 30, 2013, 10:11pm, higuy wrote:Nice. If anyone is using MBP / doesn't have those files, a reasonable alternative would be to add this to main.cs:
Code:function fix() {$enableDirectInput = 0; schedule(1000, 0, fix);
fix();}


It's kinda hacky, but gets the job done.

Why do you have to schedule it? If it is just executed after everything else is loaded (put at the end of main.cs) would that not work? Just curious.

PlayGui.cs manually sets the variable when it is shown/hidden, so the only way to continually set it without code modification would be to schedule it.

I see. Does that slow down the game since it has to have that delay loop or does the engine optimize that somehow?

May 6, 2013, 11:06am, perishingflames wrote:I see. Does that slow down the game since it has to have that delay loop or does the engine optimize that somehow?

From what I know of coding, the act of scheduling and changing one variable is extremely minimal in computer terms, requiring almost no processing power to do. You could probably run a hundred of these at once and only then would it start cutting in to frame rate(if it even did at that point).

May 6, 2013, 11:06am, perishingflames wrote:I see. Does that slow down the game since it has to have that delay loop or does the engine optimize that somehow?

Tested it with that custom function that checks rate of execution:

input was: $enableDirectInput = 0;

Ran 5.38139e+006 times in 1 second(s) - how many times that can be executed in one second
0.000185826 ms per execution (approx) - how long it takes to execute once

That's quick. Guess no reason to avoid using them then