Jesus, this is so trippy and so cool at the same time. I would love to see games implement this or maybe a whole game based around this like an obby for example.
is it stuttering on the moving platform or it just me?
Imgur: The magic of the Internet How I fix the issue? (I was check out this place earlier today with my sister and my friends and her friend…)
@TheWiseAndGreat Alright when I tested the file theres no problem at all. It feels super smooth for me. By the way how are you moving the train? Where is the script that moves the train? What parent?
I find it very cool thing! It could possibly used for sonic games where sonic is running on vertical loop!
The thing is that the train runs on frame rates meaning if your frame rate is low and the server is calculating more things than it can’t handle the train will look laggy and stutter. I experienced this when adding more cars as it looking like it was lagging the whole place.
The train moves via run service heartbeat and calculates where the train is supposed to be for every car the real trick being to sync up every car with equal distance. then I use gravity controller (Platform stick) to make the player stick to the moving platform. The result is the really smooth train ride.
The script moving the train is actually the track creator (In server script service) if you scroll all the way down you will see the function that moves the train.
@TheWiseAndGreat Oh thats why its been so hard for me to find out how it moves. Anyway i need you to team create with be by adding me as friend in roblox because my train got issues like stuttering and the train cars are separating.
Interesting work, I love the idea and design.
This may look like a basic question, i’m not very experienced with this kind of stuff, but how do you teleport a player while using the Wall Stick system?
That’s a very valid question!
There’s actually API for it included in the module so you’ll have to read that. I can’t remember it off the top of my head unfortunately.
Good luck!
I tried using WallStick.new(player)
and WallStick.HRP
to get the player’s HRP and teleport it, but everytime WallStick.new(player)
is fired the character stops colliding with everything and dies in the void.
By looking at the system’s module script i found the case of this being setCollisionGroupId(self.Character:GetChildren(), WALLSTICKCHARID)
at line 156, so I’m probably doing something wrong.
FIXED
Fix: I totally forgot that the ExampleMain script was already using the WallStick.new(player)
function. If you are gonna teleport someone with this system, do it in ExampleMain script and use the API in the Module Script.
There’s game with an obby with the gravity controller.
Just PM me if you’d like the link.
How much work was done to the PlayerModule? It’s child CameraModule and ControlModule? I don’t want to have to explore their innumerable descendants especially, which would seem unnecessary, but if I really want to understand what’s going on do I have to check these out? Ignoring them I still have around 2500 lines to translate, interpret and augment, so I figured I’d ask. And if I do, where does the prefab end and the ego start? I feel this being a code Frankenstein could present it’s own hurdle.
All the code regarding camera modifications is done via the player scripts loader. I purposefully didn’t write it in the player modules because that tends to get updated occassionally and as you say, it can be extremely difficult to navigate those modules.
I really like the idea, sounds good to me!
Is there any way that you are able to implement a feature that allows you to turn this function off with a keybind?
So I have two things to share here.
The first, and arguably more important is an update to the gravity controller. Prior to this update the controller had issues with spinning parts, that’s no longer the case. Using a very stripped down version the wallstick controller technique we now correctly spin with parts!
The second, is more or less a tip from me to you. This applies to both the wallstrick controller with the new camera and the gravity controller.
When you’re going on parts that will consistently change the gravity up vector you’ll want your camera to perfectly match the spin of the part.
If you set the transition rate to 1 then it suddenly snaps.
If you set it to some value lower than that then it gets an ugly jitter.
The solution? When you step on a part that requires the camera to have a transition rate of 1 you lerp the transition rate itself.
if (floor and (floor.Name == "SpinPart" or not floor.Anchored)) then
targetRate = 1
else
self.Camera.TransitionRate = 0.15
targetRate = 0.15
end
self.Camera.TransitionRate = lerp(self.Camera.TransitionRate, targetRate, 0.1)
Huzahh!
When I came across a problem in my current project I thought of this controller.
I recalled in the serverScript a function setting character HRP positions, so I took to the task of implementing it thinking you somehow found a loophole.
local function onFrameStep(dt)
for player, storage in next, PhysicsReplicationStorage do
if (player and storage) then
local part = storage.CurrentPart
local previousPart = storage.PreviousPart
local currentCFrame = storage.CurrentCFrame
local previousCFrame = storage.PreviousCFrame
if (part == previousPart) then
currentCFrame = previousCFrame:Lerp(currentCFrame, 0.1*(dt*60))
end
storage.PreviousPart = part
storage.PreviousCFrame = currentCFrame
local character = player.Character
if (character) then
local hrp = character:FindFirstChild("HumanoidRootPart")
if (hrp) then
hrp.CFrame = part.CFrame:ToWorldSpace(currentCFrame)
end
end
end
end
end
It’s unused though still there. So I was wondering why. I kind of want to know how you came to the conclusion of it all because for me, similar stuff with the Humanoid, augmenting the network with custom stuff like this, has only been accomplished after weeks of trial and error. Thanks.
So I’m not entirely understanding your question to be honest. So I’ll try to do my best to answer what I think you’re asking.
The first question, why is the above code unused on the server? To be honest I can’t remember the EXACT reason I disabled it. I recall it was interfering with something, but now re-enabling it, I can’t seem to find out what that was so maybe I’m misrembering.
That said, there is one thing that is certain. The code doesn’t need to be run on the server; it’s an extra replication step that doesn’t praticularily have a lot of purpose unless for some reason the server needs a very accurate position of the character when they’re on fast moving parts. Why? Because of network ownership. The server will try to match the client’s character CFrame, albeit less accurately than if you ran the above code.
Without the above code running:
With the above code running:
Now, the second question, how did I come to the conclusion. For sure there was a bit of trial and error, but for the most part the idea behind this custom networking was inherent to the idea of the wallstick itself. You’re moving relative to some part so you send (and recieve) the parts players are standing on and their relative position to them. It’s just a matter of making the transition between the updates sent over the server seem smooth (that’s where the trial and error came into play).
I hope this is okay to share here. I’ve been struggling with how I might tackle the ramp portion of an animation based skateboarding game I’m working on and stumbled across this incredible piece of work and the supporting post. Here is my very early attempt at adapting to a skate ramp:
Ego - Can’t thank you enough for all of the work you put into this, and the willingness to share.