New: Nitro Boost our Discord server and receive full donation perks here on the website! Join the Scripting Helpers Discord Server to learn more! You can also Support on Patreon as always.
Still have questions? Join our Discord server and get real time help.
-1

Can someone help me fix Devil Beater? I'm not 100% sure how this FE stuff works. [closed]

Cyrexal -12
1 year ago

(before I talk about my issue I'm not trying to hiring someone I'm simply trying to figure out how I can repair this, but I'm fairly new to this kind of stuff so I'm not really sure how to do it, but I'm trying)

Alright so one of my favorite games was broken by Roblox (from my understanding) and the creator decided to make it open source instead of fixing it and this made me really say because like I said it was one of my favorite games on Roblox. Now I understand that asking asking people to do something for me is against the rules, but I would really love to find out what the cause is and how I can fix it, and it would be helpful if I could get someone else to do it for me, but if not I won't mind learning how to do it my self because I would do anything to have this game repaired.

So with that being said from my understanding I think the issue with the game is with FE and the only thing that seems not to work are the GUIs everything else works so I put the only 2 scripts (that are in the GUI) into pastebin and maybe someone could take a look at them and see if something is wrong if there is could you give me some info on what I can do to fix it? I know that I might need to use remotefunctions and remoteevents, but I've never worked with those and I'm not sure how to set them up.

here is the local script for the character selector: https://pastebin.com/AuA6tZ6a there is also another local script called Tengen for the StoryUI: https://pastebin.com/ndimC82E (I'm pretty sure these are the only things that don't work because everything else seems to run fine it's just the GUIs that seem to be broken.) I've tried learning how to use remote events and remote functions, but it didn't seem to work

Locked by User#24403

This question has been locked to preserve its current state and prevent spam and unwanted comments and answers.

1
Fifkee 1088
1 year ago
Edited 9 months ago

I honestly love seeing people like you, the type of people that want to actively learn about coding if they can. I'll give you a basic rundown on things and so how they can look.

Dictionary

Server: Security Guard, the good guy.

Bindables: BindableFunctions and BindableEvents. These two prohibit interaction between two different script types (LocalScript and ServerScript.) This is what you should use when you want two clients, or two server scripts to communcicate between each other.

Remotes: RemoteFunctions and RemoteEvents. These two allow interaction between two different script types (LocalScript and ServerScript.) You should use these when you want to allow cross-interaction between the two.

*Functions: BindableFunctions and RemoteFunctions.

*Events: BindableEvents and RemoteEvents.

Differences

Bindables can relate to the BindableFunctions and BindableEvents. These two prohibit interaction between two different script types (LocalScript and ServerScript.) This is what you should use when you want two clients, or two server scripts to communcicate between each other.

Remotes relate to the RemoteFunctions and RemoteEvents. These two allow interaction between two different script types (LocalScript and ServerScript.) You should use these when you want to allow cross-interaction between the two.

The *Functions and the *Events are somewhat similar. The *Functions tend to yield the script in wait for a response from the code block that handles the invoking. So, you should use these when you want the handler to return something that the caller can use later. I've ran into many problems using *Functions instead of *Events even though I did not need to return an end value that I can use for later. It took me a while to finally understand the difference between the two. If you want to activate these functions, you should use :Invoke() for bindables, and :Invoke*() for client-server (and vice versa) interaction.

The *Events tend to not yield the thread that the caller has fired the event in. You should use these when you want the server to have your information, and not give something back in return. This is especially useful for when you want the server to handle attacks and you don't need a damage indicator, or anything around those lines, for that matter. Instead of using Invoke*() for functions, you use FireServer for when the Client wants to give the server information, or FireClient for when the Server wants to give the Client information. If you are using a Bindable, you should use Fire(). It would be redundant to include the Server or Client, because you wouldn't need those, due to the fact that bindables do not allow cross-interaction.

Good practice.

Assume that everything the Client does is bad. You've probably heard the saying about assuming that I'm not allowed to say here, and that your parents have probably said before. But, this is where it really applies. I've seen many games that trusted the Client, and ended up going down in shambles. Now. Lets say we had a RemoteEvent that gave you money, and you checked the money on the client.

Now, you'd probably think: Wow, isn't it obvious? If you check on the client, there should be no problem!

But, that's the wrong way to think. Although the Client will not replicate objects to other Clients without assistance from the Server, you can change your money without the server acknowledging it. So, if someone were to open up Synapse, or some other very popular/cracked exploting application, they would be able to change the Money value, stored somewhere in Leaderstats or something around those lines, and only the Client changing the value using external applications would be able to see it, but the Server wont.

So then, in LocalScripts, you could have this code running somewhere:

--In a localscript, of course, as it was stated prior.
if (Money.Value >= objects[selectedObject]['price']) then
selectedObject = {objects[selectedObject]['price'], objects[selectedObject]}
end
--not sure if this is right at all, but if it isn't, i'll write it in a way that machines probably won't understand.

--[[
if MONEY is greater than or equal to SELECTED_OBJECT's PRICE >>
<<
--]]


This looks completely viable as a way to keep money secure. But, the LocalScript only looks at what the Client can see. So, if the Client sees $7,000,000 in their bank account, but the Server sees$2 (relatable.mp4) in the Client's bank account, the LocalScript will assume that $7,000,000 is in the bank account. And, since$7,000,000 is greater than the assumed price of the selected object, the LocalScript will fire the event even though the Server sees it as false.

So, people would think that if it was already checked in the client, the server does not need to check.

In most circumstances, this is completely wrong.

(I say "most" because some scripting god will probably pull up and give me a reason on why sometimes this is correct.)

Then, people would have this in the serverscript.

game:GetService('ReplicatedStorage').Events.Buy.OnServerEvent:Connect(function(Player, Table)

--Since I provided a table, the first index in the table would be the price, and the second would be the object.
Player.Money.Value = Player.Money.Value-Table[1];

if (Player.Inventory.Value:match(Table[2].Name) then
--add it to inventory and stuff, im too lazy to code this part :P
end
end)


Take note that using *Events, we connect to the Event's signal. In Functions, you assign the On*Invoke to a function, like so:

Function.OnServerInvoke = function()
end

Function.OnClientInvoke = function()
end

--Something along those lines. Ask questions later.


See how in the first serverscript, we have nothing checking? This means that the server is trusting the Client on what it says, and goes with it. It's like pretty girls and gossip.

This can cause a multitude of problems. The exploiter will have negative money (or a huge loss in money), and the game's economy is broken. Congratulations.

Solving the issue

Now, to prevent all this from happening, you can do one of the two ideas I provided, because there's plenty more.

A) Check on the client AND server.

B) Just check on the server. Because why would you give yourself extra work?

game:GetService('ReplicatedStorage').Events.Buy.OnServerEvent:Connect(function(Player, Table)

--Since I provided a table, the first index in the table would be the price, and the second would be the object.
if not (Player.Money >= Table[2] ) then --This time, we check if the player has the amount of money on the CLIENT and the SERVER.
return nil; --This cancels the function prematurely if the condition is true.
--I prefer not to kick them, because what if one end is lagging, or I made an error?
--The client could've had a hiccup, or the server, too.
end

Player.Money.Value = Player.Money.Value-Table[1];

if (Player.Inventory.Value:match(Table[2].Name) then
--add it to inventory and stuff, im too lazy to code this part :P
end
end)



Now, the server will be independent and not rely on the client to give it information. Ultimately, the client no longer has the power to buy something that they truly cannot afford.

Any questions? First, read up on these articles.

https://www.robloxdev.com/articles/Converting-From-Experimental-Mode

https://scriptinghelpers.org/guides/how-to-use-remoteevents-properly

https://www.robloxdev.com/api-reference/class/RemoteEvent

https://www.robloxdev.com/api-reference/class/RemoteFunction

https://www.robloxdev.com/api-reference/class/BindableEvent

None of those helped? You may now ask a question below.

If I made a mistake, or accidentally provided misinformation, please let me know, and I will attempt to fix it when the comment has gained my attention

1
" So, if the Client sees $7,000,000 in their bank account, but the Server sees$2 (relatable.mp4)" lol. But you shouldn't have the server do *every single check* in the game. For example user input. No need for the server to check that using remotes. Have the client do it. The server cannot and should not handle user input. User#19524 127 — 1y
0
Well, yeah. It kinda says it right there. "User input," directly looking for: "User." User typically means that only the client needs to recognize it, right? Or maybe I'm not considering the newbies? Don't get me wrong, you actually have me thinking now. Fifkee 1088 — 1y
0
yeah you're right user interface etc User#19524 127 — 1y