Finally we are getting this! I’ve wanted this for so long.
1 Like
It would also be nice to Use them inside of Type annontations like
type coolDict = {
-- do cool things
coolFunction : () -> nil
}
2 Likes
You can do it, you just need this small workaround:
-- Health Bar GUI Wrapper
export type HealthBar = {
Model : Model?,
CharacterController : CharacterController?,
GUI : Frame,
GUIContainer : Frame,
UpdateConnection : RBXScriptConnection?,
-- Creates a new HealthBar instance linked to a CharacterController or Model, optionally associating it with a specific GUI.
New : typeof(function(ControllerOrModel : CharacterController | Model, GUI : Frame?)
local healthBar : HealthBar
return healthBar
end),
-- Updates the displayed health based on the specified health value.
UpdateHealth : typeof(function(self : HealthBar, UpdatedHealth : number) end),
-- Sets a new character model to track and updates the health connection accordingly.
UpdateCharacter : typeof(function(self : HealthBar, Character : Model) end),
-- Toggles the visibility of the health bar's GUI container.
EnableDisable : typeof(function(self : HealthBar, value : boolean) end),
}
Default support would be great though, IMO this way doesn’t look as good, but it works just fine.
1 Like
User-Defined Function Documentation has to be one of the features of all time.
1 Like
Are module script function comments going to be implemented?
3 Likes
Thanks for the tip - and yeah - I have tried BlockLua by the same Developer (v2?)
It’s not as easy as it looks - still need to understand what you can use & where.
Guess there are no shortcuts with these CodeBlocks (lacks documentation) … and have better success with ChatGPT (as I learn).
Thanks tho.
1 Like
But where is the link itselfㅤ ㅤ ㅤ
3 Likes
These are some great features, but will there be a way to detect when a developer undoes or redoes an action within the Script Editor in the future?
1 Like
This is fantastic!
However, it would be nice to be able to put a strikethrough on deprecated functions like Roblox does with their deprecated ones in the auto-complete box.
So, if you have a whole big module system that many people use with many functions, it would be nice to let them know what NOT to use. Adding a deprecation message and a strikethrough to the function for the auto-complete box, would be lovely! 
For instance, it could be done like this:
--[[
-- Function description.
]]
local function dontusethisfunction(): (type checking stuff here)--
end
--[[
-- Function description.
]]
--<strikethrough>
local function dontusethisfunction()
end
--</strikethrough>
2 Likes
Never thought about that, that would be nice as well, since some variables do indeed have descriptions!
4 Likes
ngl it would be even better if non functions even had this feature
1 Like
Do you mean like variables? Well, there would be quite a mixed take on that I think, you will have some saying “That is a great idea” and you will have some that will say “Yes… But it would be quite messy. So no.”
I think it depends on how you give the description, so here’s an example of miss-using it:
-- This true or false value determines the state of the players characters collision with other players characters.
local value = true
Heres an example of using it correctly:
-- Determines Players Collision.
local value = true
So I honestly think it would work and STILL be tidy and clean if used correctly.
Also, forget to mention: There will also be some who will say, “This is pointless because you can just check what a variable does, that’s what the find feature is for.” or “This is pointless because as long as you named your variable right, a description is unnecessary”—and to that, I say, “What about module variables?” If someone is using your module, it would be nice to also give them a bit of description of what it does, regardless of name.
3 Likes
honestly i wanted this for the module variables to give them a description like this:
local module = {}
-- Fires when blah blah blah
module["OnEvent"] = {}
since it looks useful to explain them to someone whos new to your module
3 Likes
Indeed, that’s what I was saying, I completely agree with you!
3 Likes
Dont have access to bug reports, but __call metamethods don’t show function type tips and docs
local mt = {}
--[[
test
--]]
function mt.__call(self: any, meow: "mrrp")
end
local tbl = setmetatable({}, mt)
-- doesnt show the ui that shows the function args, and the functions doc comment
tbl()
Theres a function attribute for marking functions as depreciated, its just not implemented yet.
http://rfcs.luau.org/syntax-attribute-functions-deprecated.html
1 Like
This may be too petty of an ask to even be considered, but… Can the user-defined function documentation be made to ignore the leading double-hypens that are, by some people’s preference (including mine), included at the end of a multi-line comment?
For example, this…
--[[
Does all the things
--]]
function foo()
end
…produces this:
I’ve made multi-line comments this way forever and it kind of drives me crazy.
1 Like
I like how my functions show their descriptions and info about their parameters (which I made a habit of writing long before this update), but there’s one problem with it…
The tooltip includes line breaks, which are okay for separating the first line (which lists the function’s name and parameters, which is redundant, I know) from its description, but this also includes other line breaks, but I only add those to keep the full comment on-screen without having to scroll sideways.
This is what the tooltip looks like now; Note the random line break after “If” on its third line…
Obviously, that’s just the break in the comment, but again, if I remove that, the original comment goes off the right side, adding the scrollbar at the bottom of the script editor, which I don’t like, and try to avoid.
I wouldn’t know how this could be “fixed” without messing up other programmers’ comments that require intentional single line breaks like this, but it’ll be disappointing if the only workaround is to make my comments super long, or just accept the awkward line spacing in the pop-up.
1 Like
Are these tips going to work for dynamic loading of modules, too?
An example would be creating one’s own library handler, for example.
Example
Library simple code:
local Modules = {}
for _, module in pairs(script:GetChildren()) do
if not module:IsA("ModuleScript") then continue end
Modules[module.Name] = require(Modules)
end
-- Get module by name
local function GetModule(self: any, name: string)
return Modules[name]
end return {
GetModule = GetModule
}
After adding a module named “ModuleScript” inside the library handler
local module = {}
-- Can you see this?
local function thisIsTest(test: number)
end
return module
Adding a typeof() does not work (which is kind of expected I would say). It would be cool if there was a way to do this though.
