You can cross simple data like bools or numbers or strings, but apparently there are some things you can’t cross (Like InputObject, the thing InputBegan returns).
Ultimately I want to create a simple-to-use module that makes life easier than directly using LocalScripts.
Example of code with module:
hammer = require(id)
Player = hammer:Get('game.Players.LocalPlayer')
hammer:Get('game:GetService("UserInputService").InputBegan',functionname)
hammer:Get('game.Lighting.Changed',functionname2)
* What is the issue?
There are some types of data (Like InputObject, the thing InputBegan returns) that can’t cross the border between client and server.
* What solutions have you tried so far?
I could have a thing that takes anything returned by a client and stores all the info in a table-clone.
However, that would be hard due to the requirement of an API of some sort.
It would be awesome if someone already thought of this and has made something like this. wishes upon a star
What exactly is it that you want? And why do you want them, too?
I’m a little confused by your examples. Certain things in there, such as LocalPlayer, won’t exist on the server and can be accessed by game.Players[PlayerName] anyway.
I know that LocalPlayer doesn’t exist on the server side.
This module is supposed to be a bridge of sorts between server and client.
It would be way easier to use than having to bother with remote functions and such.
And no, remote functions are not that hard.
I realise that.
This would just make life a little bit easier.
Less things you have to track in your head.
The idea when Roblox designed Remote functions and events was likely to make them as easy to use as possible while keeping all possible functionality the users could want. If you wrap this in an ‘easier to use’ module, odds are you are limiting functionality.
Remotes are not difficult; they act a lot like functions or events you have probably already used (except running on the opposing machine). Also it wouldn’t be very useful considering it could lead to exploitable methods if it can make client access/manipulate server sided objects. There is also a problem with replicating data too rapidly (which then requests become throttled). If you wish to ‘pass data from userdata’ I would recommend some sort of table conversion. Everything should be able to get send over unless it is an Instance does not exist for that machine.
It makes literally no sense though, you should definitely not be listening to local events on the server side due to how many requests it would spam or even needing to do stuff like ‘get localplayer’ when you can just get the player themselves…
A remote function would not be needed and would also be unnecessary (remote events at the least). And again unless heavy pre-fire throttling was used, it would very easily cause the system to go down. Either way the usage case examples made no sense. And the server should not really be listening for anything client does, usually the client triggers things instead (such as buying objects, or whatever) and in some cases things like mouse or client-controlled data (i.e. engine pitch) might be listened to for replication purposes but nothing else.
I suppose I could use remote events instead of remote functions in some cases, but I never said
efficiency is the ultimate goal here.
The ultimate goal is to create something that could let you write everything in a single script.
Also, I tend to disagree when it comes to listening.
Having the majority of functionality on the server side makes things less exploitable.
Thus, it would be better if the server simply asks for specific things from the client.
Anyhow, thank you for your input but I am not looking for an argument.
I am looking for an answer.
When you fire a RemoteEvent with an instance, it isn’t actually sent over the network. What’s sent is a unique identifier assigned to the instance, which the server will replace with the actual object when it’s recieved. Seeing as InputObject doesn’t and will never exist on the server, the identifier that it gets will be invalid and therefore will be discarded. A solution would be to manually serialize the object:
local function Serialize(inputObject)
return {
Position = inputObject.Position,
Delta = inputObject.Delta,
KeyCode = inputObject.KeyCode,
UserInputState = inputObject.UserInputState,
UserInputType = inputObject.UserInputType
}
end
But this is generally indicative of bad practice, as sending the entire InputObject serialized is unnecessary if you just need it to do a specific action that can be (mostly) processed on the client.
The reason you can send types like CFrame, Vector2, etc. is because they have their own types and are properly serialized into something that can actually be sent over the network.
