// So the other part we need is to actually feed input for the device. Notice
// that we already have the IInputUpdateCallbackReceiver interface on our class.
// What this does is to add an OnUpdate method that will automatically be called
// by the input system whenever it updates (actually, it will be called *before*
// it updates, i.e. from the same point that InputSystem.onBeforeUpdate triggers).
//
// Here, we can feed input to our devices.
//
// NOTE: We don't have to do this here. InputSystem.QueueEvent can be called from
// anywhere, including from threads. So if, for example, you have a background
// thread polling input from your device, that's where you can also queue
// its input events.
//
// Again, we don't have actual input to read here. So we just make up some stuff
// here for the sake of demonstration. We just poll the keyboard
//
// NOTE: We poll the keyboard here as part of our OnUpdate. Remember, however,
// that we run our OnUpdate from onBeforeUpdate, i.e. from where keyboard
// input has not yet been processed. This means that our input will always
// be one frame late. Plus, because we are polling the keyboard state here
// on a frame-to-frame basis, we may miss inputs on the keyboard.
//
// NOTE: One thing we could instead is to actually use OnScreenControls that
// represent the controls of our device and then use that to generate
// input from actual human interaction.
public void OnUpdate()
{
var keyboard = Keyboard.current;
if (keyboard == null)
{
return;
}
var state = new CustomDeviceState();
state.x = 127;
state.y = 127;
// WARNING: It may be tempting to simply store some state related to updates
// directly on the device. For example, let's say we want scale the
// vector from WASD to a certain length which can be adjusted with
// the scroll wheel of the mouse. It seems natural to just store the
// current strength as a private field on CustomDevice.
//
// This will *NOT* work correctly. *All* input state must be stored
// under the domain of the input system. InputDevices themselves
// cannot private store their own separate state.
//
// What you *can* do however, is simply add fields your state struct
// (CustomDeviceState in our case) that contain the state you want
// to keep. It is not necessary to expose these as InputControls if
// you don't want to.
// Map WASD to stick.
var wPressed = keyboard.wKey.isPressed;
var aPressed = keyboard.aKey.isPressed;
var sPressed = keyboard.sKey.isPressed;
var dPressed = keyboard.dKey.isPressed;
if (aPressed)
{
state.x -= 127;
}
if (dPressed)
{
state.x += 127;
}
if (wPressed)
{
state.y += 127;
}
if (sPressed)
{
state.y -= 127;
}
// Map buttons to 1, 2, and 3.
if (keyboard.digit1Key.isPressed)
{
state.buttons |= 1 << 0;
}
if (keyboard.digit2Key.isPressed)
{
state.buttons |= 1 << 1;
}
if (keyboard.digit3Key.isPressed)
{
state.buttons |= 1 << 2;
}
// Finally, queue the event.
// NOTE: We are replacing the current device state wholesale here. An alternative
// would be to use QueueDeltaStateEvent to replace only select memory contents.
InputSystem.QueueStateEvent(this, state);
}
// Invoked when a line of data is received from the serial device.
public void OnMessageArrived(string msg)
{
Debug.Log("Message arrived: " + msg);
// this works with CustomDevice.cs it actually feeds input for the device. Notice
// that we already have the IInputUpdateCallbackReceiver interface on CustomDevice class.
// What this does is to add an OnMessageArrived method that will automatically be called
// by the input system whenever it updates!
// Here >> feed input to our devices.
//
// NOTE: InputSystem.QueueEvent can be called from anywhere, including from threads.
// So in this case, we have a background thread polling input from your device,
// that's where we can also queue its input events.
//
// The original script read input on CustomDevice class. It made up some stuff
// there for the sake of demonstration. Additionally, It polled the keyboard...
//
// NOTE: The keyboard there was part of OnUpdate. however,
// they run OnUpdate from onBeforeUpdate, i.e. from where keyboard
// input has not yet been processed. This means that our input will always
// be one frame late. Plus, because we are polling the keyboard state here
// on a frame-to-frame basis, we may miss inputs on the keyboard.
//
// NOTE: One thing we could instead is to actually use OnScreenControls that
// represent the controls of our device and then use that to generate
// input from actual human interaction.
var state = new CustomDeviceState();
state.x = 127;
state.y = 127;
// WARNING: It may be tempting to simply store some state related to updates
// directly on the device. For example, let's say we want scale the
// vector from WASD to a certain length which can be adjusted with
// the scroll wheel of the mouse. It seems natural to just store the
// current strength as a private field on CustomDevice.
//
// This will *NOT* work correctly. *All* input state must be stored
// under the domain of the input system. InputDevices themselves
// cannot private store their own separate state.
//
// What you *can* do however, is simply add fields your state struct
// (CustomDeviceState in our case) that contain the state you want
// to keep. It is not necessary to expose these as InputControls if
// you don't want to.
// Map buttons to 1, 2, and 3.
if (msg == "0")
{
state.buttons |= 1; // |= will only ever add bits to the target
}
//string msg1 = msgSplit[1];
// Map the stick.
if (msg == "right")
{
state.x -= 127;
}
if (msg == "left")
{
state.x += 127;
}
if (msg == "up")
{
state.y += 127;
}
if (msg == "down")
{
state.y -= 127;
}
// Finally, queue the event.
// NOTE: We are replacing the current device state wholesale here. An alternative
// would be to use QueueDeltaStateEvent to replace only select memory contents.
InputSystem.QueueStateEvent(CustomDevice.current, state);
}
