I have a bus model, and a street model. I want the street to move, making it look as if the bus is moving. When the street model has moved far enough that it starts to end, I want the streets position to be moved back to where it was, making it seem like the road is infinite, I have set fog, so players cannot see when the road is about to end etc.
The issue is, is that I can’t find any materiel to help me. I’ve searched for quiet a while and still wasn’t able to find anything, so I’ve came here.
make the street into different sections models and give each model a primary part then in a while loop move the models in a while loop by the
while wait(1) do
model.SetPrimaryPartCFrame(--CurrentCframe + CurrentCFrame+CFrame.New(1,0,0) or some value)
end
then what u want to do when the street goes past the bus u want to use the Model:Destroy() function on the street and have a new random section of the street model load in infront and join the movement looop – ive kept this quite brief because its very intricate but feel free to ask questions
A way to do it would be to use TweenService. Make the road long and use .Magnitude to check if the bus is nearing the end. Then, you could clone a road model into workspace and place it in front of the old one. Check if the bus is far enough away from the old road segment, then destroy the old road segment.
If you want to tween the whole road model, I’d recommend not to use :SetPrimaryPartCFrame() because it deteriorates the model after repeated calls. This is a good post to read if you want to tween the model.
i infact disagree because the model could become out of sync using tween service and the SetPrimaryPartCFrame wont deteriorate the model because the model will be destroyed and a fresh on put infront of the bus every time the bus passess the use of Cframe digits helps you to synchronize your game better
The argument I presented in that thread against SetPrimaryPartCFrame isn’t subjective and therefore not something you can agree or disagree with. Because of floating point imprecisions, SetPrimaryPartCFrame tears models apart. It shouldn’t be used unless you are not using it frequently (e.g. one or a few times). If you need something like SetPrimaryPartCFrame, write a custom implementation that offsets related parts in object space to a point of reference.
I’m not sure what synchronisation issues you’re referring to when you’re talking about tweens, but that typically doesn’t happen. If you’re talking about position desynchronisation, you can always account for that yourself with your own methods. Server-side tweening will be slow but synchronised and client-side tweening will be fastest but dependent on the client’s machine for its smoothness and such.
Synchronisation isn’t really a talking point here because both tweening and CFraming will both have the same implications. Tweening just defines end properties to be lerped through over a period of time while CFraming sets the item instantly. You want the better option, which isn’t SetPrimaryPartCFrame.
Also no, 0.01 as an increment for either SetPrimaryPartCFrame or while wait do look equally bad. Wait has a minimum waiting time of ~0.03 seconds meaning any value lower doesn’t do anything except set the interval to the minimum time and SetPrimaryPartCFrame’s floating point imprecisions are present regardless of the increment you use. While wait do is bad.
i read the article about the “while wait do idiom” its an awfully long article to say that: using an actual conditional statement is faster because lua doesnt test truthy conditions
while game is running do
while true do
wait(something)
move the map
end
i personally like this miniscule optimization and i dont always use “while wait do” i do indeed like any extra optimization.
but on the other hand how does SetPrimaryPartCFrame deteriorate the model (never mind i found out why, but the rest of my argument still stands) its over time like i said you would be destroying the model after a couple of seconds, so even if it had began deteriorating it would soon be back to its origional state as replicated from somwhere
I’ve made this case in my post. Simulating a moving environment by keeping the bus stationary but moving the backdrop falls under infrequent usage and presumably if you’re intending to make the environment look like its passing by quickly, then the amount of times the drop is incremented wouldn’t be significant enough for the tears to be noticeable. This is one of the cases where the issue with SetPrimaryPartCFrame isn’t significant enough to avoid using it.
