Apparently, there’s currently no way to exactly loop through the properties of an instance. This is pretty much inconvenient and could be useful at many times.
For example: when you want to lerp all the properties of an instance, where you check whether it’s lerp-able with typeof(). In my case, I need to lerp all the properties from a Lighting Effect from one to another, which is a tough quest if I need to use a workaround.
Is there any chance this could be added?
If there is a possibility to do so, please let me know!
Thank you!
This discussion has stemmed back to even 3 years ago.
People have been asking for someone to at least easily grab every single property. Which would solve your use case as you can just do Instance[PropTab[PropIndex]]
So far the closest agreed upon solution is having the API dump be provided in an API call to parse or some form of official parser for it rather than having to grab the dump everytime it changes. As presented in that thread, some form of reflection system to get info about objects.
Edit: I think that workaround is overly complicated for something this simple. Even making a table of all the properties is simplier than following that API stuff lol.
I’m wondering now why it’s being disliked so much?
I’m fairly sure there is a github page with the JSON encoded description/properties of all instances somewhere around. The best solution at the time would be a GET HTTP request to it to avoid having to manually update.
As for the lerping multiple properties issue, I suggest looking into TweenService.
I made a plugin recently that needed this, and I had to write my own code to get all of this data. I have to manually update a modulescript every time I need to update the plugin. This would make that a lot easier.
(I’m pretty sure this is what you’re talking about.)
The problem being HttpEnabled must be set to true, so the majority of implementations that would take advantage of this (plugins) would be inconvenient to use. Want to convert an instance to another class? Have to turn on HttpEnabled first. Someone already did this, but it never took off just due to the inconvenience.
Yup. This is why I was manually updating a modulescript. You can require it to get the latest version without needing to update the plugin. It also means that you don’t need to turn on HttpService
What would be interesting is if we auto-updated a module with a bot. This way we get every change to the API as it happens, without the added inconvenience of enabling HttpService, having to manually update a module, or the maintainer of a plugin not updating it quickly enough. I may look into this actually.
For this particular use case, I think this would be less useful in practice than it sounds. If you write code to just lerp any types of values it knows how to, future changes to the API could easily break your code by introducing one or more numeric parameters that make no sense to interpolate. But that’s not the only problem…
In one of my places, I lerp between two environment settings, including lighting. But they are not all straightforward lerps. For example, Lighting.TimeOfDay and Lighting.GeographicLatitude wrap around, so there are modulo operations as part of this; a naive lerp would go in the wrong direction half the time (in my use case).
There are also “properties” exposed to Lua that are actually getter/setter functions on the C++ side, and some of them modify the same data as others (like Color3, BrickColor or TimeOfDay and ClockTime). You wouldn’t be able to figure out relationships like this from just the exposed variable type.
Lastly, there are some types you might want to lerp in different ways, depending on the exact property. For example, sometimes you might want to lerp between two Color3’s by hue rotation, other times just linearly (e.g. between two brightness levels of the same hue).
This does make it hard for devs to make some more abstract things for games (not necessarily front-end but I will use my serializer as an example).
The issue comes when you want to quickly store values of properties of an object for say storing them in between game sessions (which brings forth lots of possibilities, such as custom items in games) or maybe the case I mentioned where I really just want to make something cool and/or useful for other developers.
The uses I could think of right off the top of my head are serializing for storage, passing data as strings to make the client-server boundary easier to deal with, or just sending instance data from the server to the client to prevent the need of forced replicating it to all clients.
As for plugins I’m sure it could give a wider variety of possibilities.
However, @EchoReaper you can do something like the following to ignore the HttpEnabled drawback from plugins:
local Http = game:GetService'HttpService';
local Enabled = Http.HttpEnabled;
local Result;
Http.HttpEnabled = true;
Result = Http:GetAsync(Whatever);
Http.HttpEnabled = Enabled;
Since I believe plugins have access to the property.
Im going to bump this since from doing some basic research I still believe the only way to access this data is through http service calls and I can see quite a few common use cases of such a function especially in areas such as plugin development. A GetProperties() function would most likely be the most ideal solution.
