"Hidden" classes for objects' API

Bug Reports Documentation Issues
#1

This is frustrating, there seems to be more than a class for some objects. For instance, we have BasePart which is all the objects which are Part, UnionOperation, MeshPart… etc. Then we have GuiObject which is all the UI objects.

I’m requesting about what classes each object API in all belongs in, so I don’t have to waste countless of hours trying to figure out the collective class of certain objects, such as all GuiObjects with Text properties: TextLabel, TextBox, TextButton

The main usage fields of finding these hidden classes, were for filtering out objects using :IsA(className).

2 Likes
How to detect if basepart is being modified?
#2

On the wiki when you are looking through the documentation of an instance there is a sidebar on the left. Select ‘class tree’ at the top below the type index pages section. Then fill in the object you are interested in, in the search above. The class tree will automatically show you the location of that object in the class tree.

On the old wiki it used to be more obvious, since if I recall correctly it would show you what object it inherited from at the top of the page. That would be a good feature to make a return in my opinion.

5 Likes
#3

The tree of classes on the wiki should help out with this, though tbh the API docs have been lacking in this area ever since they threw out the old wiki.

Edit: ninja’d

3 Likes
#4

This is a tricky problem and one that I think @Maximum_ADHD ran into while writing the API dump. GuiObjects with text don’t inherit from a single class. IIRC they implement a “text rendering” type of interface that isn’t reflected in the API dump, which we build API docs from.

This is challenging because even thou BackgroundColor3 (for example) is shared, Text (TextLabel, TextButton, TextBox) isn’t.

As for showing the full inheritance path (like Instance > BasePart > Part) I agree, it would help. The class tree in the left sidebar should help this issue in the meantime.

1 Like
#5

That tree is still a bit of a mess currently. It’s unsorted and it doesn’t seem to update properly (given that RootInstance is still listed like, 9 months after it was removed).

Can you look into it @LuaCow @UristMcSparks?

3 Likes
#6

Hmm, perhaps Ryan might have insight @polarpanda16 @LuaPolar

#7

Interesting. We’ll have to take a look at this internally and determine how the class tree is populate, when it is updated, sorting, etc.

@Maximum_ADHD I completely correct that RootInstance is no longer published and should not appear in the tree, yet it does.

1 Like
#8

Looks like this is going somewhere. I really appreciate that if I can finally read the full class trees without having to write longer and probably unreadable if statements.

Whenever the documentations are added, it’ll make my day easier.