Some errors I've found in the data-type pages

#1

Here is a collection of issues that I have found so far with the data-type pages.
Most of these are relatively minor, but they stack up as a whole pretty fast.


In General

  • These pages could really benefit from having code samples. I set them up to support code samples before my internship ended, but they haven’t received any so far. Any code samples that exist presently could potentially be used, if they happen to refer to any of these data-types.

Axes

  • The constructor for this datatype should have links to the Axis enum and NormalId enum, as well as a code sample showing how arguments are passed to this function.

BrickColor

  1. BrickColor.Number should be an int.
  2. The first constructor, BrickColor.new(number val) should use an int instead of a number.
  3. The BrickColor.palette constructor should use an int instead of a number. It might also be worth noting that the paletteValue is limited to values in the range [0 - 127]
  4. The BrickColor.random constructor should note that it chooses a random color from the palette supplied by BrickColor.palette

Color3

  1. This page doesn’t have a main description, or indication of where its used.
  2. The argument types for Color3.fromRGB should be int rather than number.

ColorSequence

  1. There is no main description for this page, or indication of where its used.
  2. For the sake of consistency, the types defined as table should be defined as array instead.
  3. There isn’t anything that directly links the data-type with the ColorSequenceKeypoint type’s page.

ColorSequenceKeypoint

  • This page doesn’t have a main description, thus it isn’t apparent how you would use it with the ColorSequence type.

DockWidgetPluginGuiInfo

  1. The type of the first argument in the constructor should be set to InitialDockState, rather than Enum
  2. The InitialDockState property is missing. This property’s type should be set to InitialDockState, and it should reiterate information from the InitialDockState page.

Enum


Faces

  1. This page doesn’t have a main description, or indication of where its used.
  2. The types for the properties on this page should be bool, not number.
  3. The constructor should link to the NormalId enum page, and include a sample for how to use the constructor.

Instance

  • This page should have a main description so that it’s more apparent that its describing the constructor for Instances, and not the Instance class itself. It’s an awkward exception, but one that exists nonetheless.

NumberRange

  • This page doesn’t have a main description, or indication of where its used.

NumberSequence

  1. There is no main description for this page, or indication of where its used.
  2. For the sake of consistency, the types defined as table should be defined as array instead.
  3. There isn’t anything that directly links the data-type with the NumberSequenceKeypoint type’s page.

NumberSequenceKeypoint

  • This page doesn’t have a main description, thus it isn’t apparent how you would use it with the NumberSequence type.

PathWaypoint

  1. This page doesn’t have a main description, thus its ties to the Path class aren’t apparent.
  2. Enum should be PathWaypointAction in the 2nd argument of the constructor and the PathWaypoint.Action property.

PhysicalProperties

  1. This page doesn’t have a main description, or indication of where its used.
  2. The first constructor’s argument type should be set to Material rather than Enum

Ray

  • The argument names in the constructor should use camel case?

Rect

  • This page doesn’t have a main description, or indication of where its used.

Region3

  • This page doesn’t have a main description, or indication of where its used.
  • The Region3:ExpandToGrid(number resolution) function is missing.
    It should return a Region3 that is aligned with the supplied resolution.

TweenInfo

  1. This page doesn’t have a main description, or indication of where its used.
  2. Enum should be EasingStyle in TweenInfo.EasingStyle and the constructor’s easingStyle.
  3. Enum should be EasingDirection in TweenInfo.EasingDirection and the constructor’s easingDirection.
  4. number should be int in TweenInfo.RepeatCount and the constructor’s repeatCount.

UDim

  1. This page doesn’t have a main description, or indication of where its used.
  2. The argument names in the constructor should use camel case.

UDim2

  1. This page doesn’t have a main description, or indication of where its used.
  2. The constructors on this page do not have any descriptions.
  3. The math operations on this page seem to be missing their math symbols.



    The top one should say UDim2 + UDim2 and the bottom one should say UDim2 - UDim2

Vector2

  1. This page doesn’t have a main description, or indication of where its used.
  2. The arguments in the constructor are optional, and should default to 0.

Vector3

  1. This page doesn’t have a main description, or indication of where its used.
  2. The argument type for Vector3.FromNormalId should be NormalId, not Enum.
  3. The argument type for Vector3.FromAxis should be Axis, not Enum.

19 Likes

#2

@polarpanda16 Take a look

0 Likes

#3

I was staying away from custom making a beam with a script, solely because of the wiki… lots of cases of :connect, and deprecated functions like :remove… it’s a very developer friendly area in some cases, but many it’s just not good… it can be daunting for new developers wanting to learn to script.

A new scripter could easily be told to use CFrame to move a model or part, yet then fail to understand the CFrame page, and get greeted with an eight word description, and a bunch of functions, properties and events.

EDIT: I was referencing the API Reference page, however the CFrame wiki page isn’t much better.

1 Like

#4

@CloneTrooper1019 Thank you for bringing these suggestions/issues to our attention! :slight_smile: I’ll take a look into all of them.

@MrCheezyPig I’m glad to hear feedback like this. This is something we’ve been addressing as we work our way through updating and improving API pages on the DevHub. Due to the size of the project (# of API pages), it takes time - unfortunately leading to many pages that aren’t yet up to par with our new standards. If it helps, :connect and :remove are cases we are keeping a specific eye out for as we update code samples and API pages.

1 Like

#5

If I can help, I would be glad to scout out some pages that don’t look quite right… Sometimes I see deprecated functions, or non FE scripts… I haven’t used the Wiki recently, because I found how useful the autofill thing for scripts is.

0 Likes

#6

You can file these as separate Documentation Requests thread through the post approval procedure described in the forum rules (rule 15.1).

1 Like

#7

In addition to getting another doc request approved (as buildthomas mentioned above) you can also PM me directly if you want to skip that step.

1 Like

#8

Alright… thanks, will do if I spot anything.

0 Likes