VoidFrost
|
  |
| Joined: 14 Oct 2011 |
| Total Posts: 1188 |
|
| |
|
|
| 22 Jan 2017 05:12 PM |
| rewrite the things making it laggy |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 22 Jan 2017 05:13 PM |
Because clicking the little box that says "FilteringEnabled" does not convert your game. You have to optimize it.
If you haven't the slightest clue as to why your game is lagging, the answer lies within the free models.
|
|
|
| Report Abuse |
|
|
VoidFrost
|
  |
| Joined: 14 Oct 2011 |
| Total Posts: 1188 |
|
|
| 22 Jan 2017 05:15 PM |
"Because clicking the little box that says "FilteringEnabled" does not convert your game. You have to optimize it."
Did you read the title? I said everything is slow and laggy, if I clicked that button only much would stop working for others, not be slow and laggy. Also, my game does not use free models. |
|
|
| Report Abuse |
|
|
|
| 22 Jan 2017 05:19 PM |
| You'll have to make it efficient. |
|
|
| Report Abuse |
|
|
VoidFrost
|
  |
| Joined: 14 Oct 2011 |
| Total Posts: 1188 |
|
|
| 22 Jan 2017 05:23 PM |
Everything is done on remote function.
I do everything in a local script and set things in a server script of course, I use InvokeServer. Call everything in localscript. I have it like this
--serverscript function Function.OnServerInvoke(Player, requestTag, args) if type(requestTag) == "string" and type(args) == "table" then print("Hello") if requestTag == "message" then print(args[1]) end end end
--localscript Remote:InvokeServer("message", {"THISWILLPRINT"})
Everything FE-related is done like that. |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 22 Jan 2017 05:30 PM |
Of course I read the title. Did you read my post?
Your game is laggy because clicking the box doesn't convert anything to work in FE. It just turns FE on.
YOU have to make the code work in FE. If you are experiencing lag then it's your fault. Explore your scripts.
|
|
|
| Report Abuse |
|
|
Dorandir
|
  |
| Joined: 06 Aug 2016 |
| Total Posts: 844 |
|
|
| 22 Jan 2017 05:31 PM |
@Soy
He is saying his code does work with FE But since he converted it to FE its not laggy. |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 22 Jan 2017 05:33 PM |
For the love of christ
"Converted my game to FE, everything is slow and laggy." "switched to FE" "slow and laggy"
You did a bad job so post the problematic code, don't just ask such a variable question with no code for context, lol
|
|
|
| Report Abuse |
|
|
|
| 22 Jan 2017 05:33 PM |
| remote events are slow. find a better way. |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 22 Jan 2017 05:34 PM |
They're not slow, what are you talking about?
The ONLY real way to have secure conversation between scripts on the Client and Server in an FE environment is through the appropriate usage of RemoteEvents and RemoteFunctions
|
|
|
| Report Abuse |
|
|
|
| 22 Jan 2017 05:45 PM |
| Try using more unions and RemoteFunctions |
|
|
| Report Abuse |
|
|
|
| 22 Jan 2017 05:48 PM |
"Everything is done on remote function." That's your problem. Whenever you're wanting to do something on the client, you are telling the server to do it instead, through a remote function. The request is not instantaneous which means there will be latency between requesting the action and the server receiving the request.
Everything should be balanced between the server and client, you shouldn't be doing everything on the server. Input, GUIs, animations and physics, for example, should always be handled on the client. This is the challenge of FE; balancing everything properly and making sure the game runs smoothly.
If you are doing everything on the server and the client is constantly sending requests and not doing anything itself then of course your game is going to be extremely laggy. |
|
|
| Report Abuse |
|
|
| |
|
Tunicus
|
  |
| Joined: 16 Feb 2013 |
| Total Posts: 3165 |
|
|
| 22 Jan 2017 05:59 PM |
the real problem lies in that OP isn't returning in his OnServerInvoke function. Much like functions have the ability to return a value, RemoteFunctions are intended for returning a value. An example of this is a client that contacts the server to purchase an item. The server may return a bool which specifies whether the purchase was successful or not. The script that fired the other will yield until a result is given or timeout. If you do not want to send something back, use a RemoteEvent, as it's more efficient and will not hang the current thread.
Quick fix: --serverscript function Function.OnServerInvoke(Player, requestTag, args) if type(requestTag) == "string" and type(args) == "table" then print("Hello") if requestTag == "message" then print(args[1]) end end
return -- This function needs to return, otherwise it'll hang the local script! end
--localscript local result = Remote:InvokeServer("message", {"THISWILLPRINT"}) -- This will yield until the server function returns
|
|
|
| Report Abuse |
|
|
VoidFrost
|
  |
| Joined: 14 Oct 2011 |
| Total Posts: 1188 |
|
|
| 22 Jan 2017 06:31 PM |
Soybeen you are so useless, thanks for attempting to derail this thread. If anyone is confused, this is the situation I started with:
Everything converted to FE-> this means I rescripted everything aswell, but since some people (not all) are edgy and unhelpful they just claim I only pressed the FE button.
As for my RemoteFunction thing, yes I do realize if it is not returning anything, I should use RemoteEvent, I just used Function because it seemed easiest as it works whether it returns something or not, however if I am going to go through converting all this once again, I must be certain on the problem.
Are we sure this happens because I use RemoteFunction at times when I should use Event? |
|
|
| Report Abuse |
|
|
|
| 22 Jan 2017 06:33 PM |
| They're both easy. If you script with events a lot (Which you should...) then RemoteEvents are literally just an instance where you get events from. |
|
|
| Report Abuse |
|
|
VoidFrost
|
  |
| Joined: 14 Oct 2011 |
| Total Posts: 1188 |
|
| |
|
VoidFrost
|
  |
| Joined: 14 Oct 2011 |
| Total Posts: 1188 |
|
|
| 22 Jan 2017 07:16 PM |
| Bump, I want to get to the source of this latency. |
|
|
| Report Abuse |
|
|
Casualist
|
  |
| Joined: 26 Jun 2014 |
| Total Posts: 4443 |
|
|
| 22 Jan 2017 07:19 PM |
Let's say you used to make parts with local scripts. If you made a part, it'd show up instantly for you.
Let's say you have a latency of 300ms. Now, with FE, to make a part you must send an instruction to the server which makes the part and it gets replicated back to you. A ping of 300ms is one way. So not it takes .6 seconds to make a part you used to make instantly. Your source of latency is *drum roll* latency. |
|
|
| Report Abuse |
|
|
|
| 22 Jan 2017 07:21 PM |
| If you dont need anything returned use a Remote Event |
|
|
| Report Abuse |
|
|
|
| 22 Jan 2017 07:22 PM |
use RemoteFunction sparingly, only if you need a return value back use RemoteEvent for everything else |
|
|
| Report Abuse |
|
|
Dorandir
|
  |
| Joined: 06 Aug 2016 |
| Total Posts: 844 |
|
|
| 23 Jan 2017 02:34 AM |
Not sure if this is a good method,
Have client do it on client and send to server to fire to all clients but the one who sent to do the same thing.
That way it appears instant for the person who sents. |
|
|
| Report Abuse |
|
|
|
| 23 Jan 2017 02:52 AM |
| Its like a gun, pre-weld the model, weld it to your character on the server, wait for welds on client, animations on client, fire server to do bullet and take ammo. |
|
|
| Report Abuse |
|
|
Rerumu
|
  |
| Joined: 11 Oct 2014 |
| Total Posts: 950 |
|
|
| 23 Jan 2017 06:46 AM |
| Lol, RFs are 100% useless, you can do their job with REs faster and better, no reason for them to exist. |
|
|
| Report Abuse |
|
|