I really needed this sooo much to make my block saving system, thank you
Also, it’s crazy that an simple objects has thousands of properties lol
3 Likes
No problem. I just assumed it was api.roblox.com, because you might want to use that in game and it also requires a proxy to access.
Roblox Instances is already used to make Roblox games.
This module seems to just display the API for Instances. I’m not sure why I would want it though because all the API is available on developer.roblox.com
1 Like
Ah, I see what you mean. I wish Roblox didn’t require a proxy to access the website, but I understand why they do that. Though I feel like it would be better if they just added a rate limit per server? But I guess I don’t know enough about that to really have an opinion on the matter.
To be fair, this is one of those things that is extremely useful for incredibly specific things. The primary uses I can see this being used for are custom explorers and scripting plugins (such as a visual scripting system). Both of which are things that I’m interested in pursuing at some point.
A custom explorer would be useful for developers (or at least me) to have an in-game explorer for live servers that lets me view and edit things both client and server-side (depending on which I have selected).
Then visual scripting is kind of self explanatory. A system somewhat like the blueprint system in Unreal Engine or the newer system they have in Unity. I have yet to plan out exactly how I would design the nodes as it needs to be both easy to use while still allowing you to do everything you want. It needs to do that without being more tedious than simply writing the code by hand. Although the target audience would likely me people who don’t code by hand.
1 Like
Sometimes people create complex systems and algorithms that require Instances to have certain properties (such as object serialization). This module makes it easy for people to determine whether or not something has a specific property.
There’s a feature request thread filled with more use-cases.
The current work-around is something like this:
local function InstanceHasProperty(instance : Instance, property : string) : boolean
return pcall(function()
return instance[property]
end)
end
1 Like
v1.0.2
Nothing new, but I’ve updated the instance API as I haven’t updated it since last year.
Let me know if there’s any feature you’d like to see added or changed.
v1.0.3
- Updated API dump
- Added “GetRawSuperclassProperties”
- Added “JSONEncodeValue”
- Added “JSONDecodeValue”
- Added “Serialize”
- Added “Deserialize”
- Added “Constructors”
- Added “IgnoreUpdates”
- Added “GetClassIcon”
- Other minor changes.
Just a note with the serialization. I’m not sure why, but it appears to be a bit intensive. It can only really handle up to about 50 instances before it times-out (even with delays). But it does support probably 99% of instance types and properties.
One other note is that any property involving another instance can’t be guaranteed when serializing unless it’s among one of the instances being serialized.
(Also serialization doesn’t work with unions at all probably, or terrain for that matter.)
Forgot to add “GetClassIcon” to the logs
v1.0.4
- Updated API dump (Just in case)
- Fixed “GetClassIcon"
v1.0.5
- Updated API dump (Bi-Annual)
- No other changes
v1.0.6
- Updated API dump
- Added “GetClassIconV2” for new Studio icons
(Read documentation for more info)v1.0.6a
- Added optional scale argument for “GetClassIconV2” base icon size (1-3 with 1 as default).
1 Like
you have no idea how much this helps me, I’m working on a super big project and this just saved my life, I owe you this
1 Like
FYI the main API surface for this has significant performance issues as is:
APIService:GetRawSuperclassMembers inserts the superclass members into the APIService:GetRawClassData(className).Members raw class data Members table of the subclasses when called. However, that Members table is always the same table. The result is that every call effectively results in these member tables doubling in size.
The trouble is, many different functions in the API surface call down to GetRawSuperclassMembers, so even if you cache the results for every unique class you call them on, for deeply nested class hierarchies this still adds up to enough doubling of members table size that the performance tanks.
APIService:GetRawClassData works as intended but I would not use any of the other parts of this API surface until the above issue is resolved.
1 Like
Would a copy fix this issue? Tables confuse me a bit regarding the different referencing and copying methods. I did notice significant lag when trying to serialize a workspace.
function APIService:GetRawSuperclassMembers(className,superclass)
className = superclass or className
local class = APIService:GetRawClassData(className)
local members = {}
for _,member in class.Members do
table.insert(members,member)
end
if class.Superclass ~= '<<<ROOT>>>' then
for _,member in APIService:GetRawSuperclassMembers(class.Superclass) do
table.insert(members,member)
end
end
table.sort(members,memberSort)
return members
end
I also have a question regarding garbage collection. Over the years, I’ve gotten into a habit of setting everything to nil and emptying tables when they’re no longer used. How often do I actually need to do this? Do I only need to do that with variables/tables that are referencing instances? I assume I don’t need to if that instance is a returned argument. I wish there were a developer documentation page regarding specifically this topic.
Yeah, that would fix it.
Caching the results somehow as well might be nice too (so that GetProperties doesn’t have to figure out the property list from scratch every time), but at the above fix will keep the cost the same every time you call the function rather than it growing exponentially which is the main issue.
1 Like
Caching GetProperty results or GetRawSuperclassMembers results?
I suppose I could also create a table containing every instance and everything related to it, but wouldn’t that create a spike when requiring the module? Plus in that case, I should store that calculated table in an external way, that way it doesn’t need to do it every time for every script requiring it. Actually, perhaps the table could simply dynamically be updated each time a new instance is introduced.
Alternatively, I could also do this added pre-runtime so that no calculations need to be done outside of basic indexing.
I mainly left the raw functions in there in case anyone wanted to do anything custom for whatever reason.
The standard way is to do it lazily the first time someone asks for the data:
local GetRawSuperclassMembersResult = {}
local function existingGetRawSuperclassMembers(...)
...existing code
end
function APIService:GetRawSuperclassMembers(className)
local result = GetRawSuperclassMembersResult[className]
if not result then
result = existingGetRawSuperclassMembers(className)
GetRawSuperclassMembersResult[className] = result
end
return result
end
1 Like
Dynamically adding it like that does sound like the best way. Thanks for pointing out the initial issue as I probably wouldn’t have noticed it myself (plus this is older code by now), as well as the caching suggestion.
I’ll push an update for this in the near future. There’s a few other changes that I’ve been meaning to make regarding handling outdated modules and automatic updates.
v1.0.7
- Updated API dump (For the the direct download only)
- Optimized GetRawSuperclassMembers
- Minor fixes to the Serialization function?
(Don’t use this for more than one instance. It works but it freezes everything for a time. I plan on rewriting this in the eventual future)(Read documentation for more info)
Note:
Due to an issue with Roblox moderation (involving a false positive that was rejected anyway), the model page is currently unavailable. But I’ve added a direct download for it in the meantime.Ever since the new on-site moderation and appeals system, I’ve had to appeal this asset every single time I’ve made an update to it. Usually it gets appealed quickly, but this time it was rejected for some unknown reason of which I’m awaiting proper support from the appeals team via email.
If getting rejected like this becomes the new norm, I may have to come to a different solution for this so I can still continue to update it. I can’t think of any ideas off of the top of my head. Perhaps the API dump will have to be added manually, but that kind of ruins requiring the ID directly to automatically use the latest version.
Update:
Moderation refuses to elaborate whatsoever, almost like they’re not even reviewing the asset in the first place or reading my emails, so I’m left to assume that the JSON API dump is the cause of this. If this is truly the case, I will not be able to share the model in its full form. You will have to use the tool mentioned in the original post to get the latest version, or download the asset directly (which has the most recent API dump included).If you still wish to use the model version, follow the setup guide.
I have a problem where when I do GetProperties(instance, true) it still returns non-writable properties which is a problem bc I only want the writable/scriptable ones
1 Like