|
Well, there's a problem. Everything I script only works in studio and not in-game. I bet ROBLOX broke their client again, studio works fine but lag more than the client. Always breaking my scripts... Any suggestions why?
|
|
|
It's not ROBLOX's fault. You just need to learn about what you should be handling on the client or server.
|
|
LaeMVPJoin Date: 2013-06-24
Post Count: 4416 |
Are you trying to do client things server side? (like doing game.Players.LocalPlayer in a serverscript) |
|
|
It is them indeed. Studio works fine.
|
|
LaeMVPJoin Date: 2013-06-24
Post Count: 4416 |
Studio works fine because it runs everything on the client, it is your script(s) that is the problem. |
|
|
No, it's just regular scripts that should make a button visible when you click a GUI and close it if you click it again.
|
|
|
Studio works fine because the client and server are both running on the same machine, which is your computer. You can simulate an actual server in studio but it still won't function the same as an online server.
It's your fault.
|
|
|
"regular scripts"
"GUI"
There's your problem.
|
|
LaeMVPJoin Date: 2013-06-24
Post Count: 4416 |
"No, it's just regular scripts that should make a button visible when you click a GUI and close it if you click it again." So the problem was you, that should be handled locally(a local script) |
|
|
function Click()
if script.Parent.Parent.BuyVip.Visible == false then
script.Parent.Parent.BuyVip.Visible = true
elseif script.Parent.Parent.BuyVip.Visible == true then
script.Parent.Parent.BuyVip.Visible = false
end
end
script.Parent.MouseButton1Click:connect(Click)
--nothing wrong here. It's just their problems.
|
|
|
Nevermind, just saw that FE was enabled. Works fine now. Apparently it enables itself when it wants to.
|
|
|
Simplified:
local buyVIP = script.Parent.Parent:WaitForChild("BuyVIP")
script.Parent.MouseButton1Click:Connect(function()
buyVIP.Visible = not buyVIP.Visible
end)
Anyway, it should be in a LocalScript.
|
|
|
I don't need localscripts when it works fine now. FE was the problem.
|
|
|
Nothing can be your fault, can it? Stop being stubborn.
GUIs should always be handled locally because they're displayed locally. In reality the server can't even see a client's GUIs, and that explains the issue with FilteringEnabled. Even though the server script was inside the GUI, the server can't see it because the GUI was created locally by the client. The server can only see client GUIs that were created by the server, but local changes still don't replicate with FilteringEnabled.
In short: be conventional and start handling things correctly. Run the code in a LocalScript.
|
|
|
It is local anyways so it doesn't matter how you script it. I use scripts because I'm not using localscripts much because there's another way to script. Mostly why. Localscripts is only required is you're using FE.
|
|
|
|
Already done & works fine.
|
|
LaeMVPJoin Date: 2013-06-24
Post Count: 4416 |
Why would you not script a gui with a local script? It makes the guis so much easier to configure and more compatible with FE. There is no valid reason to not use a local script for a gui. |
|
|
Aha, I remember. This was the nonconformist who thought he was always right. He argued with everyone in a thread, saying that we were all wrong and deceived.
I definitely see a pattern here.
"Localscripts is only required is you're using FE."
|
|
|
'He'. I never said I was right. I don't even need you here.
|
|