Why is such a potentially game breaking and backwards incompatible change being dropped with absolutely no warning like this, without the usual three phase rollout that is now commonplace for changes like these?
“Hi devs, today I’m releasing a change that may completely brick your games. Good luck!” seems an extremely irresponsible mindset to me.
We were not expecting this change to cause any trouble. We did do a limited rollout for a time and there were no reported problems.
Does this mean there could be multiple mouse delta values UserInputService:GetMouseDelta() in one frame? If I updated a camera with that value in RenderStepped wouldn’t that miss some mouse input?
In regards to moving PreRender, why was this never announced? Hopefully we can get a new diagram for frames quickly.
Okay, that would be appreciated, and thanks for the improvement!
GetMouseDelta works the same way - we now avoid clearing it to zero until both process input calls have taken place.
We didn’t announce earlier because we didn’t anticipate that any code changes would be needed. We did a limited rollout first and that didn’t reveal any issues.
Are there any plans on a way to better bind the mobile touchpad with UIS? It would be very nice to be able to natively get a processed boolen from it 
No - the sampling of VR controllers is decoupled from ProcessInput.
Relying on this quirk of the engine is probably a lot more common than you would think. I can think of, off the top of my head, a number of FPS games I’ve worked on with code that assumes input is processed first thing in the frame loop (image that @colbert2677 linked)
Primarily my justification for relying on this order of processing was A) that image, and B) the fact that RunService:BindToRenderStep() lists Input as a distinct category with a low processing priority.
All this being said, I don’t know if this will cause any breaking changes or undefined behavior, or even off-by-one-frame errors in games I’ve worked on, but it’s also out of my hands to test it. A lot of previous projects I don’t have access to, or the time to look into as I’ve moved onto other projects professionally. So I wish it could have maybe been introduced as an opt-in workspace property similar to a number of changes in the past.
We still do process input first thing in the frame loop. The difference is that we process input again later in the frame. I hope the pattern that you describe is not disrupted by this change.
I’ve been getting reports of mouse locking issues for a couple of days now. When was this feature enabled? I’d like to check if the timeframe matches.
In response to your earlier question, while I’ve had several reports of potentially related issues, I have not been able to replicate this myself in an affected device.
This feature has been active on Mac for 8 days. It is not yet active on Windows.
This is cool, and we are all appreciative of Roblox for giving us the tools we need to keep up to date with the latest developments in gamedev, but is this the correct and future proof way to keep parity with Valve’s new CS2 tickless inputs? It feels like decoupling the input rate from the frame rate will cause more issues than it is worth, making it harder to onboard new developers and falling short of the high fidelity input times experienced developers want.
Especially given that most games get their processing done in several milliseconds, these two input events will be fired right next to each other, before waiting for the next frame to begin, or if FPS unlocked, waiting for the GPU to finish rendering.
Giving the os.clock time of input would give much higher fidelity, and give us more control over how to use the inputs we’re given, preferably through
-- mock up
UserInputService.InputBegan(function(inputObject, inputProcessed, inputTime)
Simulation:stepToTime(inputTime)
Simulation:giveInput(inputObject)
end)
What sort of improvement are you seeing internally? Does it feel nicer?
I agree on the value of timestamps. I believe this is being discussed.
The frame rate improvement is very noticeable on certain experience/device combinations. I don’t have overall stats yet though.
What events can I listen to to ensure I’m getting all user inputs, particularly if I’m looking to handle inputs across multiple input types easily?
If you are using UserInputService then the InputBegan, InputChanged, and InputEnded events cover the user inputs.
I expect this change to be activated for PC in the next 24 hours.
I know it doesn’t affect windows but, recently I have been experiencing serious input lag after the new update and I’m not alone, my other friends do too, it makes the game unplayable, please fix!
Is this lag on Windows? How long have you experienced this problem?