Properties+ is a module and plugin that reads all available properties of a given instance through a shortcut, code, or more once called through a script, since there is no built-in function to do the same as how the module does.
Functions
All available functions to call:
.New()
.GetProperties(instance) → Returns a table of properties of a particular instance.
.ReadEnumerator(enum) → Use a enum (ex. Material) and reads all EnumItems available to it.
This type of structure is really a no-no when your module is this large scale, use a table and read from it based on it’s .ClassName, (services are also their own classes iirc)
e.g:
That should run a teensy bit better while also giving so much needed scalability and cleanliness to your structure that you would not have by just continually adding if’s for each class of instance.
On that note, I don’t know much about it but I do know CloneTrooper1019 has a maintained API dump on his github, you could probably make use of this to add further flexibility so that your users don’t have to fork or pull request everytime a new class is implemented. Let clonetrooper do the work for you.
And then there’s the obvious moral question, why do I need this? I personally don’t think you really do, any use case for it would just be really niche and solvable through a more conventional alternative… Could be wrong on that tho.
Something you should ask yourself, not me. In game development, if you’re changing values of a particular value like a NumberValue or a Vector3, using this would be ideally helpful to read any property changes. Other developers using this will come up a usecase in present or future time.
I am not familiar with HTTPService nor do I want to implement into my module,
That is perfectly ok, but some may also not want to wait a week or two for you to change and then push an update to this module when a new class releases.
I have dictonaries set up to change with ease and add for long term.
That doesn’t make sense, a dictionary long term requires you to get on and edit the module to add a new list of properties everytime, you won’t be maintaining this module forever, and to be fair neither will clone trooper be maintaining his dump forever. But that’s why the API dump is open source, anyone can get on and change it, and then anything using that as a depency will instantly have the update. If anything, using a dump IS a more long term solution…
Something you should ask yourself, not me.
I’m not talking about myself, I’m speaking in general. As i mentioned earlier, niche things like this are only handy solutions to keep your current idea, that’s it. Conundrums like this are easily replaced by as stated earlier, conventional alternatives.
if you’re changing values of a particular value like a NumberValue or a Vector3, using this would be ideally helpful to read any property changes.
What you mean by this sentence is not very clear to me, if you want to see when a value changes, we have .Changed and PropertyChangedSignals for this reason. And just because you can come up with a use case does not mean it is automatically valid, as I said earlier it’s more of a moral question, picking the least redundant option is best here.
You have no clue of the capabilities this Module has allowed us to create advance things faster and better. For example, Instance serialization, Property comparison, Property copying between different classes and so on.
It’s true that this module doesn’t have to exist for all of that to be possible but for me I really don’t have the will to exert energy for something that is simply stupid, in this case Roblox not implementing :GetProperties after many years of asking.
So to me this is a god bless and frankly one of the most useful resource I’ve seen in a while on here.
Although, yeah I guess the OP could be indexing a dictionary instead of a bunch of if statements but idrc as long as it works well, I don’t think the performance gain is worth the effort.
@loueque is the source on GitHub up to date GetProperties does nothing aside from printing
Property comparison is useless in effect if we’re both thinking of the same thing here, but regular property comparison can be done without this module: (foo.Property == baz.Property) And about ‘property copying between different classes’ I genuinly fail to see a case where that’s useful, you can substitute direct class mutation with composition or even inheritance, which you should already be using anyway.
And about Instance serilization, serializing the entirety of an instance is not useful, like I said earlier many use cases you could argue this module supports may likely be redundant because it’s such a niche feature, you should only be serializing what you need to store, storing entire instances does not come cheap especially with how garguantuan the roblox API is already.
in this case Roblox not implementing :GetProperties after many years of asking.
I wonder why? Why do you think attributes are only exposed through :Get() and :Set() methods? Directly mutating properties was likely unfeasible, I doubt property access is as rudimentary as you think it is…
Although, yeah I guess the OP could be indexing a dictionary instead of a bunch of if statements but idrc as long as it works well, I don’t think the performance gain is worth the effort.
“All of this just works!” jokes aside, it’s not about performance, that’d be very micro. As I mentioned it’s about scalability and cleanliness here.
Should be up to date as of now, and what else would you want the module to do instead of having properties being printed when calling the function? Curious to know.
I’ve implemented that when starting working on this module, to be fair, it should be removed (Instance.Name seems more reliable than using :GetName()).
I’m probably going to add HTTP into the module later this month, found some open source of all instances + a post somewhere of a function to get all properties of an instance, yet HTTP isn’t a long term solution.
Return the table of properties instead of flooding the output with prints of course. It’s called GetProperties not PrintProperties so it’d expect it to do what the name suggests.
And I also don’t see why you need to use : instead of . for Methods / Functions when you are not using self
Thanks for putting this together! This is great for one-off debugging for lazy devs like myself.
I found another few more errors from the mass replace of ‘int’ to ‘instance’:
BreakJoinstancesOnDeath is not a valid member of Humanoid
TargetPoinstance is not a valid member of Humanoid
WalkToPoinstance is not a valid member of Humanoid
