@AllYourBlox Would you be able to post updated versions of the new scripts to this discussion? I would like to test the fixed versions to see if that fixed the camera bug previously reported. Thanks.
FYI, weâre going to enable new playerscripts again today, with all of the fixes for the issues we saw 2 weeks ago.
2 Likes
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.