Moving platform script not working for some odd reason?

Help and Feedback Scripting Support
#1

what I’m trying to do is just get every part in a folder and then make them move following their delays, that’s about it

but for some reason doesn’t work? and #moving:GetChildren() is returning 0, so my guess is it’s cause streamingenabled is true?

local core = workspace:WaitForChild("CoreGameplay")
local moving = core:WaitForChild("Moving")

for _, move in pairs(moving:GetChildren()) do
	local constraint = move.PrismaticConstraint
	local _delay = move.Delay
	local ext_delay = move.ExtraDelay

	local outPos = constraint.TargetPosition
	
	wait(ext_delay.Value) -- im doing .Value just in case it changes
	print(move.Parent)
	while move.Parent == moving do
		wait(_delay.Value)
		constraint.TargetPosition = 0
		wait(_delay.Value)
		constraint.TargetPosition = outPos
	end
end

this is all done in a localscript inside replicatedfirst so the platforms don’t become out of sync for any of the players

3 Likes
#2

change the network ownership of the primarypart of the model to the player and use generalized iteration or ipairs for arrays

2 Likes
#3

they’re a bunch of parts inside of a folder would it be better to put them all into a model? also what is the different of ipairs and in pairs?

1 Like
#4

a model is the ideal Instance to hold BaseParts and MeshPart

ipairs is designed to work with arrays; {5, 2, 3, 1}
pairs is designed to work with dictionaries {hello = “world”}

generalized iteration solves this confusion

for index, value in instance:GetChildren() do
end

it’s important to not use pairs over ipairs because sometimes it will lead to inconsistent results or the loop won’t execute at all

you don’t need to use ipairs, pairs or next at all anymore. Generalized iteration can also handle sparse tables, as far as i know.

use task.wait() over wait as well. you can search the forum for the best practices atm (2024).

1 Like
#5

thank you for telling me I just thought it was a shorter way of writing it

this doesn’t seem to work, and says the primarypart is nil

also none of the parts are really related just put into a folder for organization, would it still be better to use a model

#6

if that is the case, you should keep using the folder, but you have to call part:SetNetworkOwnership(player) on each of the parts within the folder from a server-script then animate it in the client. Not sure if this will ultimately fix the problem though, good luck.

1 Like
#7

even with streamingenabled turned off the script doesn’t work on the client, only the server, which makes me curious on how I could stop the platforms from lagging then? without manually setting their networkownership

#8

Why not just use a Server Script that Tweens Anchored Parts with your unanchored platform Model Parts all welded to the Anchored Part.
The tweens will control the movement of the Anchored Parts on the server and the client would read that movement from there.

#9

only reason I’m using a prismatic constraint is so the player can actually ride on the platform, from what I know players can’t actively ride on a tweening object

I don’t know if there’s a major difference but a lot of the platforms are not together or are supposed to be on different timelines

#10

Unanchored Parts welded to tweened anchored Parts have physics enabled and players will move with them just like using Constraints.

You can use different tweens for each platform, but all players should see the same movement of each platform if it’s set on the server.

#11

what would the difference be? currently constraints sometimes lag behind causing some jumps to be impossible because they aren’t “in sync” with the player
that’s why I initially thought to do it via the client

#12

ReplicatedFirst runs scripts on the client particularly before anything in the server begins to load for the client. It is likely that Moving’s descendants have not been loaded when the script runs. In this situation, it is advised to run the script when all essential instances are loaded on the server.

1 Like
#13

When testing Constraints wait for a few seconds after loading the place. Physics seems to be one of the last things loaded into a place when testing. It can cause the lagging/jumping you describe.
Also if you have a CFramed or tweened item joined to a constraint it will be jumpy because CFraming drives one item and physics drives the other.

Anchored items on the server are probably the way to go because they don’t involve issues when one player gets close to a physics item and assumes Network Ownership, then another player gets close and has to deal with the 1st player’s ping to the server back to the 2nd player’s ping.

But as we have said, trying to synchronize data between players while running on the client isn’t great. You have the ping of loading it from the first client to the server to the other client.
If it’s server based you only have the one trip for the data.

It’s why animations may lag when you watch another player, or their movements aren’t smooth (they teleport instead of walk) when there is lag between client and server.

1 Like
#14

it wasn’t necessarily my goal to have it in sync with everyone I just wanted the physics to sync with the one client (kind of how tower of hell does it)

I will try this out though it seems like the best way of doing this probably

#15

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