I’ve never encountered this problem before where I pass arguments through a RemoteEvent and the server can read the arguments fine but what should always be the first argument the Player is nil.
Odds are I just made some mistake while I was really tired writing this script.
Does it work if you exclude the player argument from the vararg?
OnServerEvent:Connect(function(player,...)
It’s always the first argument anyway.
Yeah, if you know what the first two arguments are gonna be then you might as well define them and save both your sanity and runtime in one go.
function(Player, Command, ...)
There shouldn’t be any issues, either way, though.
Maybe try waiting a bit before you fire the RemoteEvent? Recently I’ve noticed LocalPlayer has been nil when the game first loads – most likely because of this.
I found out after a little bit more of testing that when I parent the events to nil to make it more difficult for exploiters to get to them that causes the server to be unable to read the Player argument. I’m not exactly sure if this is a bug or has a purpose.
I found out after a little bit more of testing that when I parent the events to nil to make it more difficult for exploiters to get to them that causes the server to be unable to read the Player argument. I’m not exactly sure if this is a bug or has a purpose.
What I will likely be doing is having the client also provide the Player in the arguments list to fix this problem.
Don’t think parenting events to nil is really necessary. If your server side code handling events has solid sanity checks and never trusts the client, then it should be ok.
Sounds like a bug to me – nice catch.
Make a bug report if nobody else debunks that assumption 
Do not do this. This is an incredibly bad idea. If you let the client provide which player they are, this opens up a whole lot of bad possibilities for exploiters in your game, depending on what your game is. By allowing the client to provide which player they are, players can perform actions for other players.
Imagine a game with a trading system allowing exploiters to send trades for other players to themselves, just because the client has the power to tell the server which player they are. Not only would this upset the other player being stolen from, but that player could potentially have spent hundreds or even thousands of robux on your game that they’ve now wasted because the game’s system wasn’t properly secured.
As @Mighty_Loopy said, the solution is to make sure what a player does is actually possible. Staying on the example of a trading system, a simple way to secure the trade is to make sure that the items the player is sending are actually items they have.
All hiding your remote events/functions does is keeps a fair portion of exploiters from firing them. However, this is essentially pointless, since if this is your only line of defense from exploiters there are people who will get by this, and then you’ll need to start doing sanity checks anyway.
To add on top of this, Exploiters are able to access objects inside of “nil”
As long as any script has any refrence to it (even if it doesnt have a refrence) the exploiters can find it as it is kept in memory and they have full control over it.
Yeah I didn’t think about that portion. I do have sanity checks implemented and I’m thinking of also making a key system. I think I’ll just wait for Roblox to fix this issue.
I really still don’t recommend hiding remotes. It’s essentially pointless and just messy to do.
I also encountered this issue today on my games… The first argument can be on occasion nil…