When you say this in your description:

Update Roadmap
- Author column. Possible only once the API expands on LuaBootstrap.active_mods

Are you hinting that you know for sure that it's coming in the future?

If not, you could add mod-data to your prototypes so other mod authors could voluntarily provide information like the author name. (I'll explain how to use it if you don't know how.)

Since you'll only have a minority of author information available, it's probably not worth adding a whole column for it, but you could show the author name and mod description in the tooltip for the mod title.

As an aside, it would be nice to have title-ordered sorting with the official mods at the top, so the order is the same as the "Mods" interface in the Main Menu, but I know you're already working on that.

Also, do you need to list Modlist UI? It's technically correct to include it of course, but it's already mentioned in the footer. (And you could argue that listing "base" is redundant too.)

Are you hinting that you know for sure that it's coming in the future?

I guess I should have used "if", not "once", although I'm considering putting in an API expansion request on the forums for this very thing. Not sure to what degree it benefits having data stage information like this languishing around in runtime (aside from Modlist UI).

If not, you could add mod-data to your prototypes...you could show the author name and mod description in the tooltip for the mod title.

Was actually brainstorming this very idea already today. Currently developing a POC that would take in a scraped or manually collected set of
thumbnail, name, url-suffix-name, author and short description of the top-1000 mods from the mod portal, and display it in a nice tooltip.
My focus is to keep Modlist UI from being too bloated or impacting performance.

But if you're telling me that the very information used for the game's own mod-manager is still accessible somehow at runtime, by Modlist UI side-jacking the same process the mod-manager uses to read and load mods, then that would save me needing to brute-force-include mod-information piecemeal from the Mod Portal. Currently, everything I've researched points to only url-suffix-name/internal-name and version-number being easily retreivable.
I'd very much appreciate few pointers.

it would be nice to have title-ordered sorting with the official mods at the top...but I know you're already working on that.

hamster_wheel.gif

Also, do you need to list Modlist UI?...it's already mentioned in the footer.

Vanity, I know. I'll add in an exception during the loop :)

But if you're telling me that the very information used for the game's own mod-manager is still accessible somehow at runtime

No sorry, I don't think that's possible. It's provided by other mods on a voluntary basis. That being said, grabbing the top 1000 mods sounds like a good idea.

You put this in your data.lua:

data:extend{
    {
        type = "mod-data",
        name = "modlist-ui",
        data = {
            mods = { }
        }
    },
}

A third-party mod can run code such as this in their data-updates.lua:

data.raw["mod-data"]["modlist-ui"].data.mods["my-cool-mod"] = {
   title = "My Cool Mod: Recooled",
   author = "MrCoolGuy",
   description = "What if the whole world was cool?",
}

Then the list appears to you on the control.lua side via

prototypes.mod_data["modlist-ui"].data.mods

In general, you can use this trick to pass any data not normally visible in the Runtime stage out of the Prototype stage.

By voluntary basis being repeated, I'm going to assume that me "simply scraping and re-displaying" the same information as is on the Mod Portal is still frowned upon without consent because I could, technically speaking still alter it in between?

Providing a hook to find such mod-creator-provided info would be quite nice, I could add a little pictogram or something per entry in Modlist UI to prompt the user to convey there's more info when hovering over an entry.

I'm going to assume that me "simply scraping and re-displaying" the same information is still frowned upon without consent

No, it's all public metadata, I don't think any authors will have an issue with you using it. Obviously consult the website Terms of Service regarding the API before you go downloading things.

What I mean by "voluntary basis" is that if I don't put that special code in my mod, then you don't get to see it. I'm manually creating the information and passing a message from my mod to yours. It isn't automatically exposed anywhere.

So you should assume that the table will normally be empty, but if it does have an entry for a mod, then it should take precedence.

EDIT: I have a silly idea. You could dynamically declare SpritePrototypes with filename = "__mod-name__/thumbnail.png".

This would crash if any mod was missing a thumbnail, so you'd have to use an allowlist. (Not to mention it would bloat the sprite atlas.)

Awesome, I'll get to work then. ⚙️
Feel free to put such a hook/provision into one of your mods, that way I can test/iron out the precedence.

I added it to Rocks must Die, and changed the mod's title to be less "predictable".

In this example, I set the "thumbnail" field to a string, but I think that true should be a valid input as well. This would make it default to the predictable path of

__mod-name__/thumbnail.png

In the future, I highly suggest making yourself a debug mod that you can just throw random code into for when you want to do testing like this.

EDIT: I came up with an API suggestion that you might find interesting.

highly suggest making yourself a debug mod

Realized that a few minutes after my previous reply.

Modlist UI Assets is also up as a basic variant, not that it makes much impact here, but now I can work on both in parallel.

I came up with an API suggestion that you might find interesting.

Awfully kind of you, and suggesting a more flexible dynamic read/require is not something I would have considered. ✨

Edit: FAQ has a copy-pastable instruction set for 3rd party mods, give me a shout if strays too far from what you imagined.

You don't need these lines because you already checked for them:

  md.data = md.data or {}
  md.data.mods = md.data.mods or {}

I also came up with a sneaky shortcut version of the same code:

-- Copy/paste all of your info.json between the next two lines
local modJson = [[
]]

local md = data.raw["mod-data"] and data.raw["mod-data"]["modlist-ui"]
if md and md.data and md.data.mods then
    local modInfo = helpers.json_to_table(modJson)
    -- OPTIONAL: Comment out if you have no thumbnail
    modInfo.thumbnail = string.format("__%s__/thumbnail.png", modInfo.name)
    -- OPTIONAL: Strongly recommended so the thumbnail renders correctly.
    -- This must match the actual pixel size of the image file.  
    -- modInfo.thumbnail_size = 144                         -- ADJUST

    md.data.mods[modInfo.name] = modInfo
end

By the way, I assume you know about the Mod Portal JSON API? (which unfortunately seems to lack thumbnail info)

Browsing the portal, I estimate there are roughly 1,200 mods that are compatible with 2.0 that are "popular" (5K+ downloads).

EDIT: Also, your FAQ says this

Valid only after v. 2026.02.12 onwards.

That's the current version and it isn't implemented.

I assume you know about the Mod Portal JSON API?

Yep, JSON scraped the entire base >= 2.0 compatible mod info from the portal, chucked it into a blob over 44 thousand lines long. Tooltip now shows all fields populated nicely, no performance hit. Scraper can be leveraged to scrape all thumbnails too, these are already all at 144/288px, so thats easy to scale.

Have a look in the #mod-dev-discussion channel in the Discord if you want a sneak peek screenshot. There should be a thread.

Might not even need to go the hook + assets route. Scraper can be made to put a boolean has_thumbnail into the blob to help with defensive referencing and cleverly prototyping the specific assets I know the path of ahead of time from the very mods that are installed per user. Would save needing the entire FAQ + hook + Assets pack. Stay tuned.

Oh my god, I got it to work. No asset pack, no hook. Just needs crop-optimization. Update within the week.

Yeah, that was kind of what I was getting at when I posted this:

You could dynamically declare SpritePrototypes with filename = "__mod-name__/thumbnail.png".

Sorry if I didn't explain myself. Can I assume that the mod-data API is stable and start writing hooks into my mods?

Also, I am very new to Discord. I don't plan to use it very much, but I had a poke around to see if I could find what you were talking about. That was a wild ride. :o

Alternatively, I leave out base-mod things incl. space age and stuff, since @Shemp mentioned that it didn't make sense to list those things.

Just found this. What I said was that you should list them first like in the in-game mod browser.

Can I assume that the mod-data API is stable and start writing hooks into my mods?

You can remove the Modlist UI related voluntary-hook on your end entirely. Thats the beauty of what I managed now. Between that and the blob, all fields I wish to show now have data, without 3rd party input whatsoever.

you should list them first like in the in-game mod browser.

Thanks for clarification, will do.

Having seen your current work in Discord, I must admit that your new approach of pre-fetching the data is quite clever. (And it seems like FactorioPrints Browser uses the same strategy.)

However it does come with a caveat, which is that you would need to update the mod every week or month to keep it current. Although granted, any major update to Factorio is going to break your mod anyway.

If you were to disappear or get run over by a bus tomorrow, how easy is it to fork or succeed this mod? I'll note that FactorioPrints Browser does include the scraping tool with the mod.

For this reason, it might be wise to leave the mod-data declaration and priority mechanism in the mod, but not request other mods to use it at the current time.

I'll include the scraper with the next update. But it might also be worth putting a sticky-thread where I can collect a bunch of new mods that need a portal_blob update, or at least provide instructions on how people can add their own data to it.

I probably can't expect every new mod that is made to discover Modlist UI, and thus know to include the data declaration, but it certainly helps to have multiple ways everyone can ensure local currency/up-to-dateness.

As for forking, I mean, thats the easy part. Download the mod code and reupload it under your own name.

I feel more sorry for people that have to add a symbolic suffix to the end, like "Modlist UI Redux" or "Modlist UI 3.0" 😅
Not sure if the devs want to consider a "mod-ownership-transferral" mechanic on the mod-portal. Ngl, it'd be pretty intriguing.