Scripting questions

Help and Feedback Scripting Support
#1

I’ve seen some topics talk about certain things yet I have a few doubts and I dont think I’m allowed to “bump” those topics to ask since they’re extremely old.

There will have a lot of questions I’ll bring up and I’d be happy if they were answered in one go instead of post an answer to every question separately.

It seems like exploiters can access and modify the contents in module scripts so is it a bad idea to keep them in the ReplicatedStorage? In the gameplay scripting tutorial on the documentation, the laser tag place has many modules there so I’m trying to figure out if it’s or not a good idea. Does it change only to the client? I’ve put a module script that contains the informations of certains items from the shop in the serverstorage and sent those informations to the client after they joined so they can see when they hover their mouse over the item but I’m not sure if that’s the best way or if I can simply put it on the ReplicatedStorage and let the client access to access the information directly and let the server validate the purchase by checking the same module script.

Server script with RunContext to client. It seems like it works the exact same as localscripts but anywhere and you don’t need to place it on every player for something, like open a GUI after opening the shop. It helps maintain a better organization. So my first question for this one is: When should I use RunContext client and localscript? Should RunContext be used more for things like I said earlier? Since everyone can and will access the shop I can put a single RunContext client script somewhere in said shop (inside the model or a folder in there) instead of every client having a LocalScript for it, right? What about localscript? Should it be more for things where players will have something different than the others? An example being (sorry if this example is wrong. I’m still a beginner and I dont know if that’s how it goes) two players on a competitive game. They have both their own inventory so they need a localscript in the playerscript to access their inventories and use their items, right? Also, that localscript must be in playerscript instead of characterscript so the localscript don’t “reset”? According to the documentation, scripts in the characterscript doesn’t persist when they respawn so that means they “reset”, right? My second question is: Do any of them have a certain advantage against the other or are they equally “good”?

Next question is regarding the phrase: “Never trust the client”. After scripting for a while I think I know what that means but I’m still not sure. Does that mean I always have to make the client ask for permission to the server for anything? Be it sprinting, activating one of their abilities and also collecting points?

While we’re talking about asking for permission, the other question is about remote event and functions. No, not about how they work and all that since I managed to understand. Will having a remote for everything in the game affect the game’s performance? When I say remote for everything I mean things like the 3 examples I gave earlier. I’m asking that because there can be, for example, 15+ players constantly firing those remotes. If it does, what’s the best path to take to avoid that?

I know a bit how the RunService works but what can it be used for? Everytime I search about it on the forum people kept explaining what it does but not what it can be used for. This is the only service so far that I’m rather puzzled about where and when to use it

I’m still a beginner but I’ve made quite the progress. Managed to understand the basics and also managed to do a few things on my own despite scripting only once in a while. My codes are very basic still and I’ve been thinking about stopping to script to focus more on modeling and animating. Is it a bad idea? College is making me not able to spend so much time on scripting and modeling/animating at the same time so I’m planning to get to learn those more (even though I barely started). Of course, I’ll still return after I’m satisfied with my progress but will it impact my scripting level? I mean, coding is like riding a bicycle, right? Once you learn it’s hard forget.

Those are all the questions I have for now. Thought it was better to make a single topic with all my (current) questions rather than splitting them all up. Thanks in advance

#2

It will replicate to client in replicated storage.

But only the byte code. If you look at synapse decompiler documentation the script will be really messy with variables such as v1 v2 v3.

Therefore it doesnt really matter, if an exploiter is smart enough to understand and reverse engineer a messy script with v1 v2 v3 terms they might as well script their own game.

So no worries about stealing scripts unless its for something generic like camera bob.

Perhaps a concern if you have secret text and want to avoid leaks in hour game such as secret dialogue or something.

More of a tool to find what values are being sent to remotes to spoof.

Purely organizational, can you locate the script? Will you need to find and change it more easily in the future? If yes then do whatever.

What happens if you mess up? Just take your time and change it and restructure your game.

Requires a more in depth post. I can link these two resources I find good. Sometimes sacrifices have to be made such as sprinting in order for it to be smooth on the client. Also check out chicknoid if you want serversided movement but with some fake client effects to make it smooth.

Use it for code that runs every frame, functions the same as a while loop with task.wait(). Some times the order matters example a weapon viewmodel needs renderstep to make the parts follow the camera smoothly. Sometimes when modifying physics heartbeat and stepped matters due to this order as well.

1 Like
#3

Why do these kinds of posts still get made?

Important stuff goes on the server. Untrusted stuff goes on the client. It doesn’t matter where specifically you store things, like in ReplicatedStorage or elsewhere; it just matters if it’s on the server or client. That’s it.

#4

Here’s an easy example: you have a damage function. It… damages a player. Would you rather have the client able to call this whenever it wants? Or, have the client make a request to the server which will then verify if damage should be done first?
Edit: I suppose that’s really not a good example since damage typically is ever only done from the server. I guess a better example would be a playing doing an attack, using an ability, sprinting. You could leave those functions, those checks on the client, but then the client could edit this, change it around, call functions repeatedly, etc.

1 Like
#5

Not entirely sure but check this out [Live] Script RunContext

Only things that are important and give them an advantage in the game. They don’t need permission to click a button that opens a menu

Shouldn’t do. Although your game shouldn’t be structured to where clients are all firing remotes in really quick successions or that will effect performance

" RunService contains methods and events for time-management as well as for managing the context in which a game or script is running. Methods like IsClient, IsServer, IsStudio, can help you determine under what context code is running. These methods are useful for ModuleScripts that may be required by both client and server scripts. Furthermore, IsStudio can be used to add special behaviors for in-studio testing.

RunService also houses events that allow your code to adhere to Roblox’s frame-by-frame loop, such as PreAnimation, PreSimulation, Heartbeat and PreRender. Selecting the proper event to use for any case is important, so you should read Task Scheduler to make an informed decision."

ie. FPS games use run service to constantly adjust the position of the player’s gun so it stays infront of their camera

Kinda. Not difficult to get back up to speed after taking time off

1 Like
#6

There’s really not anything you can do to prevent it, and that’s fine. If someone tried to “DDoS” your game by spamming remotes, they’d get throttled by their own internet connection(s) and it wouldn’t really amount to anything. When you think of DDoS attacks, hundreds and maybe thousands of bots are used to flood a server with requests simultaneously. And given the efficiency at which Roblox handles remotes, it’s not really possible to DDoS a server that way.

I agree. I’ve taken year long breaks before. I feel like the term “If you don’t use it, you lose it” applies. As in, you’ll still be losing it so long as you aren’t actively practicing or doing anything with it. But when you try getting back into it, you can pick everything up again pretty quickly.

I agree with what’s already been said by others, but I’d like to rephrase in my own words anyway.
A rule of thumb you should follow is to assume that, when creating a component on the client, that someone will find a way to exploit it. For example, if you have a client-sided system for running and stamina consumption, assume someone will exploit it in a way they can have infinite stamina. In a more casual game? That’s fine, I wouldn’t care. I wouldn’t say it would be worth giving up the responsiveness of a client-sided system to prevent exploits. But if your game is more competitive and infinite stamina can give the player an unfair advantage, then I’d just migrate the system to the server and have it and the client communicate via remotes. Here’s a bad example:

-- localscript

shift key pressed:Connect(function()
  RemoteEvent:FireServer("hey can I sprint?")
end)

RemoteEvent.OnClientEvent:Connect(function(message)
  if message == "no you can't sprint" then
    -- be sad :(
  elseif message == "yes you can sprint" then
    --increase walkspeed and decrease stamina
  end
end)

-- server script

RemoteEvent.OnServerEvent:Connect(function(Player, message)
  if message == "hey can i sprint?" then
    if Player.Stamina > 0 then
      RemoteEvent:FireClient(Player, "yes you can sprint")
    else
      RemoteEvent:FireClient(Player, "no you can't sprint")
    end
  end
end)

Again, very bad example, but it’s the quickest way I could demonstrate the general rule to follow. Assume that a client can and will abuse your remotes. So if that could happen in a way that can cause problems, then make sure to validate that what they want to do makes sense.

2 Likes
#7

Thanks you all for answering my questions. I’m marking thecoolest’s post as solution for answering the most but every other post helped me aswell. Thanks for you time

#8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.