The user defined function docs will help me so much. I now no longer have to scroll up to the function to read the docs and back down to where I was at.
1 Like
The custom function documentation is absolutely amazing, this is going to make understanding old functions so much easier. Currently my only problem, and I’m not sure if this is a bug, something not yet implemented, or if I’m just doing something wrong, but if a comment spans multiple lines, then there will be a line break in the tool tip at each of those lines. I realize this is most likely intentional to expand formatting options, however it’s annoying when you have a single idea that spans multiple lines.
Here’s an example with a function from a module I wrote awhile ago.
--[[
This function creates a confetti effect at the given location (originPoint)
according to the settings provided to confettiInfo, which must be a ConfettiInfo
created using Confetti.NewInfo. All of these parameters are required, they do not
have any defaults
]]
Confetti.Create = function(confettiInfo: cTypes.ConfettiInfo, originPoint: UDim2): nil
--Stuff here
end
When the comment is displayed in the tool tip, it doesn’t fill the horizontal space, instead going down to a newline at each point the comment does. Although I could make the entire comment occupy one line, this would be annoying to read anywhere other than the tool tip.
Apologies if this is already a feature I missed, but some way to force multiple lines of the comment to display as a single line in the tool tip would be absolutely amazing.
moonwave is dying out due to it’s lack of customization and just not doing what you want it to, static site generators like mkdocs or vitepress are miles better and also don’t require all the comment trickery in your code (not to mention the entire moonwave generator breaks if there’s 1 single issue)
1 Like
Moonwave is not dying out, and it is already extremely customizable with the power of Docusaurus. MKDocs and VitePress suffer from requiring API Documentation to be isolated from the code, making it harder to maintain and lack integration in tooling like hover documentation unless you maintain two separate API documentation, which is redundant.
If you are experiencing an issue with Moonwave, you should also either report it on the GitHub repository or in the ROSS Discord channel, help is always quickly available. Moonwave is stable and working in lots of open-source libraries, issues are rare and often easily solvable with assistance.
2 Likes
This is cool, but can we get support for the markdown syntaxes for these since that would be more cross-compatible with other editors?
1 Like
I tried Moonwave and Rojo for my most recent project. I decided to not adopt either. It’s good for utilities if you were already using the documentation style specific to Moonwave. As I do bespoke manuals alongside thorough Lua documentation (using Affinity Publisher 2 and ROBLOX’s Script Editor), I’ve found no tool can automate that process for me. It’s extra time spent, but it’s worth that extra mile to me. The new tools ROBLOX just added empower me to strive for more, and all I want to see is it get even better.
I want there to definitely be more features of ROBLOX’s new documentation features. And I’m already getting good results with the adoption and integration of the new user-defined documentation features. I converted a script most in need of this feature in my project to using HTML tags and the new features.
The way I’ve settled into doing things is to have a single-line comment to for a rough overview of the function that developers scrolling past can see, and a multi-line comment to have a detailed breakdown of the parameters underneath. It gives some redundancy of the documentation for functions with simple signatures, but helps with larger functions in my case:
I am absolutely going to be converting my projects to utilising this feature as I’ve found it’s extremely powerful already with the use of HTML Tags and careful wording. We’re looking to get things fully migrated over for Winry 4.3 (Raphtalia) to make developer onboarding navigation much easier.
4 Likes
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>
1 Like
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
2 Likes