An asset inspector + switch-without-stalling + Windows support

After release, turning to polish

Open-sourcing handed the project to the public, and the real test begins the moment it's handed over — more people, more varied computers, more critical eyes will expose every spot that isn't smooth or stable enough. This day was the turn after release: not chasing dazzling new features but settling down to polish the existing experience smoother and harden the foundation steadier. The asset inspector lets creators clearly see every material in hand; stall-free switching removes the most frequent hitch in daily use; Windows compatibility lets more people in the door; engine self-healing keeps accidents from easily interrupting people; and load-time contract checks keep the AI's code edits from escaping with errors. Individually small, these all target "is it actually smooth and stable to use" — exactly what a project just stepping into public view should reinforce immediately. A first impression happens only once, and every bit of polish after release guards it.

An asset inspector: see every asset clearly

The editor gained an asset inspector panel this day, covering every kind of asset in a project. It addresses a basic yet long-missing need: when your project piles up a lot of materials — meshes, materials, textures, animations, scenes — how do you quickly see what any one actually is? Previously you often only saw a name, and to know its look and properties you had to actually place it in a scene. Now select any asset and the inspector on the right gives a kind-appropriate preview and details: pick a mesh and see its shape, a material and see its texture quality, a texture and see the image, an animation and see its info. A "content browser" was also linked to the material panel, forming a coherent flow from browsing to viewing to editing. The significance for creators is "knowing what you have" — a somewhat larger project easily holds dozens or hundreds of assets, and being able to open and clearly see each one keeps you from groping among a heap of vague names, raising the efficiency of managing and reusing materials.

Switching without stalling: keeping the render context alive

This day fixed a long-tormenting and, in daily use, extremely frequent old problem: the stall on switching. Previously, whether switching between different scenes or flipping between "edit" and "play" modes, the system tore down and rebuilt the whole underlying graphics rendering — a black flash, a re-initialization, and at its slowest an outright freeze. The root cause: each switch rebuilt the render context, and rebuilding a graphics context is a fairly expensive operation prone to errors in certain browser environments — the more often you switch, the more likely it breaks. This day's solution is "keep-alive": switching no longer tears down and rebuilds but keeps the render context alive in the background (moved off-screen rather than destroyed) and reuses it directly when needed. Switched to in-place, flipping between scenes and between edit and play becomes smooth and instant, with no black screens or stalls. For a creation tool that encourages you to repeatedly "tweak, glance, tweak again," switching is one of the most frequently triggered actions; turning this path from "rebuild every time" into "instant switch anytime" directly removes the most obstructive hitch in the creative flow.

Cross-platform: a batch of Windows fixes

Now that it's open source and wants as many people as possible to use it, Windows had to be tackled. This day swept a batch of Windows compatibility issues, all the typical kind of "fine on another system, inexplicably broken on Windows" pitfall: the way to tell whether a process is still alive needs a different approach to be correct in the Windows terminal; the symlinks created when making a new project hit permission limits on Windows, sidestepped with a native Windows equivalent; and environment-map (HDR format) decoding was fixed on Windows too. Startup scripts were hardened for cross-platform use alongside. Each problem is inconspicuous, but a single unsolved one could block a Windows user at install, project creation or first run, bouncing them outright. Getting this whole path, from install to running, working on Windows throws the door open to the Windows users who hold most of the desktop market — and for a just-open-sourced project eager to be tried by more people, this step's practical significance is especially large.

Engine self-healing: recover from device loss, degrade gracefully under limits

The engine advanced a big step on "withstanding accidents" this day. One is device/surface self-healing: a graphics device can suddenly drop during operation for various reasons (system resource pressure, a driver reset), which previously often meant the screen went black with no recovery; now the engine detects such a drop and attempts to automatically re-establish rendering so the picture comes back, rather than dying. Two is graceful degradation under limits: in some weaker browser environments, the engine's probe of video-memory capacity may not get an accurate value, and this day it falls back to a safe default ceiling when it can't; and when content to render exceeds capacity, it now "renders a truncated subset" rather than skipping the whole frame, preferring to draw a little less over crashing the whole picture; low-level crashes were isolated into recoverable errors too. The shared theme is "resilience": an engine meant to face all sorts of real devices and be used for long stretches by ordinary people can't assume everything is perfect; the mark of true maturity is that when imperfection happens, it withstands, recovers, and keeps working at a reduced level, rather than going on strike at the first accident.

Load-time contract checks + scene writeback

This day added another safeguard to the "AI writes code" line: load-time contract checks. When loading a game, the system automatically verifies that the game code lines up with the engine's interfaces — a "contract" being the calling conventions the engine prescribes; if, after the AI edits code, some spot misuses an interface or cross-file interfaces don't match, the system points out this "drift" directly and prominently in an on-screen error overlay, rather than crashing inexplicably partway through. This effectively sets another automatic checkpoint between "finished writing" and "running," catching interface-level errors on the spot. Meanwhile, the engine completed scene "writeback": it can serialize the current scene's contents into a structured asset pack and look up the identifier in reverse from the contents. This lays the underlying foundation for the loop of "edit in the editor and save it right away" — editing isn't just viewing and tuning; changes must also reliably persist. These two, one after the other, both make "the products of creation" more reliable: ensuring the code lines up and that editing results are saved.

Terminal checkpoint rewind + multi-agent collaboration touches

This day the command-line / terminal version gained capabilities matching the graphical interface: checkpoints and rewind. You can roll a conversation back to an earlier checkpoint and retry, backing out if unsatisfied; session recovery was added — after an interruption, one command resumes where you left off, no starting over; plus an overlay for asking you questions. The chat interface kept polishing the live details of multi-agent collaboration: when a sub-agent hands a task to another, a clear relay header shows the handoff relationship; related agents are grouped by "producer family," each in their own category; sensitive operations needing your call got a dedicated permission-confirmation card; and agent avatars were slightly lifted and enlarged to make "who's active, who's waiting on you" clearer at a glance. These together serve one thing: when you direct a team of differently-tasked AIs to collaborate, the whole process must be clear, controllable and always rollback-able — you understand what they're doing while keeping the initiative to halt and rewind.

What this day means

If the previous day's open-source release was "open the door and invite people in," this day was "tidy the house so people are comfortable living in it." It had no earth-shattering new feature, all polish and hardening throughout: letting you clearly see every asset, keeping switching from hitching, letting Windows users in the door, helping the engine withstand accidents, keeping the AI's code from escaping with errors, making multi-agent collaboration clear and controllable. What these all point to is "usability" and "reliability" — exactly the two things a project just welcoming a flood of new users most needs to reinforce at once. New users won't stay for some dazzling feature but may well turn away over a single stall, a single crash, a single failure to run on Windows. Solving these unremarkable experience and stability issues one by one looks plain but is really tamping the foundation firmer for the real usage that follows open-sourcing. Release is a starting point, not an end; this day was the start of taking "actually being used by people" seriously.