Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:12 AM |
Hello, I'm currently having trouble thinking of a way to move parts towards a destination in the simplest, cleanest way. I have about 50 parts named "Gelly". In each, there is a mover script that takes them to different "Nodes" in my game. I do this in each, and I can't support more than 50 before the game starts experiencing MAJOR performance drops, which is deadly because then it slows down the frames and therefore the speed of the Gellys.
local steps = (gelly.Position-destintion).magnitude/gelly.Speed.Value for i = 1, steps do gelly.Position = gelly.Position-(gelly.Position-destintion).unit*gelly.Speed.Value gelly.CFrame = CFrame.new(gelly.CFrame.x,stats.yHeight+gelly.Size.y/2,gelly.CFrame.z) runService.Heartbeat:wait() end
I need to bring a part to a goal at a set speed. I am not sure how to do this with lerp, and BodyMovers are unfortunately out of the question (movers behave very strangely, they don't linearly pursue the destination). Is there any way I can optimize this code? I suppose I don't need to do it on .Heartbeat, but the smoother the animation, the better.
You can see a visual here in this intro-lobby: https://www.roblox.com/games/590379220/Payload
|
|
|
| Report Abuse |
|
|
pketny
|
  |
| Joined: 27 Dec 2010 |
| Total Posts: 1162 |
|
|
| 13 Jan 2017 04:19 AM |
| Note that runService.Heartbeat:wait() is different than actually connecting the signal to a function |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:22 AM |
Yep I thought I was doing it different from how I actually am. Is there a performance difference? Should I connect the signal to a function instead? It would be an easy fix.
|
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 13 Jan 2017 04:22 AM |
| Well one thing you can do better is not set both Position and CFrame but just the CFrame alone. |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:26 AM |
I wasn't sure how to get the unit without subtracting the positions, and I know that sounds dumb, but that was just my process
So, instead, something like this?
increment = CFrame.new(gelly.Position-(gelly.Position-destintion).unit*gelly.Speed.Value) gelly.CFrame = gelly.CFrame*CFrame.new(0,stats.yHeight+gelly.Size.y/2,0)*increment runService.Heartbeat:wait()
|
|
|
| Report Abuse |
|
|
Lucas_Lua
|
  |
| Joined: 18 Jun 2008 |
| Total Posts: 7521 |
|
|
| 13 Jan 2017 04:28 AM |
I think I ran into this problem a few years back and just gave up...
I think what you're experiencing is due to having a lot of threads in the thread pool. I'd try having one thread for every 10 or so, rather than one per. You can loop through every assigned Gelly in each thread.
Of course, this is just a blind guess. |
|
|
| Report Abuse |
|
|
pketny
|
  |
| Joined: 27 Dec 2010 |
| Total Posts: 1162 |
|
|
| 13 Jan 2017 04:28 AM |
using runService.Heartbeat:wait() just has a small chance of sometimes skipping one or multiple frames. However, I do not think that is a significant factor. (But it could be since you have some CFrame calculations in your loop which often take up a lot of processor usage)
I do not know how to fix the lagg you're experiencing and I sometimes just think that roblox is just not able to handle some things like moving a lot of parts at the same time.
You could try to executing a bit of your code in the time you are waiting for the next heartbeat to happen using spawn(f). But I don't think that'll solve anything. |
|
|
| Report Abuse |
|
|
pketny
|
  |
| Joined: 27 Dec 2010 |
| Total Posts: 1162 |
|
| |
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:30 AM |
This code is sending my Gellys haywire. How does it procedurally differ from the first?
local increment = CFrame.new(gelly.Position-(gelly.Position-destintion).unit*gelly.Speed.Value) local yOffset = CFrame.new(0,stats.yHeight+gelly.Size.y/2,0) gelly.CFrame = gelly.CFrame*yOffset*increment runService.Heartbeat:wait()
@Pk & Lucas, So you're suggesting controlling my gellys movements from one main script, and spawning like 10 at a time, controlling them in pods?
|
|
|
| Report Abuse |
|
|
sayhisam1
|
  |
| Joined: 25 Nov 2009 |
| Total Posts: 2092 |
|
|
| 13 Jan 2017 04:31 AM |
You can also skip movement frames to speed up the blocks. People generally won't notice if a block is going at 30 fps vs 60 fps if the block is very fast. Also, you can look into using screenguis for the blobs(phantom forces bullets style) and just render a box on your 2d screen using rotated frames and clever shading. |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:33 AM |
@Sayhi Right, I'm deliberating doubling that "speed" throttle and just changing Heartbeat:wait() to wait() I've very interested in that second method, could you elaborate on how it could be achieved?
|
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:34 AM |
It sounds too complicated, though. I need to detect .touched when these parts come in contact with other things, and I need non-player objects to be able to see these parts (turrets/barricades/etc)
|
|
|
| Report Abuse |
|
|
pketny
|
  |
| Joined: 27 Dec 2010 |
| Total Posts: 1162 |
|
|
| 13 Jan 2017 04:36 AM |
To clearify:
select 10 from the 50 bricks and put them in a table start a thread that moves these 10 (do not use spawn for this since spawn runs whenever the main thread yealds, it does not actually create another thread) select 10 other bricks
if the parts move fast and together as a group you might however see the group split in smoe frames, don't know if this is noticeable and don't know if this will fix your problem
|
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:37 AM |
What's the difference between moving them in groups of 10 and moving all on-screen gellys at the same time?
|
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 13 Jan 2017 04:40 AM |
When you call event:wait() you cause the thread to yield until the event is invoked, when the event is invoked, the thread is then resumed. Now this doesn't sound too bad but when you have many bricks, you make Roblox have to keep track of a ton of threads in order to resume them-- and actually have to resume them all at the same time.
Using less threads (or 1 if you want) keeps that process simple.
What I meant earlier is just store that whole thing in a `pos` variable and read from that. There are tons of other way you can optimize it-- especially if the destination doesn't change until it reaches it. |
|
|
| Report Abuse |
|
|
sayhisam1
|
  |
| Joined: 25 Nov 2009 |
| Total Posts: 2092 |
|
|
| 13 Jan 2017 04:40 AM |
For interactions with .Touched and nonplayers seeing it, possibly store CFrames in a table somewhere where the nonplayers can read it, and use raycasts perhaps?
I'm not really the person to ask for actually rendering the boxes in a screengui, since I have never personally made such a script. I was just throwing out an idea that might work.
|
|
|
| Report Abuse |
|
|
cntkillme
|
  |
| Joined: 07 Apr 2008 |
| Total Posts: 44956 |
|
|
| 13 Jan 2017 04:40 AM |
"at the same time" in quotes. They'd be "resumed" whenever the thread scheduler deems fit. |
|
|
| Report Abuse |
|
|
Lucas_Lua
|
  |
| Joined: 18 Jun 2008 |
| Total Posts: 7521 |
|
|
| 13 Jan 2017 04:41 AM |
| I think the problem is that by putting a script in each Gelly to move each one individually, you're creating a lot of extra strain on the Lua interpreter. The interpreter has to switch between running a line in each of these scripts in rapid succession. By having one thread move 10 of them rather than 1, you're saving extra time and power. |
|
|
| Report Abuse |
|
|
Lucas_Lua
|
  |
| Joined: 18 Jun 2008 |
| Total Posts: 7521 |
|
|
| 13 Jan 2017 04:42 AM |
| Cnt beat me to it again. lol |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:44 AM |
| @Sayhi That's a very inventive solution and I'll definitely think about it in the future. @Lucas I figured there was some major hinderance, however, what's the benefit of moving 10 per thread or all 50-or-so on-screen gellys? #### Maybe you can help me here, I feel like optimizing this is top priority before thread scheduling https://forum.roblox.com/Forum/ShowPost.aspx?PostID=207092888 |
|
|
| Report Abuse |
|
|
Soybeen
|
  |
| Joined: 17 Feb 2010 |
| Total Posts: 21462 |
|
|
| 13 Jan 2017 04:44 AM |
Of course the first three letters of your name are censored, cntkill, lol
@Sayhi That's a very inventive solution and I'll definitely think about it in the future.
@Lucas I figured there was some major hinderance, however, what's the benefit of moving 10 per thread or all 50-or-so on-screen gellys?
@CantKillMe, Maybe you can help me here, I feel like optimizing this is top priority before thread scheduling
https://forum.roblox.com/Forum/ShowPost.aspx?PostID=207092888
|
|
|
| Report Abuse |
|
|