completed first publish was having issues clicking so refreshed page and lost all progress
Viewing post in Blueprint — An Incremental Factory comments
That's rough, sorry. Losing your first publish is the worst possible moment for this to happen. Thanks for reporting it; this is exactly the kind of feedback that forces me to harden the save system.
A few things that could have caused it, in decreasing order of likelihood:
- The autosave window. Up through v0.9.4 autosave fired every 5 seconds. If you hit publish and refreshed inside that window, the publish result hadn't landed in localStorage yet, so the page reloaded the pre-publish state and then got clobbered by the fresh-state fallback.
- Cross-origin mismatch. If you played on the itch.io embed and then loaded the GitHub Pages build (or vice versa), those are two separate localStorage buckets. Same game, separate saves, and they don't follow each other.
- Private / incognito browsing or an overly aggressive "clear site data" setting will wipe localStorage on tab close.
- iOS Safari eviction. Safari can evict localStorage from sites you haven't visited in about 7 days, even without you asking it to.
Just shipped v0.9.5, which addresses 1, 3, and 4 directly:
- Rolling backup slot. Every save also mirrors to a backup slot. If the primary slot is ever unreadable, the game resumes from the backup, so you'd lose at most around 60 seconds instead of the whole run.
pagehidesave handler. The save-on-exit path now fires reliably on mobile (iOS Safari wasn't firing the oldbeforeunloadhandler on tab-swipe). Your work gets persisted the moment the tab closes, not 5 seconds later.- Persistent-storage request. The game now asks the browser to pin its storage so it's not evicted under low-storage pressure.
- First-play warning about saves being browser-local, with a pointer to Settings → Export for manual backups.
For now, the strongest protection is still Settings → Export. It gives you a base64 string you can paste into a note, email, or file. Two-second habit that's saved a lot of players from exactly your situation.
Again, genuinely sorry about the lost run. If the "having issues clicking" part was an actual UI bug (not just a slow moment), I'd love specifics: which button, what tier were you on, desktop or mobile? That might be its own fix.
The challenge banner (the pinned ⚠ CHALLENGE · NAME · timer · progress · ABANDON strip at the top of the factory view) was doing a full DOM replacement on every single render frame, about 15 times per second. Every one of those replacements destroyed and recreated the ABANDON button. If your cursor happened to be anywhere over the banner, the browser was re-evaluating cursor state 15 times a second, hence the hand/arrow flicker.
The "getting faster the more challenges I did" is interesting. My best guess is that the flicker itself was constant (15 Hz the whole time), but you noticed it more as you did more runs because the banner content was updating more visibly (schematic counter climbing faster, timer ticking, etc.). Or simply because once you see it, you can't unsee it. Either way, the underlying cause was always there.
Just pushed v0.9.6 with the fix. The banner now builds its DOM exactly once per challenge session and per-frame only mutates the text inside it. Button stays put, cursor stays put.
This bug dated back to v0.6.0 when the banner was first added, so thanks for being the first person to flag it. Live updates often hide this kind of thing from players because it doesn't feel like a bug, it just feels like the game is "janky" or "their computer's being weird." Much easier to fix once someone actually names the symptom.