‘Dream’ Key Bindings Progress

Hey Guys! As Key Bindings are one of the top requested things to come to Dream I thought I would do a little update on the situation.

Dream being on Early Access lets us hear what you folks want; and while being on Early Access isn’t much of an excuse to why Key Bindings aren’t there, we appreciate the patience. I’d say as of right now we are about 80-90% done in implementing it – It’s quite a difficult process and unfortunately not as simple as it sounds :(

That’s the status update on the process anyway but if you continue reading I’ll go into a bit more depth of the process and what’s left to conquer. If your wanting to go ahead and change your Key Bindings now you could do so by going into ‘UDKGame>Config’ and opening the ‘UDKInput.ini’ with notepad and editing the commands.

____________________

Key Bindings work in the UDK engine by the player controller reading the settings in ‘DefaultInput.ini’ and then created a editable ‘UDKInput.ini’ once the game launches.

In order to get custom Key Bindings working I would need to find a way to;
1. Recognise a KeyPress and assign this to a variable
2. Write this variable into the ‘.ini’ file
3. Create a UI & UC script to communicate to the ‘.ini’
4. Attach the command to that key in order for it to recognise what it is meant to do
5. Feedback to the UI to update the user

input

Those are the basic steps that are needed in order to progress. After much reearch, time and tinkering, Step 1 is done. I created a DefaultDreamPlayerInput.ini file which has all the input commands needed. It’s really quite nice to have them all in one place.

You can see the lines hold all the information needed in order to bind a key to a command. The commands such as ‘GBA_Jump’ are defined in another ‘.ini’ file where it would be linked to a Function name which is executed in game.

With these set up the next step was to make them readable so I added the [Dream.DreamPlayerInputBindings] above, which means anything below is accessible by that ‘package.class

Now I just needed to recognise key presses so inside the player controller I added the line ‘InputClass=class’Dream.DreamPlayerInputBindings” under defaultproperties in order for it to look for that input class when using the player controllers game type.

Now it was a matter of making the DreamPlayerInputBindings.uc class to create the functions which listen for and feedback the keypresses and write to the ini we created. In order to access the ini file however we have to extend the class type. So instead of creating a “Class Extension” we extend a certain part of a class within a class and and add a config file like so;

class DreamPlayerInputBindings extends PlayerInput within DreamPlayerInputMesh
config(DreamPlayerInputBindings);

This lets us change PlayerInput with the Config file at our disposal.
Next is the function command used to change keybindings;

simulated exec function ChangeInputBinding(name BindName, string Command)
{

local int BindIndex;

if (Command == “none”)

Command = “”;

for ( BindIndex = Bindings.Length-1; BindIndex >=0; BindIndex )
{

if (Bindings[BindIndex].Command == Command)
{
Bindings[BindIndex].name = BindName;
SaveConfig();
return;

}

}

}

It’s a pretty straight forward function which lets us use a command ‘ChangeInputBinding(name BindName, string Command)’ – So for example ‘ChangeInputBinding W GBA_MoveForward’ – The SaveConfig(); then runs which writes the string to the ini file. The for loop just checks to see if the the string matches what’s already in the ‘.ini’ file so we don’t create duplicates. If there is one, such as S = GBA_MoveForward and we run W = GBA_MoveForward it would just change the S to a W rather than keeping the S = GBA_MoveForward and adding a new one.

The next chunk of code does most of the work. It uses the new Function Command we just made in order to change the inputs. Even though there is more to the code I’ll just take and expand upon the chunk that’s looking for the Jump Keybind button.

function bool KeyInput(int ControllerId, name KeyName, EInputEvent IEvent, float AmountDepressed, optional bool bGamepad)
{

if(IEvent == IE_Pressed && JumpBindPlz == true) // Bind for Jump – JumpBindPlz variable is one that’s activated when listening for keybind to stop the function running multiple times when its not needed – Turned true from UI
{
ConsoleCommand(“ChangeInputBinding “ $ KeyName $ JumpCommand );
JumpBindPlz = false; // Turns of the bool off to stop this function running untill ran from the UI again
`Log(“Jump Bind:”$ KeyName $ JumpCommand );
SaveConfig();
return(false);
}
return(false);
// Allow other interactions to process input.

}

defaultproperties

{
JumpBindPlz = false
JumpCommand = ” GBA_Jump”
}

So this function is looking out for a keypress AND when the JumpBindPlz variable is true. This variable is set to true from the UI that will be made in the next step. Once the command runs it takes the KeyName variable and puts it in the Command we made earlier in order to change the bindings. I had trouble making a String Variable which was something like “ChangeInputBinding & KeyName GBA_Jump” as it didn’t like breaking the string to put a variable in there, so I had to assign the command (GBA_Jump) to its own variable, and run the command using 2 variables; “ChangeInputBinding & KeyName & JumpCommand

That’s most of the difficult process out of the way but next we had to create a Menu UI in order to let people change there keybindings. I wont go into much detail about this but a Scaleform Menu is created along with a .UC script for that menu which tells it what to do. When a user clicks on the binding they want to change a pop up box appears, the relative variable to let the function run is then set to true (So if User clicks the Jump Binding then ‘JumpBindPlz = true’). The next key that is then pressed is stored and ran in the command using the function above which then also stops the function from listening and saves the new key bind.

KeyBinds1

 

*Grey background is invisible in game showing the Game in the background

Right now this is as far as it really goes. The scaleform itself listens for a keypress and writes that key to the “Text Box” to inform the user of what key they have pressed, however right now it looks like scaleform is really limited to certain keys it can recognise so I am looking into a way to feed the value of & KeyName from the .UC script into scaleform. Or getting scaleform itself to read the ini file, which would also solve the issue where reloading the screen above would show Null where the Key name should be as it keeps forgetting.

There are also a few little sticky bits that need sorting out, such as certain keys in certain levels are trapped, meaning nothing happens even if they player uses them. So binding a key to one of these “Trapped” keys wouldn’t do anything. Also stop the menu from going back when Esc or B is pressed to assign a key bind.

Hope this clears things up and thanks for taking the time to read, hopefully it shouldn’t be too long before this update is with you!

Ash