camera still borks like in previous posts
If you have a moment, please try the attached version and see if the issue you’re seeing is fixed. We got a solid repro today for the issue with Tweens and Scriptable cameras. There is currently an issue with PopperCam popping under certain conditions, even when the camera is Scriptable.
1 Like
Ok so I wasn’t going crazy when my scriptable camera was freaking out only in some instances.
yeah that fixes it
1 Like
Glad to hear! We’re very close now. Thanks for your patience, replacing 9k lines of dynamically-typed script is going to have a few edge cases fall through the cracks, but we’re committed to patching them up and keeping as much legacy behavior working as we can.
ModalEnabled is nowhere to be found in the new playerscripts. We have to do an ugly hack to hide mobile controls in menus in the meantime. D:
edit: ye, userinputservice
UIS.ModalEnabled?
Is there any place we can make pull requests? The Github page seems out of date.
I found a few issues:
-
Trying to bind to certain inputs with the context action service is not possible. For example ButtonA on a controller or the left and right arrow keys while driving a vehicle. This is easy to fix by using context action results, but I must admit is very inconsistent (i.e. PlayerActions seem to default to a pass). That is an internal problem though, nothing wrong with the Lua.
-
In the control module you accidentally call the vehicle class, not an object the class created. Super easy fix, just add a variable that references the class at the top and make sure to use
.new()on lines 94 and 270 of the control module. -
In the vehicle controller module you use the context action service to bind functions that call methods for acceleration and steering. These methods require the userInputState be passed as a parameter else they do not function as intended. This is a pretty important fix because without it controllers can’t drive vehicles well at all. It’s also worth passing a context action result here as well to allow use of these inputs while driving.
I made these fixes myself, but perhaps some of them were intentional?
contextActionFix.rbxl (128.6 KB)
5 Likes
The way the camera pops after being occluded to closer than the user’s current zoom distance is fine for close camera (less than 50 studs) but takes much too long when the user is zoomed out a far distance, especially since zooming out when the camera is tweening does not work.
Thanks for the feedback, I will make these corrections. We moved away from having PlayerScripts in GitHub and processing developer pull requests about a year ago.
1 Like
Can the thetaCutoff variable be changed to 0 by default? I had to manually change it from 0.4 to 0; I’ll show you why. This feature was jarring/annoying in my game when you’re turning and I’m worried it will negatively affect people’s cameras in other games with vehicles or slalom/turning actions in general
Location of the variable:
PlayerModule.Cameramodule.ClassicCamera - line 164-ish - thetaCutoff = 0.4
^ The variable was exaggerated from 0.4 to 2.0 to better capture on video the micro-stuttering effect while turning slightly in one direction. (Raising the value made the more-obvious “pausing of the camera when switching directions” worse but it’s still jarring at 0.4 too)
^ Edit: Here the value is 0.4 (the default) and with the thumbstick you can probably see the micro stuttering when turning slightly
^ Here the variable is set to 0. Very sm00th
I’m not sure how it makes for more precise forward movements. If anything, in my experience, having the camera behave somewhat-unpredictably like this will throw me off
Edit: Added middle video trying to show the thumbstick turning slightly and the camera stuttering. More accurate than the crazy exaggerated value in the first video lol
2 Likes
I’m not sure, I can ask. This is one of the many hard-coded constants that have simply been carried over from the previous generation of PlayerScripts. It was deliberate on our part to not change these values during the conversion to the new OOP structure, both to preserve as much legacy behavior as possible and to not have to simultaneously deal with bugs from restructuring and from functionality changes.
But… that doesn’t mean it can’t or shouldn’t be changed. It’s possible to retain a dead zone (to avoid jitter just from input device instability) but not have a jarring transition out of it.
2 Likes
I’m encountering issues where the activeController can be nil on spawn and not change to an actual controller. This seems to happen when the player’s character is morphed into something else upon spawn(?)
Seems to be a race condition because it doesn’t happen consistently, only about 20% of the time when LocalPlayer.Character changes almost immediately after set to the default character.
I’m going to have to fork the new player scripts because of this, because I need a fix right now, can’t wait X weeks, but I hope this will be eventually addressed.
(If you would like a repro file please DM me here, I unfortunately don’t have time to make it minimal and it and it’s covered by an NDA)
3 Likes
@AllYourBlox There is a slight problem with the enable/disable.
Those two scripts are parented to a character depending on the buttons we click on the GUIs it will disable and enable the movement of the player.
ControlModule is required for both scripts.
ControlModule:Enable()
ControlModule:Disable()
The Module allows you to disable but when you click to re-enable the module it doesn’t allow you to move, I think this is caused by having two scripts instead of one. Shouldn’t module’s functions be shared through scripts?
Test Place:
2 Likes
I can’t use my gamepad at all in Studio now. If I touch it while playtesting, I can no longer move my character, even if I try using the keyboard again, until I close out and start a new playtest session.
2 Likes
Any chance you’re mistakenly requiring the ControlModule in StarterPlayerScripts rather than the one that is running on your player at Players.LocalPlayer.PlayerScripts.PlayerModule.ControlModule? When a ModuleScript is copied with Clone(), the clone and the original are not recognized by Lua as being the same script, and they will return different instances.
That said, we are not going to support developer scripts requiring ControlModule directly. The supported, future-proof way to access Enable() and Disable() is to require PlayerModule and use the PlayerModule:GetControls() function to get the running ControlModule instance. I created the GetCameras() and GetControls() functions specifically to provide a layer of indirection so that we have the freedom to do future restructuring and re-organizing of the player scripts modules underneath PlayerModule without breaking games the way the removal of MasterControl did.
I don’t just mean moving modules around either; for example, right now CameraModule returns a singleton instance by return CameraModule.new(). In the future, it’s possible (likely even) that this module will return a table of its public API methods, rather than an instance. Any code requiring CameraModule and expecting a singleton instance will break, but code using PlayerModule:GetCameras() will still work as expected (since it will have been modified to return the running instance).
2 Likes
We haven’t been able to reproduce this. Is there anything special about your setup? The ControlModule should be automatically switching back to Keyboard and Mouse (the Keyboard control module) any time the keyboard or mouse is used.
PlayerModule:GetControls() returns nil. In the old module enabling and disabling the controllers would not lead to anything breaking. What would I exactly do to make it so I can enable and disable the controllers from different localscripts requiring the module without having the bug of not being able to enable it again?
How would you go about enabling the controllers when resetting? It seems to break the controllers sometimes when set to enabled.
You have to require the module to use it’s returned functions.