A moment of silence for
<<<ROOT>>>
because it is now inaccessible in the type system.
Please look more closely at the circumstances around what occurred last week. Version 453 was reverted last week and we skipped to 454 this week, following a critical data loss bug with 453. LuaCow did not receive any internal release notification so he didnât act on it last week.
Again, the whole release notes publishing flow is more or less a one man show here, my role is a volunteer thing which I coordinate with LuaCow on, but there were some highly unusual circumstances last week which resulted in this delay.
Weâre trying to reconcile and catch up now that things are back to normal.
Do you have any history of the 453 dump in the sitetest1 or sitetest2 branches on your client tracker. Probably wouldnât be too hard since Iâm fairly sure GitHub saves old commits.
found it: 0.453.0.412924 ¡ MaximumADHD/Roblox-Client-Tracker@3fa09c1 ¡ GitHub
Well⌠funny you should mention that. The commit history of the client tracker revolves around a lot of detached heads that arenât actually kept around on record for more than a few weeks.
The commit flow that my bot uses at the moment is⌠extremely backwards, in that it forks from the production branch and tries to pull from its parent upstream whenever the parent branch receives a commit, instead of merging its own changes upstream when they are effectively merged into the parent.
If thereâs a merge conflict (which eventually does happen) it just gives up and does a hard reset against the parent branch, and then recommits what its trying to change so thereâs no more merge conflict.
Itâs a horrible mess and I want to rework it to flow the other way around, but there are some annoying caveats to that approach as well. For now its good enough⢠and Iâll improve it when I have more spare time.
We will be encouraging people to use Humanoid:ApplyDescription with the second argument as Enum.AssetTypeVerification.ClientOnly on the server if they want to use models with HumanoidDescriptions.
There is no way to turn off AssetTypeVerification on the client since this would have security issues and be less useful anyway since you wouldnât be able to load private assets owned by the game developer anyway. We do not allow loading of models with HumanoidDescription on the client to avoid the risk of games being able to load models owned by the player.
Seems nice that there are more things coming to the rotate tool inside Roblox Studio.
@TheCarbyneUniverse I did make a feature request on adding the # of angles rotated/moved around a certain Instance inside Roblox Studio, you can bump that or view it if you want.
This. This seems nice to have when scripting something inside studio/Roblox and donât have to narrow a type
in some if / then
statement.
May I ask what ILegacyStudioBridge
does within Roblox development and the Engine itself? I seem curious on that it might have to do with legacy things in scripting?
Weâre well aware that developers want this and will almost certainly be doing this as part of the further dragger improvements. Although an angle display in and of itself would be fairly simple thing to add, we want to make sure that weâre making the improvements in a holistic way such that they all work together well, so it will take some time before we have a complete design and can start adding these things.
The pie-slice display was actually supposed to be in the initial version of the tool, and the code for it has existed the whole time, but the underlying rendering features needed to support it ended up getting delayed so we had to wait until now to actually turn on that part of the visual.
Loosened team create permissions so user team create games can add groups that they are not a part of with the play permission and group team create games can add users that are not part of their group with the play permission.
FINALLY. I can properly whitelist the Roblox QA team without asking them to join my group specifically to be able to test games and I can keep the play button off if people arenât authorised to play. Super helpful and should have always been the default.
Still waiting to be able to give edit permissions to specific users in a group though, so I can keep everyone in the same rank but only give certain users access to my games. Same with adding other groups to permissions and their ranks.
Edit: Fixed
Iâm not sure if this has to do with the update being reverted or with version 454, but the left and right arrow key rotation speed has yet again been reduced to a crawl.
I hope this gets changed soon, as it makes it much harder and obnoxious to play with arrow keys or arrow key camera controls.
Changed the hotkey of toggle comment from âCtrl+shift+câ to âctrl+/â.
I can change this back right?
Yep, just open the customize shortcuts menu under File.
Does this mean weâll finally be able to use :ApplyDescription on the client soon?
Humanoid:ApplyDescription will be available on the client soon for locally created humanoids. That is it will be able to be used if the Humanoid doesnât also exist on the server. The reason for this is that there is some unexpected behaviour when using it with Humanoids that also exist on the server due to legacy replication rules. We are looking into if itâs possible to change these so that ApplyDescription could be used for all Humanoids on the client but that is more long term and will not happen any time soon.
Why was GetPath deprecated, did it just not work (as i suspected as I couldnât make it do anything)?
I noticed from the API reference page that Humanoid:LoadAnimation()
and AnimationController
were marked as deprecated. All the tutorials on the API reference should be updated to the new way of playing animations by using the Animator
instance.
Is there any concern about exploiting in that case? E.g, would an exploiter be able to just apply anything to their character they wanted as long as its proper UGC/Roblox content?
An exploiter can already change their characters appearance on the local client and this wonât replicate to the server. This would still be the same even if we released Humanoid:ApplyDescription on the client.
Ah I see, I guess I misunderstood. I can definitely see how that would be useful to devs. Iâm assuming if they load body parts with different collision sizes as an R15 character nothing different would happen to how the client simulates physics, but, how would it effect animation playback? (Assuming there is even a good answer to that question)
Animation playback would still work well since we replicate just the information about the current animation track to other clients, not all the individual updates about what parts are moving.
Physics might work weirdly but this wouldnât make any client side physics exploits that arenât currently possible now possible.
This appears to be a mistake in the API documentation only, possibly due to a web code change that is case sensitive. Humanoid:loadAnimation
(lowercase) is showing deprecated, Humanoid:LoadAnimation
is not, and is showing correctly on the Humanoid API page, but not on its own detail page (where the red deprecation banner is showing for the wrong case variant). I believe this to be in error.
EDIT: Please re-read. While there is a mistake with loadAnimation not showing as deprecated, the long term goal is to transition to working directly with the Animator instance. Deprecation of Humanoid:LoadAnimation and AnimationController:LoadAnimation are intentional.
There is no need, however, to refactor your code at this time. For those who were experiencing animation loading issues this morning (Nov 5), it was not related to this API change, there was another platform issue with content loading, as well as an animation playback issue, either of which may have been the source of animations not playing or not looking correct.