DEV Community: Rocky

Three things that cost me an evening installing MOSS-Image in ComfyUI, and none of them was the model

Rocky — Fri, 30 Oct 2026 04:41:17 +0000

MOSS-Image is a 5B-parameter text-to-image model from OpenMOSS, released 16 October 2026 under Apache 2.0. It's a single-stream diffusion transformer, and the reason to care about it is layout control: you can tell it where things go, with bounding boxes or a JSON layout, instead of describing the composition in prose and hoping.

Everyone's writeup covers the interesting part — the layout control. Nobody covers the part that actually eats your evening, which is file placement. Here is what cost me the time, in the order it cost me.

The text encoders are separate files, and a missing one gives you garbage instead of an error This is the one that broke me. With a single-checkpoint model you drop one file in and you're done. MOSS-Image ships its text encoders as their own files, both of them required. If one is missing or mismatched, ComfyUI does not tell you a file is missing. It runs, and produces noise.

That sentence is the whole reason this post exists. When a tool fails loudly you fix it in two minutes. When it fails by producing plausible-looking garbage, you start suspecting your prompt, then your sampler, then your step count, and you've burned an hour before you go back and check whether the files are actually where you think they are.

Folder layout, for reference:

ComfyUI/models/

├── diffusion_models/ ← MOSS-Image checkpoint

├── text_encoders/ ← text encoder files

└── vae/ ← VAE, if distributed separately

Comfy-Org publishes a repack of the same weights already arranged in this structure. If you'd rather not think about placement at all, use the repack. The official OpenMOSS repo is the source of truth and is what you want if you care about getting the newest unmodified files, but you place them yourself.

It is a DiT, not a UNet, so your SDXL workflow does not transfer
I assumed I could take an SDXL graph, swap the loader, and be most of the way there. You can't. A single-stream transformer doesn't split work between separate text and image streams the way SD 1.5 or SDXL do, so the graph expects the model's own loader. Pair it with an SDXL checkpoint loader and you get an error that doesn't explain itself.
The node pack needs a restart, and "the node does not exist" usually isn't about the node
Install the node pack from the manager or clone it into custom_nodes/, then restart ComfyUI. A pack that hasn't been picked up on restart produces exactly the same error as a pack that isn't installed, which sends you looking in the wrong place.

Two more that bit me later, in descending order of wasted time
Variant mismatch. There are two: SFT (base) and Turbo (a LoRA, far fewer steps). The sampler settings differ. A Turbo workflow run against SFT weights gives you noise, not an image — and it looks the same as a broken install. SFT is better fidelity at 20–30 steps; Turbo is usable at roughly 4–8. I started with Turbo because I wanted fast iteration and then forgot which one I'd installed.

Starting with the layout graph. The layout workflow is the reason to use this model, so it's tempting to start there. Don't. Build the minimal text-to-image graph first — checkpoint, encoder, short prompt, 1024×1024 — and confirm you get a picture. When a complex graph breaks you cannot tell whether the fault is installation or prompt structure, and you end up debugging both at once.

What's actually good about it, once it runs
Layout control is real and it changes how you write prompts. Plan the arrangement first, then describe what goes in each region. If you write the descriptive prompt first and then try to force positions onto it, the two fight each other and the result looks like neither.

The 5B parameter count is modest, and that's the point at this resolution — it's fast enough to iterate rather than queue and wait.

I keep the fuller version of this — the exact file tree, both variants' step counts, and the layout workflow notes — at AI Handbook, linked here: aihandbook.app/tutorials/moss-image-comfyui-setup/ , updated in place when I get something wrong.

I built a Valheim seed tool that reads the seed straight out of your save

Rocky — Fri, 23 Oct 2026 02:24:10 +0000

The first ten minutes of a Valheim run are the most expensive ones. You pick a seed, you spawn, and only then do you find out whether the starting island has the resources you wanted. By that point you have already committed.
So I built a small tool that draws the map before you commit. Type a seed, get the map. That part is not novel — there are several seed viewers around. The part I actually wanted was different: reading the seed out of a save you already have.
If you have a world you have been playing for months and you no longer remember the seed, the world folder contains it. Drop the folder in and the tool reads the exact seed, then draws the map for it. It handles both .fwl files from before 1.0 and _main.N.fwl2 from 1.0. It also lists what it can find in the save — dungeons, altars, traders — so you can see what is left to visit.
Two decisions worth mentioning:
Nothing is uploaded. The save file is parsed in the browser; the file never leaves your machine. A world save is a personal thing and I did not want to be in the position of storing anyone's.
No account, no install. It is a static page. Open it, use it, close it.
Honest limits: it is a viewer, not an editor. It will not modify your world, and it cannot tell you whether a seed is "good" — that depends entirely on what you are trying to do (a speedrun start and a base-building start want opposite things).
It is free and it will stay free: https://valheimworldgenerator.com

I grade every game fact A, B or C before it goes live

Rocky — Tue, 20 Oct 2026 02:20:57 +0000

I once published a description of a feature that did not exist.

It was a small thing — a paragraph explaining that a tool accepted a URL parameter it had never accepted. Nobody complained. I found it myself, three days later, while reading my own page trying to remember why I had written it. The feature was plausible. It fit the rest of the product. I had clearly assumed it into existence somewhere between "this would be useful" and "this is how it works."

That was the moment I stopped trusting my own drafting process for factual claims, and started grading them.

Game guides are unusually good at generating wrong facts

If you write about a game, you are working with four sources that look interchangeable and are not:

The store page — price, release date, platforms, player count. Authoritative, but sparse and occasionally stale.
In-game testing — the truth, if you actually did it, on the build you actually ran.
Other guide sites — fast, plentiful, and frequently copied from each other, so "three sources agree" can mean one source repeated three times.
Community chatter — ahead of everything else and wrong maybe a third of the time.

The dangerous mix is 2 and 3. A number you measured yourself and a number you read on another fan site feel identical by the time they reach your draft. One is evidence. The other is a rumour with good formatting.

The three tiers

Every claim on the site now gets sorted before it gets published.

Tier A — hard facts. Checkable against a primary source. I write the source and the date I checked it, on the page, visible to readers.

What lives here: price, release date, platforms, player count, module counts, review score. All of it traces back to the store page or the store's API, with a re-check date attached.

The rule that actually matters: a Tier A claim without a date is not a Tier A claim. It is a memory. Prices change, platforms get added, review scores move. An undated fact is a fact about the past that the reader will apply to the present.

Tier B — how-to content. Needs at least two independent sources agreeing before it gets published as fact.

What lives here: solving rules, role techniques, which modules appear together on which level, timing behaviour. This is the bulk of a guide site, and it is where the copying problem bites hardest. Two sites agreeing is not two sources if one of them is reading the other. So "independent" is doing real work in that sentence — I have to be able to say where each of the two came from, and they cannot share an ancestor.

Tier C — unconfirmed. Not published as fact. Either left out entirely, or written explicitly as "unannounced" or "not confirmed."

This is the tier that took me longest to accept, because it is the one that costs traffic. Console release dates. Mobile crossplay. Per-level walkthroughs. Unreleased content. All of it is high-volume search demand, and all of it is speculation wearing a headline. The honest version of those pages is a paragraph saying we do not know yet, which ranks for nothing.

So most of Tier C simply does not get written.

What grading actually changed

Three things, in order of how much they surprised me.

The site got smaller. Fewer pages, shorter pages. Several drafts I was happy with got cut down to a sentence or dropped, because I could not get a second independent source for the part that made them interesting.

Errors got cheaper to fix. When a claim carries a tier and a source, a correction is a two-minute edit: change the number, change the date. When a claim is buried in flowing prose with no provenance, a correction means re-reading the whole page and wondering what else came from the same unreliable place.

"I don't know" turned out to be a usable answer. Not as a cop-out — as a labelled state. A reader who is told "this is confirmed" and "this is unconfirmed" can make their own call. A reader who is told everything in the same confident voice cannot.

The part that does not scale

Grading is slow, and it does not get faster with volume. Every Tier A number needs a re-check eventually. Every Tier B claim needs its two sources named. The maintenance cost is permanent, because the underlying facts move whether or not you touch the page.

There is a temptation to relax the rules once traffic arrives — to let a plausible number through because the page is already written and the keyword is already targeted. That is exactly the moment the tiers stop meaning anything. A grading system you override when it is inconvenient is not a system, it is a style.

The rules I use, including the exact wording of each tier and what falls into it, are written down on the site rather than kept in my head: the fact-grading rules in full. Publishing them turned out to be useful in a way I did not expect — it makes overriding them a visible decision rather than a quiet one.

If you write about anything with moving parts, the tiers do not need to be three, and they do not need to be mine. They need to be written down somewhere before the draft, not reconstructed afterwards.

I stopped writing guides for a co-op game and built solvers instead

Rocky — Sat, 10 Oct 2026 06:10:35 +0000

I play BOMBANANA! with two friends. It's a three-player co-op bomb-defusal game, and its entire design premise is that no player can verify anyone else's information. The three roles are labeled Blind, Deaf and Mute — one player can't see the panel, one player can't hear the sequence, one player can't say anything out loud.

We lost seven runs in a row on the same module. Not because we didn't understand it. We understood it completely. We were each reading our own version of it, differently, and by the time we agreed on what it said the panel had already moved on.

That's the moment I stopped writing guide pages.

A guide page assumes the problem is knowledge. You don't know how the module works, so you read about it, then you apply it. That model breaks here, because all three of us already knew how the module worked. The problem was that the three of us were holding three different fragments of the same puzzle, with no shared place to put them.

A guide can't fix that. A tool can.

So I built the site the other way around: instead of explaining each module, it resolves each one into a single action. You count the cables, read the LED, get the exact wire to cut. You combine the raised Braille number with the light color and get one arrow. The output is never a paragraph — it's one instruction, because that's the only thing that survives the moment of panic.

A few things I got wrong on the way, in case you're building something similar.

A static site was the right call, but not for the reason I expected. I picked it for cost and speed, which was fine, but the real win was that there's no account and no install. The defuser has one hand free and about four seconds. Anything with a login screen is already too slow.

The page that got used the most wasn't the clever one. I built a resolver that collapses a whole module into one action, and I was proud of it. But the page people actually sit on is a drill for reading Braille digits. The resolver assumes you can already read the input. Most of our failures were in the reading, not the resolving.

Sharing needs to be built in from the start. The drill pages accept a seed in the URL, so the same set of prompts can be replayed by someone else, and the result can be copied as a short challenge line. Without that, nobody has any reason to send the page to a teammate — and a tool nobody sends is a tool nobody finds.

The manual changes between patches, and that is the actual maintenance problem. Lookup tables go stale. I'd rather be corrected than be confidently wrong, so every page carries a note asking to be told when something is off.

If you're building for a game with asymmetric information, the shape I'd reach for is: same inputs as the game, one output, no accounts, shareable state. The content you'd normally put in a guide is still useful — put it next to the tool, not instead of it.

The tools are at https://bombananaguide.xyz/tools/ — the module resolvers are there, and the Braille drill I mentioned is linked from that hub.

It's a fan-made site for a game I just play badly. If a lookup table is wrong for your patch, tell me and I'll fix it the same day.

What actually mattered building a small SEO site from scratch

Rocky — Fri, 09 Oct 2026 06:10:15 +0000

For the last few weeks I've been building a fan wiki for a three-player co-op game — nine pages, English, no backend, no accounts, no CMS. It exists for one reason: when someone gets stuck and searches for the answer, this should be the thing that shows up.
I'm a developer, not an SEO person, so I wrote down what actually seemed to matter. Some of it is obvious in hindsight. Some of it surprised me.
A static site is not a compromise for this
The whole thing is static HTML on a CDN. I generate the pages in a build step and push a directory. There is nothing to scale, nothing to keep warm, and the pages load before anyone can decide to leave.
The reason I'd pick it again isn't speed, though. It's that there is nothing standing between the reader and the answer. No login wall, no cookie interstitial, no modal asking for an email. If a page exists to answer one question, then every click you add before the answer is a click that costs you the visit.
Structured data was the highest-leverage hour of the project
I added JSON-LD before I had a single visitor, which felt premature at the time. It wasn't.
Most of a page is written for a person. Structured data is the only part written for a machine, and if you don't write it, a machine has to guess what your page is about. It will guess worse than you would.
The other half is that almost nobody fills it in properly. That's not an advantage you have to be clever to earn — it's the one you get for doing the boring thing your competitors skipped.
For a page describing a game, that meant marking up the game itself, the organization behind the site, and the questions as questions — not as a heading that happens to end in a question mark.
Title, description and heading order are most of the work and none of the fun
Every page needs a title written for a search result, a description written to be clicked, and exactly one H1. This is unglamorous, and it is the bulk of the actual effort.
The one rule I'd pass on: write the outline before you write the page. If you can't list the H2s, you don't know what the page is about yet, and no amount of prose will fix that afterwards.
The surprise: being late didn't mean the topic was closed
We started about two weeks after the game launched. When I looked at the results page there were already a dozen sites covering it, several of them far bigger than us. My first instinct was that we'd missed it entirely.
Then I actually read the top results. Most of them answered the same first question and stopped. Sitting right next to it was a second question nobody had written up.
Being late to a topic is not the same as being late to every question inside it. A small site doesn't win the head term. It wins the sentence nobody else bothered to finish.
Tools get linked to. Pages don't.
This is the part that changed how I plan content.
A guide page, however good, is something people read and close. A tool is something people keep open, and occasionally send to a friend. If pages are your only asset, search is your only distribution. If you have one small useful tool, you get a second and weaker channel — people passing the thing around.
So I stopped planning more pages and started planning things that do something. The smallest interaction that turns "I think it says five" into "it says five".
What I don't know yet
I want to be clear that this is a process report, not a results report. The site has almost no visibility right now and I genuinely don't know whether any of it will work.
What I can say is that the checklist turned out to be short and unexciting. Static pages. One clear question per page. Real structured data. An outline before prose. Something interactive that's worth keeping open. Then wait.
There's no trick in there. That was the part I wasn't expecting.