Client Difference Log
API Changes
Added Property float Humanoid.JumpHeight
Added Property bool Humanoid.UseJumpPower
Added Property float StarterPlayer.CharacterJumpHeight
Added Property float StarterPlayer.CharacterJumpPower
Added Property float StarterPlayer.CharacterMaxSlopeAngle
Added Property bool StarterPlayer.CharacterUseJumpPower
Added Property float StarterPlayer.CharacterWalkSpeed
Added Function Dictionary AssetService:GetBundleDetailsSync(int64 bundleId) {RobloxScriptSecurity}
Added Function Array DataModel:GetObjectsList(Array urls) {RobloxScriptSecurity}
Added Function Dictionary StudioService:GetClassIcon(string className) {PluginSecurity}
Added Function float Workspace:CalculateJumpPower(float gravity, float jumpHeight) {RobloxScriptSecurity}
Changed the superclass of Class Backpack
from: GuiItem
to: Instance
Changed the superclass of Class BackpackItem
from: GuiItem
to: Instance
Changed the superclass of Class Hopper
from: GuiItem
to: Instance
Changed the superclass of Class StarterPack
from: GuiItem
to: Instance
Changed the write permissions and serialization of Property PackageLink.VersionNumber
from: {✏️None} [<💾> Save-only]
to: {✏️NotAccessibleSecurity} [<📁> Load-only]
Removed Class GuiItem
Removed Class ButtonBindingWidget
Removed Class GuiRoot
Removed Tag [ReadOnly] from Property PackageLink.VersionNumber
(Click here for a syntax highlighted version!)
HOLD THE PHONE.
(375)
(367)
It’s HERE!? Even the documentation page is filled out and ready to go! (or not qq)
Oh my God, amazing. Can’t wait to see the announcement thread for it. I’m going to get to work to implementing this where needed right away.
I am sensing the explorer is being ported to Lua in the near future.
Backpack, Hoppers, and StarterPacks were considered GuiItems??
A very long time ago, yes. This was when they were native UI written in C++.
This older system is being quietly phased out.
Soon TM. There is still some backend stuff they need to enable before it’ll be fully available to developers, but I have good faith that time is close at hand.
It actually isn’t. What you see on that page is the result of the API page automation. No descriptions have been filled yet.
isn’t this what starterhumanoid is for… : |
Perhaps the intent here is to explicitly state which values should differ from their default state? Correct me if I’m wrong, but I think overriding the StarterHumanoid currently just overwrites the existing humanoid object without taking anything like the varying HipHeight of R15/Rthro into consideration.
Ultimately I’m just the messenger here, so this would be a good question to anyone working on the avatar team.
I hope not. ScrollingFrames are lackluster at the moment and it would be a shame to lose the functionality of the arrow buttons in the Explorer.
To be fair, the idea of making all that Lua is that Roblox will have more of an incentive to make things like scrolling frames better for us.
Obviously that would be annoying but in the end it would be beneficial.
Having windows ported over in Lua is good, because (1) it forces Roblox engineers to eat their own dog food, which otherwise doesn’t always happen a lot and (2) it makes it easy for developers to fork it and make changes / improvements as required for your own workflow, without needing to write the majority yourself (since it’s already done).
The transition period would probably not be perfect, but the prospect of having everything available in Lua and easily editable is pretty exciting.
I’m all for porting the windows to Lua, but I’ll be sad if it comes with reduced functionality. Thus my worry about the ScrollingFrames.
So far the Toolbox has been working pretty well. I trust they will take appropriate actions to make sure it remains parallel with the existing system, if not better.
One other interesting thing to point out with class icons is that Roblox has moved the spritesheet into the content folder! Its stored at rbxassetid://textures/ClassImages.PNG
Originally it was baked into the exe, which made it difficult to alter the class icons. I actually ended up making an explorer icon editor which would find the image in the exe and patch it with new icons in my mod manager.
When this function is enabled, Studio starts using the external image instead of the embedded image, which unfortunately makes this editor useless in its current form. Can’t say I’m too mad about not having to rip the sprite-sheet from the exe though.
I’ll have to refactor this editor to be some sort of sprite manager specifically for that texture.
cc @Dekkonot You had a feature request like this before, didn’t you? Your wish was answered, I guess?
I did, and it has! I’m going to go ahead and leave that feature request alone though since changing it won’t net any gain even though it’s closed. I’m happy that this has happened.
Just a heads up: StudioService::GetClassIcon seems to be live (at least it is in my studio). As said in the API, it takes a string that’s the class name you want to get the icon for and it returns a table with three fields: Image, ImageRectOffset, and ImageRectSize. They correspond to the properties of the same name in Image* objects.
Thus:
game:GetService("StudioService"):GetClassIcon("Workspace")
returns a table that looks like this:
{Image = "rbxasset://textures/ClassImages.png", ImageRectOffset = Vector2.new(304, 0), ImageRectSize = Vector2.new(16, 16)}
Which looks like this when put into an ImageLabel:
This is without a background, but it looks exactly like you would expect it to.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.