1. STEP 1 Make it What a package is, and how to write one
2. STEP 2 Check it Paste a repository, no account needed
3. STEP 3 Submit it Sign in, and it lists
4. STEP 4 Manage it New versions, and taking it down

1. Make it in the editor

   Open Window ⏵ 📦 Packages ⏵ ✚ Add ⏵ New Package. Give it an id and a name, and you get a folder that already works:

   packages/com.you.yourtool/
     package.ron       what it is, what it needs, what it may reach for
     editor/main.lua   runs in the editor
     scripts/          Lua your game can attach to nodes
     assets/           meshes, textures, prefabs, scenes, effects, shaders
     README.md

   The id is the identity. Reverse-DNS, at least two lowercase parts, something you control the front of: com.yourname.grasstools. It is what a dependency names, what pkg:// addresses resolve through, and what tells your grass tool apart from everybody else's. Pick it once. Whoever publishes an id first keeps it.

2. Build the thing itself

   Put editor tools in editor/, gameplay scripts in scripts/, and anything an artist would recognise in assets/. Press ⟲ Reload all after an edit and it is live in the editor, so the loop is as short as editing your own game.

   Keep the first one small. A package that does one thing well is worth more than one that does five things badly, and it is far easier to get right on your own machine.

3. Test it the way somebody else will get it

   Make a second, empty project and use 🔗 Link folder to point it at your package. Nothing is copied, so one edit reaches both projects, and you are testing the package rather than the project you happened to build it in. Almost every "works on my machine" package is one that never left the project it was born in.

4. Fill in the manifest properly

   package.ron is the only description of your package that anyone reads. The catalogue does not keep its own copy of any of this, it reads yours:

   (
       id: "com.you.grasstools",
       name: "Grass Tools",
       version: "1.0.0",
       description: "Scatter and paint grass on terrain.",
       author: (name: "You", url: "https://example.com"),
       license: "MIT",
       keywords: ["terrain", "vegetation"],
       engine: ">=0.55.0",
       permissions: [],
   )

   • description and keywords are what search matches on, and every word someone types has to match somewhere. Two good keywords are the difference between being found and not.
   • engine is a claim worth making on purpose. Leave it out and you are saying it works with every version there will ever be.
   • permissions are Network, Files and Browser, and they are shown to people before they install. Ask for nothing unless you need it: anything you do not declare is simply absent from your package's Lua.

   Every field, and the version-range syntax in full, is in the engine's packages documentation.

5. Put it in a public repository and tag it

   Installing is git clone, so your package needs to live somewhere anyone can clone from over https. GitHub is the path this site can check automatically today.

   git init && git add . && git commit -m "Grass Tools 1.0.0"
   git tag v1.0.0
   git push origin main --tags

   Tag it. A listing points at a revision, and a tag is what keeps version 1.0.0 installing the same code next year. Pointing at a branch means "whatever I pushed this morning", which is not a version.

   The package can be the whole repository, or a folder inside one. If it is a folder, note the path to it — that is the "folder" field when you submit.

   Starting from scratch is optional: copy the starter package and edit it.

6. Check it before you submit it

   Paste the repository and the tag into the checker. It reads your package.ron at that exact revision and tells you what the editor will make of it, line by line. No account, nothing recorded, run it as many times as you like.

   Check a package

7. Submit it

   Sign in with your Foverse account and submit the same repository and tag. A package that passes every check goes into the catalogue immediately, which means it is in Window ⏵ 📦 Packages ⏵ 🌐 Browse for everybody, that day. Anything that could not be checked automatically waits for a person instead.

   Publishing version two later is the same three fields and the same flow. Your listing keeps the id, and the description, keywords and engine range are re-read from your manifest each time, so fixing a typo there fixes the listing.

   Submit a package See what is listed

8. Look after it

   A listed package is yours to run. Your packages shows every one you maintain, what state it is in and why, and it is also in the account menu at the top of any page on this site.

   • Publishing a new version is the same three fields again. The id stays yours and the listing is re-read from your manifest, so fixing a typo in package.ron and tagging a release fixes the listing too.
   • Taking it down is one click, on a single version or the whole package, and putting it back is one click as well. Neither reaches into anybody's project: a copy that is already installed stays installed.
   • Nothing about the listing is edited here, on purpose. The catalogue has no second copy of your description to drift out of step with the real one.

   People who have your package installed and enabled can review it from inside the editor. You cannot delete a review, and neither can we for being unflattering — only for being abuse, and with a reason.

A note on what we do and do not do: the site never hosts your files. Your repository is the thing people install from, so you keep control of it, and taking your package down is a button on your own page. There is nothing to pay and nothing to sign.