Better way to send an InputObject from client to server?

I was confused yesterday over another certain limitation when firing RemoteEvents (client to server) with an InputObject as a parameter, where InputObjects are one of many things that are always omitted when sent over the network; thankfully I’ve already had experience struggling with this exact same issue regarding other objects and so i was able to figure out that it seems as though i need to refine the InputObject down to the KeyCode or UserInputType to be able to send it;

-- this is on a localscript btw

local function func_onBindFired(actionName,
	inputState: Enum.UserInputState, inputObj: InputObject)
	
	RemoteEvent:FireServer(inputState, inputObj)
	-- ^ this would fire as inputState, nil (the data within the second parameter is omitted)
	RemoteEvent:FireServer(inputState, inputObj.KeyCode)
	-- ^ this would fire as inputState, AND the correct KeyCode which is what i just figured out
end

RemoteEvent:FireServer(Enum.UserInputState.Begin, Enum.KeyCode.R)
-- ^ this would fire as inputState AND the correct KeyCode, which is what confused me originally

ContextActionService:BindAction("hi", func_onBindFired, false, Enum.KeyCode.R)

because of this, I would assume that my best bet would be to make a simple function to return a reasonable KeyCode/UserInputType depending on what the InputObject represented? (keep in mind I’ll be sending keyboard + mouse inputs for now but likely multiplatform inputs later)

local function Converter(inputObj: InputObject): (Enum.KeyCode | Enum.UserInputType)
	local keycode = inputObj.KeyCode
	
	if keycode == Enum.KeyCode.Unknown
	then return inputObj.UserInputType
	else return keycode end
end

-- and then the new code would look like the improved version below
local function func_onBindFired(actionName,
	inputState: Enum.UserInputState, inputObj: InputObject)
	
	RemoteEvent:FireServer(inputState, Converter(inputObj))
end

is this the correct way I should be doing this? im feel content with this solution as it works for me but i would prefer a second opinion incase i overlooked anything with my Converter function

1 Like

The reason is because InputObjects are instances that the client creates. You can normally send instances but this case is different because this instance is only on the client so it turns to nil when you send it to the server. I can’t see why someone would realistically do this because it puts extra load on the server when you could process it on the client and fire remote events when something notable happens.

2 Likes

this actually makes alot of sense then, thanks for explaining that, maybe it was placed somewhere in the documentation but i didnt see it when i skimmed through so thats strange


yeah, admittedly this is likely going to be a somewhat short-term system for an unpublicized game while i’m needed somewhere else but the application is for a survival game where the server requests the client to fire a RemoteEvent for certain inputs unique to any item being held;

the reason i havent hardcoded for certain inputs such as LMB, R, etc. is because i wanted to make the system dynamic for each item which may need more inputs than others, or none at all (eg you could imagine a weapon needing LMB to attack, a keybind for something fancy like blocking, etc. but a coin wouldn’t have any interactions when held)

frankly i may just hardcode certain inputs later on but right now i wanted to make the system more ambiguous so it would feel less restrictive while testing any new items add in the future with as many keybinds i’d like to use for it

2 Likes


is it like this?

sorry for such a late response, was out on holiday :sweat_smile: the difference between the code example you have sent and the code i am using is that it will not work for InputObjects with no keycodes, like MouseButton1.

i believe this would work for all keyboard inputs, however wouldn’t for other inputs like with the mouse, which are kept within the InputObjects UserInputType, instead of its Keycode