No one said it’s a LocalScript, just stating the fact that from the information provided to me the script that is firing is located inside the Character. Yea it won’t be sending this information to the server (if fired from the client) but anyway based on the information provided the script is infact inside the Character.
You do realize that @TaresuDesu is attempting to change the experience value of a player within the game right? If that is the case, in order to know when this change should be made to the experience value, the client needs to send remote notifying of the action done that could potentially result changing the experience value. Ex: Client: Kills a player in game and sends data to server notifying of the kill made and to verify it’s authenticity (exploit check), Server: Checks if the information is accurate and now the server is able to give experience to the player. In this case you can see the usecase of a player notifying the server in order to gain experience points. The whole “A remote is unnecessary here” is false as the client does need to initate the process in which they are rewarded experience points and you also said “Good way to get exploited” this is only the case if you aren’t verifying the reason on why you are rewarding this player. However, the method that @TaresuDesu is using to update the experience value isn’t good but also I would like to know why you wanted to call my arguments “moot”.
I’m referring to and assuming based on the fact that you replied “Umm no?” to the following statement:
Which is not untrue at all. There was no reason to disagree with him because what he said is completely valid.
What does this have to do with anything though? This is an implementation choice that doesn’t impact the code’s functionality. It’s still moot to mention. A script firing from the character doesn’t mean anything here.
Only if a client action that warrants a gain in EXP. That’s not the case here. This doesn’t invalidate what I said. A remote isn’t necessary in this scenario. Death checking from the server is fine, which is what OP is doing. The error falls in the lack of sent arguments when the BindableEvent is fired.
If you have the client checking for a kill, your networking model is improper. The client has no business checking this information. Only the server should be checking and confirming kills. In an elaborate client model, sure the client can check hit detections and the server can validate but the client still doesn’t check for deaths and tell the server.
It’s not false. The client does not and should not be authoritative of a kill declaration.
I only called some of them moot, the rest I’m saying are false or unsubstantiated. The moot arguments are pointless to bring up here, hence moot. For example, your disagreement with @tlr22’s response is moot. Not only does it not properly disagree, but it branches to a different point which doesn’t matter.
Based on the script provided (the one inside the character) I would be assuming that TaresuDasu wanted to update the experience from the client (for whatever reason). Based on that, it is appropriate to use a Remote as that is the only way of communicating to the client to server or vice versa.
Misunderstanding on this one. As I did mean to say that the client would be firing to the server notifying that the action has been made to kill a player and for the server to verify this action and to actually kill the player. In any case, the client cannot replicate to other without the consent of the server so this is fine.
It is false. Again , the client would need to do an action to initate the cause for this reward in experience. In the layout that TaresuDasu was using, it didn’t seem like the experience value was being used as a reward system but in any game model, the client would have to do action(s) in order for the reward to happen.
This is going around in circles. This is why I mentioned a LocalScript. This paragraph assumes that the OP is using a LocalScript to attempt to communicate with the server. Yet again, it’s moot to mention. I’ve already explained this, read my replies please.
This is unrelated to the issue that the OP is having.
A LocalScript firing a BindableEvent being listened to by the server will not throw an error.
The script is in the character, or maybe it isn’t, but it references the Humanoid. Okay. The BindableEvent fires and the EXP updating script receives the event clearly because it tries to fetch the arguments in the called listening function, which are nil and thus throwing an error.
I don’t know why this is still being brought up as a point, it’s been addressed long time ago. The location of the script nor the type do not matter in this circumstance. They’re moot to bring up. Focus on the actual issue that OP is experiencing.
Misunderstanding how and where? Read my post again. Why does the client have any business alerting the server that a kill action was performed? It doesn’t. Clients being authoritative of a kill declaration is nonsense. Its request should only be as far as requesting permission from the server to do something. The server validates the action and performs it. In the case of damage, it also checks what to do should the humanoid die.
Regardless of all of this, a remote is still unnecessary to include here. The sending script fires the BindableEvent when the humanoid dies and the receiving script attempts to perform an action based on the arguments that are sent. Where does a remote fit in this structure?
Unless OP’s structure is fundamentally flawed and needs rework up to how they’re handling requests from the client to perform actions, remotes don’t fit in the picture here. The humanoid dies; a server script informs another one by way of a BindableEvent that a death happened. Read my post, again. Standard kill-check code has assailants logged server-side and based on who attacked the victim before/at their death, stats are awarded accordingly.
Read my post, AGAIN.
If the client is initiating an action, such as swinging a melee tool, they have the grounds to inform the server that they performed a melee. Sure, a remote is necessary there. That’s not what I’m talking about though. The client should ONLY be informing the server that they performed said action. Making the client authoritative of a kill declaration too is absurd and a poor networking model.
The client can initiate actions but that doesn’t imply that it should be authoritative over aftermath conditions too. The experience reward is monitored by the server listening to a BindableEvent, which receives the fire from the server script watching if the humanoid died. The script hooked to the Humanoid death event should also be logging who attacked the user and sending it over accordingly for rewards. NOT. THE. CLIENT.
This is completely unrelated to the overall point I’m making and I’m concerned that you’re cherry picking parts of my post to make a point or disagreeing for the sake of disagreeing. Please stop.
No game model lets the client determine “I killed the user, give me my reward”. Game models involve informing the server that they performed an action and request for the action’s validity. The server checks and if it’s valid, passes the action and handles any actions on its end. If the action meets a condition (such as killing the humanoid), then it lets related services know that happened and that a reward should be given for such.
The location does matter, the problem could be that TaresuDasu may have a mixed understanding of how bindable work in Roblox. This is a logical conclusion to come across since when asked to provide the script that is in charge of firing to the bindable, TaresuDasu chose to show the script located inside the character that seems to be doing what was asked of him to provide. This goes on to make me believe that he may not have a clear understanding of FE and the boundaries client and server.
The client should in any case inform the server that they have done actions that require the server to perform a kill reaction as that is what causes the server to replicate this action (after verification)
You have said it here, the client should be initiating what could result in a kill action by the server. Please read over your replies before blindly responding.
This is not what I said, please read my replies thoroughly. I mentioned that the client initiates the process in which the server could potentially decide if that action is worth rewarding during verification and replication
AGAIN Please read through what I have said. I stated that the client initiates the process in that could potentially result in a reward for the client, I said nothing about the client being authoritative over aftermath conditions.
This infact seems to be what you’re doing as you seem to be arguing points I have already made for some reason.
You can put server scripts in the character and have them run on the server. Also it might not be in a players character, but NPCs around the map.
You are assuming far too much about what is happening here, and when pointed to why your assumptions are incorrect you keep assuming more to try and make them correct. Because the event is in Server Storage the client can’t see it at all. This means the script is running on the server.
As a side note, you appear to keep taking only a portion of @colbert2677’s arguments which leads me to believe you are not reading all of what he says because he covers all the points you bring up.
Okay, my mistake. I will try to fix this for the future, I really shouldn’t be diving too much into topics that I don’t have clear and accurate information or understanding on.
So what are you trying to say here? I really don’t understand what you’re getting at by constantly bringing this point up or ignoring what I’m saying about this.
…? What? How is ANY of this relevant? It’s a server script in the character. OP is not misunderstanding how bindables work. Nothing about the setup is wrong and the only issue that was originally brought up was that the BindableEvent was receiving nil arguments. This is not a logical conclusion. I can’t understand what standpoint you’re approaching this situation from.
You’re confusing bindables and remotes. FilteringEnabled is irrelevant to mention here, as is the client-server boundary. Scripts in the character aren’t implicitly treated as local. Everything here is server-sided. Please do some research before replying. You don’t know what you’re talking about.
No it should not. I’m not going to repeat myself again if you aren’t going to read and understand my perspective or point or tune it out. The client should not be holding authority of kill declarations. Period.
If they perform a damage or kill action, the only thing the client should be doing is informing the server they performed an action and request for the server to handle its end. The server is the one that validates the request and handles what it needs to on its end (damaging the players, killing them and/or granting rewards to a player).
Appreciate the ad hominem attack.
My point is not the same as what your posts are asserting. Client-based hit detection and client declarations of a kill are two different topics altogether. This is a blatant cherry-picking of my post: read it again and with the whole context in mind.
The statement alludes to an “elaborate client model”, relating to performance and having the client perform hit detections with server validation on the side. It says nothing about the client being authoritative about anything, which is what I’m arguing against.
That is not what you said. Scroll up and read your own replies. You’ve said it countless times that the client should be notifying the server that it killed someone and should grant a reward accordingly, to which the server checks. No. That is a flawed and terrible networking model. The client should only hold responsibility for notifying the server that it performed an action at all. Full stop. Client involvement ends there.
Half these points are irrelevant to the thread, some of which are unsubstantiated? Half of what you said is meaningless. This thread is about the fact that the sender script isn’t sending arguments and the receiving script is assuming non-nil values on its end. This is the third time I’m saying it. I’m not going to say it a fourth.
It’s a clear demonstration of what I mean by cherry-picking my posts to disagree for the sake of disagreeing.