Every version, and what changed in it.

The second beta of v0.94.0. Everything in rc1 — particles that squash and stretch, the Animating tab's curves — plus trails behind anything that moves, and four things a multiplayer game and a headless check found wanting.

Trails

A particle trail records the particle's own motion, which is nothing for a particle sitting still on a moving node — and a sword trail is exactly that. Every trail now has follows the emitter (under the trail row in the Inspector): the ribbon is recorded along the node's path through the world, so one still particle at a blade tip leaves a sword trail, a wing tip a streak, a wheel a tyre mark — all in one effect asset, no script. It is depth-tested like every particle, so a trail behind a pillar stays behind it. The Particles tab's ∞ sweep moves the preview through a figure-eight so you can see it, and a world-space track or inherited velocity, without leaving the tab.

For a ribbon in the blade's own plane, scripts have draw.quad: one textured quad in the world, depth-tested, blended with the image's alpha, visible from both sides. Give it four corners, a colour and a slice of a streak texture per segment, and a ribbon between two marker nodes is a dozen lines — floptle api draw.quad has the copyable one.

A spawn survives a scene change

The server's scene.load tells every client to load the same scene, and each takes its own time over it. Anything the server spawned in the new scene meanwhile — the player rigs a scene.onLoaded handler spawns on the very next frame — was dropped by a client still loading, and never re-sent: the first rig after every map change was missing on someone, and which one depended on who joined first. Those spawns are now held through the swap and applied the moment the client's load finishes, in order. No warm-up spawn, hold timer or "ask for a body" call is needed any more; docs/multiplayer.md says what you may assume.

Headless checks that tell the truth

floptle run --join keeps real time. A joined run is a client of a server ticking on the wall clock; stepping as fast as the CPU allowed sent an input clock the server watched race ahead until it dropped the peer, while the client believed it was still in. Each step now waits for its tick, so a client run stays connected for the whole --seconds.

floptle shot tells its scripts the picture is the viewport. From the first update, camera.exists() is true and camera.screenRect() is the --size you asked for, so a HUD that sizes itself from the screen can be checked at 1440p, an ultrawide or a portrait window without opening a window. floptle run renders nothing and still reports no camera.

floptle serve passes every flag it takes. --status-file, --max-players, --lobby-code and --script-budget-ms were accepted on the command line and dropped on the way to the server. They arrive now.

Upgrading

Nothing to change. An effect written before this release has no emitter-path trail and draws as it did; a game's scene-change workarounds can come out at your leisure.

Switch the Hub to the beta channel to install this build.

The first beta of v0.94.0. Particles squash and stretch, the Animating tab has a curve view and keys that ease, and the editor's biggest functions are now outlines you can read — verified frame-for-frame against the previous build.

Particles squash and stretch

Every particle track has a squash property, under 📈 Over each particle's life in the Inspector next to size. It keeps the particle's area while changing its proportions: the width is multiplied by the value and the height divided by it. Above 1 flattens, below 1 lengthens, and a curve from 0.6 through 1.4 back to 1 is the classic pop — a drop that lands, a coin that bounces. Like size and colour it animates over each particle's life, can be randomised per particle with 🎲, and has its own lane on the timeline. A mesh particle squashes the same way along its own axis.

A velocity-aligned billboard also stretches + by speed: extra length per unit of speed, so a fast spark draws a long streak and a slow one stays a dot, where before every particle on the track was stretched the same.

And a new emit shape, box: particles are born anywhere inside a box of the size you give — rain over a field, dust through a room, snow. The emitter gizmo draws its outline.

Particles fade where they meet the scene

A sprite crossing a floor or a wall was cut along a hard line, the one tell that a puff of smoke is a flat picture. Each particle now fades over the last few world units in front of whatever is behind it — soft edges under 🎨 Look, 0.5 by default, 0 for the hard cut.

The Particles tab fits its panel: fields sized to the width, a random range on two lines, forces as labelled rows, and the selected clip as its own section under ✳ Emission with a pool you can set. A looping effect whose particles outlive the loop no longer refuses every second generation's births. An effect is named by its file, so a renamed file is a renamed effect.

The Animating tab: curves, easing, packed rows

The dopesheet says when; the new 📈 Curves view (Tab) says how much and how fast. A node's position, rotation and scale are drawn as values over time, sampled through the same tracks the game plays, so what you see is the motion you get. Every key is a point on its curve: drag it in time and value, right-click empty space to key a lane there, right-click a point for its interpolation. Rotation is drawn in degrees as one continuous line, without the fold at 90° that Euler angles usually produce.

Right-click a key → ↗ Interpolation now offers Linear, Smooth (a spline through the neighbouring keys, so the motion has no corner), Ease in, Ease out, Ease in-out and Hold; with several keys selected the choice applies to all, and the key's shape says which. A node's row opens with ⏵ into its position, rotation and scale lanes, each key editable on its own lane. With a snap grid set, the ruler counts in frames.

Rows run from 4 to 80 px, typed in the toolbar or Alt+wheel, so a large rig fits the panel; a 🔍 rows filter shows only the rows whose name matches.

Under the hood

The editor's largest functions — the frame loop, the Inspector, the timeline, the material and post-processing editors, the Play step, the network tick — are now short outlines that call one function per phase. Every move was checked against the previous build: floptle shot and floptle run on five projects give pixel-identical pictures and identical reports before and after. Comments across the workspace say what the code does today.

floptle shot draws particles textured, as the live frame does. The passes that read the depth buffer — ambient occlusion, depth of field, motion blur, 2D lighting, soft particles — and authored post shaders build on OpenGL.

Upgrading

Nothing to change. A particle effect written before this release has no squash, no speed stretch and its old shapes, and draws as it did. An animation clip's holds load as Hold keys and are saved in the new form.

Switch the Hub to the beta channel to install this build.

A patch for a bug that has been in the sky for a long time: while you look around, a wedge of the sky would flash a flat colour for a single frame — a straight-edged slice, usually at a corner or side of the screen, cut off exactly at the horizon. It happened far more often while the camera was moving than while it was still, and it was over before a screenshot could catch it.

What it was

The renderer built each pixel's ray as the line from the near plane to the far plane. With a far plane hundreds of thousands of units out, the far point sits at the very edge of 32-bit floating-point precision — and for some camera poses, the rounding tipped over along a straight line across the screen. Beyond that line the direction came out as not-a-number, and a sky shader given no direction painted its bare horizon colour. Every camera pose had its own line, or none; looking around visited many poses a second.

The ray now runs from the near plane to a point halfway down the depth range. It is the same line, without the precision cliff at the end of it. On a test rig that swung the camera around a project continuously, the flash appeared 156 times in eleven thousand frames before and not once in ten thousand after.

Also in this patch

floptle shot never compiled a project's Sky shader, so every picture of a scene with a procedural sky showed the flat Skybox colour instead. It draws the sky now. The shot verb also takes --frames N and --turn DEGREES to photograph a sequence while the camera sweeps, and FLOPTLE_FRAME_DUMP=<dir> writes every frame the editor or a build presents to that directory — the tools that caught this bug. See docs/export-builds.md.

Upgrading

Nothing to change.

A character stands where it looks like it stands. This release closes a report that survived two patches: a character hovering over terrain and clipping into slopes, on a project where every collision measurement said the ground was under its feet.

A body under a group node is drawn where it is

The cause was not the terrain. A physics body is placed from its node's world position, and the sim wrote that position straight back into the node — but a node's position is stored relative to its parent. A body at the scene root was fine. A body under a group node was displaced by the group's whole transform every frame: its model, a child drawn where the node says, stood beside and above the capsule the collider was resolving. On a project whose player sits in a group placed 0.6 units up and two units aside, that was a character hovering exactly 0.6 over flat ground and walking into every slope by two units, while the collision itself was right to the millimetre.

The sim now writes every body and assembly back in its parent's frame. A parented character stands on its capsule, wherever its group is.

See exactly what you collide with

Terrain physics has collided with the triangles you see since v0.92.1, at any voxel size and node scale — but the tools for checking that were wrong. View ▸ Terrain collider wireframe drew a coarse proxy of the field, a surface nothing collided with, in the wrong place for a moved, turned or scaled terrain. It now draws the exact surface physics uses, through the node's full transform: turn it on and the lines lie on the ground. And the ◆ Rigidbody outline draws the live body during Play, so a controller that sets its own stand height no longer leaves the outline floating above where the body meets the ground.

Choose the surface

The terrain node has a collide with picker in the Inspector: the drawn surface (the default, and what every existing scene gets) or the field — smoother than the picture, cheaper, and never meshed, for a server that draws nothing or a project tuned against it. It takes effect on the next Play.

Capsules stand on their feet, along their whole length

A capsule's round bottom touches a slope off to one side, bridges a crease and coasts off a crest, leaving the feet you drew in the air on rough ground. Capsule bodies now stand on the ground straight beneath their centre line, pushed up out of it and held down onto it while standing — following crests and stairs instead of hopping — with jumps, walls, cliffs and ledges untouched. And a capsule collides along its whole length rather than as its two end spheres, so legs no longer sink into a steep face.

floptle shot draws the terrain

The shot verb photographed a terrain project with no ground in it: the field loaded and the character stood on it, but the ground is meshed by the frame loop and a one-frame verb has none. It meshes the ground around the camera before it draws now.

Upgrading

Nothing to change. A character whose model was nudged to compensate for the group offset will now sit low by that nudge — remove it. A project that relied on a capsule coasting off a crest will find it follows the ground.

The second beta of v0.93.0. Terrain collision is now something you can see, and choose; and a capsule collides along its whole length.

See exactly what you collide with

Terrain physics has collided with the triangles you see since v0.92.1, at any voxel size and any node scale. Measured on a real project through the live player, a walking character's feet sit on the drawn surface to within a few millimetres on nearly every tick, and nowhere near the underlying field.

But you could not check that for yourself. View ▸ Terrain collider wireframe drew a coarse proxy of the field — a surface nothing collided with — in the wrong place for a moved, turned or scaled terrain. It now draws the exact surface physics uses, through the node's full transform. Turn it on and the lines lie on the ground, or something is wrong; a screenshot settles it.

The ◆ Rigidbody outline had the same problem during Play: it drew the capsule as authored, while a controller that sets its own stand height had changed the live body and moved its centre to keep the feet planted. The outline sat a hand's width above where the body met the ground, and anything lined up against it lined up wrong. It draws the live body now.

Choose the surface

Some projects want the old behaviour: the underlying field is smoother than the picture, cheaper to query, and never meshes anything — a server that draws nothing, or a project whose physics was tuned against it. The terrain node has a collide with picker in the Inspector: the drawn surface (the default, and what every existing scene gets) or the field. It takes effect on the next Play, and the wireframe follows the choice.

A capsule collides along its whole length

A capsule was tested as its two end spheres, so a face steep enough to reach a character's shins between the feet and the head let the legs walk through it, and a crouching body could put its waist through a low wall. The point of the capsule closest to each surface is tested too now.

Also in this beta

Everything from rc1: capsule bodies stand on their feet — the ground straight beneath the centre line — following crests and stairs instead of hopping, with jumps, walls, cliffs and ledges untouched; and floptle shot draws the terrain, which it never had.

Upgrading

Nothing to change. A scene written before this release collides with the drawn surface, exactly as it did on v0.92.1 and rc1. A character walking along a steep face may now be pushed out of it where its legs used to sink in.

Switch the Hub to the beta channel to install this build.

A character on terrain now stands where it looks like it stands. This is a beta: it changes how every capsule body meets the ground, so it goes out on the beta channel first.

What was wrong

After v0.92.1 the terrain collider matched the picture to a few millimetres — and a character still hovered over a rough hillside, and toed into it. The collider was not the problem any more. The shape was.

A capsule has a round bottom. On a slope, a sphere touches the ground off to one side, so the point straight under the centre — where the character's feet are drawn — hangs above it. In a crease it bridges the two sides and the feet hang over the bottom. On a bump it perches. Walking over a crest, it coasts off the edge and lands some way down the far side. On a coarse terrain, where one voxel is several units across, those creases and bumps are everywhere.

Measured while walking a character around a real project: the feet floated more than five centimetres off the drawn ground on one tick in five, and by up to a third of a unit.

What changed

Capsule bodies stand on their feet: the ground straight beneath the centre line. A body is pushed up out of the ground under its feet, and pulled down onto it while it is standing — so it follows a crest instead of hopping off it, steps down a stair instead of coasting past it, and walks up a ramp onto a flat top without being launched. A jump is untouched: leaving the ground under your own power is exactly what the feet do not interfere with.

Walls, cliffs, slopes past the body's slope limit and ledges still meet the round bottom exactly as before, so a character still hangs by its rim at an edge and still slides off a face it cannot stand on. Moving platforms count as ground too.

There is nothing to set. Every capsule, in every project, stands on its feet. Spheres roll on their curve as they always did.

Measured on the same project afterwards: the feet sit within two millimetres of the drawn ground on nine ticks in ten and within seven on ninety-nine in a hundred, and the only ticks more than five centimetres off are the landing itself.

floptle shot draws the terrain

The shot verb photographed a terrain project with no ground in it: the field loaded, the collider was live, the character stood on it — and the picture showed it standing on the sky, because the ground is meshed by the frame loop and a one-frame verb has none. It now meshes the ground around the camera before it draws, and says so if it could not finish in time.

Upgrading

Nothing to change. A character that was tuned to sit right on rough ground may now stand a few centimetres lower on slopes and in creases; that difference is the correction. A game that relied on a capsule coasting off a crest will find it follows the ground instead.

Switch the Hub to the beta channel to install this build. Once it has been played, it will be promoted to stable as v0.93.0.

A patch for v0.92.0's terrain collision. It said the ground matched the picture. It did not yet — and on a scaled-up terrain the gap was over a metre.

What was wrong

v0.92.0 measured collision against the triangles you see, but decided which side of them you were on by asking the underlying field. Those two surfaces disagree by a fraction of a voxel, and the side is what decides where a body comes to rest — so a character still settled on the field, exactly as before, and the triangles only changed how far away it thought the ground was.

A fraction of a voxel is small until the voxel is not. On a terrain built at a 1.5-unit voxel and scaled up five times, one voxel is 7.5 units across, and the measured gap between where you stood and where the ground was drawn reached 1.15 units — a knight hovering a shin's height over flat ground, and up to his ankles in a slope a few steps away. Both directions on the same hill, and worse the bigger the terrain.

What changed

Collision now decides the side from the drawn surface itself, using the same normals the picture is lit with. On the same terrain the gap is 0.005 units.

Raycasts land on the drawn ground too, which is what a character controller's ground check actually uses: a ray cast at a scaled, rotated terrain stops on the triangles you see, not a voxel above or below them. Digging and sculpting are unaffected, and the cost is unchanged from v0.92.0.

Upgrading

Nothing to change. If a character or a prop was tuned to sit right on v0.92.0's ground, it may now sit a little higher or lower — that difference is the correction, and it is the same everywhere rather than varying from place to place.

Ten things that were quietly not true. The ground you walk on is the ground that is drawn. Fog can be dark. The Console keeps talking after the second time you press Play. And the scripting guide is a set of chapters instead of one very long page.

The ground matches the picture

Terrain collision was measured against the underlying field, and the terrain you look at is triangles extracted from that field. Those are two different surfaces — the triangles cut across every curve, inside a bulge and outside a hollow — so a hillside you could see solid in front of you let you sink into it, and a dip you could see beneath your feet held you above it. The same model, in both directions, on the same hill, which is why it read as collision being vaguely wrong rather than as an offset you could learn to expect.

Physics now collides against the triangles you are looking at, and asks the field only which side of them you are on. Measured on rough ground at a half- unit voxel, the old answer was out by up to a fifth of a voxel where the terrain is busiest — and it scales with the voxel, so terrain authored coarse was out by more. Digging, sculpting and terrain.* from a script are unaffected: the surface is remeasured the moment the ground changes.

Fog can be dark

Fog tinted surfaces and left the background alone, which reads as fog only while the fog colour is close to the sky's. Pick anything darker and the distant hills turn to silhouette against air that has not moved: the geometry visibly changes and the fog is nowhere. There was a hard seam at the horizon in every foggy scene.

The distance fog now reaches the sky, weighted toward the horizon so a painted skybox survives overhead. Lighting ▸ fog ▸ takes the sky is how much, and 0 is the old surfaces-only look if a scene wants it. A night fog, a cave haze, a dust storm at dusk — all of them are a colour you can now actually pick.

The Console keeps talking

Press Play a second time without editing anything and the Console went silent. Every diagnostic the engine writes is deliberately said once and then held back — sixty identical lines a second is how a Console stops being read — but the suppression was keyed to the file, not to the run, and pressing Play clears the panel. So the second run emptied the Console and then refused to refill it.

Worse: a script stopped for overrunning its time budget was held back "until its file changes", and after a Stop there was nothing left to change its mind. It never ran again for the rest of the session, and nothing said so.

Every run now starts with a clean slate. A script that cannot load says so on the first frame of every Play; a lookup that finds nothing explains itself again; a script the budget stopped gets another go.

node.scripts

node:getScript("name") answers nil when the name is wrong — and nil is also what "no such node" and "not running yet" look like. The plural is the thing you actually want first:

for _, s in ipairs(node.parent.scripts) do print(s.kind) end

Every script on a node, as handles, in the order they were attached. Possibly empty, never nil.

Posing a model without losing it

Locking the selection exists so a stray click cannot take you off the thing you are working on — and posing is exactly when you want that. But the lock swallowed bone clicks too, so it could not be used with the Animating tab at all. A bone of the held model is part of that model, not a way out of it: those clicks land now, the model stays selected, and its rig stays on screen. A bone belonging to some other model is still refused.

Keyframes that hold, one at a time

A clip could be stepped or smooth, whole. That is not what stepped animation is: it is a clip that holds each pose and snaps on the beats the animator chose, with the odd move eased through. The only way to get a hold in the middle of a smooth lane was to key the same value twice and hope nobody retimed it.

Right-click any key in the Animating tab → ⇥ Hold until next key. It is per key, on transform and property lanes alike, and the lane's own setting is now the default for keys that have not been told otherwise. A clip that does not use it is unchanged, down to the bytes its file is saved as.

Terrain textures: the real picker, and a scale each

The texture slots in the Terrain tab had a plain dropdown listing every image in the project in tree order — no search, no folders, no thumbnails — while every other texture field in the editor had the full picker. They all use the same one now.

Each slot also gets a ▦ × control: how often that texture repeats, relative to the rest of the palette. A fine gravel and a broad rock face only look like the same ground if one of them tiles several times as often, and until now the only way to arrange that was to resample the image.

The edge of the picture keeps up

With motion blur on, a fast camera swing left a band around the edge of the frame that stayed sharp while everything inboard of it smeared — worst on the sky, which is at infinity and so the fastest thing in any pan, and gone the instant the camera stopped. Blur samples that fall outside the frame are dropped now instead of folded back onto the border pixel.

The scripting guide is chapters

The guide was one page of thirty-seven sections — findable by searching for a word you already knew, and no use at all for the thing you did not know existed. It is eleven chapters now, each a page of its own: Start here, Nodes & the scene, Physics, Input, Assets & materials, Animation, particles & sound, Maths & the world, Multiplayer, Data, time & the outside world, Steam and Working in the editor.

The same chapters are in the editor — Scripting ▸ § Docs ▸ 📖 Guides — with the contents down the left and one page at a time, instead of twenty-four collapsing headers in a single scroll. Section numbers have not moved, so the engine's own messages still point where they always did.

Every call that can fail says how

A reference that names a second return value and then never mentions it again is not something you can write error handling against. Every call that hands a script an error now lists what fills it — all four assets.read* / write* calls, json.decode, and every steam.* call — and the reference will not build without it the day a new one is added.

Upgrading

Nothing in a project needs changing. Scenes saved by this version gain a fog setting and, if you use them, per-key animation holds; both are written only when they differ from the default, so an untouched project's files do not move. Scenes from earlier versions open with the fog reaching the sky — if a scene was built around the old seam at the horizon, set takes the sky to 0.

A script can read and write its own data files now. A rhythm chart, a dialogue tree, a table of enemy stats — anything you would rather author as JSON than as a Lua table — is a file under Assets/, and a script gets it in one call.

Data files, in and out

json.encode and json.decode have been here since v0.20.0, but a script had no way to open a file: assets.getFile answers a path, which is what a model or a material wants and nothing a script can read. So a chart authored outside the game had to be rewritten as Lua, or pushed through save.* a kilobyte at a time. Four calls close that gap:

local chart, why = assets.readJson("charts/neon.json")
if not chart then return log("no chart: " .. why) end
for _, note in ipairs(chart.notes) do
  spawnNote(note.t, note.lane)
end

• assets.readJson(path) — a JSON file decoded straight to a Lua value, by json.decode's rules: objects are tables, arrays are 1-based lists that stay lists on the way back out, null is nil.
• assets.writeJson(path, value [, { pretty = true }]) — the reverse. pretty indents it for a person, or for a git diff.
• assets.readText(path) / assets.writeText(path, text) — the same for any text file, when the format is your own.

Writing back is the half that makes a chart editor a scene in your game rather than a tool outside it: record the hits, call assets.writeJson, and the file it wrote is one the Asset Browser shows, git diffs and the export ships. A write creates the folders on the way.

Every one of them answers value, why rather than raising — a data file is content, and a file that is missing, not text, or not JSON is a message in the Console and a nil the script can handle, never an error that stops the script loading. Paths are relative to Assets/ and stay inside it, the same rule assets.getFile follows; a path that would leave the project is refused and says so. The same calls work in an exported build and in a browser, where a read comes from the bundle and a write lands in the page's own storage.

A relay's inbox is sized for the players it serves and says so at startup, the relay bench measures the shape a real lobby produces and refuses to print a ceiling off a failing step, floptle shot draws the game's UI so a menu can be looked at from a terminal, and a shader knob on one part of a model can be driven from a script.

A relay's inbox is sized for the players it serves

A relay on a small box was dropping packets at a hundred players while its link sat under one percent used, its forwarding loop at a millisecond and its CPU idle. The limit was not the machine: a UDP socket left at the kernel's default receive buffer holds a couple of hundred datagrams, and one synchronised burst from a hundred clients filled it. The only symptom was retransmit latency that reads as "the internet".

The relay now asks for an 8 MiB buffer, receive and send, and prints what it was actually given on its first line of output — because the kernel silently caps the ask at net.core.rmem_max, and on a stock Linux box that cap is a fraction of the ask:

socket buffers: asked 8388608 B each; kernel reports rx 8388608 B, tx 8388608 B
floptle-relay: ⚠ socket buffer CLAMPED below the 8388608 B asked — raise
  net.core.rmem_max … and net.core.wmem_max … with sysctl, then restart

The sysctl is the operator's half; the relay is the only thing that knows it was clamped, so it says which one to raise and to what. Linux reports double what it applied, which is why an unclamped ask reads as sixteen megabytes here and in ss -m; the line spells out the usable half so it reads honestly beside the ask. A bigger machine with the same socket drops at the same point, so this is the fix and a bigger box is not.

Measuring a relay tells the truth about a failing step

floptle-relay-bench drives synthetic lobbies through a relay and reports what a player costs. Three things about the first walk of that curve were wrong, and each is fixed.

The host fans out. A game host tells every player what the others did, so the bench's host now sends each ping to every other member of its lobby, not only back to its sender — --lobby-size changes what the relay carries, not just how many lobbies there are. --echo-only keeps the lighter shape.

A ceiling is printed only on a clean step. The old report printed its highest ceiling on the step where the relay was dropping: stalled senders lowered the rate, which lowered the per-player figure, which raised the arithmetic. A step with anything unreturned, or a send rate short of the one asked for, now prints implied ceiling withheld and marks its per-player cost as not one. The report also shows how many pings were sent against how many the rate asked for, so a stalling relay shows as a shortfall before it shows as loss.

Bytes are called bytes. The relay's usage report named its throughput egress_bps and ingress_bps and counted bytes. The fields are egress_bytes_per_sec and ingress_bytes_per_sec now, before the first reader applied eight the wrong way.

Every simulated player is a socket on the machine driving the bench; the help and the docs now say to raise ulimit -n before a large run, because the default limit fails a join past about 400 players with an error that reads like a relay fault and is not one.

floptle shot draws the UI

floptle shot is how a project is looked at from a terminal, and it drew the world alone: no UI pass, so a scene whose whole point is a screen — a main menu, a character creator, a dialogue box, a HUD — came out as its backdrop. Every enabled UI layer is now in the picture, drawn the way the Game view draws it: world canvases in the scene, screen-space layers over the finished frame in their z order at the scale their scale mode gives --size.

Elements a script builds with ui.make in start exist only once the project has played, so they need --after; hand-authored elements are drawn as authored. --no-ui gives the world alone, for a lighting comparison or a GI preview.

node:uiRect() under floptle run used to answer 0, 0, 0, 0, which reads like a measurement and is not one — nothing lays out without a surface. It answers nil there now, as the reference always said it did; guard the call (if x then) in anything that also runs headless, and use shot to see a screen.

A shader knob on one part of a model

A model's parts can each wear a .flsl shader — skin on the head, a face decal, a cloth overlay on the torso — with every uniform authored in the scene and not one of them changeable at runtime: node:setShaderParam writes the node's own Material, which on such a model usually does not exist, and the part handle had no spelling for a uniform at all. The handle has one now:

local head = node:material("Head#2")
head:setShaderTexture("face", "faces/02.png")   -- the character creator's face swap
head:setShaderParam("blush", 0.6)
if head:shaderTexture("face") ~= "faces/02.png" then ... end   -- reads back, same frame

node:material() with no name drives the node's own Material through the same four calls. A shader write lands only on a part that already has an override wearing a shader — it never creates one, because an override is a whole material and a uniform must not be able to blank a part — and a write with nowhere to land is said once in the Console rather than lost. The node-level call on a model with part overrides and no node Material fans out to every part that wears a shader.

Upgrading

If you run a relay, add net.core.rmem_max = 16777216 and net.core.wmem_max = 16777216 to a sysctl file on the box before restarting onto this version, and read the relay's first line of output afterwards — the buffer is fixed when the socket is created, and a relay restart ends every lobby on it, so pair the two. If anything reads the relay's usage report, the two throughput fields are renamed. If a script reads node:uiRect() and also runs under floptle run, it gets nil there now. Nothing else needs a change.

The editor, the player and the Hub carry the Floptle logo now, everywhere the desktop will show one.

The logo is the icon

The editor's and the Hub's windows show the logo in the taskbar and title bar, the Windows executables carry it as their file icon, and the Hub's title bar and About page show it too. On Linux the Hub also puts both apps in your application menu with the logo — it writes launcher entries for itself and for the editor it installs, and refreshes them whenever the binary moves. On Wayland desktops that is the only way a window gets an icon at all, which is why both apps used to show the compositor's placeholder.

A macOS bare binary still shows the generic icon in the Dock; an .app bundle is a later packaging step.

Upgrading

Update the Hub, then install this engine from it — the editor's icon comes with the editor, so an engine version installed before this keeps the old look until you open a project on this one.

A relay can present a real certificate and pick up its renewal without ending a lobby, a dedicated server keeps its lobby code across a restart, a box reports which version it runs, a game key stays out of every world-readable file, and a server bundle says when it was made and what you called it. Nothing here changes how you write a game; it is the release in which the things you run say what they are.

A relay presents a certificate you gave it

floptle-relay --tls-cert fullchain.pem --tls-key privkey.pem presents the chain in those files instead of minting a self-signed one at startup. PEM, as certbot writes them; half a pair is refused at startup, and a pair that will not load is a relay that does not come up, never one that quietly came up self-signed instead.

A renewal ends no lobby. The relay watches both files; a renewal written to the same paths — which is what certbot does — is presented to new connections within ten seconds, and every connection already up keeps the certificate it agreed. A renewal that will not load (a torn file, a key for a different certificate) is said once on the relay's log and the previous certificate stays. There is no restart to schedule and nothing for a deploy hook to signal.

floptle-relay-bench --verify is how you check it from outside, with the same handshake a player's build runs: it prints the SHA-256 fingerprint of the leaf the relay actually presents, in openssl's spelling, and whether the chain verifies for the relay's name against the public roots. openssl s_client cannot do this — it speaks TCP, and a relay answers QUIC on UDP.

A dedicated server keeps its lobby code across a restart

A server that restarts onto a new build and asks the relay for the code its players already know was granted it — and, in the same second, the relay ended the lobby for having had nobody in it for half an hour. The restored lobby had inherited the old process's idle clock, and a server that sits empty waiting for players is exactly what a dedicated server is for. The server then went on advertising six characters that answered nothing, with no error anywhere.

A reclaimed lobby now starts a fresh idle window at the reclaim, whether its host is a dedicated server or a player whose connection blipped. A dedicated server's lobby is never reaped for idleness; a player's reclaimed lobby gets the same window a new one gets.

A box says which version it runs

The fleet agent and the managed relay each report their own version on the reports they already send — the version compiled into the binary, never read from a file or a unit, so an upgrade cannot leave a row saying the old number. The two are different binaries on different machines and are kept apart.

The agent also forwards which key a running server was started with — the first twelve characters, never the key — so a developer mid-rotation can see what the process that is running presented.

A game key stays out of every world-readable file

A dedicated server's unit file is world-readable, as unit files are, and it carried the whole game key. On a box that runs more than one developer's server, that was somebody else's credential at rest for anyone to read.

The key now lives in a file of its own under --keys (default /etc/floptle/keys), one 0600 root-only file per deployment that the unit names with EnvironmentFile=; the unit itself carries no secret. A rotated key changes that file and not the unit, and the agent restarts the server for it all the same. A deployment that is removed takes its key file with it.

A server bundle says when it was made and what you called it

floptle export … server writes exported_at into the bundle's manifest, and --label "lobby v3" writes a label. The control plane knows when the bytes arrived; it could not know when the build was made, and a bundle exported on Tuesday and uploaded on Friday read as Friday's work — which is how somebody deploys a build they thought they had replaced. The label is what you call the build, shown beside its checksum and never instead of it. Bundles exported before this carry neither and work as they did.

A usage report says where a key's lobbies are hosted from

Each per-key sample a managed relay reports now lists the addresses its live lobbies are hosted from and how many at each. It is the number behind "is my key being used by someone who is not me" — and the first thing the control plane does with it is count and show, not refuse: a CI runner, a LAN party and a whole ISP behind one address all look like "many lobbies from one address" and are honest.

Upgrading

If you run a relay, nothing changes until you pass --tls-cert and --tls-key. If you run a fleet agent, its first reconcile on the new version writes each server's key file and rewrites each unit to read it, which restarts every dedicated server on the box once — pick the moment. If you export server bundles, --label is optional. Nothing else needs a change.

A script stays inside its project, a loop without an exit stops the script rather than the editor, a game reaches public addresses only, the editor no longer goes down with the terminal it was launched from, and a relay keeps its shape under load. Nothing here changes how you write a game; it draws lines a game could previously cross.

A path is relative to the project, and stays inside it

Every path a script or a scene file names — assets.getFile, assets.getContents, node.model =, a texture, an audio clip, a scene, a script name on a node, a terrain save folder — is read relative to the project folder and resolves inside it. One that would land anywhere else, whether spelled as an absolute path or climbed to through .., resolves to nothing, and the Console says which rule refused it, once per distinct reference.

A game runs on a machine that is not yours. What is on that machine's disk is not your game's business, and a scene file is data that may have been written by somebody else.

assets.getContents lists at most 20 000 files and says so when it stops, and it does not follow a linked folder. A linked package's folder still resolves, because that is where a linked package is.

A loop without an exit stops the script, not the editor

while true do end in update used to freeze the editor, the player and a dedicated server alike, forever, with nothing to say why.

A pass into your scripts may now run for 2 seconds — 500 ms on a dedicated server, adjustable with floptle serve --script-budget-ms. Past that, the script that overran is stopped with an error naming the budget, and it is not called again until you edit its file. Everything else keeps running.

The scripts share 512 MB between them. A table that only grows hits "not enough memory" in its own call, and the rest of the game goes on. A print inside a loop keeps a thousand lines a frame on the Console and reports the rest as a count, and a save slot holds at most 10 000 keys and 4 MB.

A game reaches public addresses only

http.* from a script connects to public addresses and nothing else. Loopback, private networks, mDNS names, .internal names and link-local addresses are refused, judged on what a name resolves to rather than on how it was spelled, and the refusal is res.error with the rule named.

The editor's Play is the one exception: hitting http://localhost:3000 while developing is the ordinary case and keeps working, and the Console says once per session that an exported game and a dedicated server will not allow it.

Redirects are no longer followed. A 3xx arrives as an ordinary reply with res.location, and the script decides. A request body is capped at 8 MB like a reply, and Host, Content-Length, Transfer-Encoding and Connection are the transport's headers to set.

A script acts as the player, not as the developer

account.* from a game reaches the player's surface — /wallet, /missions, /games/… and /me/… — and nothing else. The token behind those calls belongs to whoever is signed in to the Hub on that machine, and the developer endpoints under /cloud/… (keys, builds, usage) are not a game's to call on a player's behalf. A call to one is refused at the call site with the rule named.

A project's packages ask before they are trusted

A project that arrives with packages inside it — a folder or a zip whose packages/ carry manifests asking for Files or Network — loads them with no permissions the first time it opens, and a banner across the top of the editor names each package and what it asks for. Trust this project grants them and remembers that set of packages for that project; Keep them restricted leaves them loaded with nothing for the session. A changed manifest asks again.

A withheld API is still there: http.get in an untrusted package raises with the trust rule named, not as a package that forgot its manifest. floptle exec is not held to any of this — a script you named on your own command line is your own code.

The editor survives losing its terminal

Every line the engine writes to the terminal now survives the terminal going away — a closed window, a pipe nobody reads. The Hub launches the editor with its output in a log file of its own (logs/ under the Hub's data folder, the last five kept), which is also the file to send along with a bug report.

openUrl parses what it opens

openUrl, ed.openUrl and sys.openUrl parse the address before anything opens it: http or https, a host, no username or password, and nothing in it a shell could read as its own syntax. An address that fails is refused at the call with the reason, on every platform. On Windows the link is handed to the shell's own open call rather than through cmd.

A relay keeps its shape under load

Every relay, the one you self-host included, now refuses a few shapes: one lobby per connection, at most 4 096 lobbies and 64 clients in each, ten lobby opens and thirty joins a minute from one address, half a megabyte a second from one connection, and a lobby nobody has joined for half an hour ends unless its host is a dedicated server. A reliable message a client pushes at a host is capped at 64 KB, a host's at 128 KB — four times the largest prefab any shipped game spawns. A refusal is a sentence on the wire, and each is counted in the relay's report. floptle-relay --no-address-limits lifts the two per-address rates for a load test run from one machine.

A host checks what a client sends on receipt, not only at the sender's queue: an RPC value past the wire's guardrails is dropped, a server-only message from a client is ignored, and both are counted.

A managed relay is verified by name. A relay reached under fopull.com has to present a certificate for that name; a self-hosted relay or a direct host:port keeps the dev-trust model, where the lobby code is the secret. Until the managed relay's certificate is live, a connection that cannot verify it goes ahead on the older model and says so once in the Console. A later release will refuse instead.

A managed relay that cannot refresh its key list backs off — one second, doubling to its normal half-minute — and says so once when it starts, at most once a minute after, and once on recovery with the window in it. It kept serving through a nine-hour outage exactly as designed; it also retried fifteen times a second and wrote every attempt to a journal that then lost everything before the storm. That rate is gone.

docs/multiplayer.md now says the honest thing about a game key: a stranger with it can use up your plan's players, it cannot cost you money, and rotating it is what rotation is for.

For a server you run

A dedicated server's unit keeps its runtime and state directories to its own user, denies the process link-local addresses, and gives up a handful of capabilities a game server never uses. Its status file names the prefix of the game key rather than the key. A deployment row carrying a control character in any field is refused with the field named, rather than written into a unit file.

One VM

The vm-luajit escape hatch — buildable for one release after Luau became the default, as ADR-0028 scheduled — is removed. Luau is the only VM the engine embeds, native and browser alike. scripts/vm.sh still switches the code generator (luau-codegen) for benchmarking.

Upgrading

If a script of yours reads a file by absolute path or through .., it now reads nothing and the Console says so — move the file into the project and reference it relatively. If a script reaches localhost from an exported build, it is refused; in the editor's Play it still works. If http.get was relying on a redirect being followed, read res.location and make the second request yourself. If a game calls account.get("/cloud/…"), it is refused — that is a developer call, and the portal is where it belongs. If you open a project that carries packages asking for permissions, you will be asked once. If you run a relay and a load test from one machine, pass --no-address-limits to the relay. Nothing else needs a change.

The second candidate, on top of rc1: a game's account calls act as the player, a project's packages ask before they are trusted, a relay keeps its shape under load, and the last LuaJIT build is gone. Still beta — play yours on it.

A script acts as the player, not as the developer

account.* from a game reaches the player's surface — /wallet, /missions, /games/… and /me/… — and nothing else. The token behind those calls belongs to whoever is signed in to the Hub on that machine, and the developer endpoints under /cloud/… (keys, builds, usage) are not a game's to call on a player's behalf. A call to one is refused at the call site with the rule named.

A project's packages ask before they are trusted

A project that arrives with packages inside it — a folder or a zip whose packages/ carry manifests asking for Files or Network — loads them with no permissions the first time it opens, and a banner across the top of the editor names each package and what it asks for. Trust this project grants them and remembers that set of packages for that project; Keep them restricted leaves them loaded with nothing for the session. A changed manifest asks again.

A withheld API is still there: http.get in an untrusted package raises with the trust rule named, not as a package that forgot its manifest. floptle exec is not held to any of this — a script you named on your own command line is your own code.

A relay keeps its shape under load

Every relay, the one you self-host included, now refuses a few shapes: one lobby per connection, at most 4 096 lobbies and 64 clients in each, ten lobby opens and thirty joins a minute from one address, half a megabyte a second from one connection, and a lobby nobody has joined for half an hour ends unless its host is a dedicated server. A reliable message a client pushes at a host is capped at 64 KB, a host's at 128 KB — four times the largest prefab any shipped game spawns. A refusal is a sentence on the wire, and each is counted in the relay's report. floptle-relay --no-address-limits lifts the two per-address rates for a load test run from one machine.

A host now checks what a client sends on receipt, not only at the sender's queue: an RPC value past the wire's guardrails is dropped, a server-only message from a client is ignored, and both are counted.

A managed relay is verified by name. A relay reached under fopull.com has to present a certificate for that name; a self-hosted relay or a direct host:port keeps the dev-trust model, where the lobby code is the secret. Until the managed relay's certificate is live, a connection that cannot verify it goes ahead on the older model and says so once in the Console. A later release will refuse instead.

docs/multiplayer.md now says the honest thing about a game key: a stranger with it can use up your plan's players, it cannot cost you money, and rotating it is what rotation is for.

One VM

The vm-luajit escape hatch — buildable for one release after Luau became the default, as ADR-0028 scheduled — is removed. Luau is the only VM the engine embeds, native and browser alike. scripts/vm.sh still switches the code generator (luau-codegen) for benchmarking.

Upgrading

If a game calls account.get("/cloud/…"), it is refused now — that is a developer call, and the portal is where it belongs. If you open a project that carries packages asking for permissions, you will be asked once. If you run a relay and a load test from one machine, pass --no-address-limits to the relay. Nothing else needs a change; rc1's notes still apply.

A script stays inside its project, a loop without an exit stops the script rather than the editor, and the editor no longer goes down with the terminal it was launched from. A release candidate on the beta channel: nothing in it changes how you write a game, but it draws lines a game could previously cross, so play yours on it before it goes stable.

A path is relative to the project, and stays inside it

Every path a script or a scene file names — assets.getFile, assets.getContents, node.model =, a texture, an audio clip, a scene, a script name on a node, a terrain save folder — is read relative to the project folder and resolves inside it. One that would land anywhere else, whether spelled as an absolute path or climbed to through .., resolves to nothing, and the Console says which rule refused it, once per distinct reference.

A game runs on a machine that is not yours. What is on that machine's disk is not your game's business, and a scene file is data that may have been written by somebody else.

assets.getContents lists at most 20 000 files and says so when it stops, and it does not follow a linked folder. A linked package's folder still resolves, because that is where a linked package is.

A loop without an exit stops the script, not the editor

while true do end in update used to freeze the editor, the player and a dedicated server alike, forever, with nothing to say why.

A pass into your scripts may now run for 2 seconds — 500 ms on a dedicated server, adjustable with floptle serve --script-budget-ms. Past that, the script that overran is stopped with an error naming the budget, and it is not called again until you edit its file. Everything else keeps running, and the Console still says what happened.

The scripts share 512 MB between them. A table that only grows hits "not enough memory" in its own call, and the rest of the game goes on. A print inside a loop keeps a thousand lines a frame on the Console and reports the rest as a count, and a save slot holds at most 10 000 keys and 4 MB.

A game reaches public addresses only

http.* from a script connects to public addresses and nothing else. Loopback, private networks, mDNS names, .internal names and link-local addresses are refused, judged on what a name resolves to rather than on how it was spelled, and the refusal is res.error with the rule named.

The editor's Play is the one exception: hitting http://localhost:3000 while developing is the ordinary case and keeps working, and the Console says once per session that an exported game and a dedicated server will not allow it.

Redirects are no longer followed. A 3xx arrives as an ordinary reply with res.location, and the script decides. A request body is capped at 8 MB like a reply, and Host, Content-Length, Transfer-Encoding and Connection are the transport's headers to set.

The editor survives losing its terminal

Every line the engine writes to the terminal now survives the terminal going away — a closed window, a pipe nobody reads. The Hub launches the editor with its output in a log file of its own (logs/ under the Hub's data folder, the last five kept), which is also the file to send along with a bug report.

openUrl parses what it opens

openUrl, ed.openUrl and sys.openUrl parse the address before anything opens it: http or https, a host, no username or password, and nothing in it a shell could read as its own syntax. An address that fails is refused at the call with the reason, on every platform. On Windows the link is handed to the shell's own open call rather than through cmd.

For a server you run

A dedicated server's unit keeps its runtime and state directories to its own user, denies the process link-local addresses, and gives up a handful of capabilities a game server never uses. Its status file names the prefix of the game key rather than the key. A deployment row carrying a control character in any field is refused with the field named, rather than written into a unit file.

Upgrading

If a script of yours reads a file by absolute path or through .., it now reads nothing and the Console says so — move the file into the project and reference it relatively. If a script reaches localhost from an exported build, it is refused; in the editor's Play it still works. If http.get was relying on a redirect being followed, read res.location and make the second request yourself. Nothing else needs a change.

One small fix for anyone running a dedicated server with a fixed lobby code.

A server that could not keep its lobby code now says so

floptle serve --lobby-code ABCDEF asks the relay to hand back the code your players already know. When the relay does not agree — the code is reserved for a different game, is already in use, or the relay is too old to understand the request — the server was handed a fresh code and carried on without a word. The players holding the old one could not join, and the only trace was on the control plane, one report later.

The server now prints a line naming both codes and the relay it asked, the moment it happens. A reclaim that worked stays quiet — a line per successful start is a line nobody reads.

Upgrading

Nothing to do.

One fix, and it is worth taking if you make a fast-paced multiplayer game.

A rollback match sent state nobody was reading

A rollback session had every peer simulating the same nodes locally from the same inputs — and the server was also putting all of those nodes' positions into every snapshot. The receiving side threw all of it away, correctly, because it had already worked them out for itself.

Nothing was broken and nothing desynced. It simply cost an order of magnitude more bandwidth than it needed to, and the cost scaled with how much of your game was rollback-simulated.

Measured on the wire: about 43 bytes per rollback node per frame. At 60 Hz that is roughly

A real two-player match was measured at 234 kbps per player before this. Almost all of it was this.

Nothing to change in your game. Rollback nodes still replicate normally before a match starts, which is what puts a late joiner in the right place, and ordinary networked nodes are untouched.

If you want to see where your own traffic goes, net.traffic() breaks it down by message kind — a large Snapshot row in a rollback match is the thing to look for.

Upgrading

Nothing to do.

A host whose connection blips for a moment no longer ends everybody's match, and a lobby code can now survive a server restart. Plus a way to see where your bandwidth is actually going.

Your match survives a moment of bad connection

Two players fought over a relay for ten minutes. Three times, the host's connection dropped for a few seconds — and each time the lobby was destroyed and the other player was quietly cut off. For them, everything in the world vanished except the sky and the HUD, and nothing said why.

A lobby now outlives its host's connection by twenty seconds. The players stay in it, and a host that comes back is put straight back into the match it was already in, with the same people. A rebinding router or a Wi-Fi hiccup costs a stutter instead of the game.

If the host really is gone, the lobby still ends and everybody is told what happened — with a sentence that names it rather than a bare disconnect.

If you host a relay yourself, its log now names lobbies and says why each one ended, instead of printing a count. That count was the reason the problem above went unnoticed for so long: it could not say which lobby died, or what killed it.

A lobby code can outlive the server behind it

floptle serve --lobby-code ABCDEF asks to reclaim a code rather than be handed a new one. Managed servers get this automatically. It means a server that restarts, or reconnects to a relay that restarted, comes back on the same six characters your players already wrote down.

A relay only honours the request when the code genuinely belongs to that game, so asking for somebody else's does nothing but get you an ordinary code.

Joining a server that is still starting up

net.joinState() gained "starting" in the last release. It is now wired through: a join to a server that is still coming up waits instead of failing, the engine keeps trying on its own, and the second return carries something you can put on screen.

local state, why = net.joinState()
if state == "starting" then
  find("Status").text = why          -- "about 30 seconds"
end

Give up sooner if you want to: net.join(addr, {timeout = 30}). The default is 90 seconds, after which it becomes a normal refusal. This only ever applies to a server that is waking — an ordinary join is answered immediately, as before.

See where your bandwidth goes

for _, r in ipairs(net.traffic()) do
  log(r.kind .. ": " .. r.count .. " msgs, " .. r.bytes .. " bytes")
end

net.traffic() breaks down what your game has sent by message kind, biggest first, and resets each time you read it — so calling it once a second shows you the last second.

It is worth a look if you have a fast-paced multiplayer game. A rollback match should be almost all Input, at a few bytes per player per frame. A large Snapshot row means full state is going out where inputs would do, which is the single biggest thing you can fix about a game's bandwidth.

Measuring a relay you run

New alongside the relay: floptle-relay-bench, which drives synthetic players through a relay and reports what one player costs, where packet loss starts, and the round-trip time your players would feel. See relay-bench.md.

Also

• floptle serve documents --lobby-code alongside the flags added last release.
• A dedicated server now reports the player cap it is enforcing, so a hosting dashboard can show the real number rather than the one it asked for.

Upgrading

Nothing to do. If you run a region box, take the new fleet agent and relay — the match-survival fix is in the relay.

A joining player can be told that a server is still waking up, rather than being told the game does not exist. Plus two flags that were always there and never written down.

A server that is starting is not a server that is missing

net.joinState() has a new answer: "starting".

Until now a join could only be going ("connecting"), done ("joined"), or never going to work ("refused"). A dedicated server that has been asked for but is not up yet is none of those, and the only honest-looking option was a refusal — which tells somebody holding a perfectly good lobby code that their friend's game is not there.

local state, why = net.joinState()
if state == "starting" then
  find("Status").text = why      -- "about 20 seconds"
elseif state == "refused" then
  find("Status").text = why      -- "no lobby QK7RM"
end

The second return carries words you can show a person, not a status word you have to translate. Treat "starting" as a waiting state like "connecting" — with the difference that "connecting" is one round trip to the relay and this one can take tens of seconds, long enough that a bare spinner reads as a hung game.

Games already published keep working exactly as they do now. A build that has never heard of "starting" sees "connecting" for the whole wait and draws the spinner it already draws. Nothing to recompile, nothing to guard.

What is not in this release: nothing sends "starting" yet. Sleeping a server and waking it on demand is being designed and is not here. This is the half a game is written against, shipped early so that when the rest arrives your lobby screen is already right.

Two server flags that were real and undocumented

floptle serve has always accepted --status-file and --max-players. Neither appeared in floptle help, so the only way to know was to read the source.

• --status-file PATH writes live status as JSON on a timer — players connected, uptime, tick timing, the lobby code, and the port or relay the server is actually reachable on. It is how anything supervising a server learns the lobby code, because the relay hands that to the server and nowhere else.
• --max-players N refuses joins past a number you pick.

--budget was documented as a cap on entities per tick. It is a bandwidth ceiling in bytes per second, and it only does anything alongside --interest. If you set it from the old description, check the number.

Floptle Cloud sees a region filling up

Region relays now report their own load, so a busy region is something Floptle Cloud can see coming rather than something it learns about from complaints. A server running on a region also reports what it costs to run, which is what the per-region capacity is worked out from.

None of this changes how you host or what you pay. It is the difference between capacity planned on measurements and capacity planned on estimates.

Servers on a region are also told which deployment they are, so their logs can be matched to the right entry on your game's page.

Upgrading

Nothing to do. If you run a region box, take the new fleet agent and relay.

One fix, finishing the one before it.

Your server's address comes from your server

The last release taught a dedicated server to report where it can actually be reached — the port it is listening on, or the relay it went out through — because a server hosted through a relay listens on no port at all, while the address being published for it said otherwise.

The agent that runs your server on a Floptle Cloud region read that and then threw it away, so the correction reached somebody standing at the machine and never reached your game's page. It carries it now.

Nothing about this is visible in the editor. If you host on Floptle Cloud, it is the difference between a published address that means something and one that was guessed.

Upgrading

Nothing to do. If you run a region box, take the new fleet agent.

Five fixes, four of them found by running a game on a real server for a week and one by measuring a fighting match.

The player who joined a rollback match was getting a worse game

Two people play a rollback match. The host sees a clean game. The person who joined has every single one of the host's actions arrive as a correction — a press that lands as a small pop instead of a motion, on every input, for the whole match, even on a perfect connection. Both machines agree about everything, so nothing anywhere says this is happening. It reads as "rollback feels worse for my friend than for me", which is not something anybody would report.

The two machines never started counting from the same moment. The clock banks real time and spends it in fixed steps, and the person joining arrives at the starting gun having banked their whole scene load — then spends it at once, and runs up to eight steps ahead of the host for the rest of the match. Raising the input delay could not touch it, because the gap was bigger than the delay.

A match now starts when it starts. If you have been tuning input delay to fix a joiner's experience, try it again from scratch.

A server on Floptle Cloud comes back by itself

Restarting a relay destroyed every lobby on it, and the servers hosted through it never noticed. They did not reconnect, they said nothing at all, and they carried on handing out the six-character code they were given when they started — which the site published, your game page showed, and your shipped build was told. Everybody who typed it was turned away, and there was nothing anywhere to explain why.

A server now takes the relay's word for its own lobby code rather than remembering one. If the relay goes away the code goes with it, the server says so, and it re-hosts itself and tells you the new code when it is back. Your game can see this too: net.joinState() reads "reconnecting" while the relay is unreachable, and net.lobbyCode() is nil rather than a code that does not work.

An empty server is not a player

A dedicated server counted itself as somebody playing. Your game's page said "1 in this game right now" about a server nobody was on, and one of your plan's player slots was spent for as long as it ran — so a game with room for twenty seated nineteen people and told the twentieth it was full.

Shipping a server is one command

floptle export <PROJECT> ~/builds/my-game-server.tar.gz server --scene scenes/lobby.ron

Name the output as an archive and you get the file you upload. Before this you got a folder and then ran a tar line copied off the website, which is the step that assumes you have a shell and is easy to get wrong. Naming a folder still gives you a folder.

A port that was never listened on

A dedicated server given both a port and a relay used the relay and ignored the port, without saying so. It says so now, at startup, and it reports where it can actually be reached, so nothing publishes an address that leads nowhere.

Upgrading

Nothing to do. If you run a region box, take the new server and fleet binaries the way you took the last ones.

A patch for two things found on a live server within an hour of 0.86.0.

Changing a dedicated server's settings reaches the server

Change a deployment's scene, its player cap, its tick rate or its port, and the region would write the new configuration and leave the old server running — with no sign that anything had been ignored. The next time that server happened to restart, minutes or days later, it would silently adopt settings you had changed and forgotten about.

The same gap is why 0.86.0's status-file fix needed a server to be restarted by hand before it did anything. It no longer does.

A game key can reach a server through its environment

A service manager cannot safely put a key on a command line, because every process on the machine can read one and it is copied into the system log. A dedicated server now reads FLOPTLE_GAME_KEY from its environment, which is how Floptle Cloud's own region boxes have been passing it all along. An explicit --game-key still wins.

Upgrading

Nothing to do. If you run a region box, take the new agent the way you took the last one; it will bring your servers onto the new configuration by itself this time.

This one is about the two moments where a multiplayer game meets other people: the server you left running somewhere, and the friend who could not get in.

Your server says who is playing it

A dedicated server hosted on Floptle Cloud now reports its player count, how long it has been up, how fast it is ticking, and — the one that matters — the six-character code people join with. Before this, a server could run all day while its page showed no players and no code to give anybody, which is a strange thing to see about a game that is working.

The server had nowhere it was allowed to write. It runs locked down, as a user of its own with no access to anything it was not handed, and the file it was asked to write its status into belonged to somebody else. It gets a place of its own now.

Nothing to do. Deployments pick this up when the region is updated.

A bundle arrives with all of its files

If a file in your project was readable only by you — which is what some machines do to every file you create — it arrived on the server unreadable, and the server ran without it. Not an error, no failed deployment: a game quietly missing its input bindings, or four of its scripts, and playing on regardless.

Every file in a server bundle is now readable wherever it lands. The export writes them that way, and a server unpacking a bundle makes sure of it — so this is fixed for bundles you have already uploaded, not only for the next one.

Two more things in the same area:

• A build that cannot start now stops trying. It settles as failed, with the reason, instead of restarting forever.
• Exporting a server bundle from a beta engine is refused, with the reason. Floptle Cloud runs stable engine versions, so a bundle pinned to a beta could never have started. The export says so before it writes anything, rather than leaving you to find out from a deployment that will not come up.

A game that fills up is good news

Two different people see a full game, and until now they got the same sentence — the developer's one, which named the game, the number, the plan and a price page.

The person trying to join is your friend holding a lobby code. They cannot buy anything and it is not their problem, so they now read:

This game is full right now. Try again in a minute.

You hear it once — not once per person turned away — with the number, the fact that nobody already playing was disconnected, and where to raise it. It reaches the editor console, a dedicated server's output, and your own game through net.notice(), so you can put it on your lobby screen for the people it actually concerns.

Nobody is charged for reaching the ceiling, nothing is throttled, and nobody playing is ever dropped for it.

Your game key lives in the editor

Project settings ⏵ Networked ⏵ Game key is where a Floptle Cloud game key goes. There is a Game name beside it, a link to manage that game or register a new one, and no .ron file to edit by hand.

Hosting with relay = "cloud" and no key now says so before anything touches the network, and names where to get one. It used to look like a connection problem — which was a poor thing to see on a plane, behind a firewall, or in a headless test, about a project that was simply never connected. It also says plainly that hosting on your own machine, or your own relay, needs no key at all.

If you run your own relay, its periodic line now includes how much traffic it has carried, so the figure you see is one you can check against the machine.

Documentation

• Shipping a server bundle is written down, in export-builds.md: the one command, what is left out of a bundle and why, which scene a server actually boots into, and the two things a game needs before it runs well on a box you do not sit at.
• The multiplayer tutorial ends by letting a friend join from their machine, which is the step that makes it a multiplayer game.
• The command line now describes itself to the website, so the page listing every verb — and whether each one needs a graphics card or writes into your project — is generated from the engine instead of kept in step by hand.

Upgrading

Nothing to do. Open your project and it works.

Your game runs in a browser. It has voice chat, a dedicated server you can put on a box and leave, and every export now ships a real player instead of the editor wearing a disguise.

This is the stable release of everything the 0.85.0 betas carried, plus the last round of fixes found by going looking for them.

Your game, in a tab

File ⏵ Export Game… ⏵ Web (browser) stamps a folder you can upload anywhere that serves static files — itch.io, a bucket, your own site. It is the same project, the same scripts and the same renderer; there is no separate "web version" of your game to maintain.

Everything a game does at runtime works there: saves (they live in the browser and survive a reload), audio, input, pointer lock, and multiplayer through the relay. What a page cannot do, it says so about rather than failing quietly.

Sound now works in a browser. It did not in the betas: the feature flag that keeps a Linux server from needing a sound card was also switching audio off in the tab. A browser build with no sound at all is now a browser build with sound.

Clicking Play no longer shows a black screen while the engine boots. The loading panel stays up until there is something to look at, and if the engine cannot start — an older browser, a machine without the GPU flag — the panel says so instead of leaving you with a black rectangle.

A web build fills its window. It used to letterbox itself into a black border at whatever size the page gave it, with no way out. There is a fullscreen control now, and the canvas follows the window.

A server you can leave running

A dedicated server is a server bundle: your project, with everything nobody on a server can see or hear left out, and a manifest naming the scene to host and the engine version to host it with.

floptle export . builds/server server --scene scenes/lobby.ron

There is no binary in it. The machine runs its own copy of the engine version your bundle pins, so you never cross-compile for somebody else's processor, and a bundle of a 45 MB game is 25 MB.

It refuses, with the reason, at your machine rather than as a deployment that fails on a box you cannot see: a project with no networked nodes, a rollback scene (those are simulated by every player, so a server has nothing to drive), or a scene that is not in the bundle.

A dedicated server is no longer a player in its own lobby. This one was worth the release on its own. A server answers net.isServer() exactly as a hosting player does — correctly, because the simulation does not care who started it — so a lobby script would seat the empty machine as a player, deal it a character, count it toward "enough players to start", and then wait forever for it to press Ready. A match on a dedicated server could never begin, and nothing said why.

if net.isDedicated() then return end   -- nobody is sitting at this one

net.isDedicated() is the one thing a game cannot work out for itself. Both kinds of host are the server; only one of them has a person at it.

Voice chat

Players in a session can talk. A remote speaker is an ordinary sound in your world, so it is positioned in space and goes through your mixer like anything else — a voice across the room sounds like it is across the room.

voice.setForward(true)      -- open the microphone

Nothing is required of you beyond turning it on. If a speaker's audio drops for a moment, they are heard again when it comes back rather than going silent for the rest of the session.

Multiplayer you can test without a second person

floptle run . --seconds 10 --ghosts 2

joins that many headless clients to the session your project hosts, and reports how many replicated nodes each one was actually sent — which is the number that tells you whether hiding a node from a player worked. floptle run --join connects to a server that is already running, and now prints why it could not when it could not, instead of pointing at an empty log.

Two knobs a tint could not reach

A tint multiplies, and a multiply can only take light away. Give a character a team colour on a mid-toned, ambient-lit model and "crimson" arrives as a slightly warm grey — the one thing the tint exists to say, which player is this, is the thing it says worst. The way out was always a Material, which says it perfectly and costs the model every texture it was imported with.

So a tint carries the two knobs that add light:

model:setTint{ rim = teamColor, rimStrength = 1.3 }  -- an additive edge
model:setTint{ ambient = 1.6 }                       -- lift it out of the room's shadow

The rim reads on a dark costume and a bright one, from across a room, which is what actually tells two team-coloured fighters apart in motion. Both are on the ◐ tint rows in the Inspector too, and an animation clip can key either.

Fields you leave out keep their value, so a hit flash that rewrites the colour every frame does not cost the model its rim. setTint(color) positionally still means exactly what it always did.

Fixes

A tint set only by alpha turned models black. setTint{ alpha = 0.5 } — the spelling the documentation gives — was read as a colour rather than as options, and a colour with no red, green or blue in it is black. It fades, now. Anything in that table that is not a colour or a number says so by name instead of silently doing nothing.

Hosting on Floptle Cloud could refuse for a day after a region opened. The list of regions is cached so that going online does not wait on a web request — and a cached list with nothing open in it was kept just as long as a useful one. A region that went live was invisible until the cache expired, and relaunching did not help. A list with no open region in it is no longer worth keeping.

"Your plan" is no longer guessed at. When the account service cannot be reached, the Hub said you were on the free tier, which is indistinguishable from actually being on it. It now says it could not check, shows the free tier's limits, and re-checks next time. Nothing is blocked either way, and a script that reads a player's tier gets "unknown" rather than a wrong answer.

A second net.host or net.join is refused out loud. It was always refused — a second session must not tear down the first — but it was refused silently, so a script that hosted twice got a result it could not tell from success. floptle run --join quic://… also takes the address in the spelling its own help prints, which previously produced a lookup failure for a hostname you never typed.

A creature could walk off a sofa into the room below. Baking a navigation mesh treated the eroded gap beside furniture and doorframes as a ledge, found the floor of the storey underneath, and linked a drop straight through the ceiling — 3,170 of them in one two-storey house. A drop now has to have somewhere to fall through. Real ledges and balconies are unaffected.

A light's Inspector says how many of the sixteen are in use. Sixteen lights reach the shader at once; past that the ones contributing most win and the rest are simply not drawn, which reads as "my seventeenth torch does nothing". The count is on every light now, and it warns when something was cut.

Two dozen messages had holes in them — hover text and errors with a run of blank space in the middle of a sentence. All closed.

Documentation

The documentation site now carries only pages that help you use the engine and are true today. Three that were neither — a north star, a superseded design record, and a work plan — have come off it, and the particle system's page, which described an asset format the engine does not have, is rewritten against the one it does.

Upgrading

Nothing to do. Scenes, projects and scripts from 0.84 open unchanged, and a scene that only ever set a tint colour writes the same bytes it always did.

If you use Floptle Cloud, docs/fleet-agent.md is new and is only for people running a region's box; nothing about hosting a game changed.

This is a beta release. It is on the beta channel, not stable. To try it: Floptle Hub ⏵ Settings ⏵ Channel: beta, then install 0.85.0-rc6. Your stable install stays where it is.

Everything in 0.85.0-rc5 — your game in a browser, voice chat, a real player under every export, and a dedicated server — plus a batch of work aimed squarely at things you could not previously check: multiplayer without a second machine, a screenshot of a game that builds its own world, and errors that named Lua instead of the cause. There is also a prebuilt relay for small Linux servers, coloured text, and a trigger flag you can afford again.

Multiplayer you can test on one machine

floptle run could already host a real session with no window and no GPU. Nothing could join it, so the half of a multiplayer game that is only true across the wire — a client's mirror, targeted RPCs, late joiners, and above all what a client is not sent — could only be checked by a person clicking in the editor, or by two machines.

floptle run . --seconds 10 --ghosts 2

joins that many headless clients to the session your project hosts. Each gets its own world and real snapshots, and the run says how many connected and how many replicated nodes each one was actually sent:

2 of 2 ghost client(s) connected — each is sent [1, 2] replicated node(s).

A count that differs between clients is interest management doing its job. That is what makes net.setRelevant(node, peer, false) checkable at all: the cheat-resistance of a hidden-role game is defined by what a client is not sent, and there was no way to be a client and look.

For the client half of your own scripts, be the client:

floptle serve .
floptle run . --join 127.0.0.1:7777 --seconds 10

--join is a real network connection rather than the in-process harness, and your own scripts run as the client — net.isServer() answers false, and your game does its own checking.

FLOPTLE_NET_IMPAIR=50ms,2% now degrades all of it, including the in-process harness, which it never used to touch. "Does this hold up on a bad connection" is a question one machine can answer.

Screenshots of a game that builds its own world

floptle shot draws your scene as authored — nothing has moved, no start has run. That is the right picture for "what did my edit do", and the wrong one entirely for a game whose planet, terrain, buildings and props are made by scripts on the first frames of play. For those, every screenshot was an empty room.

floptle shot . --after 30s --out shot.png

plays the project first and then takes the picture. Time is fixed and never read off the clock, so two runs give the same image, and --seed pins the randomness for a game that generates its cast. The camera is chosen after the span, so a game that takes over the view is photographed through the camera it chose; --camera still names one and still wins.

Both verbs' help now says plainly which frame you get. run plays and reports numbers; it writes no picture.

One trigger on a mesh no longer costs the whole level

A single node with a Collider and its trigger switch on, over a thousand-triangle mesh, could put a 57 ms stall on a fifth of your frames, while thirty other mesh props in the same scene cost nothing at all. The geometry was never the problem: trigger overlap asked every physics body in the world for an exact distance to that mesh, at any range.

Triggers reject by bounds first now. If you turned trigger off on a node to get your frame rate back, you can turn it on again.

Colour one word in a line, and move one letter

A text element carried a single colour for the whole string, so highlighting the bound key inside the sentence that tells you to press it meant splitting the line into separate elements and positioning them by hand — which re-wraps wrong at every window size and breaks the moment the string is translated.

label:setTextSpans{ { len = 10 }, { len = 3, color = { 1, 0.3, 0.3 } } }

len is in characters of your string, and spans run end to end from the start; a span with no colour is how you spell a gap. Characters no span reaches keep the element's own colour.

Spans style, they never lay out: a two-colour run wraps exactly where the same string in one colour does. That is also why a span cannot change size or font — those would move the text.

label:setGlyphOffsets{ vec2(0, 0), vec2(0, -3), vec2(0, 1) }

displaces individual characters at draw time, one entry per character, applied after layout — so a moved glyph never re-wraps its line or nudges its neighbours. Wobble, shake and per-glyph reveal are yours to write. Your string stays your string through both, so you can still measure it and count its characters.

A crowd can wander around one place cheaply

nav.random gathers and measures every polygon its window covers, and does all of it again on the next call — so a dozen agents redrawing a destination in one frame cost about 4 ms.

local s = nav.sampler(node.position, 20)
local p = s:point(math.random(), math.random())

gathers once and answers many draws. Quadrupling the radius no longer costs sixteen times as much. A sampler is a snapshot: rebuild it if you re-bake that part of the mesh.

Errors that named Lua instead of the cause

synced in a script with no replicated table. This failed as attempt to index nil — Lua's words for a cause that lives at the top of a different file, while the node's Networked component, the live session and net.role() all said replication was on. It now names the script, the variable and the fix, on the first read as well as the first write. The read was the quieter half: it came back nil and failed silently, so a client mirror just never updated.

local n = createNode("Stain"). createNode and spawn are queued — the node is made after the pass — so neither can return one, and the handle only ever arrives through the callback. Writing the obvious thing gave you nil, and failed a line later as attempt to index nil with 'position'. Both now hand back something that says so the moment you touch it, and shows the line that works:

createNode("Stain") does not return a node — the node does not exist yet (it is
made after this pass), so `.position` has nothing to read. The handle arrives in
the callback: createNode("Stain", function(n) n.position = ... end).

A relay you can run on a small x86 box

The managed relay — the one that checks lobby keys against Floptle Cloud rather than letting anyone through — now ships as a prebuilt Linux x86_64 binary alongside the engine bundles:

floptle-relay-0.85.0-rc6-linux-x86_64
floptle-relay-0.85.0-rc6-linux-x86_64.sha256

sha256  2ff924d86ccf4f6a662894934f86696d23d9d1aba487134a882f3b47fb2ac52e

It is a bare executable and its checksum, not an archive, because installing it is four lines on a server with nothing on it. It links no windowing, audio or input libraries — only the C runtime — so it starts on a minimal Ubuntu image, and it is under 4 MB.

floptle-relay --help now prints the flag table instead of refusing, which is also how you tell this binary from an older relay before installing it on a live box — an older one answers --help with anything but a flag table.

Running a relay of your own is unchanged and needs none of this: with no --control and no --token it is the open relay it has always been — no keys, no control plane, no accounting.

One behaviour change if you run a managed relay: it now reports usage on every interval even when it has no lobbies at all. An idle relay used to say nothing, which made a quiet region indistinguishable from a region that had fallen over.

Also in this release

• Editor packages can ask a scene what its gravity is — scene.gravity([at]) gives the vector at a point, plus whether one number is the whole answer. A level with no gravity volume has zero gravity rather than the engine default, so anything assuming −9.81 was guessing in both directions.
• An exported game is 22 MB smaller than the editor — 30 MB against 52 — now measured rather than estimated.

Upgrading

Nothing to do. Open your project and it works.

Two notes if they apply to you:

• synced is now a table rather than nil in a script that declares no replicated table. If you guarded a write with if synced then, that guard was silently doing nothing, and you will now see the error it was hiding.
• createNode and spawn now return a value instead of nil. If you tested one for truthiness — if spawn("bullet") then — it now reads as true. Touching it raises with the explanation above.

This is a beta release. It is on the beta channel, not stable. To try it: Floptle Hub ⏵ Settings ⏵ Channel: beta, then install 0.85.0-rc5. Your stable install stays where it is.

Everything in 0.85.0-rc4 — your game in a browser, voice chat, and a real player under every export — plus a dedicated server you can leave running on a machine nobody is sitting at, and two multiplayer bugs that broke the path the documentation tells you to take. If you have written any networked code at all, read the next two headings.

net.on at the top of a script never fired

Every example in the multiplayer guide registers handlers at the top of a script, outside any function. That form did not work. The handler was created when the script ran and then deleted a few lines later, by the pass that clears out the previous version's handlers — which matched the one just registered.

Nothing was logged, because from the engine's side nothing failed: a handler was registered, and a handler was removed. Only net.on written inside start survived, which is why some projects worked and some did not for no visible reason.

Handlers are now pruned by position rather than by name, so the ones a fresh run registers are kept. No change to your code.

The first player to join was told the server was offline

A joining peer could be on the roster before the host had finished its first tick — and net.role() was only updated at the end of a tick. playerJoined therefore ran while the host still believed it was not the server, and net.spawn, net.kick, net.setOwner and net.setRelevant all check that role and quietly refuse.

So the first player to arrive got no avatar and no moderation, and everybody after them was fine. That reads exactly like a flaky connection, and it is not: it was deterministic and it was always the first one. The role is now set the moment the session exists.

A server that runs where nobody is listening

floptle-server is a new binary for hosting a world with no window and no local player. It is not a second engine: it runs the same tick the editor runs when you press Play, so everything you already rely on behaves the same — every net.* command, interest management, the rewind history, join policy, scene switching, gravity volumes, and scripts that arrived from a package.

floptle-server <project> --scene scenes/mp.ron --port 30000 --max-players 8

• --max-players is a real ceiling, refused at the door. A full server turns away the next arrival; nobody already playing is ever dropped for it.
• --status-file writes a small JSON document every five seconds — players, uptime, ticks, tick rate, scene — to a temp file and renames it, so whatever is watching never reads half a document.
• --relay <addr> hosts through a relay instead of a port, exactly as the editor does.

It also starts on a minimal Linux server image with nothing installed. The editor binary could not: it links a sound library and a device library at load time, so on an image without them it failed before reaching main, with an error about audio, on a machine where nobody was going to hear anything. floptle-server needs only the C and C++ runtimes every image already has.

A scene made of Rollback nodes is refused with an explanation rather than served badly — a rollback match is simulated by every peer and hosted by one of them, so there is nothing for a dedicated server to drive.

A stopping server says goodbye

Stopping a server used to look identical to a crash from the player's side. Now Ctrl-C, systemctl stop, or any SIGTERM tells every connected player the world is going away, gives that message half a second to leave, and exits cleanly. They see "the server is shutting down" where they used to see a connection that dropped for no reason.

Restarting a populated server is now an ordinary thing to do.

Under the hood

Groundwork for managed hosting, present but not switched on: a relay can be told which games may host it, lobby codes can carry a region letter, and a project can hold a hosting key that it presents when it hosts. A relay started without those options is byte-for-byte the relay you already run, and there is a test that says so.

This is a beta release. It is on the beta channel, not stable. To try it: Floptle Hub ⏵ Settings ⏵ Channel: beta, then install 0.85.0-rc4. Your stable install stays where it is.

Everything in 0.85.0-rc3 — your game in a browser, voice chat, and a real player under every export — plus nine fixes found by going back over the release before promoting it, four of which would have been real problems for somebody. If you are on rc3, update: two of these are silent, and a silent problem is one you would have spent an evening on.

Packages work in an exported game again

A package's scripts did not load in an exported build. If your game had a package attached to a node, that node did nothing once exported — and nothing was logged, because from the engine's point of view nothing had failed: the script name simply resolved nowhere. Assets referenced with pkg:// kept working the whole time, which is exactly what made this read as "my scripts are broken" rather than "my packages are missing".

This arrived with the editor/player split, so it affects exported builds from this release series only; the editor was never wrong. Export again and the package's scripts are there.

A voice that goes quiet comes back

If a listener missed a run of speech — they muted and unmuted, they left and rejoined a proximity list, or their connection stalled for a second — the speaker never came back. Not a dropout: silence for the rest of the session, from that one player, with everyone else still audible.

The buffer that puts a speaker's audio back in order was trying to walk forwards to catch up, one frame at a time, at exactly the rate new speech was arriving — so it never arrived. A jump that large is a new run of speech rather than a lost packet, and it is now treated as one. The buffer also shrinks back down after a rough patch, which it could not do before: one hiccup early in a match held the extra delay for the whole match.

Hiding a player actually hides them

net.setRelevant(node, peer, false) withheld nothing unless you had also turned on interest management. It returned success either way. A hidden-role game that used it and nothing else was sending the hidden player's position to every other player, every update, while the call that was supposed to stop that reported it had worked.

A pin now holds whether or not interest management is on. With interest unset, every client is still told about everything except what it has been pinned away from — no radius, no budget, nothing else culled. Turning on a hidden-role filter was never a decision to opt into distance culling as well.

A browser that cannot run your game says so

If the game stopped after it had started — most often a browser without WebGPU switched on, or a graphics card the browser refuses to use — the page went black and said nothing. The message was being written into the panel the page had already hidden the moment your game started. The panel comes back now, with the reason on it.

Esc gives you your cursor back in a build

A game that captures the mouse for a first-person camera took the pointer with no way to get it back short of killing the window. Esc releases it and a click gives it back — the behaviour the editor has always had, and that export-builds.md has been promising. Alt-tabbing away releases it too, so a build can no longer reach out of an unfocused window and take the pointer off whatever you switched to. In a browser the same two gestures work, and the page no longer asks for the cursor sixty times a second after you press Esc.

The package catalogue works on a beta engine

📦 Packages showed "nothing for Floptle 0.85.0-rc3 yet" for every package on every shelf. rc3 fixed this for installing a package and missed the two places that decide what the catalogue offers you in the first place. Browsing works on a pre-release engine now, and a version marked incompatible in a package's version list is one that really is.

A mistyped allow list is refused, not ignored

net.host{ allow = "abc123" }     -- refused: it is a list, not a string
net.host{ allow = { "abc123" } } -- what was meant

The first form used to be read as an empty list — and an empty allow list admits everyone. One typo in the option whose whole job is to keep people out turned it off, silently, and the server came up looking exactly as it should. Both allow and deny now say so instead.

Your email address is not your player name

net.identity(peer).name fell back to the account's email address when an account had no display name set — and that name goes to every other player in the session and into their game scripts. It does not any more. An account with no display name reports no name, the same as a player with no account at all, which your game already has to handle.

Also in this release

• A web export into a folder that already held a desktop export cleared out that build's loose asset folder. Serving the folder was publishing the whole previous game beside the page as browsable files.
• A shipped web build no longer sends a request per line of log output to a path no host serves. That was a failed request roughly twice a second, in every player's browser, for the benefit of a test harness that was not listening.

The Hierarchy and Inspector changes that never got a note

These shipped earlier in the 0.85 series without being written up:

• Dragging near the top or bottom of the Hierarchy scrolls it, so you can drag a node to a parent that was off screen without letting go.
• Holding a drag over a folded node opens it, after a moment, so you can drop inside it.
• The whole row is a drop target, and it outlines green for a drop it will take and red for one it will refuse, before you let go.
• The Inspector's name row has a lock. With it on, clicking in the Scene or the Hierarchy leaves the selection alone, so you can look at another node's values — or click around the level — without losing the node you were editing. It releases itself if that node goes away.

Upgrading

Nothing to do. Export your game again to pick up the package fix and the cursor fix — both live in the build, not in your project.

This is a beta release. It is on the beta channel, not stable — the browser export is new and has not been through a real playtest yet. To try it: Floptle Hub ⏵ Settings ⏵ Channel: beta, then install 0.85.0-rc3. Your stable install stays where it is. It moves to stable once it has been played.

Two things your game could not do before this release: run in a browser, and let players talk to each other. It can do both now. A third thing changed underneath: an exported build is finally a player, not the editor wearing a disguise — which is what made the browser possible and made every build on every platform smaller.

Your game, in a browser

File ⏵ Export Game… has a new target: Web (browser). It stamps a folder you serve: a page with a loading bar and a Play button, your project packed into one file the page downloads, and the engine as a WebAssembly module. Put it on any static host, or zip it for itch.io. From a terminal it is one line:

floptle export ~/games/MyGame ~/builds/MyGame-web web --title "My Game"

Nothing about your project changes for it. The same scenes, scripts, physics, audio and UI run in the tab that run on the desktop — it is the same player and the same engine, reading its files from the bundle instead of a disk. save.* writes to the browser's own storage, so a slot survives a reload. Sound works, after the click browsers require before a page may make one; the Play button is that click.

Three things are different in a browser, and the build says so rather than pretending otherwise:

• The whole project downloads before the game starts. There is no streaming in this version, so a build's size is a player's wait.
• WebGPU is required — current Chrome, Edge and Safari; Firefox is still rolling it out. A browser without it gets a page that names the problem instead of a black canvas.
• Networking, Steam and http.* are not available, and each refuses in one sentence rather than hanging.

export-builds.md is the page for using it.

What a large game should expect today

The export ships your project as you authored it — no audio re-encoding, no texture downscaling. On a large game that shows, and the export prints the numbers so you can see where the weight is:

game.flpk is 294.0 MB (1275 asset file(s)), the engine module 18.5 MB
  — mostly ogg 183.2 MB, png 61.4 MB, glb 23.3 MB

That is a real finished first-person game, and it is too big for the web as it stands — audio is 62% of it. Re-encoding assets at export time is the next piece of this feature rather than part of it today. Small and medium projects are fine now; plan around this if yours is large.

Voice chat

Players in a session can talk, and a remote speaker is an ordinary voice in your mixer — not a parallel audio path bolted on beside it. That one decision is why everything else works: a speaking player is positioned in the world, falls off with distance, routes through your buses and takes your effects, because that is what every other sound in your game already does.

Which means turning the killer into a monster is:

voice.source(peer):setTrack("Voice Monster")

with no new audio API to learn. Proximity is the default: you hear who is near you. The codec is Opus, in pure Rust, so there is no toolchain for you or your contributors to install.

Two things are not verified and are worth knowing: the end-to-end latency has been added up (~75–85 ms) but never measured with a clap on two machines, and the microphone capture path is exercised through injection rather than real hardware. The no-device path is tested and is what most machines take. The 🌐 Multiplayer window's 🎤 test voice from a WAV… plays a file in as though a remote player were speaking it, through the real forwarding rules and jitter buffer, so you can hear the whole chain on one desk.

Netcode: rigs, secrecy, and moderation

A replicated spawn is a whole rig now. net.spawn sends the subtree, so a player rig — capsule, camera child, arms mesh, a bone-attached item socket — crosses as one thing instead of as a node that arrives without its parts. net.setOwner came with it. Two real bugs fell out on the way: a dedicated server was reserving a predicted slot for a host that does not exist, leaving an avatar nobody drove; and floptle serve never despawned what a leaving player had spawned.

The server decides who is told what. net.setRelevant(node, peer, bool) hides a node from a peer outright, and net.host{ interestOcclusion = "Level" } does it by line of sight. A hidden-role game can now be made cheat-resistant, because a client is no longer sent everyone's position and asked not to look. Losing sight is damped and regaining it is instant, so cover does not flicker.

Sessions have identity and moderation. net.kick, net.identity, and an allow/deny check consulted before a join is accepted. One deliberate gap: the verified flag is false for everyone. Checking a claim needs a credential scoped to the server you are joining, and shipping a token that is not would let any server you join spend your Fobucks. The engine reports its own confidence honestly rather than dressing an assertion up as proof.

An exported build is a player now

Until this release, "export" shipped the editor with a flag set — every panel, the dock, the Inspector, the asset browser and the file pickers compiled into a game that could never open them. Now there are two programs over one engine, and a build gets the one with no authoring half in it.

Nothing about the game changes: it is the same play loop and the same renderer the editor shows you, which is the point of doing it by compiling the editor out rather than by writing a second player that would drift.

Builds stopped carrying what they can't open

Every build — desktop as well as web — used to copy your whole project folder, including files nothing loads: the .fbx an import already turned into a .glb, a bought pack's .uasset leftovers, a .blend, a build script. On the game above that was 857 files and 45 MB.

They stay out now, and the export says what it left and what it weighed. Nothing is lost — none of those could be opened at runtime before either. The .glb an import produced ships exactly as it always did, and .meta files stay, because those belong to the terrain streamer.

The doors were there all along

The first playtest of a browser build found doors, the NPCs and the player's own arms missing while medkits, pills and the flashlight drew fine. Nothing was wrong with the models. The difference was how each was referenced: some were recorded by their full path on the machine that authored them (/home/…/Forgery/models/door.glb), and a path like that was taken as written — which inside a bundle, or on any other machine, names nothing. A missing model simply doesn't draw, and nothing said why.

Two fixes, so a build never leans on either alone. The export now rewrites a full-path reference to the build's own copy of the file whenever it carries one — including a reference written on another disk or on Windows — and lists each one in its report, rather than only fixing paths that happened to start with the folder it was exported from. And the player rescues one it meets anyway, by taking the longest tail of the path that exists in the project, so a project that moves folders, disks or operating systems keeps drawing. A reference that already resolves is never touched, and one that points at a file the build does not have is still named as a warning at export.

The second playtest found the next layer down: with the doors back, the NPCs, the entity and every particle effect a script spawns were still absent, and nothing was logged. Files in a browser have no modification time, and the cache behind spawn() treated "no time" as "no file" and gave up before reading the prefab. Every scripted spawn in a web build did nothing. A missing timestamp is now a timestamp like any other — a bundled file never changes, so the first parse serves the whole run — and the same rule now covers the two other caches keyed the same way.

Sound that stays smooth

Audio in a browser fluttered, and once it started it never stopped. The cause was in how sound is handed to a page's speakers. The engine keeps a short run of sound queued ahead of the moment you hear it, and in a browser the mixing happens on the very thread that draws your game — so one long frame, like importing a model or baking a shadow, could drain that queue. The queue was then permanently behind: every piece of sound after it was handed over late, which is what turned a single hiccup into a permanent stutter.

The browser build now schedules its own audio, with the rule the old path was missing: when the queue has run dry, restart it ahead of the clock rather than behind it. A stall costs one gap and is then over. The cushion is bigger too, so an ordinarily busy frame costs nothing at all. On a real game the reserve of queued sound held above 88 ms for half a minute of play, where before it collapsed under 10 ms and stayed there. Desktop builds are unaffected — they have always had a thread of their own for this.

Packages load on a beta engine

Cutting this release on the beta channel turned up a bug it was the first to be able to find: a package that declares which engine versions it works with (engine: ">=0.55.0") refused to load on any pre-release build, because the version rule that stops an unfinished package installing itself into a project was also being applied to the engine itself. It is not the same question — the engine is not a candidate being chosen, it is the build in your hands — so a pre-release engine now counts as the release it leads up to. Your packages work on beta.

A shader fix that only a browser could show

Shaders using noise or hash compiled everywhere the engine had been tested and were refused by browsers, over one rule about mixing operators that desktop drivers do not check. A game with a custom sky or water shader drew its interface and nothing behind it. Fixed — and the engine now compiles every one of its example shaders through a real browser as part of its own test run, so this class of problem is caught before a release rather than by a player looking at a black screen.

A performance patch, and it is a large one. A scripted node cost the engine about 4.5 KB of memory a frame before your script did anything at all, and a body standing on a mesh floor cost far more than it should have. Both are fixed, and the profiler that should have shown you the first one now does.

On the first-person game these numbers come from, a frame went from 6.4–7.6 ms to 3.5–3.7 ms, and the memory its scripts churn through went from 478 KB a frame to 48 KB. Nothing to do on upgrade — open your project and it is faster.

Your scripts were being blamed for the engine's memory

floptle run --alloc reports how much memory a frame's scripts make. On that game it said 478 KB a frame, and the biggest single line was a pickup script running on 34 items. Emptying that script's update completely changed the figure by 4%.

The memory was the engine's. Every scripted node has a node table that the engine refreshes before each hook and reads back after it, and the read-back was going the slow way around: about 96 bytes for every field, ten fields, twice a pass, three passes a frame, on every scripted node in the scene. A node with an update that does nothing at all was costing 4,522 bytes a frame.

It now costs 375.

Nothing about how you write a script changes. If you have been watching --alloc and wondering why the numbers were so much larger than the tables your code builds, this is why, and the number you see now is much closer to yours:

floptle run --frames 600 --alloc --seed 7

Standing on a mesh floor got cheap

Collision against an imported mesh — a level, a terrain, any model you gave a mesh collider — asks the mesh "how far is this point from your surface". That question was searching a fixed block of 125 cells every time it was asked, however close the answer turned out to be, and a body is asking it dozens of times per tick. On the same game, seven moving bodies against a level's meshes were most of the physics budget.

The search now stops when it can prove nothing else is closer, and never looks outside the mesh's own extent. Same answers, down to which triangle — a replay still replays identically — for about a fifth of the work.

The frame profiler adds up now

The ⏱ panel and perf.ms("scripts") used to time only the hooks themselves. Everything the engine did to reach a hook — the setup per node, the reference params, the scene sync — was in no bucket at all, so a heavily scripted frame could report 5.3 ms of a 12.9 ms step and leave you looking in the wrong place. That is how the memory above stayed hidden for a release.

scripts is now the whole pass, and the scene sync has a bucket of its own:

perf.enable(true)
print(perf.ms("scripts"))   -- the whole pass
print(perf.ms("mirror"))    -- the ECS-to-Lua sync inside it, counted once
for _, s in ipairs(perf.scripts()) do
  print(s.name, s.ms)       -- hook time: part of "scripts", not all of it
end

perf.buckets() gains mirror, and the panel says which of its numbers is which. On a scene of sixty scripted nodes the buckets now account for 99% of the step where they accounted for 34%.

If you have an assertion like perf.ms("scripts") < 4 in a script, it is now measuring more than it used to and may need a larger number. That is the point: it was measuring a fraction of the pass.

Also in this release

• The two design records the engine's own source comments point at — the command-line design, and the decision to move to one script VM and a WebGPU-only browser target — are published at docs/adr/, so following a citation lands somewhere.
• The web export page now marks plainly which of its steps shipped in 0.84.0 and which are still plan.

Upgrading

Nothing to do. No project file changes, no script changes, no settings moved.

The clean-up behind 0.84.0's new Lua and its vector setting. A way to see which script a frame's allocation comes from, a seed so two runs of your game can be compared, three warnings that had gone quiet or vague, a home of its own for the vector setting, and a lint that reads more of your code.

You can see which script allocates

floptle run --alloc gave one number. Now it says where the number comes from:

floptle run --frames 600 --alloc
# scripts allocate 538.2 KB per frame of Lua heap — …
#   loot_director              211.4 KB/frame
#   enemy_brain                148.9 KB/frame
#   hud                         61.0 KB/frame
#   (12 more scripts)           88.7 KB/frame
#   (outside any script hook)   28.2 KB/frame

Largest first, in the names you call them, with what falls outside any script hook as its own line. Under --json the same list is alloc.by_script, and alloc.unattributed_bytes_per_frame is the remainder.

This exists because of a measurement. A shipped game with a known collector problem switched its vector to fast — the one that allocates nothing — and its per-frame allocation moved by 2%. The vector was never where the garbage came from, and until now nothing could say what was. The setting's description in ⚙ Project Settings, the scripting guide and the web-export plan all said or implied that vectors are most of what a vector-heavy game spends a frame on; they now say to measure first, and how.

Two runs can be the same run

floptle run --frames 600 --timing --seed 7

--seed pins math.random and the no-seed rng() form to one whole number, so a game that re-randomises its cast or loot every run rolls the same game twice. Without it, an A/B between two settings is mostly measuring which run got the bigger fight. Each rng() still gets a stream of its own; the seed pins the run, not the streams. The JSON report carries seed when one was given.

Three warnings that had gone quiet or vague

• A script with only fixedUpdate or lateUpdate is warned about a param it never reads. Since 0.84.0 a script pays only for the hooks it has, and the "the scene sets speed, which the script no longer declares" warning had moved with the hooks — a controller with no update was never told about a stale tunable stored on its node.
• A vec3 that cannot cross the wire is refused as a vec3. net.* used to say "userdata can't replicate" for exact and "vector can't replicate" for fast. It now says "a vec3 can't replicate as a value — send its x, y, z (or a {x=, y=, z=} table)", in both.
• A script that raises every frame no longer re-reads its file every frame to quote the line. The quoted line still follows the file when you edit it.

Script vec3 has a home

⚙ Project Settings has a Scripting section, and Script vec3 lives there, not under Rendering. Searching the ⚙ tab for vec3, lua or script lands on it. The Console lines that name the setting point at the new place.

floptle lint --vec3 reads more of your code

• if a == b then v = vec3() end binds v. The scan used to give up on any line whose first = was a comparison, so a v.x = 1 further down was never reported.
• enemy.pos.x = 1 is a node field, writable in both modes, and is no longer reported just because a local pos = vec3(…) exists elsewhere in the file.

Also

• floptle migrate writes script_vec3: Some(Exact) into project.ron the way opening the project in the editor does, so a command-line upgrade leaves no default to shift under a shipped game later.
• Export no longer counts an HTTP endpoint path such as "/api/login" in a script as a reference outside the project.
• The starter templates are checked under both vectors, not only exact.

Upgrading

Nothing to do. If you upgraded to 0.84.0 with floptle migrate and never opened the project in the editor, run floptle migrate once more to write the vector pin.

The performance release. A game that was slow on an older machine is faster on every machine, fullscreen works in every build whether or not your menu offers it, and the engine runs a new Lua underneath — with a choice of vector to go with it.

Your game spends half the time it did

A report of a Floptle game running at 10–15 fps on a 2017 laptop turned out to have nothing to do with the graphics card. The picture cost under two milliseconds; the rest of the frame was the engine getting ready to run your scripts. A level with sixty scripted nodes and a couple of hundred mesh colliders cost 12.5 ms of CPU per frame before this release. It costs 6.4 ms now, on the same machine, running the same scripts.

Where it went, in one sentence each:

• A script only pays for the hooks it has. A file with just update in it was doing the full per-frame setup three times a frame — once for update, and twice more for the fixedUpdate and lateUpdate it did not define.
• params is built when it changes, not on every call. A script that never writes into it is never scanned for writes.
• The scene mirror your handles read from is refreshed, not rebuilt, when only positions moved between two passes — which, with physics running, is nearly always.
• Mesh colliders have a size now. They used to be offered to every body on every tick, wherever in the level the body was, and the collision index was rebuilt every tick whether or not anything had changed.

Scripts allocate about two and a half times less per frame as a result, so the collector pauses less often as well. Nothing in your project changes.

Fullscreen, in every build

F11 and Alt+Enter toggle fullscreen in every exported game — borderless, on the monitor the window is on, no mode switch — with no code on your part. For a Video tab:

app.setFullscreen(true)     -- or false to go back to a window
if app.fullscreen() then …  -- the real state, including after F11

Like app.quit(), this is honest about where it is running: in the editor the window is the editor's, so the call leaves it alone and says so once in the Console. The setting is for this session; persist the player's choice with save.*.

A new Lua underneath

Scripts now run on Luau, the Lua dialect Roblox maintains, instead of LuaJIT. Two reasons: it is faster at what this engine actually does — a script here spends its time crossing into the engine to read a position or set one, and Luau is quicker at every crossing — and it is the only one of the two that can ever reach a browser (web-export.md is the plan).

The whole scripting reference, every shipped script and every tutorial were run on both and compared before the switch. What you will notice:

• The 60-upvalue ceiling is gone. A long controller file no longer stops loading because it declared one more file-scope local.
• A runtime error names the typo. node.postion.x used to fail as "attempt to index nil with 'x'". It now says which expression was nil and quotes the line it happened on.
• goto no longer compiles. It was a LuaJIT extension. Rewrite the loop with break or a function; the error names the line.
• bit.* is still there and answers the same numbers.

If something in your game behaves differently and you cannot see why, tell us. For this one release the engine can still be built from source against LuaJIT (--features vm-luajit) to compare.

Pick your vector

Luau has a vector type of its own: three 32-bit floats carried inside the value, costing nothing to make and nothing to collect. Floptle positions are 64-bit on purpose — a solar system needs the range — so which one a vec3 is made of is now a project setting, Script vec3 in ⚙ Project Settings.

Every project that exists today is exact, and stays that way until you change it. New projects start fast. The methods, operators and constructor forms are identical in both; the one thing you write differently is changing a component:

v.x = 0            -- works in exact, raises in fast (naming the fix)
v = v:withX(0)     -- works in both, and the better habit either way

floptle lint --vec3 lists every line a project would have to change to switch, with the fix beside each. In fast, a script that builds a vector past the precision limit is told so in the Console, once, by name — you will not have to diagnose the jitter.

Measure it yourself

Three flags answer the question "where does the frame go" without a window:

floptle run --frames 600 --timing   # p50 / p95 / p99 / worst step, in real ms
floptle run --frames 600 --alloc    # how many KB of Lua heap a frame allocates
floptle shot --timing               # what each render pass cost on the GPU

--alloc stops the collector across a window in the middle of the run, which is the only way allocation can be measured — a per-frame reading of collectgarbage("count") under-reports by a wide margin, because a collection inside the frame eats part of what the frame allocated.

Upgrading

Nothing to do. The first time an existing project is opened in the editor, one line is written into its project.ron — script_vec3: Some(Exact) — recording the vector it has always had, so no later default can change it underneath a shipped game. If a script of yours used goto, it will name the line.

An exported game now looks like the game you were just playing in the editor. Models a script puts in a character's hand arrive with it, and the editor's own overlays stay behind where they belong.

Your build contains everything it renders

A script that swaps a model at runtime — node.model = "models/items/medkit.glb", the ordinary way to make one pickup node serve every item in a game — worked in the editor and quietly did nothing in an exported build. The node stayed in the world, kept its collider, kept its interaction prompt, and drew as nothing at all. The same silence covered mesh colliders, mesh shadow occluders and the navmesh bake: a wall you could walk through, a shadow that never fell, a level your agents could not find their way across.

The cause is worth one sentence, because it tells you where else to look. References like models/items/medkit.glb are relative to your project, and the editor happens to run from inside your project — so reading one as a plain file path worked there and only there. A build keeps your project in assets/ beside the executable and starts wherever the player launched it, so every one of those reads missed, and missed without saying so.

If a model of yours has ever been mysteriously invisible in a build and fine in the editor, this was why. Re-export and it will be there.

Nothing from the editor rides along

Three pieces of editor furniture were showing up in shipped games, permanently: the red PLAY — edits here are discarded on Stop banner across the top, the Esc — free the mouse hint along the bottom, and the no-active-camera warning. All three belong to the editor's Play/Stop cycle, which a build does not have. They are gone from builds and unchanged in the editor.

The Steam overlay

Games can now open the Shift+Tab overlay themselves, and hear when the player opens or closes it — enough to pause a single-player game while somebody reads their messages.

steam.openOverlay("community")          -- also "friends", "players", "settings"…
steam.openInviteDialog(lobby.id)        -- the invite panel for a lobby
steam.openOverlayStore()                -- your store page, or a DLC's by id
steam.openOverlayUrl("https://…")       -- the overlay's own browser

steam.onOverlayChanged(function(active)
  paused = active
end)

steam.overlayEnabled() tells you whether the player has the overlay switched on at all, so a Community button can show a plain link instead of doing nothing. A misspelt page name is refused with the valid names in the message, in any session — you do not need Steam running to find that typo.

Make it multiplayer

A new follow-along project takes the platformer from the first tutorial and puts two machines in it: what has to move to the host, what each player owns, and what to do about the half-second the network costs you. It is in the Learn tab beside the others, and in the online handbook.

Upgrading

Nothing to do. If you have shipped a build with a missing model, a missing shadow or an editor banner in it, re-export it — no project change is needed.

Your main menu's Quit button works. So does a Video tab: frame pacing and internal resolution are things a script can read and change now, which they were not.

app.quit(), and the rest of a settings screen

Every game has a menu with Quit on it, and until now there was no way to wire it — the button was either drawn dead or not drawn at all. There is a new app table:

What quit does depends on where the game is running, and they are honestly different things. An exported build closes, with your save.* data flushed first — somebody quitting from a settings menu expects the setting they just changed to have been kept. The editor stops Play instead and says so, because an editor that closed because a game under test called quit would take your unsaved work with it.

The rest of an options menu was already here and is documented together for the first time: audio through audio.track(name):setVolume(db), accessibility through access.*, the picture through the Post Processing node's own component, and rebindable controls through input.startRebind.

function start(node)
  app.setVsync(save.get("vsync") or "On")
  app.setRetroHeight(save.get("pixelHeight") or app.retroHeight())
end

A setting you change this way lasts for the session. These live in project.ron, which is the file that ships to everybody who plays, so pressing Stop puts it back — persist the player's choice yourself with save.*, the same way access.* works. And a mode setVsync does not recognise is an error rather than a shrug: a control that silently keeps the old value is a control that appears to work.

Not here yet: window resolution, fullscreen and monitor choice. Those are one question and it deserves answering properly. In a pixel-art game app.setRetroHeight is the "resolution" a player means, and it was already a live setting.

A broken project.ron says so

A project.ron the engine could not parse was quietly replaced with defaults. One misplaced bracket and the project opened with no title, the wrong frame pacing, none of its layers and none of its mixer — looking exactly like a project nobody had configured, with nothing anywhere saying the file had even been read.

It now names the file, the line and column, and says the project has opened with default settings and that nothing has overwritten it. A project with no project.ron at all stays quiet; that is a real state, not a fault.

The profiler stops blaming the wrong script

perf.scripts() times each script with a wall clock, so anything that happened while your script was on the CPU — a garbage collection, the operating system taking the core away — was reported as that script's cost. Scripts with no update at all were being listed with 12–21 ms peaks, which sends you to optimise a file that did nothing.

A script with no hook for a pass is no longer listed. A stall can still land on one that is running — that is what sampling a wall clock means — so docs/scripting.md now says which number to act on and what makes a worstMs spike.

While looking at that: if the collector is what you are chasing, the biggest source of it in most games is vectors. Every vec3 a script builds is an object, so a + b, v:normalized() and node.pos each allocate, while scalar reads like node.x and v:length() allocate nothing at all. A hot loop written in components rather than vectors produces no garbage, and that is usually the largest win available to a game script today.

Upgrading

Nothing to do.

Your bake is there when you open the project. A query says what it hit and what that thing is made of. And you can look at a particle effect without opening the editor.

Your navmesh survives being closed

Bake a Nav Mesh, save, close the editor, open the project again — and the bake was gone. Not lost: the file had been sitting beside the scene the whole time. It was never loaded, and nothing said so. An unloaded navmesh looks exactly like one you never baked, so the only thing to do was press Bake again, every session.

Light Probes had it too. A scene came back with no bounce light for the same reason, with the same silence.

Opening a project through File ▸ Open Project always worked. Launching the editor on a project — from the Hub, or from the command line, which is how a project actually gets opened — did not. Both load the bakes now, and so does a scene a script switches to with scene.load while the game is running: a game that changed levels had been pathing on the previous level's navmesh.

A bake written by an older version of Floptle is remade once, on its own, the first time you open the level, and the Console says so when it happens.

What am I standing on?

A footstep, an impact decal, a splash — each of them needs to know what the ground is made of, and the engine could only tell you which node you hit. One building is one node, and its brick, its grass and its floorboards are three materials on it, so a whole mansion answered "brick".

Every query hit now carries material: the name of the material slot it landed on, exactly as you typed it and as the Inspector shows it.

local hit = spherecast(node.pos, vec3(0, -1, 0), 0.14, 1.2, { layers = "Level" })
if hit and hit.material == "Boards" then
  audio.play("audio/footstep_wood.ogg", node)
end

raycast, spherecast, capsulecast and overlapSphere all answer it. It is nil for anything with one surface — terrain, a Collidable cube, an imported model, another character — because a name invented for those would be right for map meshes and quietly wrong everywhere else. Use hit.node:material() there.

Reading it costs a lookup; not reading it costs nothing. A line-of-sight ray that only wants hit.distance pays for none of this.

raycast also names the node it hit for level geometry now. It used to answer nil for anything that was not a physics body, while spherecast — same fields, same documentation — named it. If you tried a ground check with raycast, got nothing, and concluded the engine could not tell you, it can.

Look at a particle effect without opening the editor

floptle vfx --effect Sparks

One effect, rendered to PNGs across its own timeline, with no window:

Sparks: visible over 0.141s, 5 frame(s) at 480x480
  t=  0.028s    1.5% of frame  Sparks.t00028ms.png
  t=  0.056s    1.9% of frame  Sparks.t00056ms.png
  t=  0.084s    2.0% of frame  Sparks.t00084ms.png
  t=  0.113s    1.9% of frame  Sparks.t00113ms.png
  t=  0.141s    1.4% of frame  Sparks.t00141ms.png
  all of them: Sparks.sheet.png

A single frame cannot show an effect. A burst is a blank frame before it fires and drifting smoke after it, and both are correct — so this takes a spread of moments and tiles them into one contact sheet. The camera is identical in every frame, so the start really can be compared against the middle. --at 0.084 renders exactly that moment, framed close.

Which moments are worth photographing is decided by looking: the effect is rendered at thumbnail size across its whole timeline first, and the frames are spread over the part where something is actually on screen. A quarter-second burst gets five frames of that quarter second rather than four frames of the empty second after it.

--scene renders it inside a level, at the node that plays it and through that scene's camera; --background sets the colour behind it otherwise. Each frame reports how much of the picture the effect covers, measured from the picture itself — so a frame with nothing in it says so, instead of leaving you to wonder whether the effect or the renderer was at fault.

Upgrading

Nothing to do.

Characters stop treating every ledge as a wall. The navmesh now works out where they can drop down and jump across, on its own, from the shape of your level.

A navmesh is a surface, and a surface stops at every edge. Until now the only way to say "and you can get down here" was to place a Nav Link by hand — one per ledge, in a level with hundreds, all of them moving the moment you moved the geometry. So nobody placed them, and characters walked the long way round a knee-high step or gave up entirely.

Drops and jumps, found for you

The Nav Mesh node has two new numbers under how the ledges are joined up:

• drop height — the tallest ledge a character steps off deliberately. Any ledge between the step height and this gets a one-way link off the edge.
• jump distance — the widest gap it will clear. That gets a two-way link, because a gap you can jump you can jump coming back.

Both are on by default, at a metre and a half and two metres. Set either to 0 to switch that kind off and go back to placing every crossing by hand.

On a real 23,000 m² level, this found 651 drops and 55 jumps where there had been none.

The bake will not invent a character that climbs: ground above a ledge is still a wall, and a ladder is still a Nav Link you place. It also will not hop over a wall, and it will not cross ground you carved out with a Nav Area — carving is you saying nothing may walk there, and a tool that argued with that would be worse than no tool.

A character that does not leave the floor refuses a whole kind of crossing in the question rather than by needing its own bake:

local cart = nav.agent(node, { filter = { canJump = false, canDrop = false } })

While an agent is crossing, agent.linkKind is "drop", "jump" or "placed" — so one rule picks the fall animation, the vault and the ladder climb, rather than six hundred link names.

The overlay answers the question it is for

The one thing a navmesh picture is for is are these two pieces of ground joined? — and it was coloured by how the bake grouped the floor, before any link was counted. A balcony and the floor its drop lands on came out two colours while a character walked freely between them.

It is coloured by what a character can actually reach now. Ground you can get around is one colour; ground you cannot is another. Links are drawn as arcs whose shape is the crossing: a drop leaves the ledge flat and falls away, a jump bows over its gap, a ladder goes straight. Amber for a drop, green for a jump, blue for one you placed, red for one whose end missed the floor.

Agents follow the same curve they are drawn on, so a character dropping off a ledge falls instead of sliding down an invisible ramp.

"N separate areas" in the Inspector counts the same thing — pieces with no way between them at all — and now says how much of the walkable ground the biggest piece holds. A count on its own could be a level with 150 cupboards in it or a bake that has shattered; the share is what tells them apart.

Specks are thrown away

A real level bakes hundreds of scraps of walkable ground — a window sill, the top of a crate, a triangle of floor behind a pillar. Nothing can reach any of them, every one is an island in the count, and each is somewhere a character can be dropped by mistake when you ask for the nearest point on the navmesh.

smallest patch (1 m² by default) throws them away. The biggest piece is never thrown away, however small it is, so a bake of a small level is still a bake of that level. The level above went from 494 separate pieces to 156.

The overlay stopped getting stuck

Turning gizmos off used to leave the navmesh drawn on screen, frozen in place, until you deselected the node. It clears with everything else now.

Big levels also draw far less: anything off screen is skipped rather than sent to the graphics card every frame, so looking closely at a navmesh no longer costs more than looking at all of it.

Settings that quietly did nothing now say so

Two of the new numbers have a threshold below which they are exactly equivalent to zero, and neither is visible from the slider. A drop height inside the step height finds nothing, because the lip is walked over. A jump distance under twice the agent radius finds nothing, because erosion has already pulled the walkable surface back by the radius at each side — jump distance is measured between the edges of the navmesh, which is what you see in the overlay, not across the hole in the floor.

Both are named in the Inspector and the Console, with the number to beat.

Baking a navmesh without opening the editor

floptle bake nav [PROJECT] [--scene S] [--json]

No window and no graphics card needed. It was the one bake with no way to run it from a script, which meant a level whose geometry is generated could never have its navmesh generated too.

Upgrading

Your navmesh is baked again, once, the first time you open each scene. The format changed to carry what kind of crossing each link is. The editor does it for you and says so; nothing is lost.

Two defaults change what an existing level bakes, and both are sliders on the Nav Mesh node if you want the old behaviour:

• Drops and jumps are on. Routes that used to go the long way round a ledge now take it. Set drop height and jump distance to 0 for none.
• Patches under 1 m² are dropped. If your game deliberately puts characters on something smaller than that, set smallest patch to 0.

When a script asks for something that isn't there, the engine says so.

Nearly every hour lost to Floptle scripting has had the same shape: a call answers nil, nothing is reported, and the symptom turns up three scripts away as a value that was never set. This release goes through the calls that do that most and gives each of them a voice — and fixes the two lookups that were answering nil when they should have found something.

Scripts in folders answer to their own name

If your script lives at scripts/forgery/playermovement.lua, this now works:

local movement = findTagged("Player")[1]:getscript("playermovement")

Before, only the full "forgery/playermovement" found it. The short name — the one on the editor tab, in the Inspector row, and in front of every line that script prints to the Console — matched nothing and returned nil without a word. Both spellings work now, everywhere a script is named by name: getscript, findScript, findScripts, and scriptref params.

If two folders hold a file with the same name, the short name is refused and both are named, rather than one being picked for you.

The node calls are spelled like the rest of the API

node:getChild, node:getParent, node:getScript, node:getComponent and node:getSorting — camelCase, like hasTag, lookAt, distanceTo and every other node call. These five were the only lowercase ones, and typing the spelling the rest of the API taught you died with "attempt to call a nil value". The lowercase spellings still work and always will; nothing in your project needs changing.

Mistype any other node call and it now tells you the one you meant:

a node has no `HasTag` — did you mean `hasTag`?

Lists start at 1, and say so

findTagged("enemy")[0]   -- this list is 1-based, so [0] is never one of its
                         -- elements — the first is [1] and the last is
                         -- [#list]. It holds 3.

[0] used to hand back nil, which then failed on the next line as "attempt to index a nil value" — pointing at the wrong place and saying nothing about the cause. Asking past the end still reads nil, so if findTagged("boss")[1] then is still how you check whether there are any.

Lookups that find nothing name what IS there

Hero:getscript("helth") found nothing — that node carries health, inventory.
Hero:getcomponent("rigidbody") found nothing — that node carries RigidBody,
  Material. (did you mean `RigidBody`?)
findScript("spawner") found nothing — no node in this scene carries a script
  by that name. This scene runs: enemy, hud, player_controller.

Each is said once, however many frames ask. A script that is attached but switched off now says that too, instead of reading as a script with no such function — two problems that looked identical and want opposite fixes.

Writing a field a node doesn't have, on a handle from find or getChild, says so as well: those handles are rebuilt each time you ask for one, so the value was going nowhere.

Console and terminal

log(...) and print(...) were each printing to the terminal twice, which reads as your code having run twice. Once now. A dedicated server prints them at all now — it was the one place a script could talk and nobody was listening, and its warnings were going the same way.

Items on a bone stay where you put them

A node attached to a bone was placed correctly only while it was also a child of that model in the Hierarchy — which is how the editor sets it up, and nothing held it afterwards. Move it anywhere else in the tree and it still tracked the bone's motion perfectly while sitting in the wrong place. It is placed by world position now, so it lands on the bone wherever you file it.

Selecting a part opens its material

Click a part of a model — in the viewport or in ◈ Objects & Rig — and that part's material editor opens while the others close. A model with a dozen parts no longer means scrolling past eleven open editors to reach the one you just clicked. Open a second to compare, or close the one you're on, and it stays that way until you select something else.

Upgrading

Nothing to do. Every older spelling still works.

A script can now see who's on Steam with them, and let them know what you're up to.

Friends and presence

for _, friend in ipairs(steam.friends()) do
  if friend.playingThisGame then
    print(friend.name, "is also playing —", friend.state)
  end
end

steam.setRichPresence("status", "Boss fight, 2 players")

steam.friends() returns the local user's friend list — each entry's id, name, online state ("online", "away", "busy", "snooze", "looking to trade", "looking to play", "invisible", or "offline"), and whether they're currently playing this same game. steam.setRichPresence(key, value) sets a status line friends see on your name in their own friend list; steam.clearRichPresence() clears it, and steam.friendRichPresence reads a specific value a friend's own game has set for them.

Not in this release: group and clan membership — Valve's own current toolkit for this engine doesn't support it. Inviting a friend, and having a game react to being launched from an invite, are their own upcoming pieces — this release is about seeing and being seen, not joining yet.

Upgrading

Nothing to do.

Achievements, stats and Cloud saves reach Lua, and a game can ask whether it's running on Steam Deck or in Big Picture mode.

Achievements and stats

if steam.statsReady() then
  local ok, err = steam.unlockAchievement("FIRST_WIN")
  steam.setStatInt("wins", steam.statInt("wins") + 1)
end

steam.unlockAchievement/clearAchievement/achievementUnlocked cover unlock/clear/query; steam.achievementGlobalPercent is the share of players worldwide who've earned one; steam.achievementName/achievementDescription read Steam's own localized text for it. steam.statInt/setStatInt and statFloat/setStatFloat cover int/float stats. Every write goes into a local queue and reaches Steam's servers on an automatic batch every few seconds — call steam.flushStats() if you want it sent right now instead — and a failed send is never silently lost; it stays queued and the next batch tries again. Every write also answers ok, err rather than just failing quietly, and err names the actual problem — a mistyped achievement ID says so, rather than leaving you to guess. steam.resetAllStats(achievementsToo) wipes everything for testing.

Not in this release: average-rate stats and achievement-progress notifications aren't wired up yet — Valve's own toolkit for this engine doesn't currently support either, and closing that gap is its own piece of work. Achievement icons are in the same boat as avatars (see the last release): nothing in the engine can turn raw image bytes into something a script can put on screen at runtime yet.

Cloud saves

local ok, err = steam.cloudWrite("save1.dat", data)
local data, err = steam.cloudRead("save1.dat")

steam.cloudWrite/cloudRead/cloudDelete cover the basics; cloudFiles() lists everything currently in Cloud storage, cloudFileExists and cloudFileTimestamp let you check before you read, and cloudForget removes a save from the Cloud while keeping the local copy — for a player who wants one save to stop syncing without losing it. steam.cloudEnabled() and setCloudEnabled toggle Cloud for this game specifically; the account-wide setting is read-only here, same as it is anywhere else — that one belongs to the player, not the game. There's no built-in notion of a save "conflict" to resolve for you: cloudFileTimestamp is there so you can compare it against your own local save's modification time and decide what "newer" means for your own game.

Not in this release: Steam's storage-quota numbers aren't exposed yet.

Knowing where you're running

steam.uiLanguage() reads Steam's own current UI language — a reasonable default for your own localization. steam.isSteamDeck() and steam.isBigPictureMode() tell you when to assume no keyboard and mouse, or to lean into a bigger, couch-friendly layout.

Upgrading

Nothing to do.

The first slice of Steam support: a script can check whether the game is actually running through Steam and, when it is, who's signed in. Posing a rigged character also stopped burying the model in bone lines.

Scripts can check whether they're running on Steam

Set a Steam App ID in ⚙ Settings ▸ Game, and floptle run --steam, a floptle play, or an exported/served build will try to talk to Steam. steam.available() is always safe to call — it's false, never an error, in the editor's own Play-mode preview, on a machine with no Steam client running, or on a project with no App ID set at all. Once it's true:

if steam.available() then
  print(steam.personaName(), "is playing, id", steam.localUserId())
end

steam.onPersonaChanged(function()
  -- the signed-in user's name changed since the last frame
end)

steam.buildId(), steam.installDir(), steam.betaName(), steam.isFamilyShared() and steam.isCybercafe() round out what a game can ask about its own build and license. No App ID set yet? floptle run --steam still works — it falls back to Valve's public test app (Spacewar), so trying this out never needs a partner account.

This is the foundation, not the whole of Steam support — achievements, the overlay, cloud saves, friends, Workshop and the rest are still ahead. Avatars aren't drawable yet either; the engine has no way yet to turn raw image bytes into something a script can put on screen at runtime, Steam or not.

Posing a bone no longer buries the model in lines

Selecting the Armature row stopped drawing a fan of clickable lines across the whole model back in the last release — but selecting an ordinary bone under it, which is what posing a character actually means doing, still did. Every bone now draws and clicks cleanly on its own, whatever you've selected.

Upgrading

Nothing to do. A project with no Steam App ID set behaves exactly as before.

A freshly placed Shader Graph node can be wired the moment it appears, a selected Armature stops burying the model in bone lines while you're animating, and the Gizmos menu can turn everything off in one click.

A new "combine" node in the Shader Graph can be wired right away

Dropping a combine node in from the node picker used to show a single locked-looking value with no way to reach its individual lanes — the only way to build a vec4 from separate values was to hand-type the shader as text. Each lane (x/y/z/w) is its own wireable input from the moment the node appears, and the quick number / vec2 / vec3 / vec4 / color type switch is still there for as long as every lane is left at its default.

Selecting the Armature no longer buries the model in bone lines

Clicking a rig's Armature row — rather than one of its actual bones — drew every bone in the skeleton as a solid fan reaching out from a single point, and those lines could be clicked and dragged like the bones underneath them, making it hard to select the bone you actually meant to pose. The Armature now draws faint and dashed for context only; clicking those lines does nothing, and the Armature itself is only reselected by clicking its own handle at its actual position.

An "All off" button in the Gizmos menu

The Scene view's Gizmos menu (the ⏷ next to Gizmos) had a button to turn every gizmo category on at once, but none to turn them all off. It does now.

Upgrading

Nothing to do.

A part of a model can finally wear its own shader, two Inspector panels stay fully on screen instead of running off the edge, and the shader language picked up the math vocabulary other engines already have.

A part's own shader actually draws now

Giving one part of a model its own material — the override button next to a part in ◑ Model materials, or ◑ Override material for this object in the Inspector — let you pick a custom shader for it, but the shader never took effect: the part kept its plain material look no matter what was set, and the shader panel got stuck reading "compiling…" forever. A part's own shader now compiles and draws correctly, independently of whatever shader (if any) the rest of the model is wearing — so one arm can be glass while the rest of the character stays ordinary.

Sliders stay inside the panel

A slider with a caption — bounce, friction, radius, and dozens more across the Inspector — could draw its label past the edge of a narrow panel instead of shrinking to fit, most visible in the Rigidbody component's stack of sliders. Captions now shrink to an ellipsis before they'd run off the side, the same way every other label in the Inspector already does.

New shader math: lerp, remap, rotate, refract

The shader graph and the .flsl language gained five functions: lerp (the same blend mix already did, under the name most people reach for first), inverseLerp and remap for turning one range of values into another — health into a fade, distance into brightness — rotate2D for spinning a UV or a point without hand-building the matrix, and refract alongside the existing reflect for bending a ray through a surface.

Upgrading

Nothing to do.

Four fixes to the tools you use to check what's actually happening in your project — a screenshot, a performance count, a light budget, a frame rate — all told the truth a little less often than they should have.

Screenshots show what's actually there

floptle shot, the command-line tool that renders a picture of a scene without opening the editor, skipped a level's map-tool geometry entirely — a level built with walls, floors and ceilings photographed as an empty room with only its props and characters floating in it. Screenshots now match what you'd see playing the level.

The editor tells you when a scene has too many lights

A scene can only light with sixteen point lights at once — always true, and now said out loud. Past sixteen, the ones actually contributing light near the camera win the remaining slots and the rest cost you placement time for nothing. The editor now warns you, once per scene and naming the count, instead of quietly picking sixteen and staying silent about the rest.

perf counts you can trust

The perf scripting API — for a project to check its own frame cost from Lua — could answer 0 for draw calls and lights even while the game was running normally, because part of the count simply wasn't being kept for every view. Those numbers now reflect what's actually on screen, in the editor and from the command line alike.

The editor knows when your display is the slow part

On some machines, a scene that costs almost nothing to render can still show a low, flat frame rate because of how the display is presenting frames — not because anything in your project is slow. The performance panel and the console can now tell the two apart and say which one it is, along with the setting to try (Project Settings ⏵ Rendering ⏵ Frame pacing).

Upgrading

Nothing to do.

A room full of settled props stops costing what a room full of falling ones does, a streamed level actually finishes its first navmesh bake, water reacts the moment it exists, and packages get a read-only look at tilemaps and a warning before you install something.

A room full of resting props costs almost nothing

Two hundred ordinary Dynamic props — mugs, chairs, litter — sitting completely still could cost the entire frame budget several times over, because nothing in the physics solver ever stopped paying for them. A prop mid-flight and a prop that has sat untouched since the level loaded were the same amount of work.

A body that has been slow enough for long enough now goes to sleep: no gravity, no collision solving, nothing, until something actually touches it — a moving platform, a grabbed prop being let go, a script writing its velocity, or the ground underneath it disappearing. A settled room of props now costs close to what the same props cost as static geometry, not what a room of things actively falling does. Nothing changes in how you set a body up; sleeping is automatic and invisible from a script's point of view.

A streamed level finishes its first navmesh bake

On a level that streams its geometry in as you move rather than shipping it all baked ahead of time, automatic navmesh rebaking could get stuck re-measuring the whole scene on nearly every tick — and, separately, a level with no hand-placed geometry to bake at editor time had no way to get a navmesh at all until something forced one.

Automatic rebaking now waits for the level to actually hold still before it re-measures anything, however long that takes, and the very first bake on a level with nothing baked yet builds a mesh instead of refusing. Dragging a wall and waiting now genuinely produces a fresh navmesh; it isn't a special case any more.

Water reacts the moment it's there

Spawning, moving, resizing, or destroying a water volume while a game is running could take a frame or more to reach the physics solver, so a pool that appeared mid-session could be there to look at and not there to swim in — or the other way around.

Water is rebuilt every frame now, the same way gravity already was, so what you see and what the solver knows about agree from the moment a volume exists. A water volume can also carry a Material of its own — its own specular highlight and its own alpha — and can be exempted from a project's retro dithering the same way any other material can.

Packages can read a level's tilemap

An editor package could see everything else about a 2D level except its tilemap, which meant a level tool couldn't tell where the floor actually was. tilemap.of(id) hands back a read-only handle — grid size, tile size, tileset, and per-cell lookups by index or by world position, including solidity and tags — documented alongside the rest of the package API.

The package browser warns you before you install

The catalogue now carries what a package's manifest declares it needs — network access, file access outside its own folder, opening your browser — and the Browse tab shows it before you install, not only after, when the consent dialog would otherwise be the first you hear of it.

Smaller things

• A script calling find("Lighting") used to always get back nothing; the Lighting node has a Transform like every other node now, and find sees it.

Upgrading

Nothing to do. A project with resting props, a streamed level, or water volumes just runs better; existing scripts and packages are unaffected.

The editor stops under-reporting and under-doing. Your navmesh and your baked lighting are still there when you reopen the project, the frame counter reports a number you can act on, mouse look is smooth at high frame rates, and setting a collision layer applies to everything you selected rather than to one node.

Your bakes are still baked when you come back

Bake a navmesh, save, close the editor, open the project again — and the navmesh was gone. Baking a level felt like something you had to redo every session, because it was.

The bake was on disk the whole time, beside the scene, exactly as intended. Opening a scene loaded it; opening a project — which is what happens when the editor starts, and when you switch projects — did not ask for it. The same was true of baked lighting, so a level opened at startup came up with no bounce light either.

Both load with the project now. Nothing to do on upgrade: open your project and the bakes you already made come back. If you have been rebaking every session, you can stop.

The frame counter tells you the truth

A scene that plays like a slideshow could report hundreds of frames a second, and the number was not a rounding error — on a real capture, a genuine 21 frames a second read as 481.

The counter averaged the wrong thing. It smoothed frames-per-second, and the average of a rate is not the rate of an average: it gets dragged toward the fast frames, so the choppier the scene, the more flattering the number. It now measures how long frames take and converts at the end.

The title bar also carries a 1% low beside the average — how long your worst frames take. That is the number that matches what a stutter feels like, and it is the one an average cannot show: a 40 ms hitch once a second adds well under a millisecond to a 60-frame mean.

Finding out why a fast scene feels slow

The ⏱ button opens ⏱ Frame cost, which now opens with a frames arriving line: the average, the 1% low, and what your display is actually doing.

The engine smooths out the small timing noise between frames, because that noise is what turns steady movement into shimmer. Doing that requires knowing your monitor's refresh rate — and on some setups it never got one, so the smoothing was switched off for the whole session with nothing to say so. That is fixed, and when the smoothing genuinely cannot apply, the panel now says so and shows both numbers: what the display reports, and how fast frames are really arriving. Usually it means the window is on a different monitor than the one being reported, or nothing is pacing to the display at all.

The panel also flags it when your worst frames take more than twice the average, which is a stutter whatever the frame rate says.

Mouse look is smooth above 240 fps

The camera got jittery at exactly the frame rates where it should have been smoothest. A mouse axis reports movement per second so that a script multiplying by frame time cancels it back out and a given hand movement turns you the same amount at any frame rate — but that cancellation stopped being exact past 240 frames a second, and uneven frame times went straight into your camera.

A fixed mouse movement now turns you the same amount at 60 fps and at 600, and a single long frame still cannot fling the view. Nothing to change in your scripts.

Setting a collision layer applies to everything you selected

Select twenty crates, pick a collision layer, and one crate moved — even though the Inspector says an edit there applies to all of them.

It applies to all of them now, as one undo step. When the selected nodes do not agree on a layer the dropdown reads — mixed (5) — instead of claiming they all have the primary's; picking a layer from there puts the whole selection on it, including the layer the primary already had.

Changing a layer asks about the children

A collider usually hangs under the node you just changed, so moving only the parent leaves the pieces that actually collide on the old layer — a node that reads as changed and behaves exactly as it did.

Changing the collision layer on a node with children now asks whether the children come too, with the counts in the buttons, and changes nothing until you answer. Nodes with no children are not interrupted.

Upgrading

Nothing to do. Open your project once and your existing navmesh and lighting bakes load with it.

Materials on models, sorted out. A material you put on a model now actually replaces what the model came with, one part of a model can be given its own look from a script, and a model's own textures can be taken out of it as files. Plus a tint that leaves everything else alone, and a sprite you can flip in one line.

A material you apply is the material you get

Putting a Material on an imported model and pointing it at a texture left the model wearing its old picture. Its colour tinted, its emissive glowed, its roughness took — everything except the thing you could see.

A Material on a model now supersedes the materials the model was imported with. Every part draws with it, textures included, so a material naming no texture draws untextured. That is what the component is for: this whole thing is made of THIS. A model that already looks right needs no Material at all.

To change one part instead, use the model's own material list — or, now, a script.

On upgrade: a model wearing a node Material will look different, because it is finally wearing it. If you had one on there to nudge a colour or add a normal map, either move it to the parts you meant (◑ Model materials in the Inspector) or replace it with a tint, below.

Dressing one part of a model, from a script

for _, slot in ipairs(node:materials()) do
  print(slot.material, slot.object, slot.textured, slot.overridden)
end
-- Clothing  Torso#2    true  false
-- Head      Head#2     true  false
-- Pants     RightLeg#2 true  false

node:material("Clothing").texture = "art/shirt.png"
node:material("Pants").texture    = "art/jeans.png"

node:materials() says what a model's parts are called; node:material(name) is one of them, read and assigned. Every field of a material is there — the texture and the surface maps by path, color / emissive / specular / rim as colours, and alpha, roughness, metallic, emissiveStrength, unlit, fog, cell as values.

Ask before you address: a model that repeats an object name has it renamed on import (Torso becomes Torso#2), so a guessed name reaches nothing. Every part answers to two — its object, which is exactly one part, and its material, which is every part wearing it. A character's Clothing is usually its torso and both arms, which is the group a clothing system wants.

A material's fields read back now, too. mat.texture used to answer nil however many times it had been set, so a script could tell a material what to wear and never ask.

Taking a model's own textures out of it

A .glb keeps its images inside itself, where nothing else can point at one. Select a model — or its node — and press ⬇ Extract textures: each material's image is written beside the model as <model>_textures/<material>.png, and from then on it is an ordinary project texture. Paint over it in the 🖼 Image tab, assign it to anything, use it as the base layer a costume is drawn on.

Overriding one part of a textured model extracts that part's texture on the spot and starts the override wearing it, so "override" never means "go blank".

The same model, but red

node:setTint(color(1, 0.3, 0.3))     -- hit flash
node:setTint(teamColor)               -- one prefab, four teams
node:setTint(color(1, 1, 1), 0.4)     -- ghosted while being placed
node:setTint()                        -- back to normal

A tint is multiplied over whatever a node already draws, so the model keeps its own textures and each part keeps its own colour. It needs no Material and does not create one. In the Inspector it is the ◐ tint swatch beside a model's material list; white is no tint.

It is a component, so an animation clip can key it — a hit flash is a tint faded back to white over a fifth of a second — and a script can read it back with node:getcomponent("Tint").

Flipping a sprite is one line

local sp = node:sprite()
sp.flipX = mx > 0

node:sprite() is a Sprite's own drawing numbers as something you hold: flipX, flipY, cell, ppu, size, pivotX, pivotY, each readable and assignable. Reads answer with what you last wrote, so asking which way a character is facing is a question you can now ask.

vec3 and vec2 also answer to :magnitude(), the name most engines use for :length().

A table of options written as a list is now refused. node:setSprite{ 8, 1, true } set nothing at all and said nothing about it — every option is read by name. It now tells you so, and names the keys it reads. This applies to every call in the API that takes an options table.

Shots and headless runs tell the truth

floptle shot drew a scene in the textures its models were imported with, whatever their materials said, and photographed planets before their ground had loaded. It waits for the world now, and says on the error stream when it ran out of patience rather than handing you a finished-looking picture of an unfinished world.

floptle run reported the full span of simulated time even when it had simulated none of it — a paused session steps happily at a dt of zero. It reports the time it actually advanced, and says when the two differ. Runs of a project with generated terrain now advance at all.

Games that build their world as the player travels can ask terrain.busy() whether the background worker is occupied — true from the moment a fill is queued, so building one system and waiting for quiet before the next is a loop you can write.

Smaller things

• A library script has its settings before anything calls it. A script with no start and no update — one that exists so others can call into it — held params = nil until something happened to tick it, so the first call into it raised. Whether it raised depended on the order nodes sat in the scene file.
• ⊕ Transform ▸ … ▸ Reset transform puts a node back to the origin, no rotation, scale 1. Copy and paste values were already there.
• The right edge of the panels is no longer under the scrollbar. A slider's label could be cut to its first letter, and the … menus sat half over the edge.
• node:getcomponent("Sprite").flipX reads back as a boolean. It was a number, and 0 is true in Lua — so "is it flipped" was always yes.
• Headless runs no longer warn that perfectly good models have nothing to draw.

Upgrading

Open your project once and the editor updates its editor-support files.

The one thing to check is any model with a Material on the node: it now wears that material instead of blending with what it came with. The Inspector's ◑ Model materials list is where to put it back per part, and ◐ tint is what to reach for if what you wanted all along was "the same model, but coloured".

The loose ends from the command line, closed: baking light probes no longer opens a window, the dedicated server has a verb, and a machine can be asked whether it will run the things that need a screen. Plus a spritesheet animation fix and a renderer that builds on OpenGL.

Animating a sprite's frame works

Attach an animation controller, press ● Record, click through the frames of a spritesheet — the keys landed correctly and playback never changed the picture. Every key was right, every value was right, and nothing moved, which reads as spritesheets being broken.

A ▫ Sprite carries its own frame number and ignores its material's copy. The timeline was keying the material's, so playback wrote a number nothing draws. Clips you already recorded start working; there is nothing to re-record.

Baking light probes no longer needs a window

floptle bake gi said "and exit" and did the opposite — it opened the editor and baked there, so on a build machine with no display it did not bake at all.

floptle bake gi                       # bakes and exits
floptle bake gi --scene arena --json

It runs the same bake the editor runs, back to back instead of a slice per frame, and writes the result beside the scene. It still needs a graphics adapter, because it photographs the scene from every probe. A scene with no enabled Light Probes node says so instead of baking nothing.

--bake-gi is unchanged and still opens the editor, so anything driving the old flag keeps working.

The dedicated server has a verb

floptle serve --port 7777
floptle serve --relay relay.example.com --scene arena --tick 30

The same server floptle-runtime --server runs — this is just where to type it, so one command line covers the engine. A scene with no Networked nodes, or a rollback scene (which is hosted by one of the players, not by a dedicated server), is refused by name rather than served empty.

Ask a machine what it can do

floptle doctor

floptle 0.71.0
  graphics    NVIDIA GeForce RTX 4060 (discretegpu)
  backend     Vulkan
  rendering   yes — shot, bake gi, open and play will run here

It answers by building the renderer, not by asking the adapter what it supports, because those turn out to be different questions. It exits non-zero when the machine cannot render, so a build script can check before it reaches for shot, and when it cannot it lists what still runs without a screen.

The renderer builds on OpenGL

On a machine with only an OpenGL adapter, the renderer could not be created at all — so shot and the editor itself were unavailable there, and the failure looked like a crash rather than an answer. Two shaders were sampling one texture with two samplers, which OpenGL does not allow. Both fixed, with no change to what anything looks like.

If you are on hardware where Floptle would not start, this is worth another try.

floptle check notices a stale spritesheet grid

A scene saved before its textures were sliced — or one whose materials were built by a script — carries a sheet grid the project's own import settings contradict, and it draws as a sprite showing its whole sheet instead of one frame. check reports it now, naming both grids and the frame it would move to.

It does not correct the files, on purpose: writing a scene back reformats it and drops every comment in it, and a command you are told to run after every edit should not do that. Opening the project in the editor and saving applies the correction, which is what the warning says.

A picture with the light in it

floptle shot was rendering before the scene's baked global illumination had been uploaded, so every picture was taken with the bounced light missing.

Upgrading

Nothing to do. Scenes, projects, clips and scripts are unchanged, and every existing flag behaves as it did.

Floptle has a command line. You can now find out whether a project loads, whether it runs, what it looks like and what is inside it — and change it correctly — without opening the editor. That means your CI can do those things, and so can an AI assistant working in your project folder alongside you.

Find out whether it works, without opening it

floptle check                    # does everything still load?
floptle run --frames 120         # play it for two seconds and report what raised

check loads every scene, prefab, effect and material and reports every reference that does not resolve — a parent pointing at the wrong node, a material naming a texture that is not there, a node carrying a script with no file behind it. A .ron file that parses is not a scene that works, and until now the only thing that could tell you the difference was opening the project.

run is the bigger gap closed. It plays the project for a fixed number of frames with no window at all — the real scripts, the real physics — and reports every warning, error and print with its file and line, exiting non-zero if anything raised. Pointed at a real game it found a script indexing a nil value on the first try.

Both are safe to put in a build pipeline. Neither needs a display.

See what it looks like

floptle shot --out look.png
floptle shot --scene arena --camera "Chase Cam" --size 1920x1080

One frame through the scene's active camera, straight to a PNG. It goes through the same rendering path the editor's own Game view uses, and it applies the project's post-processing — bloom, vignette, ambient occlusion, posterise, colour grading, depth of field, your own post shaders, and the retro presentation at its own resolution. What lands in the file is what the editor would show you.

Read a project, and change it correctly

floptle inspect                          # what this project is
floptle inspect --scene first            # its nodes, as a tree
floptle inspect --select Player --json   # one node's whole document
floptle exec fix.lua                     # change it, through the editor's own API

inspect reads the files, which is what you want when you are about to edit them, and it builds the hierarchy the way the engine does rather than the way the file happens to be ordered.

exec runs a Lua file against the project through the same scripting API the editor's own extensions use — scene.find, scene.setPos, scene.add, ed.saveScene(). Use it instead of hand-editing scene files when the change is structural: node ids, parent links and defaults come out right because the same code does it. Nothing is written unless the script calls ed.saveScene(), and if it changes something and forgets, the run tells you rather than losing it.

Look up what a script can call

floptle api setSprite
floptle api "collision"      # search the descriptions too

Every name a script can reach, with what it does and an example, searchable by part of a name or by a word from the description. It exits non-zero when nothing matches, so floptle api node:doesNotExist answers a yes/no question.

Every command describes itself

floptle help --json

The whole surface as one document: every command, its arguments, the values each one accepts, what comes back, what each exit code means, and two flags worth knowing before you run anything in a container or over SSH — whether the command needs a display, and whether it will write into your project.

It is generated from the same table the parser is built from, so it cannot describe a command that does not exist, and a command cannot exist without appearing in it.

Every flag that worked before still works. --export, --new, --migrate, --play, --version and the rest are unchanged; the verbs sit alongside them. If you drive Floptle from a script today, nothing you wrote has to change.

New projects come with a guide

floptle new now writes an AGENTS.md at the project root — a short page telling an AI assistant which commands exist, what the project's folders are for, and two things about scene files that otherwise cost an afternoon. It is written once and never touched again, so edit or delete it freely.

A lit sprite draws one frame, not the whole sheet

With 2D lighting in the scene, a ▫ Sprite on a spritesheet drew the correct frame and a squashed, stretched copy of the entire sheet on top of it — usually crowded into one corner, wherever that sheet's filled cells happened to land. Changing the frame moved the sprite underneath and left the ghost where it was. Turning the lights off made it disappear.

2D lighting works by correcting the frame that was already drawn: it measures the difference between what is on screen and what the lights say should be, and adds that difference back. It was measuring against the whole sheet rather than the one frame, so the difference it added back was the rest of the sheet.

The same reading decided which pixels of a sprite block light, so a sprite's shadow was cast by the shape of the whole sheet rather than by the frame you can see. Both are fixed together.

This is the other half of the spritesheet fix in v0.69.1. If you upgraded to that one and a stretched sheet was still sitting over your sprites, this is what was left. Tilemaps were never affected, and neither is anything in a scene without 2D lights.

What isn't in it

There is no floptle serve yet — the dedicated server still has its own command line. check reports problems but does not fix them. And --bake-gi still opens the editor to do its work despite what its help says.

floptle shot needs a Vulkan, Metal or DirectX 12 adapter. On a machine with only OpenGL it cannot build the renderer, and it now says so and stops instead of looking like a crash. Everything else on this page works with no graphics adapter at all.

Upgrading

Nothing to do. Scenes, projects, clips and scripts are unchanged, and every existing flag behaves as it did. Existing projects do not get an AGENTS.md; if you want one, floptle help --json is the page it would point at anyway.

The follow-up to the 2D release. Spritesheets reach the sprites wearing them, a 2D camera can land on whole pixels, a sprite's own numbers can be keyframed, and the panels that had run past the edge of a narrow dock no longer do.

Keyframe what a sprite does with its picture

⏱ Animating ▸ ✚ Property ▸ Sprite ▸ Node.

Sprite ▸ frame says which picture. The new lanes beside it say what this node does with it:

• ppu and size — squash and stretch.
• pivotX / pivotY — shift the origin, so a crouch keeps its feet on the ground.
• flipX / flipY — face the other way on a turn.

Every one of those was already reachable from a script and from no clip, which is the wrong way round in a game where the clip is the character. A whole turn-and-swing is now one clip and none of it needs code.

The flips are stepped, like every other on/off lane: 0 is left alone, 1 is mirrored. An eased flip would turn the sprite round exactly halfway between two keys, at a moment nobody authored.

Turn a node you already have into a Sprite

Inspector ▸ Add Component ▸ Type now offers ▫ Sprite, ▩ Tilemap, ▧ Sprite Batch, ⇄ Nav Link and ▨ Nav Area. They were in ✚ New and not in the Type menu, so the only way to make an existing node into a Sprite was to create a fresh one and move the work across.

Panels that fit a narrow dock

Drag ⚙ Settings or ▦ Model as thin as you like:

• ⚙ Settings ▸ Input wraps. An action with several bindings puts the extra ones on the next line instead of pushing the ✕ that deletes the action off the edge. A binding too wide for a whole line — 🖱 Motion x0.006 (hold RMB) — is shortened with the full name on hover. A long action name is shortened the same way rather than taking the row with it.
• The collision matrix scrolls sideways. It is one checkbox per pair of layers, so its width is decided by how many layers your project has, not by how wide the panel is.
• ▦ Model ▸ per-slot material fits, including its Surface maps and Retro artefacts sections and the spritesheet cell picker.
• Shortcut keys, the reserved-keys list and the how-to text all wrap.

Icons that mean one thing each

▪ was Capsule and Sprite Batch. ▦ was Model Mesh and Tilemap. A Reflection Probe wore one glyph in the Inspector and a different one in ✚ New. Tilemap is ▩, Sprite Batch is ▧, Reflection Probe is ◍, everywhere.

VSCode knows the 2D API

The stub library the extension reads was missing 35 node methods — the whole 2D surface (node:setSprite, node:setCamera2D, node:shake, node:sorting, node:setParallax, node:tilemap, node:sprites, …) plus a dozen older ones like node:toWorld, node:lookAt and node:animator. Every call to them was marked as an error on an unknown field, on the one surface you are looking at while you write the line. Re-open a project to refresh .floptle/library/floptle.lua.

The 2D camera can snap to whole pixels

Inspector ▸ Camera 2D ▸ snap to whole pixels, or node:setCamera2D{ pixelSnap = 32 }. The number is pixels per world unit — the same one a ▫ Sprite's pixels per unit uses.

A camera that stops between two pixels resamples every sprite in the scene by a fraction of one, and pixel art shimmers along its edges while nothing is moving. Every 2D project ends up writing this by hand. The engine's version snaps what is drawn and keeps the follow's sub-pixel place, so the camera can still creep slower than a pixel a frame instead of sticking.

Fixes

• A spritesheet set from the Assets panel did not reach the sprites already wearing that texture. The grid lives on the texture — slice the .png once and every material using it inherits the cells — but the only thing that copied it onto a material was the Inspector's material editor, running for the one node you had selected. Every other sprite still believed its texture was a single whole cell, so it drew the entire sheet stretched across its quad and came out sized from the whole image. Re-slicing a texture now re-slices every material that wears it, and a cell past the end of the new grid falls back into range. Opening a scene puts its materials in step too — and says so in the Console, leaving the scene unsaved, because an exported build ships the scene file and a grid corrected only in memory never reaches it.
• Clicking a frame in the Material's cell picker did nothing on a ▫ Sprite node. A Sprite carries its own cell — that is what lets one sit on a shared material — and the picker was writing the material's. It now drives the node's, so the control you reach for is the one that draws.
• Selecting a sprite laid a wrongly-sized quad over it. The selection outline was built without the material or the texture size, so it fell back to the authored world size instead of measuring one cell.
• camera.pixelsPerUnit() was wrong under an orthographic camera — scaled by the camera's distance from the origin, which has nothing to do with it. A camera 9.33 units back answered 9.33× too small, and only pixelsPerUnit(1) was usable. An orthographic view is the same height at every distance; the argument is now ignored for one.
• Pinning a retro width did not change the framing. The scene was composited into the fixed target while the camera still projected at the panel's aspect, so the picture came out squashed inside the letterbox — defeating the reason to pin a width, which is that the framing stops depending on the window.
• A frame with hold: 0 never appeared. It landed on the same instant as the frame after it and lost the tie. Zero, negative and nonsense now mean one frame; a fraction above zero is kept exactly as written.
• A clip file whose name was capitalised resolved to nothing. Walk.SpriteAnim.ron showed in Assets, dragged onto a controller state, and played silence — the browser matched the extension loosely and the loader matched it exactly. Extensions are matched case-insensitively everywhere now.
• A texture path saved on Windows found its import settings only on Windows. Backslashes are normalised, so pixel art keeps its Pixelated filter when the project moves between machines.
• Importing an Aseprite sheet whose tags name frames it does not have is refused with a sentence naming the tag, instead of quietly producing a clip that is short. It happens when the .json and the .png come from different exports.
• Y-sorted nodes standing at the same height stack the same way after a reload — and after a pooled enemy is destroyed and spawned again. The tiebreak is now left-to-right rather than an internal number.
• A 2D camera following a name that two nodes share picks the same one every frame instead of whichever it met first, so the picture no longer jumps between two places with nothing in the scene changing. The lookup also runs once per frame rather than once per camera.

Nothing to do on upgrade

Scenes, projects, clips and scripts are unchanged. If you had reached for Sprite ▸ frame in a clip it keeps working exactly as it did; the new lanes sit beside it.

A release about making 2D games. A sprite node that knows what a pixel is, sorting that puts a character in front of the table they are standing at, sprite animation whose frames can come from anywhere, and a camera that follows.

A sprite is a node now

✚ New ▸ ▦ 2D ▸ ▫ Sprite.

You could always build one out of a Plane and a Material, and every 2D project did — each of them working out the same three things: that the plane is 1.4 units across and not one, that flipping means a negative scale, and that the sheet cell lives on the Material. A Sprite answers all three once, and carries two things a Plane cannot:

• A size in pixels. pixels per unit measures one cell, not the sheet, so slicing a sheet finer does not resize every sprite on it.
• A pivot. The origin defaults to the middle; the feet button puts it at the bottom, which is what a Y-sorted character wants.

Lower on the screen draws in front

Set a node's sorting layer to Y, and nodes level on layer and order sort by how far down the screen they are. Walk behind a table and you are behind it; walk in front and you are in front.

The order is sorting layer, then order, then Y. Y is the tiebreak, not a replacement — a drop shadow on order −1 stays under a Y-sorted crowd, and a lantern on order 1 stays in front of whoever is carrying it.

Two things to know:

• A node's sorting layer and its collision layer are different things. They were both labelled "layer"; they are not any more. (Nor is the third one, the layers a 2D light reaches.)
• A Y-sorting layer holds about 64 nodes before two of them tie — that is measured, not estimated. Split crowded scenes across sorting layers.

Backgrounds that move less than the world

parallax is a per-axis scroll factor: 1 moves with the world, 0 pins to the camera, 0.3 is a distant range of hills.

A factor rather than a distance, because the other way of getting parallax — putting a layer further back — only works under a perspective camera, and a flat game wants an orthographic one so its pixels hold still.

Sorting and parallax move the picture. Colliders stay where you put them and node.x reads back what you set.

Sprite animation, from any sheet

A frame names its own art, so one animation can use frames from different sheets and from plain PNGs that were never on a sheet at all.

Three ways in:

• Right-click a sliced texture in Assets ▸ ▦ New sprite animation — one frame per cell, ready to cut down.
• Right-click an Aseprite .json ▸ ▦ Import Aseprite sheet — the tags become clips, the grid slices the image, and per-frame timing is kept.
• ⏱ Animating ▸ ✚ Property ▸ Sprite ▸ frame — a lane beside position and rotation, for when the sprite is only part of what is animated.

A sprite animation is an ordinary clip: drop it in a controller and it crossfades, layers, carries events and plays from Lua like anything else.

// hero_walk.spriteanim.ron
(
  fps: 12,
  loop: true,
  cols: 8, rows: 4,
  texture: "art/hero.png",
  frames: [
    (cell: 0),
    (cell: 1),
    (texture: "art/hero_extra.png", cols: 4, rows: 4, cell: 9),
    (cell: 2, hold: 3.0),
  ],
)

Record picks up what you actually changed

● Record used to notice numbers and nothing else, so changing a material's texture with record on wrote no key — which is the one gesture sprite animation is for. It writes one now.

Materials also gained the rest of their surface: opacity, base colour, emissive, specular, rim, roughness, metallic and the rest are all keyable, so fading something out is a lane rather than a script.

The ✚ Property menu is grouped by component, with the fields people reach for at the top.

A camera that follows

Tick 2D camera on an orthographic Camera:

With no follow target the camera's position is left to whatever else is moving it — a script, a cutscene, your own placement — and only the limits and the shake are applied. So you can drive the camera by hand and still shake it.

node:setCamera2D{ follow = "Player", smoothing = 0.12, deadZoneX = 1.5 }
node:shake(0.4, 0.25)

Shake is added to what is drawn and never fed back into the follow, so it composes with the chase and with the limits instead of fighting them. Calling it again takes the louder amplitude and the longer time, each independently — a bang during a rumble does not cut the rumble short.

All of this applies to an orthographic camera and to nothing else.

Menus that stay short

✚ New is grouped — ▦ 2D, ■ 3D, ▦ Model shape, ● Lighting, Δ World, ⬚ Navigation, 🖼 UI — so adding a node is a glance rather than a scroll.

Panels fit however thin you drag them

Every form panel now shrinks, then wraps, then stacks. Drag the Model, Tiles, Inspector or Settings panel as narrow as you like and nothing goes past the edge.

Smaller things you will notice

• Drag a .png into the Scene view and you get a Sprite wearing it. It used to do nothing at all.
• Sorting, parallax and 2D light settings follow a multi-selection, so putting forty tiles on a background layer is one edit.
• Greyed-out menu entries now say why they are greyed out. They had the explanation written and could not show it.
• The ✚ Property menu in the Animating tab is grouped by component, and a material's texture and opacity sit at the top rather than in a wall of surface maps.
• Duplicating or pasting a node keeps its sorting layer, parallax and 2D camera. It used to drop them.

For package authors

• json.array(t) / json.isArray(v). {} is both an empty list and an empty object and encodes as an object, so there was no way to send [] at all. json.decode now marks the arrays it builds, so reading a body, emptying a list and sending it back keeps it a list.
• ed.copy(text) puts a string on the clipboard, so a panel can have a copy button. Write only — nothing can read the clipboard — and the editor shows how much was copied.

Upgrading

Nothing to do. Everything here is opt-in: a scene that does not use sorting layers, parallax, sprites or a 2D camera saves exactly the file it saved before.

Two additions to the package API, both about text a package paints itself.

A package can ask how wide a string is

gui.measure(text [, size]) → {w, h} — the size that string will be when it is drawn, in the same font gui.textAt would draw it in.

Painting has never had this. A package laying out a chart axis, a legend, or a line of prose with one word emphasised has to place each piece at an x it works out for itself, and with no way to ask, the only option is characters × an assumed width:

x = x + #text * 6.9   -- the old guess

That is wrong for every proportional face by a little, and wrong for an i beside a W by a lot. The error accumulates along a line, so emphasis lands past the word it belongs to and the right edge goes ragged — which reads as a layout bug rather than as a missing measurement.

local at = gui.cursor()
local x = at.x
for _, word in ipairs(words) do
    gui.textAt(x, at.y, word.text, 13, 1, 1, 1)
    x = x + gui.measure(word.text, 13).w   -- exactly where it ended
end

Painted text now uses the typeface you asked for

gui.font(name, fn) has always set the face for widgets inside it. gui.textAt ignored it and drew in the editor's own type, so a package shipping a typeface could set it for every button and label and then watch its hand-painted chart labels come out in something else — with nothing to say why.

textAt and measure both follow the enclosing gui.font scope now, so painted text matches the widgets around it. A measurement taken in a different face than the drawing is worse than no measurement, because it looks right until somebody changes the type.

Upgrading

Nothing to do. gui.measure is new, and textAt outside any gui.font scope draws exactly as it did.

Packages that want the measurement while still supporting older editors can ask for it:

local function width(text)
    if gui.measure then return gui.measure(text, 13).w end
    return #text * 6.9        -- older editor: the old guess
end

The Assets browser converts models the engine cannot open. Right-click an .fbx and pick ⇄ Convert to .glb — or just double-click it.

Asset packs are FBX. Scans are PLY. Anything out of CAD is STL. Until now the answer to all of those was "export it as glTF first", which is fine advice if you own the source file and useless if you bought the model.

The result is written beside the source: one self-contained .glb with the geometry, materials and textures inside it. Your original is not touched, and nothing is overwritten — if the .glb is already there it says so instead.

It normalises, it does not just re-encode

Every one of these formats disagrees with glTF about something, and a converter that only re-encodes hands you a model that loads and is wrong:

• Axes. FBX is Z-up out of 3ds Max and Y-up out of Maya. glTF is always Y-up. A model that arrives on its face is the commonest complaint about importing FBX anywhere.
• Units. FBX records its own, and most exporters write centimetres. glTF is metres, and a model a hundred times too big reads as a broken importer rather than as a unit.
• Winding. Fixing handedness — or any mirrored node, which is how anyone makes a left boot from a right one — inverts triangle winding. A model with every face backwards is invisible from outside and solid from within.
• N-gons. FBX and OBJ have quads and worse. glTF has triangles.

All four are settled on the way through.

A loose .gltf becomes one file

Not a format change, and the thing people need most without expecting to. A .gltf is JSON that points at its geometry and its textures, so it is three to thirty files that have to travel together — and half of them go missing in a zip or a move between folders, leaving a model that opens as an empty scene.

Converting one packs all of it into a single .glb.

It tells you what it did

The Console gets the counts, and everything that did not come across:

Convert: hero.fbx → hero.glb — 4 meshes, 12,536 triangles, 2 textures embedded
Convert: The source measured in centimetres; it has been scaled to metres.
Convert: 3 animations, skinning (the mesh is converted in its bind pose) was not
         carried across — .glb here holds geometry, materials and textures.

Animation and skinning are dropped, and named rather than left for you to discover. A file with no meshes in it at all — bones only, or a scene of lights — fails with "there is no geometry in that file" instead of writing an empty model that opens fine and shows nothing.

Conversion runs off the main thread, so a large character model does not freeze the editor.

What has not changed

The engine still loads glTF and only glTF at runtime, which is ADR-0006 and is still right: one well-specified load path beats four half-supported ones. This is an authoring step that gets you to that path.

Upgrading

Nothing to do. Existing .glb and .gltf assets are unaffected, and .glb is deliberately not offered for conversion — it is already the format this converts to.

A package can read a file's bytes, and a file the user picked is one it can open.

ed.readBytes(path)

Raw bytes as a Lua string, or nil.

ed.read is text. A PNG comes back as nil — the same answer you get for a file that is not there, which is the most confusing available way for something to be unreachable. Anything binary was out of reach: an image to upload, a font to inspect, a .bin to parse.

Lua strings are byte strings, so there is nothing to decode: #bytes is the file's length and string.byte indexes it.

The picker is the permission

ed.pickFile returns paths from anywhere on the machine. ed.read scopes to your package and the project, which is right for a path a package makes up — and wrong for one the user chose in an OS dialog for this exact purpose. So the picker could tell a package the name of a file it had no way to open.

ed.readBytes accepts any path ed.pickFile handed this package during this session, on top of the usual scope.

ed.pickFile({ title = "Choose a floor plan", label = "Images",
              extensions = { "png", "jpg" } }, function(paths)
    if not paths then return end
    local bytes = ed.readBytes(paths[1])   -- readable: the user picked it
end)

The grant is recorded when the path is handed over, before your callback runs — reading the file inside that callback is the obvious thing to write, so it is the thing that works.

Matched on the resolved path, so a granted file cannot be spelled with a .. in the middle to reach a different one. Paths you make up are unchanged: your own package always, elsewhere in the project with Files, outside it never.

Upgrading

Nothing to do. ed.read is untouched.

Two small additions to the package API, both found the same way as v0.65.0's and v0.65.1's: by writing a real editor tool against it and hitting a wall.

A panel can fill a shape

gui.poly({x1, y1, x2, y2, …}, r, g, b [, a]) fills a convex polygon, in the same panel coordinates as the rest of the painting calls.

The scene side has had handles.poly since the beginning. A panel could only outline, which meant a hand-drawn chart filled an area by stacking one-pixel rectangles under it — a draw call per column, a ragged diagonal edge, and no way at all to fill a shape that is not a function of x. A radar chart is exactly that shape.

-- One triangle per axis, fanned from the centre.
for i = 1, n do
    local j = i % n + 1
    gui.poly({ cx, cy, x[i], y[i], x[j], y[j] }, 0.5, 0.2, 0.8, 0.22)
end

Fewer than three points draw nothing rather than a degenerate sliver, and an odd number of coordinates raises — a flat list is easy to build one element short, and a polygon quietly missing its last vertex looks like the data was wrong rather than the call.

Convex, matching handles.poly: a concave outline fills as its convex hull, so split one into triangles. Worth knowing before you draw a chart with it, because the hull of a dented shape is the undented one — it flatters rather than fails.

A field can be cleared, not just set

json.null encodes to JSON null.

Lua nil cannot do this job. t.field = nil does not put a null in the table, it removes the key, so the encoder never sees it and the field is simply absent from the output. Any API that reads an absent field as "leave this alone" and an explicit null as "clear it" was therefore half-usable from a package: you could set such a field and never unset it.

json.encode({ cleared = json.null, kept = 1, absent = nil })
--> {"cleared":null,"kept":1}

Decoding is deliberately not symmetric: a JSON null still arrives as Lua nil. Every package already reads an optional field with if body.field then, and handing them a sentinel that is truthy would silently turn every one of those tests the wrong way round.

Upgrading

Nothing to do. Both are additive.

Two more places a package's Scene overlay can go, both found the same way as v0.65.0's: by writing a real tool against the API and running out of room.

An overlay can sit at the bottom

corner takes "bottomLeft" and "bottomRight" as well as the two top ones. The bottom stacks grow upward from the bottom edge and are independent of the top ones, so a package can put a readout in one corner and a row of buttons in the other without either moving the other.

ed.overlay("Quick Actions", { corner = "bottomRight", bare = true, width = 250 },
    function()
        …
    end)

A row of buttons wants the bottom of the viewport. Pinned to the top it sat over the level the moment anything above it changed height — and things above it change height constantly, because the overlay above is usually a readout that grows as the analysis fills in.

fill is ignored on a bottom overlay: one pinned to the bottom edge that also took the whole column would be an overlay pinned to the top edge.

An overlay can take the full height

fill = true gives a Scene overlay the whole column between the toolbar and the bottom of the viewport.

This was written for v0.65.0 and landed just after the tag, so it is in this release rather than that one. Without it an overlay is only as tall as whatever it has drawn so far, which means gui.available() inside one reports the content rather than the space — so a panel that wants to fill the side of the screen has no way to find out how much screen there is. A conversation written into one came out two messages tall.

Upgrading

Nothing to do. Both options are additive, and an overlay that does not ask for either draws exactly where it always did.

Everything a package needed to build a tool that looks like it belongs in the editor rather than bolted onto it: its own dock tabs, overlays it can place and paint itself, the layout cursor, the keyboard, and the file picker.

Plus two fixes worth having whatever you use: a project opened from the command line now loads its packages, and a package's saved settings survive a crash.

Your tools dock like the editor's own

ed.tab(title, drawFn) gives a package a real dock tab — dragged, split beside the viewport, stacked with the Inspector, closed when you want the room. It comes back where you left it across a reload of the package and a restart of the editor.

A package could only float a window before. That is right for something you call up and dismiss, and wrong for anything you keep open beside the scene: settings, a list, a report. Both are available now, and they mean different things.

Overlays that get out of the way

ed.overlay takes options: which corner it sits in, how wide it is, and whether the editor draws a frame around it at all.

ed.overlay("My HUD", { corner = "topLeft", bare = true, width = 330 }, function()
    …
end)

bare is the interesting one. A Scene overlay is a heads-up display about the level behind it, and a grey panel slab hides the thing it exists to annotate. With bare the package paints its own look and the editor stays out of it. The left-hand stack tucks in under the viewport toolbar, and follows it if you drag the toolbar somewhere else.

Existing overlays are untouched — the two-argument form draws exactly as before.

Painting more than one thing

gui.cursor() returns where the next widget would go, in the same coordinates the painting calls use.

Without it, painting could only ever draw one thing: the origin is the panel's top-left and it does not move as widgets are added, so a second painted card landed on top of the first however much space you reserved between them. A list of painted rows — a chat log, a stack of cards, a legend — was not expressible.

The keyboard, and asking for a file

gui.keys() reports the modifiers and whether Enter or Escape went down, and gui.textField now also returns whether it was submitted with Enter. Together that is enough for the convention every text box uses — Enter for a newline, Shift+Enter to send — which a package simply could not offer before, because a returned string looks the same whether you typed a character or pressed the key that means "send".

ed.pickFile(options, fn) opens the operating system's file picker, optionally narrowed to a set of extensions:

ed.pickFile({ title = "Choose an image", extensions = { "png", "jpg" } },
    function(paths)
        if not paths then return end   -- cancelled
    end)

It needs the Files permission, and is absent rather than refused without one.

A project you opened from the command line loads its packages

Start the editor with a project as an argument — which is how the Hub starts it — and the project came up with its packages missing. No menus, no panels, and no error, because nothing had failed. The only way to get them was to switch a package off and on again in 📦 Packages.

Your package settings survive a crash

A package's saved settings — an API key you typed, a server address, a switch you flipped — were only written to disk when the editor closed cleanly. Anything else threw them away, so you signed in again. They are now written the moment they change.

Upgrading

Nothing to do. Every existing package keeps working: the new overlay options are additive, and gui.textField's second return value is dropped by Lua wherever nobody asks for it.

Adding a package from a folder works on Linux. One fix.

Adding a package from a folder works

Window ⏵ 📦 Packages ⏵ Add, then 📂 Choose folder… or 🔗 Link folder…, and the editor shut down the instant you clicked. No file picker ever appeared, no message, no crash report — the window simply went away, which reads like a broken button rather than like something going wrong.

The file picker was asked for in a way that cannot work on a Linux desktop. The system's own dialog is reached through a background service there, and it was being asked for from the thread that draws the editor, which has no way to wait for the answer. Nothing was wrong with your package or your project, and nothing was left half-done: the editor stopped before it read a single file, so there is no stray entry to clean up and no partial install to undo.

Windows and macOS were never affected.

Two things are better than before the bug, too. The editor keeps drawing while a picker is open instead of standing still, and both buttons grey out until you have answered it — one folder question at a time.

Upgrading

Nothing to do.

Spot lights. And a large step for editor tools: a package can now read and write a whole node, read a mesh's actual triangles, use its own typeface, follow a server's progress live, and take you to a place in the level.

Spot lights

A light you aim. Add ⏵ ◤ Spot Light, then rotate the node — the beam runs down the node's forward, the same axis a camera looks down, so pointing a lamp is the same gesture as pointing a camera.

Two numbers:

• cone — the full angle, the number on a real fixture. 45° is a 45° cone.
• edge — how much of that cone is falloff. 0 is a hard circle; 1 fades from the middle out. It is a fraction of the cone, so widening a beam keeps the edge you gave it instead of going hard.

A spot is not a different kind of node. It is a point light that has been aimed, so everything you already know about lights still applies to it: the same emitter shapes (a spot can come from a sphere bulb or a disc), the same range, the same local shadows, the same 2D/3D behaviour, the same sixteen-light budget. The Scene view draws the cone instead of the reach ring, because a circle around a lamp tells you nothing about which way it is facing.

From a script it is the same handle, with two more fields:

local lamp = node:getcomponent("PointLight")
lamp.spotAngle = 12          -- tighten the beam
lamp.spotSoftness = 0.05     -- and harden its edge
node:lookAt(target)          -- aim it

spotAngle of 180 or more means no cone at all — an ordinary omnidirectional lamp. That is what every existing light reads, and it is how you turn a spot back into a normal one. There is no separate switch to keep in step.

Spot lights also default to casting shadows, where a point light does not. A spot is aimed at one thing, and one that shines through the wall it is pointed at is not much of a spotlight.

Nothing to do on upgrade. Every light in every project you have is untouched, and a scene file saved by this version is byte-for-byte the one you had unless you actually aim something.

Pressing F on a child node goes to the child

Framing the selection used a node's position relative to its parent rather than where it actually is. Select a door inside a building parked away from the origin, press F, and the camera flew to wherever (0.4, 0, 1.2) happens to be in the world — usually nothing, usually nowhere near the door. It read as the key having missed rather than as it having gone somewhere.

Anything not parented worked correctly, which is why this lasted as long as it did. It now frames the node's real world position, and sizes the distance by its real world scale.

What a package can do now

Five things, all of them general — none is specific to any one tool.

Read and write a whole node

scene.info(id) gave a summary. Now scene.doc(id) reads the whole node — the same document a .ron scene, a prefab and the clipboard all use — and three calls write it back:

scene.set(id, { tags = {"cover"}, layer = "props" })   -- change only these keys
scene.add({ name = "Guard Post", children = { { name = "Lamp" } } })
scene.setParent(id, nil)

scene.set is a partial write: keys you do not mention are left alone. scene.add builds a whole subtree as one undo step. A key the document does not have is refused by name, and tells you which one you probably meant — a misspelt field used to be accepted and silently do nothing.

Before this, a tool that worked out where something should go could only leave a marker where it meant to put the thing.

Read a mesh's triangles

scene.bounds gives a box. For measuring a room, exporting a level or uploading geometry, a box is not an approximation of a shape — it is a different shape.

mesh.read(nodeId, function(m, err)
    -- m.positions is {x,y,z,x,y,z,…}; m.indices count from 0
end)
mesh.read("assets/models/chair.glb", function(m) … end)

Works on a model node, a map mesh, a built-in primitive, or a file by path, and reads through the exact same code the navmesh bake uses — so a tool can never measure one shape while the level paths on another. Terrain declines and says why: it is a field meshed per chunk at the detail it is viewed at, so "the terrain's triangles" has no single answer.

Your own typeface

Ship a font in your package and name it:

fonts: [ (name: "Heading", path: "fonts/YourFace-Black.ttf") ]

gui.font("Heading", function() gui.heading("Lumen") end)

.ttf, .otf and .ttc. It needs no permission — the file is inside your own package folder, which require already reads. A face is chosen for the length of a closure rather than switched on, so it cannot outlive the panel that wanted it, and a face that fails to load draws in the editor's type and says so once in the Console rather than drawing boxes.

Follow a long job live

http.stream reads server-sent events, so a progress bar can move instead of stepping every two seconds:

local s = http.stream(url, {}, function(name, body)
    bar = body.percent
end, function(ok, why)
    if not ok then fallBackToPolling() end
end)

The closing callback fires exactly once whatever ended it — you stopped it, the connection died, or the server has no stream at all — because a tool that has to fall back to polling needs telling, once.

Take somebody to a place

ed.lookAt(vec3(12, 0, -4))
ed.lookAt(hit.point, 3)

The same move the F key makes, aimed at a point instead of at the selection. Any tool with a list of places in it — a search result, a lint hit, a measurement — needed this; the alternative was selecting a node in order to move a camera, which is an edit to somebody's selection made behind their back.

And a smaller one

scene.info(id).ui now says what a UI node actually is — button, slider, text, image, scroll, panel — with its label and whether it is interactive. A tool that wants to find every button in a screen no longer has to guess from node names.

Under the hood

The scene mirror a package reads is rebuilt only when the scene actually changes, rather than every frame. Panels that walk the node list are cheaper on a large level whether or not they use anything above.

Upgrading

Nothing to do. Scene files, prefabs and scripts all load and save exactly as before; the new light fields are only written when you use them.

A script that builds your level stops getting slower the more level there is — spawning into it, and re-measuring its navmesh a room at a time instead of all of it. Tools can read the navmesh. And two things every package was writing by hand are now one line each.

Build as much as you want

If your game builds its own world — a streamer loading chunks as the player walks, a dungeon generated at the start of a run, a building that comes apart — you may have noticed it getting heavier as the world got bigger. Not at any one moment; just steadily worse, until a level that ran fine at the size you tested it stutters at the size you shipped it.

That was the engine's fault, in four places at once. Spawning a node did work proportional to how much scene already existed — rebuilding a table of every node to add one, re-importing every model in the level to account for one new prop, walking the whole scene to turn an id back into a node. Each is fine for a bullet. A thousand of them to build one chunk is not.

Here is the same thousand-node chunk, spawned into scenes of three different sizes:

The point is not the last column, it is the shape of the first two. A chunk is the same thousand nodes every time — it should cost the same whatever it lands in, and now it does.

Nothing to change on your side. If you built any of the usual workarounds — parenting a chunk to one node so unloading it is a single destroy, baking a rotation into a prefab so no spawn needs a callback, rationing spawns across frames — they all still work, and you can start taking them out. spawn with a callback is no longer the expensive one.

Tools can see where a character can walk

Editor packages get nav: the shape of the walkable surface, what kind of ground each piece is, where the links are, and every query a running script has.

ed.onSceneDraw(function()
    local a, n = nav.areas()
    handles.color(0.3, 0.8, 1, 0.5)
    for i = 0, n - 1 do
        local o = i * nav.AREA_STRIDE
        handles.wireCube(vec3(a[o+8], a[o+9], a[o+10]),
                         vec3(a[o+3] - a[o+1], 0.05, a[o+4] - a[o+2]))
    end
end)

It is the reading half only. No agents, no obstacles, no opening and closing links — there is no game running for those to act on, and a hole cut in your project's own navmesh would be a level edit made by a panel.

Two things went with it that a running script wanted as well. nav.ground() lists what the level calls its kinds of ground, so a filter saying avoid = {"water"} can be written by reading rather than by guessing — a guess that misses used to read as "nothing to avoid" rather than as a mistake. And nav.offLinks() reads back every Nav Link as data: a script could shut a door, but nothing could list the doors.

A bake reads a level, not a texture library

If your level changes while somebody is walking through it, the navmesh has to be re-measured — and re-measuring it was doing an enormous amount of work that had nothing to do with navigation.

Reading a model's shape used to read the model's pictures too: every .glb opened, every PNG inside it decoded to raw pixels, and every one of those pixels thrown away one line later, because a bake only wants vertex positions. On a level of a few hundred props that is tens of megabytes of decoding, on the thread that draws your frame, every time the level changes shape.

Now it reads geometry only, and remembers what it read:

That is one model. A level's worth is the same numbers multiplied by however many props you have, and the third row is what a second bake of an unchanged level now costs.

And a model is baked as the thing it collides as

A prop authored as a model with a static box body collides as a box — and the navmesh was cutting it out of the floor at its detailed silhouette instead. So a character routed carefully around the arms of a chair that it actually bumps into as a plain box, and squeezed through gaps that physics does not have.

The rule was always "what you path on is what you bump into"; a model quietly broke it. A node with ▦ Collider and no Rigidbody still paths on its own triangles, exactly as it collides — nothing changes there.

Worth a look if you have a baked navmesh and props with static bodies. Their footprint in the navmesh will change — to the shape your characters were always colliding with. Press Bake and have a look at the overlay.

Re-measure one room, not the whole building

The other half of it. When your level changes shape, its navmesh has to be measured again — and until now "again" meant all of it, however little had moved. So the cost of building a chunk grew with how much level was already loaded, which is backwards: the amount of new level per chunk is the same every time.

buildTheChunk(cx, cz)
nav.rebake(vec3(cx * 32 + 16, 0, cz * 32 + 16), vec3(32, 16, 32))

That re-measures the box and splices the answer into the navmesh in hand, in the same frame, and characters walking through repath onto it.

The finding is the shape of the last column, not the first. Widen your streaming radius and a full rebake costs more per chunk; a nav.rebake costs the chunk.

It is not nav.obstacle, and the difference matters. A crate standing in a corridor is an obstacle: it can be taken away and the floor comes back. A corridor that has just been built is a rebake: it is the level now. Obstacles you have carved survive a rebake — re-measuring the ground under a crate does not move the crate.

You need a navmesh baked once before there is anything to splice into, and the box is snapped outward to whole navmesh cells, so read the result back rather than assuming you got exactly the box you asked for.

Nothing to path on in start()

A note rather than a change, because it costs an afternoon every time somebody meets it. On a level that builds itself — a streamer, a generated dungeon — there is no navmesh when start() runs, because there is no geometry yet for a bake to measure. So this never runs:

function start(node)
    if nav.ready() then self.agent = nav.agent(node) end   -- not yet, and never
end

…the agent is never made, every routing call falls through to whatever your script does without one, and nothing errors. Ask each frame until you have one.

Waiting, without writing a clock

local poll
poll = ed.every(2, function()
    checkTheJob(function(done) if done then poll:cancel() end end)
end)

ed.after(seconds, fn) runs something once, later. ed.every(seconds, fn) runs it again and again. Both hand back a handle with cancel().

Every package that waited for anything was writing the same four lines: keep a deadline, compare it against ed.time() from inside onUpdate, remember to take it down afterwards. A repeat keeps its period rather than drifting a frame at a time, and it never tries to catch up — a minute spent in a modal dialog costs you one firing, not a hundred and twenty.

Randomness worth signing in with

ed.randomBytes(n) gives you bytes from the operating system.

math.random is a generator seeded from the clock. That is exactly right for a puff of smoke and exactly wrong for anything somebody gets to guess at — a sign-in challenge, a nonce, a token, an id that must not collide. A package could not build one out of what it had, so the choice was the wrong tool or not doing the job.

Upgrading

Nothing to change. nav.areas() gained an eleventh number per rectangle — which kind of ground it is — appended after the ten that were there, so anything written against nav.AREA_STRIDE keeps working. That is what the constant is for.

Sun shadows over a plain floor. One fix.

Your floor is not striped

Turn sun shadows on in a scene made of meshes — a plane, a character standing on it — and the ground came out crawling with dark bands. Not a shadow of anything: stripes, ruled across open floor, with no clean edge where the real shadow stopped and the lit ground began. Adding a terrain made it go away, which is the worst kind of clue.

The shadow ray could not tell "nothing is in the way" from "I ran out of road." A ray that gives up partway through its search is treated as blocked — which is right, because a ray that spends its whole life pressed against something is inside something. But a ray that leaves the scene entirely stops early too, and it stops for the opposite reason. Both were read the same way, so a shot of open sky came back as full shadow.

It only showed up in a scene with no terrain, no blobs and no baked level geometry — where a plane and a character are the only things that cast at all, which is to say in an ordinary game scene. Every scene with a hill in it hid the bug completely.

Fixed in the shadow march. Nothing to change on your side: open your project and your floor is even.

Upgrading

Nothing to do. If you turned sun shadows down, off, or reached for dither the penumbra to disguise this, you can put those back where you want them — they were never the cause.

Drop a crate in a corridor and your characters walk round it, without the level being measured again. The Scene view's floating panels stop covering the scene. And the package browser reads like the rest of the engine.

Something is standing there now

Two lines, and the ground under a crate stops being ground:

local crate = nav.obstacle(box.position, vec3(1, 2, 1))
-- …and when it is picked up again
crate:remove()

Every character walking a route through that space works out a new one, in the same frame. Nothing is rebaked, nothing is saved, and nothing has to have been prepared for it.

This is what "bake again when the level changes" was never going to be good at. A rebake measures your whole level — every triangle, every floor, every gap — which is exactly right when the level has genuinely changed shape, and enormous overkill for a barrel. On a 256 m level a rebake takes about 460 ms and a crate takes about 0.6 ms. Both are still here, and they are for different jobs: put a building down, rebake; put a crate down, carve.

nav.obstacles() counts what is currently cut, and nav.clearObstacles() gives the whole level back in one call — for a wave ending or a level resetting, without anything having kept a list.

A few things worth knowing before you use it:

• The hole is grown out to whole navmesh cells, so it is never smaller than the box you asked for and can be up to one cell bigger on each side. Blocking slightly more than a crate is a crate; blocking slightly less is a character walking through one. Read crate.size and crate.position for what was actually cut.
• A box in mid-air blocks nothing. A crate on a shelf five metres up does not carve the floor underneath it.
• nav.reachable keeps up. A wall dropped across the only corridor really does split your level in two, and asking whether one side can reach the other now answers no.
• Removing gives back exactly what was there. Not something very like it — the same navmesh, so the same question gets the same answer it did before.
• Nothing is written to your project. Like a bake taken while your game runs, the holes are a fact about this session. Press Stop and your level is back.
• Obstacles are boxes and they do not move. Something that moves wants a nav agent, or a rebake — carving every frame is rebuilding every frame, which is the cost this exists to avoid.

View ▸ Navmesh shows the holes while your game runs, so a unit that went the long way round is explained by the picture rather than by a guess.

The Scene view's panels get out of the way

The little gizmo strip in the top right was pinned to the corner of the window, not the corner of the Scene view — so unless the viewport happened to run to the edge of your screen, it sat on top of the Inspector, or the tab strip, or whatever else lived up there. It is inside the viewport now, where it belongs.

Both floating strips — the tool palette on the left and the gizmo bar on the right — now do everything you would expect a floating panel to do:

• Drag it anywhere by the ≣ grip on its left.
• Dock it to a corner — right-click the grip, or use the ▾ button, and pick top left, top right, bottom left or bottom right.
• Fold it away with ⏶. It shrinks to a small named tab, still one click from coming back, and stops covering the thing you are editing.

Where you put them is remembered between sessions, and neither of them ever moves on its own: a docked panel stays welded to its corner, and a floating one keeps the exact spot you dropped it at, measured from the viewport rather than from the window, so dragging a dock divider carries it along instead of leaving it behind. The ▦ Model tool's status strip rides under the tool palette wherever you have put it.

The package browser looks like the engine

📦 Packages ▸ 🌐 Browse has had a pass over its structure rather than its colours. Four sizes of text instead of the four unrelated ones it had, so a package's name, the section you are in, the description and the fine print each look like what they are. One card treatment, hairline-ruled, with the open one marked in your theme's own accent. Package ids, version numbers, engine ranges, revisions and the catalogue address are set in monospace, because they are things you copy and compare character by character.

And Install is the loudest button on a package again. It was competing with a solid button for editing a review you had already written, which is backwards. Colour now appears for four things and nothing else: a rating, a permission a package is asking for, a version that will not run on the engine you have, and the one primary action.

Everything reads your chosen theme, so this looks right on Floptle Dark, Midnight, Slate, Carbon (OLED) and Light rather than on one of them.

Upgrading

Nothing to do. Existing bakes, scenes and packages are untouched, and no file format changed.

If you have been rebaking during play to account for something being put down, nav.obstacle is likely what you actually wanted — but the rebake is still there and still correct, so there is nothing to migrate in a hurry.

Bake a navmesh once. It is saved beside the scene, it comes back when you open the project, and if it ever cannot be read the engine makes it again rather than asking you to. Plus a navmesh that keeps up with a level while you build it, and an overlay that shows your links and your painted ground.

Your bake stays baked

"I have to bake my navmesh again every time I reopen the project." That was real, and it is fixed.

A bake has always been saved beside its scene. v0.60 added areas and links to what that file holds, which changed its layout — so every bake made before v0.60 stopped being readable, and the editor reported it as no bake yet, which is exactly what a scene nobody has ever baked looks like. The work looked undone, so the only thing to do was do it again, every session.

Three things now:

• A bake says which version wrote it, so this can never be silent again. A file that cannot be read is named, with what happened to it.
• The editor makes it again for you, in the background. A bake is a function of the level and the level is open — pressing a button to recompute something the editor could recompute itself is not a fix. One line in the Console says it happened. (A scene you have never baked stays unbaked. That is your call.)
• The Nav Mesh node names the file the bake came from — saved in scenes/level.1.fnav — it loads with the scene — so "did that actually save?" is answered by looking rather than by experiment.

A navmesh that keeps up while you build

There is a new switch on the Nav Mesh node: bake again when the level changes.

It is off by default, because a finished level's bake is a file that loads with the scene and never needs doing twice. Turn it on while you are building — or in a game that puts buildings down while it runs — and the volume watches what it would bake, waits for it to stop moving, and bakes on another thread. The editor keeps its frame rate, and so does a running game.

That closes the gap v0.60 named: a building placed during play now turns up in the navmesh, and units start walking round it. (Nothing carves a hole in an existing bake in place yet — a rebake is still a whole rebake, which is a fair answer at room and building scale.)

A bake made while your game is running never touches your project. It describes what that session spawned or knocked down. Press Stop and your level's own navmesh is back exactly as it was.

A volume that misses your level says so

A Nav Mesh box smaller than your level bakes perfectly, and gives you a navmesh of one corner of the map. It counts polygons, it draws, characters walk on it — right up to an invisible edge in the middle of the floor, where they stop.

Now the bake compares the box against what it was handed, and says both numbers: the volume covers 24 × 32 m of a level that spans 846 × 538 m, so 12,300 of 12,900 triangles were left out of it. In the Console, and on the node, which is where you look when a character will not go somewhere. A new Nav Mesh node still arrives with fit the box to what it finds ticked — it measures your level instead of trusting a number, which is why it is the default.

In a script, agent.offMesh tells the two apart:

if unit.blocked then
  if unit.offMesh then
    -- there is no navmesh where you sent it: a bake problem
  else
    -- it cannot get there: a level problem
  end
end

Both look identical from outside — a character standing still — and they have nothing in common.

See your links and your painted ground

View ▸ Navmesh now draws more than the walkable surface.

Nav Links appear where the bake resolved them, not where you dropped them: cyan for a crossing that works, grey for one that is switched off, and red for one whose end missed the floor. That last one does nothing, forever, and used to look exactly like a route that simply preferred the long way round.

Painted areas are drawn in their own colour, so "did my mud volume actually cover the puddle" is a thing you look at rather than bake and guess.

The RTS example pathfinds

rts_unit.lua and rts_commander.lua — click to select, drag a box, right-click to send a squad — are on the agent layer. The unit keeps the same names (moveTo, stop, isMoving, selected) and gains isBlocked() and remaining(), plus a red selection ring when one gives up. Setup instructions are at the top of each script, where you read them as you attach it.

With no navmesh in the scene they still work, walking straight at the order, exactly as before. Adding a Nav Mesh node should be what makes units clever, not what breaks a scene that has not got one.

Orders now land on the navmesh before they are given, so a squad told to stand near a wall does not hand half its units a destination inside it.

Upgrading

Nothing to do. Open a project whose navmesh was baked by an older version and it will be rebuilt for you, once, in the background.

Units that walk the level themselves, in three lines of Lua. Plus an undo that gives you back the thing you were working on, a save indicator you can always see, and level geometry you can carry between scenes.

Your units find their own way

Floptle could already answer questions about a level — where can I stand, how do I get there, how far is it. None of it walked anybody anywhere, so every project wrote the same follow-the-path loop, and getting it subtly wrong is what makes AI look broken.

Now there is an agent:

function start(node)
  unit = nav.agent(node, { speed = 6 })
end

function update(node, dt)
  if ordered then unit:moveTo(target) end
end

That is a working unit. It finds its own route, walks it smoothly rather than corner to corner, goes around the units beside it, slows down at the end, and tells you what it is doing (unit.state is idle, moving, arrived, blocked or crossing). There is no step function — the whole crowd is advanced once a frame, after your update, so an order given this frame is acted on this frame.

Sixty units through one two-metre doorway all get through. That is the case a crowd layer either handles or deadlocks on, and it is the one this was built against.

Three nodes in the ✚ Add menu (also on the Hierarchy's ✚ New, and as Add child on any node):

• ⬚ Nav Mesh — the volume that gets baked. Tick auto bounds and it measures the level for you. It bakes what a character would collide with, so a wall you built today blocks a path today without anyone tagging it.

• ⇄ Nav Link — a ladder, a jump-down, a door, a lift. Two points with a cost, and a switch: nav.link("front door", false) closes it and everybody walking to it works out another way, with nothing rebaked. An agent reports which link it is on and how far across (unit.link, unit.linkProgress), so the climb animation has something to run off. Give a link a duration and a slow lift takes the time it should.

• ▨ Nav Area — a box that paints ground as a kind: mud, water, road. One bake serves a whole cast, because the difference between a guard who takes the road and a zombie who wades the river is in the question, not the level:

  luaCopy

  nav.agent(node, { filter = { avoid = { "water" }, cost = { road = 0.5 } } })
  

  A box can also carve — a hole nothing walks in, whatever it thinks of the ground.

The queries are all there too, in world coordinates: nav.path, nav.nearest, nav.onMesh, nav.reachable, nav.distance (how far it is to walk, which is the number a decision is actually made on), nav.raycast — the walker's answer rather than the collider's, so a ledge this character would fall off reads as a wall — and nav.random for wander and patrol points.

There is a tutorial in the 🎓 Learn tab, and the full write-up says plainly what it does and does not do yet.

What it does not do yet

A building placed during play does not appear in the navmesh until you bake again. That is the honest gap for an RTS, and it is the next thing on this list. The bake is also whole-level and synchronous — fractions of a second at the sizes tested, still a pause on a very large one — and agents move on the frame clock, so a rollback-netcode game should drive movement itself and use the queries.

Undo gives you back what you were working on

Undo used to drop your selection every time, which made it feel like it had gone one step too far — you would undo a move and be left holding nothing, unsure whether the move had gone or something else had.

Two things changed. Undoing an edit leaves the node selected, so you can undo and redo a nudge and watch it move. And picking a node is now its own undo step: Ctrl+Z walks back through what you selected as well as what you changed, in the order it happened, so you can retrace your steps rather than jumping over them.

Selecting is history, not an edit. It does not mark your scene unsaved, and it does not throw away your redo — undo a move, click another node to check something, press Ctrl+Y, and the move comes back.

You can always see whether your work is saved

The scene view had a saved indicator, which was no use with the scene view closed. There is now one at the right of the menu bar, on every tab: a quiet ✔ saved, an amber ● unsaved the moment you change something, and a green glow when a save lands. Hover it to see which file it means; click it to save.

It also tells the truth about the whole save now. A scene writes several files — terrain, paint, map geometry — and if any of them failed to write, the indicator stays ● unsaved and says so, rather than reporting a clean save while an hour of sculpting sits only in memory.

Take a level's geometry into another scene

The blockout you build with the ▦ Map tool is stored in maps/, and those files are now proper assets rather than something to scroll past.

Select one and the Inspector shows what it holds: which scene it belongs to, the shapes and their sizes, and a top-down floor plan drawn from the geometry itself. Double-click opens the scene that owns it.

Drag it into the viewport — or right-click ▸ Add to scene — and that geometry arrives in whatever scene is open: every shape a fresh, independent copy with its names, placement, materials and collision intact, grouped under one node and undoable in one step. Build a corridor once and reuse it; lift a room out of a prototype into the real level.

Fixes

A link that could be crossed in half a second took as long as the walk it replaced. A Nav Link's duration was collected and never used, so a four-second lift was crossed at walking pace and the animation that followed it ran at the wrong rate.

agent:teleport moved nothing. It cancelled the order and left the character where it was — so a respawn put a unit back on its feet exactly where it died.

Changing an agent's filter mid-game did nothing until the next bake. Handing a unit a boat and telling it water was fine now takes effect immediately, rather than silently waiting for a rebake that a shipped game never performs.

A mistyped agent option was accepted and ignored. nav.agent(node, { speeed = 3 }) now says so, and suggests what you meant, instead of quietly walking at the default speed.

Two copies of a Nav Link shared one id. Duplicating, pasting or prefabbing a link kept the original's id, so nav.link(...) only ever reached one of them and a route across the second could arrive at the first one's far end. Copies get their own ids, and a scene file with a genuine clash says which links clashed.

An area named on a link but not painted by a box did nothing. Tagging twenty links jump and excluding jump excluded nothing, silently. Naming an area anywhere now registers it. A stray space no longer makes "water " a second kind of ground that no filter can find, and a second box that names a different cost for the same area now says so instead of quietly losing it.

A box that carved a hole could be un-carved by a painted box overlapping it. Blocking is a fact about the level; a decorative paint volume cannot cancel it, whatever order they were made in.

A navmesh from an older version of Floptle read as no navmesh at all — no outline, no paths, every character standing still, and nothing said why. It now tells you the bake could not be read and to press Bake.

Asking for the nearest walkable point with no distance limit searched one corner of the level. nav.nearest(p, math.huge) could come back empty on ground it was standing on.

A crowd could jam short of a shared destination. Only one unit can stand on the point you clicked; the rest now settle around it instead of grinding against each other, and a unit pinned by its own crowd rests and tries again rather than giving up for good.

Units walked slightly faster than their own speed, by an amount that changed with your frame rate — each one was pushing away from where it had been at the start of the frame.

Upgrading

Nothing to do. Existing projects open unchanged; navigation is opt-in — add a Nav Mesh node from the ✚ Add menu and press Bake.

If you have a navmesh baked with an earlier version, open its scene and press Bake once — the editor will tell you if it needs it.

A kit of real assets to start a project with, and a package browser that can actually show you what a package is.

Something to put on screen

There is a gap between installing an engine and having anything in front of you, and it is usually filled by a grey capsule. Fofighter Sample Kit is the other thing you could put there — characters, music, a display face and a procedural sky, lifted out of a real game and released into the public domain.

Find it under 📦 Packages ▸ 🌐 Browse. In it:

• Five models. Four stylised characters — one of them rigged — and a prop. One of them is authored lying down, in a defeated pose; that is the asset, not a broken import.
• Four music tracks: a fight theme, a menu loop, a story beat and an exposition cue.
• A display face, blocky and pixel-gridded. Latin, digits and common punctuation; check it against your own strings before using it for body text.
• A sky shader driven entirely by one number. Point a Skybox node at ashfall and drag burn from 0 to 1 to go from a cold void, through embers, to a skyline appearing in its own firelight, to flames taking the roofs, to the whole sky alight.

It is CC0: no attribution, no conditions, commercial use fine. Ship it, cut it up, sell it. The kit contains no code of any kind — no editor extension, no game script — so installing it adds files to your project and does nothing else.

A gallery you can actually look at

Package screenshots were being shrunk to thumbnail size before they were drawn, which is fine for a grid cell and useless for a screenshot: a wide picture came out as a smudge. Gallery images are now kept at full detail, and clicking one opens it as large as the window allows — Escape or ✖ to close it again.

An installed package draws its own pictures from your disk, so a gallery works with no network at all, and — the part that matters if you are writing a package — you can see your own gallery before it is ever published. Point thumbnail: and media: at files in your package folder and they show up.

What a package holds is now counted, not just listed. An installed package reads 5 models · 4 audio · 1 shaders · 1 fonts, worked out from the files on your disk rather than from anything it says about itself. That is a different sentence from "Art3D", and it is the one that answers what did I actually just install.

Fixes

A package linked from a relative path could not be found. Linking a package in place — the mode you develop one in — read its path relative to wherever the editor happened to be started from rather than relative to your project. The same link worked when the editor was launched from a terminal inside the project and silently found nothing otherwise. It is relative to the project now. Absolute paths are unchanged.

"Most downloaded" is no longer offered when nothing counts downloads. The catalogue does not report install counts, so the sort was a control that appeared to work and reordered nothing.

Upgrading

Nothing to do.

A wall you built is a wall the navmesh knows about — all of it, whatever it is made of and wherever it happens to sit.

Walls block, and they block all the way along

Bake a navmesh through a room you had built and the walls did not all arrive. Some sections blocked, some blocked in patches, and some were passed straight through as though nothing was there — with no pattern to it that you could act on, because the pattern was where your walls happened to fall against a grid you cannot see.

A wall has no height. The bake worked by asking each piece of geometry how high it was over the middle of each square of ground, which is the right question for a floor and a meaningless one for a wall: seen from above, a wall is a line. So it answered nowhere, and the only parts of your wall that registered at all were its top and its bottom — and only in the squares whose middle happened to land inside them. A thin wall missed every one.

The bake now reads what a piece of geometry occupies rather than what it is over. A wall records the solid it fills, foot to top, in every square it touches, and solid ground inside it is no longer ground. In practice:

• A wall blocks along its whole length, at any thickness — including thinner than the cell size, which used to be invisible.
• Where it sits against the grid stops mattering. The same wall nudged 3 cm gives the same answer.
• A doorway is a doorway: the navmesh runs through the gap and stops at the jambs, and closing the gap closes the route.
• The middle of a thick wall, pillar or plinth is filled in rather than left as a patch of floor stranded inside it.

This is the same for everything you can build a level out of — the Model tool, imported meshes, box and sphere primitives, and terrain. Nothing to configure; there is no "treat this as a wall" setting, because there was never a question about what a wall is.

Ground too narrow to notice

The other half of the same problem: ground thinner than the bake's cell size could fall between the squares and be dropped. A catwalk, a kerb, a narrow ledge along a drop — there, in the level, and absent from the navmesh. They are baked now.

Steps and kerbs are unchanged in behaviour and worth a re-check anyway: a lip under your step height is still walked over rather than around, and one above it is still a ledge.

The Model tool is called the Model tool

The viewport toolbar still said map. It says model, like the ▦ Model tab it belongs to, and so do the messages that go with it.

Upgrading

Re-bake your navmeshes. Existing bakes are still loaded and still work; they just contain the old answer, and the walls they were missing stay missing until the bake is run again.

One thing to expect when you do: the navmesh is fitted to the bake's grid, so it now reaches up to a cell past the true edge of a floor before the agent radius pulls it back in. With a sensible cell size — half your agent radius or less, which the bake tells you if you have strayed from it — the result sits inside your floor as it always did.

Some rooms will come out with more separate areas than before, because they genuinely have more: geometry that used to be walked through is now walked around. If a path you relied on has stopped existing, the wall it went through is the reason, and the navmesh overlay in the Scene view shows you where.

The navmesh now looks like the ground your characters walk on. The package catalogue shows you what a package actually is. And the editor opens the way you left it.

The navmesh is a surface, not a pile of boxes

Baking a navmesh used to draw every rectangle the bake had cut the floor into. That is honest about the maths and useless to look at: one continuous room came out as dozens of floating outlines, and the question you were actually asking — are these two pieces of ground joined? — was the one it could not answer. Two rectangles a character can walk between looked exactly like two it cannot.

Now it draws the walkable surface. Filled, one colour per connected area, with an outline only where the ground actually ends. The seams where the bake divided one floor are gone, because they were never real; a room reads as a room and a hole reads as a hole.

Where two elevations are genuinely connected — a step, a kerb, a ramp a character can take — that join is drawn as the surface joining them. This is what makes the settings legible. Drop max slope below the angle of a ramp and you watch the mezzanine come away from the floor it was part of: one continuous run becomes two separate elevations, in the Scene view, as you drag the slider. Raise step height past a lip and the two ledges knit together.

If you want the bake's working back — every rectangle it cut, to judge whether your cell size is too coarse — View ▸ Navmesh ▸ ⊞ …and the rectangles it was cut into puts it under the surface.

Asking the navmesh the questions you were actually asking

nav.path answered "how do I get there". These answer the rest:

nav.raycast(from, to)     -- can I just walk straight at it? nil means yes;
                          -- a point means the walk stops there
nav.reachable(a, b)       -- is there any way at all
nav.distance(a, b)        -- how far it is to WALK, not how far it looks
nav.onMesh(p)             -- am I still on the floor
nav.regionOf(p)           -- which island of the level this is
nav.random(math.random(), math.random())   -- somewhere to wander
nav.settings()            -- the character the mesh was baked for

nav.raycast is the one worth knowing about. A physics ray hits geometry, which says nothing about whether the ground beyond is somewhere this character could stand — a ledge it would fall off is empty air to a ray and a wall to a walker. This gives you the walker's answer, so "close enough to just charge at it" becomes one call instead of a sweep and a guess.

nav.distance matters more than it looks. The straight-line distance to something on the far side of a wall is a lie, and "chase the nearest one" built on it picks the wrong one every time.

nav.random takes your two random numbers rather than drawing its own. That is deliberate: rollback re-simulates a tick, and a wander destination has to come from the same seeded stream as everything else that tick decided.

For anything that needs the shape itself, nav.areas() and nav.links() hand back the polygons and the portals between them as flat arrays of numbers — nav.AREA_STRIDE and nav.LINK_STRIDE give you the step. Flat rather than one table per area because a real level is thousands of areas, and that is the difference between a call that works and one that runs the editor out of room.

A catalogue that can hold art

Packages started as editor extensions, where a name and a paragraph describes one fairly. That is no use for a texture kit, a model pack or a library of sound effects — and a texture kit described in words is a texture kit nobody installs.

A package can now show itself. In package.ron:

(
    id: "com.you.brutalistkit",
    name: "Brutalist Kit",
    version: "1.0.0",
    categories: [Art3D],
    thumbnail: "media/icon.png",
    banner: "media/wide.png",
    media: [
        (image: "media/overview.png", caption: "Every piece in the kit"),
        (video: "https://youtu.be/…", poster: "media/poster.png"),
    ],
)

categories is one or more of EditorTool, Scripts, Art3D, Art2D, Audio, Shaders, Vfx, Ui, Fonts, Template, Data — a package can honestly be two things, and an environment kit shipped with the tool that places it is one package rather than two. The long tail — "low-poly", "pixel", "PBR" — stays in keywords, which is searched.

🌐 Browse is a grid. Thumbnails, filtered by category, sorted by recently updated, highest rated, most reviewed or name, with every count telling you how many rows that filter would actually leave. Packages with no picture get their category's mark rather than a broken frame.

Alongside the shelves an author picks, you can filter by what a package demonstrably holds — has models, has audio, has editor tools — worked out from the files it ships rather than from anything it claims. I need SFX is a different question from show me what somebody filed under Audio, and this answers the first one.

"Highest rated" now means it. A single five-star review no longer outranks a package with ninety reviews and a track record. The score on screen is still the plain average of the reviews you can read; only the ordering knows the difference between confident and lucky.

Nothing here is required. A package with none of it lists exactly as it does today, and an older catalogue browses exactly as it did.

One honest note on timing: the editor can read all of this now, and you can put it in your package.ron today. The catalogue on fopull.com starts carrying thumbnails and categories shortly — until it does, Browse is the new grid with the old information in it, and packages draw their category mark rather than a picture. Nothing you write now is wasted; it is read the moment the catalogue serves it.

📦 Packages is a tab

It was a floating window over the scene you were judging a package against, which meant closing it to look and opening it to act. It is now a dock tab like any other: drag it beside the viewport, split it under the Hierarchy, leave it where you want it. Window ▸ 📦 Packages opens it.

The editor opens the way you left it

Panel layout and window size, position and maximised state are all remembered between sessions. If you work with the Inspector wide, or the Console pulled out beside the viewport, that is how it comes back.

Two ways out, under Window:

• ⟲ Reset layout — every panel back where it starts, and the saved one forgotten, so it stays reset.
• ⟲ Reset window size — back to a size that is definitely on screen.

A window saved on a second display that is no longer plugged in opens where you can see it, rather than off the edge of the world.

Upgrading

Nothing to do. Your first launch after updating uses the default layout and starts remembering from there. Existing bakes draw the new way immediately — there is no need to re-bake.

A navmesh could quietly miss the floor. And several things decide where they apply from a box or a radius you could not see — now you can see them.

A navmesh no longer loses the floor

With fit the box to what it finds turned off, a bake could come back with the tops of your furniture and almost nothing to walk on between them.

A floor is usually a couple of very large triangles, and their corners are nowhere near the box you would draw around a room. The bake kept a piece of geometry only when one of its corners was inside the volume — so the floor was thrown away for being too big, while every small object standing on it was kept. The result looked like a level that was somehow not walkable.

Anything overlapping the volume is now baked, whatever size it is. If you have a navmesh that came out in scattered patches, re-bake it.

Areas of effect are drawn

View → gizmo menu → Areas of effect draws the volumes that were previously only a number in a panel:

• Reflection probes — the box, and the fade as a second box inside it. The gap between the two is the crossover, which is why one outline was never enough to show it.
• Light probe volumes — the box the baked bounce applies inside.
• Navmesh bounds — the box a bake covers, which matters most when you have turned fit the box to what it finds off to bake one room of a larger level.

Each outline is scaled by its node exactly the way the volume is, so what you see is the volume that is actually used.

Sound range is drawn

Sound range in the same menu draws two rings around every positioned sound: the inner one is full volume, the outer one is silence, and the gap between them is the fade. Placing a sound and knowing how far it carries used to be two numbers and a walk around the level to check.

Sounds set to play flat draw nothing. They ignore position entirely, so a ring around one would say something untrue about it.

Upgrading

Nothing to do. Both are on by default and can be turned off per category in the gizmo menu, like every other gizmo.

Characters can now be told to walk somewhere, and they work out how to get there. And reviewing a package is a button rather than a sign-in.

"Walk to that door"

Add a Nav Mesh node, press Bake, and the engine works out every place your character can stand and how to get between any two of them.

local route = nav.path(self.node.position, door.position)
if route then
    for _, corner in ipairs(route) do walkTo(corner) end
end

nav.path hands back the corners to walk — not a step-by-step crawl through the level, but the few points where the route actually turns. Across an open room that is a straight line. Around a corner it is one turn, hugging the inside of the bend the way a person would.

It also tells you whether it reaches the goal:

local route, arrives = nav.path(here, there)
if route and not arrives then
    -- as close as the ground allows: the far side of a gap, the near
    -- side of a chasm. Walking there and stopping is usually right.
end

That is different from getting nothing back. Nothing means an end was not on the navmesh at all — off the level, or inside a wall. A route that does not arrive means the place exists and you cannot walk to it. A character who walks to the edge of a chasm and stops is behaving; one who stands still because the answer was empty looks broken.

nav.nearest(point) drops a click, a spawn, or a knocked-back character back onto walkable ground. nav.ready() says whether this scene has a bake at all.

What gets baked

Whatever your character would collide with. That is the rule that stays right as a level changes — a wall you build today blocks a path today, without anybody remembering to tag it. Terrain counts without being marked.

Narrow it two ways:

• Layers on the Nav Mesh node. Tick Level and only that layer is baked. Nothing ticked means everything.
• Navmesh Exclude, a component you add to one object. It comes out of the bake whatever else is true of it — a glass floor collides, and is not ground.

The bounds size themselves

Fit the box to what it finds is on by default, so you never measure a volume by hand. The bake looks at everything your filter selected, moves the node to the middle of it, and sizes the box to match. Untick it if you want to bake one room of a larger level.

The character it is for

Four numbers, and they are the four that describe walking:

Cell size is the fifth, and the only one about speed rather than about the character: how finely the level is sampled. Halving it quadruples the bake. It also has to stay small next to the radius, and the Inspector tells you in words, with the number to use, when it is not — a coarse cell quietly closes narrow gaps, and "my corridor vanished" otherwise gives no hint which setting did it.

Seeing it

The bake draws in the Scene view whenever its node is selected, or always from View → Navmesh, with a colour per connected area.

That colouring is the useful part. The question you will have is "why won't it walk over there", and two different colours meeting at a doorway answers it instantly: that gap is too narrow for the character this was baked for. Widen the door, or bake a smaller character.

The Inspector counts what a bake would cover before you press anything, so an empty filter and an empty bake are not the same screen.

Reviewing a package is a button

Write a review appears on any package you have installed and enabled, and opens that package's review page with the package already picked. It becomes Edit your review once you have written one, alongside the version you wrote it against — "you reviewed v1.0.0 — you have v2.0.0 now" is worth knowing about your own review.

Reviewing happens on fopull.com now rather than in a panel. That is where your account already is, and it means the button works without signing in twice.

fopull.com/packages is a proper catalogue too: search across name, id, author and keywords, and sort by recently updated, highest rated, most reviewed or name.

Upgrading

Nothing to do. A scene with no Nav Mesh node behaves exactly as it did.

A bake is saved beside the scene and loads with it, so it is worth committing alongside your scenes — and worth re-baking after you move walls, since a bake does not know the level changed.

Anybody can publish a package, and nobody vetted it. So the catalogue now says that plainly, and shows you what people who actually ran a package thought of it.

The catalogue tells you what it is

🌐 Browse now says, in as many words, that packages are made and managed by their authors rather than by Fopull — that listing is automatic, that the checks are structural, and that a package is code that runs in your editor.

It is not a warning sticker. It is the honest description of what a listing means, said once where you are deciding, because "it was on the official catalogue" is otherwise very easy to read as "somebody vouched for this".

Reviews, from people who ran it

Every row shows a score and how many reviews it is made of — or no reviews yet, which is drawn as its own thing, because a package nobody has got to is not a package everybody disliked.

Open reviews on a row to read them. Each one says which version it was written against. That matters more than it sounds: a glowing review of 1.0.0 tells you very little about the 3.0.0 you are about to install.

Writing one

You can review a package once you have it installed and enabled. That is the whole gate, and it is the point — a package sitting in your project switched off has not been tried, and reviewing it would be reviewing something that never ran.

Pick a rating out of five. Words are optional — a rating on its own is a perfectly good review — up to 2000 characters, counted as you approach it rather than refused after you have written past it. The version you have installed goes with it, and posting again replaces your earlier review rather than stacking a second one: you are allowed to change your mind about a package that got better. Remove my review takes it back.

You are already signed in

The editor now knows your Floptle account, because it is the same account as the Hub. One entry in your operating system's keyring is shared by the Hub, the editor and every game you run, so signing in anywhere signs you in everywhere, and staying signed in is the default rather than something you re-do.

The Packages window shows who you are, and lets you sign out or sign in as someone else. Nothing else in the editor requires an account, and nothing sends anything anywhere until you post a review.

Upgrading

Nothing to do. Scores and reviews appear as the catalogue starts carrying them; a package with none shows none.

If you point the catalogue at your own registry, its reviews come from there too. Posting only ever goes to fopull.com — the editor will not send your access token to another host.

A package you installed from somewhere else does not run until you say so.

Installing something is no longer the same as running it

Installing a package from the catalogue, or from a Git URL somebody sent you, used to load and run its code immediately. What the package had asked for — network access, the run of your project's files, your browser — was only visible afterwards, folded away in its row.

That is the wrong order. A package that declares any permission now arrives installed but switched off, with what it asked for shown on its row in 📦 Packages. It starts running when you tick the box, and that tick is the decision.

A package that declares nothing is enabled on arrival, as before. It can read its own folder and nothing else — the same standing every built-in tool already has — and a confirmation nobody can act on only teaches people to click through the ones that matter.

Packages installed from a folder on your own disk, or linked while you write one, are unchanged. You chose those file by file.

Why now

Listing on the catalogue is automatic once a submission passes its checks. That makes the moment you tick that box the last point at which anybody looks at what a package wants — so it needed to be a moment, rather than something that had already happened.

Also

The permissions table in the packages guide claimed the list was shown before a package was installed. It was not; it is now shown before one runs, which is the part that matters. The guide says what actually happens.

Upgrading

Nothing to do. A package you have already installed and enabled stays enabled — this changes what happens when a new one arrives, not what you have already decided.

Renaming a scene used to leave its terrain behind.

A scene keeps its work when you rename it

Terrain fields, the blockout map, vertex paint and autosaves are all stored under the scene's name. Renaming a scene moved the .ron and nothing else, so all of it stayed behind under the old name and the scene reopened with an empty terrain.

That is the worst possible way for this to fail, because an empty terrain looks exactly like a terrain you never made. Nothing announced it, and the obvious reading of the situation — the work is gone — was wrong.

A rename now moves all of it together. Two details that matter as much as the fix:

• If anything would land on a file that already exists, the whole rename is refused and names the file in the way. A half-finished rename would leave one scene reading another scene's terrain, which is worse than not renaming at all.
• If the scene you renamed is the one you have open, it follows. Otherwise the next save would write the terrain straight back under the old name.

A terrain with no data says so

Opening a scene whose terrain data is missing now tells you, in the Console, naming the file it looked for — instead of quietly handing you a flat slab.

And if the data is sitting there under a different scene's name, it says that too, and names the file. A rename is not the only way a field can go missing, so this stands on its own; but when a rename is the cause, the message is the answer.

If this already happened to you

Your work is very likely still on disk. In your project's terrain/ folder, look for files named after what the scene used to be called:

terrain/<old name>.1.cfield      the terrain itself
terrain/<old name>.palette       its texture slots
maps/<old name>.map.ron          the blockout map
paint/<old name>.vpaint          vertex paint

Rename each to the scene's current name — <old name> becomes <new name>, the rest of the filename stays exactly as it is — and reopen the scene. Copy rather than move if you want to keep the originals until you have checked.

If you are not sure what the scene used to be called, open it and read the Console: it now names the orphaned file for you.

Upgrading

Nothing to do.

Six small additions to the editor API packages use, all found by writing a real package against it.

Widgets a tool actually reaches for

• gui.helpBox(text, "info" | "warn" | "error") — a boxed note. A tool with something to tell you should look like it is telling you something.
• gui.flexibleSpace() — pushes the rest of a row to the far end, for a toolbar with something on each side.
• gui.height(px, fn) — the partner to gui.width. What you use to keep an input row at the bottom of a panel instead of letting a scrolling list walk it down the page.
• gui.textField(value, hint, grabKeyboard) — pass true as the third argument and the box takes the keyboard that frame. A panel opened with a shortcut can now be typed into straight away, rather than needing a click first, every time.

Which way a thing is facing

scene.info(id).extents is a node's oriented half-extents in world units. Read it with rot when orientation matters, which is most of the time for a placement, measurement or export tool.

scene.bounds is now the world-aligned box around that oriented box rather than around its bounding sphere — so a crate turned 45° reports a wider bounds than its extents, correctly, and a square-on wall no longer reports a box big enough to contain a sphere it never filled.

Hashing

bit — LuaJIT's bit library — is available to packages. It is pure integer arithmetic with no route out, and it is the difference between a package being able to compute a hash and not. A tool that uploads something wants to know whether it has changed since last time; one that signs you in through a browser needs a challenge.

Upgrading

Nothing to do. Every addition is new; nothing existing changed shape.

One clarification now written down: keep a package's library files outside editor/. Everything under editor/ runs on its own when the package loads, so a module kept there executes once as a script and again when something requires it. require resolves from the package root, so lib/ beside editor/ is the layout that works.

Floptle now has packages: folders of tools, scripts and art that anybody can write, install and share. And the editor has an API of its own, so a package can add menus, panels and viewport tools that sit beside the ones that ship with it.

Install a package

Window ⏵ 📦 Packages.

A package is a folder. Point the editor at one and it is copied into your project; paste a repository URL and it is cloned and copied the same way; or open 🌐 Browse and install from the catalogue. What you installed is recorded in packages.ron at the project root, so a teammate who clones the project gets the same list.

Every package can be switched off without removing it — one checkbox. That is the first thing to try when the editor starts behaving oddly, and it deletes nothing.

A package can hold any of:

• editor tools — menus, panels, viewport overlays, gizmos
• scripts your game attaches to nodes, exactly like your own
• assets — models, textures, prefabs, scenes, effects, shaders, tilesets
• samples — example scenes and demo art, copied in only when you ask, so a package can carry a big demo without every project paying for it

An assets-only package is a perfectly good package. It needs no code at all.

Address anything inside one with pkg://<package id>/<path>, which keeps working wherever that package's folder ends up — including inside an exported build.

Write a package

📦 Packages ⏵ ✚ Add ⏵ New Package. Give it an id and a name and you get a folder that already runs: a manifest, an editor script that draws a panel, and somewhere to put scripts and art.

While you are working on one, use 🔗 Link folder instead of installing it. Nothing is copied — the project reads the package where you are writing it, so one edit reaches every project you have linked it into. Press ⟲ Reload all and your changes are live.

The manifest is short. Three fields are required:

(
    id: "com.you.grasstools",
    name: "Grass Tools",
    version: "1.2.0",
    description: "Scatter and paint grass on terrain.",
    engine: ">=0.55.0",
    dependencies: [ (id: "com.you.core", version: "^1.0") ],
    permissions: [Network],
)

A package says what it may reach for, and you see that before you install it. Network, Files and Browser — and a package that declared none of them can read its own folder and nothing else. This is not a label: a capability a package did not declare is simply absent from its code, not merely refused when it is used.

Dependencies are worked out for you, including load order. A package that will not load — a missing dependency, an engine version it cannot run on, a mistake in its code — is skipped, loudly: the project still opens, the row in 📦 Packages says what happened, and everything else keeps working.

docs ⏵ Packages is the full guide.

Add your own tools to the editor

A package's editor/*.lua runs in the editor, with an API the game never sees.

local brush = 2.0

local panel = ed.window("Grass", function()
    gui.heading("Brush")
    brush = gui.slider(brush, 0.1, 20, "radius")
    if gui.button("Scatter here") then
        ed.undo()
        scene.create("Grass")
    end
end)

ed.menu("Grass/Brush…", function() panel:show() end)
ed.shortcut("Ctrl+G", function() panel:toggle() end)

ed.onSceneDraw(function()
    handles.color(0.3, 1.0, 0.5)
    handles.wireDisc(ed.camera().pos, vec3(0, 1, 0), brush)
end)

What that gets you:

• Panels and menus that sit in the editor's own menu bar, and keyboard shortcuts.
• Overlays pinned inside the Scene view, for a tool you want to hand while you work.
• handles.* — lines, boxes, spheres, discs, arrows, filled shapes and text drawn in the world, for regions, paths and measurements.
• gui.* — buttons, sliders, text fields, dropdowns, colour pickers, collapsing sections, scroll areas, and direct painting for charts and heatmaps.
• The scene, readable and editable: names, transforms, hierarchy, bounds, tags, layers, attached scripts — with a real undo point, so Ctrl+Z undoes what your tool did.
• scene.raycast, for finding the ground under a point, picking what is in front of the camera, or snapping something to a surface.
• Somewhere to remember things: per person, per project, or until the editor quits.
• http.*, for a package that declared Network — never blocking, so a slow server cannot freeze the editor — including a loopback listener for signing in through a browser.

An error is reported to the Console once and the callback that raised stops being called, rather than raising sixty times a second. The panel shows what went wrong; fix the file and press ⟲ Reload all.

docs ⏵ Editor scripting is every call. Scene Report in the repository is a small, complete package that uses one of everything — install it from disk and read it.

Publishing

A public Git repository with a package.ron in it can be installed today, by anybody, from the URL. To appear in 🌐 Browse, submit it at fopull.com/packages. If you would rather not publish, point the browser at a catalogue of your own — the URL is a box under Registry.

Upgrading

Nothing to do. Projects with no packages are unchanged, and no existing file gains a field.

One thing worth knowing if you write scripts: a package can ship Lua your game attaches to nodes, and your project's own scripts/ folder is always searched first. Installing a package can never change what a script name in your project already means.

Mirrors that are actually mirrors, a panel that says which part of a frame is slow, and interiors that render two and a half times faster than they did.

Mirrors can be mirrors now

A polished surface came out frosted, and no setting would fix it. Roughness 0 was sharp; anything above it fell off a cliff. A material at roughness 0.1 — a surface you have asked to be nearly a mirror — was being read from a blur eight times wider than it should have been, so the only way to get a crisp reflection was to sit exactly on zero, and the moment you nudged the slider you were back to frosted glass. It was easy to make something look like brushed steel and near impossible to make something look like a mirror.

The blur a reflection is read through now follows the size of the highlight the surface actually has. Sharp materials stay sharp across the whole polished end of the slider, rough ones blur as before, and the two ends finally meet in the middle.

Two more things came out of the same work:

• A reflection of something close stays sharper than a reflection of something far. The same polished floor should mirror the chair leg beside it and blur the far wall — that difference is how far the light travelled, and it is now part of the picture. Frosted glass gains the same behaviour: a pane held against a wall frosts it less than the same pane held across the room.
• Reflections at a distance no longer fall apart. A mirror ball looked right up close and wrong from across the room, because close up the reflection came from the scene in front of you and further away it fell back to the probe. Both ends of that hand-off are now sharp, so the change of source stops being something you can see.

Reflection detail

Project Settings ⏵ Rendering ⏵ Reflection detail. A ◐ Reflection Probe captures the room around it as a single picture spanning a whole turn, and the size of that picture is the finest thing a mirror standing in that room can possibly show. It was fixed, and it was small — about one and a half degrees per pixel, which puts a doorway across a room on roughly four of them. Below that, no roughness setting helps, because the detail was never captured.

Four levels, high by default and four times the detail it used to have. The cost is paid when a probe captures, not every frame — standing still, all four cost exactly the same — so this is a load-time and memory trade rather than a frame-rate one. ultra is there for a hero mirror.

Two mirrors facing each other

A pair of facing reflective surfaces used to climb into a white blob. Not settle somewhere bright — climb, over about a second, brighter every frame, until whatever they could both see was blown out. A reflection is drawn from the picture the frame before it, and that picture already contains its own reflections, so two mirrors pass the same light back and forth and a polished metal gives almost none of it up on the way.

Lighting ⏵ brightness cap is the ceiling that makes it settle instead. Ordinary highlights sit well underneath and are untouched; set it to 0 if you want the old behaviour back.

Where the time goes

Window ⏵ ⏱ Frame timing. Until now the engine could tell you a frame was slow and nothing about which part of it was — so the only way to find out was to switch features off one at a time and watch the number, which is slow, and which under vsync doesn't work at all, because every answer comes back the same.

The panel measures each part of the frame on the GPU and lists them longest first: the sky, the depth pass, opaque surfaces and lighting, 2D lighting, glass, the post chain, the editor's own drawing. Nothing is measured while the panel is shut, so leaving it closed costs nothing.

The first thing it was pointed at was a Backrooms-style interior, and it named the culprit immediately.

Interiors render 2.6× faster

Volumetric fog was most of the frame — in that scene, six milliseconds out of eight, on a scene with four ceiling lights in it. Three things were wrong, and all three are fixed:

• The fog asked every lamp for a full surface-lighting calculation and then used two numbers out of it. There is no surface in mid-air — nothing to be facing the light, no highlight to place — but the air was paying for both, once per lamp, per step along the ray, per pixel.
• Lamps out of range were evaluated and then discarded. The range test came after the expensive part, so a lamp at the far end of a level cost as much as one overhead.
• The fog's drifting texture was sampled forty times per lump. It is tens of metres across and was being asked for a fresh value every fraction of a metre along every ray.

Fog looks the same. It costs about a seventh of what it did.

Two smaller ones alongside, both worth knowing because they describe scenes rather than settings:

• A scene with the sun turned down still paid for sun shadows — every interior, in other words. The shadow trace ran per pixel and the result was multiplied by black.
• Screen-space reflections ran on every surface, including the ones with no reflectivity at all, because the "how reflective is this" multiplier was applied after the work rather than before it. Rough surfaces now stop tracing early as well, since past a point the result is blurred into what the probe already says.

Children that went missing from the Hierarchy

Anything parented to something that isn't a folder disappeared when you reopened the project — a Reflection Probe under a plane, a light under a mesh — and nothing would bring it back. The row showed no arrow to expand, so it read as though it had nothing inside it, and a child added afterwards vanished the same way.

They were always still there and always saved; there was simply no way left to reach them. Reopen an affected scene and its children are back, in place, untouched.

Upgrading

Nothing to do. Reflection detail defaults to a level four times finer than before — if a project is tight on memory and never looks closely into a probe, low restores the old size.

Two bugs behind "it looks right in one view and wrong in the other", and the answer to "why is this tiny scene running at 20 fps".

The Scene view and the Game view agree again

Reflections, contact shadows, shoreline foam and lamp shadows could be missing from one view while working in the other, and could start working on their own after you resized a panel. All four read the same hidden pass, and the editor was handing it out per view — but not always to the right view.

Two separate faults, both fixed:

• The Scene view could be drawing with the Game panel's depth. Once both views existed, the Scene view stopped refreshing its own copy and used whatever the Game panel had left: another camera, at another size. Reflections landed in the wrong place or vanished, and any resize made them briefly correct again — which is exactly what it looked like.
• The Scene view skipped the pass entirely in some scenes. If your scene had contact shadows on but not reflections or lamp shadows, the Game panel ran the pass and the Scene view did not, so contact shadows appeared in one and not the other.

Nothing to change in a project. If you have been squinting at a difference between the two views, look again.

Why a small scene ran at 20 fps

A scene that costs 8 milliseconds a frame was presenting at 20 fps, and there was no way to see that from inside the editor. The frame was not slow. The display path was accepting one frame in three.

Two things come out of that.

Project Settings ⏵ Rendering ⏵ Frame pacing. How finished frames reach the display is now yours to choose:

• smooth (vsync) — every frame shown, in order, at the display's cadence. The default, unchanged, and the one whose motion is most even.
• uncapped, no tearing — render freely; the display takes the newest frame each refresh. No cap, no tearing, but movement can judder, because the frames you see sampled the world at moments unrelated to when they appear.
• uncapped — present the instant a frame is ready, tearing and all. The setting for "how expensive is this frame, really".

If your frame rate is pinned to a round number no matter what is in the scene, try one of the other two. On the machine this was found on, a window doing nothing but painting itself a solid colour sat at 20 fps under vsync and ran freely under either of the others.

And the window title now shows what a frame actually costs, beside the rate:

Floptle Editor — first — 20 fps (8.2 ms/frame) — 23 nodes …

Those answer different questions. A low rate with a small cost is the display pacing you; a low rate with a large cost is a scene to optimise. Time spent waiting for the display is measured and kept out of the cost, so the two never get confused again.

Worth knowing

Reflections of the scene are a switch you have to turn on. A shiny material shows the sky and the lights without it; showing the room is Lighting ⏵ reflections, and it is off until you set it. If a floor is reflecting less than you expected, that is the first thing to check — and indoors, pair it with a ◐ Reflection Probe so what leaves the frame comes back as the room rather than as daylight.

Upgrading

Nothing to do.

Three things reflections and shadows could not do last month, all of them the same shape: the engine only knew about what the camera could see. A mirror indoors reflected daylight through a sealed ceiling. A torch stopped casting the moment you turned away from the wall doing the blocking. A pane of glass hid everything behind it, including other glass.

A mirror indoors shows the room

Add ⏵ ◐ Reflection Probe.

Turn reflections on and a polished floor shows the table standing on it — but only the part of the table that is on screen. For everything else, until now, it showed the sky. Outdoors that is right: a reflection that leaves the frame is heading for the horizon. Indoors it is daylight arriving through the ceiling of a sealed room, and there was nothing you could do about it.

A reflection probe is what a room reflects. Drop one in, size its box to the walls, and every reflective surface inside it shows the room instead of the sky.

The box does two jobs, and sizing it to the room is what makes both work. It says which surfaces the probe speaks for, and it is what makes a reflected wall land on the wall — without it a reflection is a picture at infinity and slides about as the camera moves.

• size — the room, in metres. Move and scale the node like anything else.
• edge fade — how far outside the box the room gives way to the sky. Give a doorway a metre or two so walking out of it crosses over smoothly.
• strength — how much of the capture to apply. 1 is what was measured; this is the knob for a room that reads too busy or too dim in its reflections.

Up to four probes are live at once and they blend where their boxes overlap, so a corridor opening into a hall does not switch environments in one step. With more than four in a scene the nearest four to the camera are the ones you get.

find("Hall"):getcomponent("ReflectionProbe").intensity = 0.6

Nothing is saved to disk. The picture is taken when the scene loads and again whenever you move or resize the probe, which takes a fraction of a frame — so there is no file to go stale and nothing to remember to rebake. What a probe cannot notice is the room being relit or the furniture being moved: there is a recapture button on the node for that.

A lamp stops at a wall you are not looking at

A Point Light ⏵ casts shadows — same switch, twice the shadow.

Last release gave lamps shadows, with one honest limit stated plainly: an occluder the camera could not see could not cast. Turn away from a wall and the shadow it was throwing stopped existing, which is the most alarming way a shadow can behave.

A casting lamp now also checks the scene's own geometry, not just what is drawn on screen. A wall blocks a torch whether you are facing the wall or facing away from it. Between the two halves, the shadow keeps the exact silhouette of what is in frame — every railing and bolt of it — and stops guessing about the rest.

Nothing to turn on. Any lamp already set to cast picks this up.

The soft edges come for free, and correctly. How sharp a shadow is depends on how big the light looks from the surface, so a wide sphere lamp close up throws a soft edge and a bare point throws a hard one — with no knob for it, because there is a right answer.

What blocks a lamp is anything the scene knows the shape of: terrain, blobs, and anything carrying a collider. A decorative mesh with no collider is not in that list; give it one — or stand any collider shape in for it — and it casts.

One thing worth re-checking: a scene with the sun's shadows switched off and a lamp set to cast was quietly missing half its occluders. It is not any more, so a level lit only by lamps may have shadows in it that were not there yesterday.

Glass behind glass

Lighting ⏵ glass layers.

A see-through surface works by looking at a picture of what is behind it, and that picture has to be taken before the surface is drawn. One picture means one correct layer — the nearest — so a fish tank's back wall stopped existing the moment you looked through its front one. The advice was to build it as one box rather than six.

Glass layers is how many depths of see-through surface can be looked through at once, 1 to 4. At 2 — the new default — a window can have a bottle standing behind it, a tank can be six panes, and a pair of glass doors reads as two doors.

Each layer costs one more pass, and only while something see-through is actually in view. At 1 you get exactly what the engine did before, for exactly what it cost.

find("Lighting"):getcomponent("Light").refractionLayers = 3

Two panes at the same distance still show only the nearer one, so 4 is a ceiling rather than a promise — but the case that sent people to the manual, one pane in front of another, works now.

Upgrading

Nothing to do. Glass layers goes to 2, which costs nothing in a scene with no glass in it. Reflections still show the sky until you place a probe. Lamp shadows are still off per lamp until you turn them on — but a lamp already casting will now be blocked by more than it was, which is the point.

Not in this one

• Probes stream, but only four at a time. A level with twenty rooms wants probes swapped in and out as you walk; today the nearest four are live and the rest wait their turn.
• A probe does not notice a room changing. Relight it or move the furniture and press recapture.
• A reflected object does not reflect. A probe captures the room around it, not the mirrors in it, so a mirror facing a mirror shows the room rather than a corridor of itself.

A floor shows the room standing on it. A crystal ball shows the room through it, upside down. A lamp stops at the wall. And the Game panel finally shows the same game whether it is docked in the corner or filling the window.

Mirrors that show the room

Inspector ⏵ Lighting ⏵ reflections.

Set a material to physical shading, turn metallic up to 1 and roughness down to 0, and you have a mirror. It shows your scene's sky — a skybox image, a sky shader, or the built-in star vault — and, with the scene's reflections switch on, it shows the scene as well. A polished floor reflects the table standing on it. A wet street reflects the sign above it.

Raise the roughness and the same reflection blurs. That one slider is the difference between chrome, brushed steel and a dusty ball bearing.

Reflections are a scene-wide switch on the Lighting node rather than a per-material one, because whether a mirror shows the room is a fact about the scene, not about one surface. What each material still decides is how much it reflects and how sharply — there is a new reflections slider beside metallic for that. It is at 1, the real amount, and it is there for the times physics is not what you want: pull it down to take the sheen off something reading too glassy, or push it past 1 on a hero prop that deserves to be flattered.

node:setMaterial{ shading = "physical", metallic = 1, roughness = 0, reflectivity = 1 }
find("Lighting"):getcomponent("Light").reflections = 1

Three knobs sit under the switch. Reach is how far a reflection sees — a puddle showing a building across the street needs more of it than a floor showing the table on it. Steps is how carefully it looks; raise it with the reach, or reflections start missing thin things. Thickness is how solid the scene is assumed to be: too little and reflections come out speckled with holes, too much and railings and leaves smear over what is really behind them.

Only what is on screen can be reflected. Anything behind the camera, off the edge of the frame, or hidden behind something nearer falls back to the sky. That is the shape of the technique rather than a setting, and it is why the sky reflection underneath still matters: it is what makes a reflection fade into the horizon instead of into a black patch.

This changes how existing physical materials look, and that is the point: they were computing a reflection and had nothing to reflect, so anything metal came out far darker than it should have. Materials on the default (classic) shading are untouched.

Glass, and things you see through

Inspector ⏵ Material ⏵ see-through.

A crystal ball now behaves like one. Turn see-through up and the scene behind the surface comes through it — bent by bend (the index of refraction), frosted by roughness, and tinted by the material's own colour, so green glass makes what is behind it green. A solid ball at a real index of refraction is a lens, and turns the room behind it upside down.

This is a different thing from opacity, and worth keeping straight. Opacity fades a surface away and takes its highlight, its reflection and its bright grazing edge with it — at 0.2 you have almost no surface left. See-through keeps all of that and lets the light through as well, which is what actually makes something read as glass rather than as a ghost.

• bend — 1.0 does not bend at all, 1.33 water, 1.5 window glass, 1.8 heavy crystal, 2.4 diamond.
• thickness — how far light travels inside the material, in metres. Set it to roughly the size of the object. How far the distortion actually throws what is behind also depends on how far away that is: glass against a wall barely shifts it, the same glass held up against a distant one throws it right across.
• roughness frosts it — the same slider that blurs a reflection blurs what you see through.

node:setMaterial{ shading = "physical", transmission = 1, ior = 1.6, thickness = 1.2 }

A scene with no glass in it costs nothing for this: the extra work happens only when something in view is actually see-through. The one limit worth knowing is that only the nearest layer of glass distorts — two overlapping panes show the front one's bending, so a fish tank wants to be one box rather than six.

Lamps that stop at walls

Inspector ⏵ a Point Light ⏵ casts shadows.

Every placeable light in the engine used to shine through everything. A torch in a doorway lit the room behind the door exactly as brightly as the one it was standing in, and there was no setting anywhere that changed it.

Now a lamp can cast. Tick casts shadows on the light and it stops at the walls, crates and characters between it and what it is lighting.

It is per lamp and off by default, because most lights in a level have nothing to be blocked by — a strip under a counter, a glow inside a sign, a fill light placed exactly so — and each casting light costs something. The ones worth turning on are the ones a player can walk around.

Same rule as reflections: it shadows from what is on screen. A wall casts while it is in frame and stops when you turn away from it.

find("Torch"):getcomponent("PointLight").shadows = 1

The Game panel is the game

A docked Game panel showed a different picture from the same game fullscreen. Contact shadows, shoreline foam, reflections and lamp shadows were all missing from it — not dimmed or approximated, simply absent — so the small panel you work in disagreed with the window you test in, and only the window was telling the truth. Every one of them works in both now.

And the border is gone. The panel had a band of the editor's own view of the scene showing all the way around the game, which moved when you orbited the Scene camera, because that is exactly what it was. The game takes its whole panel now, rendered at the size it is shown at.

Water that knows where the shore is

The built-in water shader foams against anything, not just terrain. Rocks you modelled, a jetty, a hull, a crate someone dropped in the shallows — the waterline finds all of it, with nothing to mark up.

Three knobs where there was one: foam (how far it reaches), foamEdge (how crisp the line is) and foamNoise (how much the waves eat into it, which is what stops it reading as a painted-on band). Thin water is see-through now too, so the edge sells itself.

In a scene made only of meshes this did nothing at all. It worked against terrain and quietly gave up on everything else, which is the worst possible half — the shader looked correct in a test level and blank in a real one. Anything that measures the scene behind a surface was affected the same way, including soft particles and contact glow. Fixed.

If you write shaders, this is surfaceGap() — how much room there is between a surface and whatever solid thing is behind it.

Copying keyframes

Copying a rotation key used to move the object to the world origin. If a key only set a rotation — which is most keys, on most spinning things — copy read a whole pose anyway and filled in the position and scale it could not find. Paste, and the object jumped to nowhere at scale 1.

A copied key now carries exactly the channels it had. While we were in there:

• Property keys copy. Opacity, light intensity, an image swap — Ctrl+C over one of those used to do nothing at all, and say nothing about it.
• The clipboard answers. ⎘ / ✂ / 📋 buttons sit beside undo, greyed out with the reason when there is nothing to copy or nothing to paste, and every copy, cut and paste says what it did.
• The shortcuts work where you are working. Ctrl+C/X/V belong to the dopesheet whenever your pointer is over it, not only when the tab has been clicked in exactly the right place.

Bones you can grab

Bones are drawn as octahedra — wide at the joint, tapering to the next one — instead of bare white sticks. The shape twists when the bone rolls, so you can finally see which way an elbow is facing, and you can click anywhere along a bone rather than hitting a small dot at its end.

Telling which way is which when you rotate

The rotate gizmo drew three full circles on top of each other, which is a ball of overlapping rings and not much else. Now each ring draws solid on the near side and ghosted on the far side, so you can tell them apart and tell which way each one faces. The object's own X, Y and Z are labelled beside it.

The Model tool

• Ctrl+A selects everything in the mesh you are editing. It was on U, which nobody has ever guessed.
• Ctrl+click selects the path between two picks — click one face and Ctrl+click another, and everything on the shortest route joins the selection. Works on vertices and edges too. (Ctrl+drag still subtracts a box, and Shift+Ctrl+click still removes one thing.)
• Loop cut (Shift+/) inserts an edge loop across a strip of quads, so a shape has somewhere to bend without its silhouette changing at all.
• Bevel (Shift+') takes the sharpness off the selected edges, with a width you set once.
• Ring select (Shift+\) extends a selection across a strip — the edges a loop cut would run through.

Fixed

• The editor crashed when you opened a shader in the graph. Opening one shader, then a second one, could take the whole editor down. It was not any particular shader: the thumbnails could not tell two freshly-opened files apart and drew one graph using the other's compiled preview.

Upgrading

Nothing to do. Physical materials will look different — brighter and more reflective, which is what they were always asking for. Reflections, lamp shadows and glass are all off until you turn them on, so every scene loads doing exactly what it did.

The PS1-era look is now a project setting rather than something you set on every material you own. And any single surface can now stand outside the scene's fog.

The era's artefacts, for the whole project

Project Settings ⏵ Rendering ⏵ Era artefacts.

Vertex jitter, affine textures, vertex lighting and screen-door transparency used to be four checkboxes on each material. For a game whose whole look is of that era, that meant setting them on every material you own — and on every material you import next week. Now you ask once and the project answers.

They reach everything that draws: models, primitives, tilemaps, map geometry, terrain chunks, characters. Including the surfaces that never named a material at all, which is most of a level.

Jitter is offered as named strengths measured against your own pixel resolution, not a number:

They are derived from the project's own pixel rows, so pixels means the same thing whether you render at 240 rows or 480 — you don't have to work out which number is right for your resolution. The raw grid-step number is still there under the presets for anything in between.

Nothing changes for a project that doesn't turn this on. All four start off, and a project file that never touched them loads to exactly the look it has now.

Holding one thing steady

A material can take none of it — Retro artefacts ⏵ project artefacts ⏵ opt out, or retroExempt = true from a script.

That's for the one thing in a wobbling world that has to sit still: a first-person weapon a metre from the eye, a screen-facing card, a sky shell whose seams the snap would tear open.

A material's own settings still work too, and still win. A jitter you dialled in by hand on one surface stays the number you dialled; leaving it at 0 means "follow the project".

About that wobble

Vertex jitter is a snap, not a shimmer. It runs every frame, but a still camera looking at a still object lands in the same grid cell every time and holds perfectly still — which is exactly what the hardware did. The wobble is what motion looks like through the grid, so move something to see it. If you have been staring at a paused scene wondering whether it is on, that is why.

Each vertex also crosses its own cell boundary on its own frame, so a surface doesn't slide in clean steps — it warps. That's the era's look, not a fault.

A surface can stand outside the fog

New on every material: fog — affected by scene fog, on by default. Turn it off and the surface draws at its own colour however far away it is. Both the distance ramp and the volumetric layer leave it alone.

For the things that aren't really in the world at that distance. A first-person weapon sits a metre from your eye and a hundred metres from the level's origin, so the fog treats it as scenery. A backdrop card or sky shell is painted at its own depth, and greying it out fogs the horizon twice. A marker has to stay readable through the weather that is the point of the scene.

From a script:

node:setMaterial{ fog = false }

A planet's atmosphere is a separate effect with its own controls, and still applies — a world seen from orbit still hazes.

Upgrading

Nothing to do. Every new setting starts at the value that changes nothing, and project and material files written before this release load exactly as they are.

A crash fix, and a change so that the next one like it doesn't end your session.

Scenes with a UI shader open again

Opening a scene whose UI uses a stage ui shader killed the editor before it drew a frame. If you have a project with a custom meter, gauge or instrument built as a UI shader, this is the one to take.

It had been broken since the release that made the scene render in real light — the shader's world-space pipeline was still built for the window's 8-bit format while the scene it draws into is now HDR — but you would only meet it once v0.50.0 fixed the textured-menu crash that used to happen first.

Nothing to change on your side.

A rejected draw no longer takes the editor with it

When the graphics driver refuses something, the editor now says so in the Console and carries on rendering, instead of ending the session on the spot. The two crashes above both worked that way: one bad draw, and everything unsaved went with it.

The message names what was refused, so it can be reported or acted on. It is said once, not once per frame.

Crash reports also keep the first failure now. A graphics crash rarely arrives alone — it takes the rest of the frame down with it, and the report used to end up describing the last thing to fall over rather than the thing that pushed it. If you sent one that just said "panic in a destructor during cleanup", that is why.

Upgrading

Nothing to do.

A fix for a crash that killed any game with an image in its menu, and a pass over the shader graph so it shows you what your shader is actually doing — starting with textures, which you previously could not see at all.

Games with a textured menu run again

On 0.49.0, a UI element drawing an image from your project crashed the game on the frame that element first appeared. A menu with a logo, a button with a custom face, an inventory slot with an item icon — the first menu frame, and it was gone. If you have a project that worked on 0.41.1 and died on 0.49.0, this is almost certainly why.

Nothing to change on your side. Open the project and the menu draws.

You can see your textures in the shader graph

A texture slot now carries its own image, picked right on the node:

texture ramp = "art/ramp.png"

Before this, a texture slot was a name and nothing else. Every preview downstream of it — the slot's own thumbnail, the sample() that read it, the final colour — showed a grey checkerboard, so the one node whose entire job is to bring a picture in was the one node you could not look at.

The image is not just for the graph. It binds wherever a material leaves the slot empty, so a shader that samples a texture looks right the moment you assign it, with no material setup at all. A material still overrides it per node, and the Inspector now names the shader's image on an empty row instead of saying "none" — so an empty row never implies an empty binding.

Triplanar previews were also wrong on the graph: they came back as noise regardless of what you sampled. They show the texture now.

The graph tells you what each step is

A new ▣ focus panel on the right shows the selected node large: its type, the op's one-line description, where each of its inputs comes from, and — the part that matters when you are learning — how its preview is being drawn. A float is grey from black to white. A vec2 is red and green. An sdf is a distance read-out, blue inside and amber outside. Without that written down, the thumbnails are a puzzle. With nothing selected the panel watches the output, so the finished shader is always one glance away.

Building a graph got faster to do

• Let a wire go over empty canvas and the node palette opens right there, then connects what you pick, in the direction you were dragging.
• Copy and paste between shaders. Ctrl+C / Ctrl+V carries the whole chunk: the steps your selection reads, plus the knobs and texture slots it reads, re-declared in the destination — unless a name already lives there, in which case it binds to yours.
• Ctrl+A selects all, F frames the selection, arrow keys nudge it (hold shift for fine).
• Line up / space out for a selection you placed by hand — ⇅ Arrange re-lays out the whole graph, which is the wrong tool once a graph has a shape you like.
• Hover any input and it tells you what it takes and whether it is required. A coloured dot only says "vec3" to somebody who already knows.
• ? in the toolbar lists every gesture.

Baked lighting is in the Add menu

Baked bounce light shipped in 0.49.0, but the node that carries it was never in ✚ Add — the only way to create one was editing a scene file by hand. Add → ☀ Light Probes, size the box over your space, press Bake.

The Shaders tab stops working when you do

With the graph open, the engine was re-rendering every node's preview every frame, whether or not anything had changed — and a large graph computes every one of its thumbnails for every pixel of that image. Now it redraws when the graph changes, when a texture changes, or when the shader reads time and genuinely has something to animate. A shader sitting still costs nothing.

Upgrading

Nothing to do. Existing shaders parse unchanged, and a texture slot without an image behaves exactly as it did.

This is everything since 0.41.1, in one release: physically-based surfaces, a finished picture with a real tonemap and a colour grade, bounced light you can bake, air you can see through, lights with a size, contact shadows, and motion blur. Plus four things the editor had been missing.

Nothing here is switched on for you. Every effect is off until you turn it on, and a project opened in this build renders what it rendered before — with two exceptions, both spelled out under Upgrading.

Surfaces made of something

Materials have a Physical shading model with roughness and metallic, and four surface maps: normal, roughness, metallic and ambient occlusion. A glTF-style packed map drops straight in — roughness is read from green, metallic from blue, occlusion from red.

The normal map works on geometry that could never carry a tangent attribute: sculpted terrain, primitives, Model-tool meshes, tilemaps and skinned characters all take one. Metal behaves like metal: no diffuse at all, and the highlight takes the base colour rather than staying white.

A picture, finished

The scene is now rendered in real light all the way through and only turned into a picture at the very end, which is what makes everything below possible.

• Tonemap — Clip, Reinhard, ACES or AgX. How light past white lands on a screen, instead of clipping to a flat white shape.
• Colour grade — exposure, contrast, saturation, temperature, tint, lift, gamma, gain.
• Depth of field — focus distance or a node to follow, separate near and far ranges, aperture blades for polygonal bokeh, and highlight bokeh that keeps a glint a bright disc instead of grey mush.
• Lens — chromatic aberration, distortion, sharpen, denoise, film grain.
• Screen shaders — your own full-screen passes, in order, each one getting the finished frame plus its depth and normals. A scanline CRT, an outline pass, a heat haze; crtScanlines.flsl ships as a worked example.

Light that bounces

Add a Light Probes volume and press Bake. Light coming off a red wall lands red on the floor beside it, a corner the sun never reaches stops being flat black, and none of it costs anything at runtime beyond a texture lookup.

Knobs that matter: bounces (1 is "light comes off surfaces once", which is most of the difference), intensity (physically-correct bounce is often a little too polite for a game), and leak for the one artefact everybody recognises — light from the lit room next door glowing faintly through the wall.

Air you can see

Fog is lit by the scene. Turn one slider up and the sun standing behind a bank lights it, a lamp carried into it glows around itself, and a shadow crossing it stays a shadow — which is where beams through a window come from.

• lit by the scene — 0 is exactly the flat fog you had.
• forward scatter — why looking toward the sun blooms and looking away stays dim. A mote of fog has no facing, so this does the job a surface normal does.
• shafts, quality, max distance.

Lights with a size

A light can be a shape: point, sphere, rect, disk or tube. A window, a strip light, a bulb with an actual bulb — and the room knows the difference, because a four-metre window lights a wall evenly where a point at its centre leaves a hot spot in the middle and darkness at both ends.

Rects and disks are one-sided, so a window lights the room and not the wall it is set into. The Scene view draws the emitter at its real size with an arrow out of its emitting face, which is worth one look: a rect light aimed at the wall behind it lights nothing, and there is no way to see that in the finished picture.

Where things touch

Contact shadows — the small dark line under a foot, in a seam, behind a bolt. Until now a moving mesh cast its shadow through its collider, so a character's shadow was a capsule's; this traces what is actually on screen, so anything gets its true silhouette with nothing to tag and nothing to bake.

Off by default. Short reach is the point — a third of a metre is a foot on a floor.

Motion blur

New in this release. On the PostProcess node: a shutter, and how many samples the streak takes. 0.5 is the 180° shutter a film camera has and is the one that reads as footage rather than as a smear.

It blurs camera motion — a pan, a whip, a dolly, a roll — which is most of what a player ever sees blurred, and a pan is the case it does best. Something crossing a locked-off shot stays sharp: object motion needs a different piece of machinery that isn't in this release.

It shows in the Game view. The Scene view is left sharp on purpose — placing a prop while the camera is still coasting is not something you should have to fight.

Edit twenty things at once

Select twelve crates and set roughness once. Whatever you change in the Inspector is handed to the rest of the selection, and only what you changed — each node keeps its own colour, its own texture, its own everything else.

It works across kinds: a light and a camera in one selection exchange the things they have in common and ignore the rest. Two lights share an intensity; two cameras share a lens but never each other's play-authority or render-target name, because those are identities rather than settings.

Script tunables travel too, by script and by parameter name — retune speed once for twenty enemies. Tags travel as the change rather than as a list, so adding one to the selection adds it to all of them without flattening the tags each node already had. And ✚ / ✖ on a component now applies to the whole selection: add a rigid body to twelve nodes, drag one script onto all of them.

Click a bone

Select a rigged mesh and its skeleton is drawn in the Scene view. Click a joint to select it and the transform gizmo poses it straight into the open clip — posing without a round trip through the Hierarchy for every bone.

Only the selected mesh's rig is ever drawn, and the whole thing is under Rig bones in the gizmo menu.

Things stay on ramps

Friction is now a real coefficient. A ramp holds a body while tan(its angle) ≤ friction and lets go above it — 0 is ice, 0.3 lets go at about 17°, 1 holds exactly 45°, and a grippier surface than that goes above 1.

That one sentence replaces three separate wrong behaviours. Nothing used to hold: gravity added a little downhill speed every step and friction only scaled it, so every object on every ramp crept downhill forever and no amount of friction stopped it. A crate touching a floor and two walls was braked six times as hard as the same crate on open ground. And the same number felt different at 60 Hz and 120 Hz.

Friction now opposes motion instead of capping it, so a shoved crate travels and then stops rather than halting in three frames. A hard landing skids where a gentle one sticks. Sliding down a wall you aren't pushing into doesn't slow you.

A rigid body also gets a slope limit (60° by default, which is what this was fixed at before). Past it the body is not grounded, the surface reads as wallNormal rather than groundNormal, and it stops holding the body up — so a character slides off a cliff face however grippy its boots are.

local rb = node:getcomponent("RigidBody")
rb.friction = 0.9        -- holds a 40 degree ramp
rb.slopeLimit = 45       -- but cannot stand on anything steeper than this

Off means off

Shortcuts that stopped working now keep working. Copy, paste, delete, duplicate, F-to-frame and the animator's own keys could all quietly die until you clicked in the right place by accident — the editor was treating any clicked widget as "the user is typing", so everything that yields to a text field also yielded to a button, a checkbox or a dropdown. Only a real text field takes the keyboard now.

A tile floor you painted solid stays solid after you close the project, and switching a node off actually switches it off.

Upgrading

Two things change on their own. Everything else is off until you turn it on.

Physics. Friction means something different, and it is the meaning it should always have had. Anything you built on a ramp is worth a look: a slope steeper than atan(friction) now lets go, where before everything stuck to everything. If a crate needs to sit on a 30° ramp, give it a friction of 0.6 or more. If a character was relying on being braked to a stop in a few frames, drive it every frame or raise its friction — it will now coast.

If a controller sets friction = 1 to plant a character while it stands still, that used to mean "freeze", and it now means "hold up to 45°". Anything steeper and it slides. Raise it — 2 holds about 63°, 3 about 71° — or set a slopeLimit and let the surface decide.

Volumetric fog. A scene already using it arrives lit, with beams on, and it will look different and better. Setting lit by the scene to 0 pins the old look exactly, not approximately.

Everything else — surface maps, the grade, depth of field, baked GI, emitter shapes, contact shadows, motion blur — is off, at a default that changes nothing, until you switch it on.

Tile collision you draw by hand, including slopes. Editing many tiles at once. An autotile picker that tells you which piece you are choosing. And a 2D switch on a rigidbody, so a platformer character is one tick rather than a puzzle.

Slopes

Pick shape under TILE and draw the collider straight onto the tile: click an edge to add a point, drag one to move it, right-click to remove it. The four 45° ramps are one button each.

Points snap to the art's own pixel grid, and that is the part that matters. A slope is built from several tiles whose diagonals have to meet; a ramp ending a third of a pixel above where the next one begins is a character catching on every tile boundary, for a reason nothing on screen shows you. Snapping makes "the corner of that pixel" something you can hit exactly, which is how you were thinking about the sheet anyway.

It collides as the shape you drew — not as the box around it. Concave outlines are fine, so an L-bend keeps its notch. A drawn shape turns and mirrors with its square like every other collider, so one ramp tile serves all four diagonals.

This is the case the tileset deliberately did not have. Offering a slope that behaved as its bounding box would have been worse than offering none, and there was no real shape to give it. There is now.

Edit many tiles at once

Everything under TILE applies to every tile you have selected. Drag a box in the palette, or ctrl-click to pick out tiles that are not next to each other, and set the collision once — the whole sheet's worth of ledges, or the six slope tiles scattered across it.

A selection whose tiles do not currently agree says so, rather than showing you one of them and quietly writing to forty. Tiles being edited get a blue ring and a corner tick; the tile the brush will place keeps the orange one, because those two stop being the same thing the moment you ctrl-click a second tile.

The autotile picker says which piece it wants

Two fixes, and the first is a plain bug.

The neighbourhood diagram was upside down. The little 3×3 picture on each rule — and the sentence under it — had north below the centre. A tile that answers "there is more of this group above me" was drawn and described as below. Picking tiles by what the panel showed built a sheet answering the vertically mirrored neighbourhood of the one you meant, which in a level reads as your art being wrong rather than the table.

And every shape is now named. The armed slot says "waiting for: the top-left corner", not just a diagram you have to translate. bottom edge, left end, vertical middle, inner corner, notch at top-right — the words you already have in your head while drawing the sheet, which is what makes "which of my tiles goes here" a question with an obvious answer.

Switching between a tile and an autotile

There is a brush row at the top of the palette now: Tile, then a chip per autotile group. One click each way, and it shows which one is armed.

Before, arming an autotile was a side effect of clicking a tile that happened to belong to one, and disarming it was a side effect of clicking one that did not — with nothing on screen saying which had just happened.

2D rigidbodies

Tick 2D on a rigidbody and it stays in the XY plane: it keeps the depth you gave it, can never be pushed out of the layer, and still spins the one way a flat object spins. That is all "this is a 2D object" means to a solver, and it is one switch instead of working out that it means freeze pos z, freeze rot x, freeze rot y.

Everything else is unchanged, and that is the point: a 2D body collides with the same world a 3D one does. A tilemap's colliders, a slope you drew, a Collidable cube, terrain — all of it, because there is no separate 2D physics engine to be missing features. Gravity, raycasts, touch events and layers behave exactly as they do in 3D.

It adds to the freeze boxes rather than replacing them, so ticking it can only lock more, and unticking it cannot silently release an axis you locked yourself. From a script: node:getcomponent("RigidBody").two_d = 1.

A level you painted solid now says why it isn't

If a tilemap has solid tiles and the node is not Collidable, pressing Play warns in the console and names it. A level you can see, with tiles you ticked solid, that a character falls straight through looks exactly like a physics bug — and it is a missing switch that nothing pointed at.

Upgrading

Nothing to change. Existing tilesets, collision and autotile groups load and behave as they did.

One thing to look at: if you built an autotile group by following the panel's diagrams, check it. The diagrams were vertically mirrored, so a sheet picked by eye against the art is fine, and one picked by trusting the little dots may have its top and bottom pieces swapped. The panel is right now, and each slot names the piece it wants.

2D light is smooth now, whatever else your scene is set to. Posterize at any band count, dither on or off, retro on or off — the light will not band, and there is no setting you have to find to get that.

Your palette is quantized. Your light isn't.

Posterize quantizes your palette: the set of values your art is allowed to be. A light is not one of those values — it is a multiplier on whatever value your art is. Until now the two were the same setting, because the quantize was the last thing to touch the frame, and by then a lit pixel and a painted pixel were the same number.

That left no configuration that was right:

Every row gave something up. So the quantize moved: it now runs over your art, before any light reaches it. Your tiles land on their bands and your lights ride on top of them. A torch is a soft pool again, an explosion flares and fades, and a dark room gets darker smoothly instead of in five steps.

Nothing to switch on. A scene that has never heard of any of this is correct.

The vignette stopped banding too

The same rule fixes something you may have put up with without filing it. A vignette is a smooth radial darkening, and it was quantized along with the palette for exactly the reason a light was — so it arrived as a set of rings in the corners of the screen rather than a fade.

Everything that is shaped like light now comes after the quantize: the vignette, bloom, and ambient occlusion. Your art still lands on its bands. What was never art stops pretending to be.

Dither is for art

dither the bands is now what it always sounded like: a way to hold a gradient your palette can't — a painted sky, a soft-edged sprite — as a stipple instead of a hard step. It has nothing to do with lighting any more. Turning it on will not change how a light looks.

A warm ramp keeps its hue

PostProcess ▸ step brightness, keep colour still matters, and it has a clearer job now. Quantizing each channel on its own means a warm gradient crosses each channel's band boundary at a different value, so a sunset or a torch-lit wall steps through colours nobody picked — olive where red and green have stepped and blue has not, maroon where only red has.

With it on, the step happens once to brightness and the colour rides along. Per channel is a real look and stays the default; an exactly grey pixel comes out identical either way, so switching it on cannot move art that was already neutral.

Upgrading

Nothing to change, and two things you can now undo.

If you turned on dither to smooth your lighting, turn it back off. It was the least-bad of a bad set of options and it is no longer doing that job — leaving it on will stipple your tiles and nothing else.

If you squashed a light's falloff into one band to stop it ringing, you don't have to any more. The last release recommended setting full out to near the light's range for exactly that reason; that recommendation is withdrawn. It replaced soft rings with one hard disc edge, and the edge was still there with posterize switched off — which is how you know it was a workaround rather than a fix. The controls stay, because shaping a light is a real thing to want. Set them to whatever reads best.

One thing to look at: if your scene uses posterize together with a vignette, bloom, or ambient occlusion, those three are smooth now where they used to step. Your art's palette is unchanged.

2D light stops at walls, comes in the shape you give it, and no longer bands a warm lamp into rings of colours you never picked.

A wall has a dark side

A 2D light is occluded now. Before this, a light in the middle of a room lit the floor, the counter, the shelf, the wall behind the shelf, and the floor on the far side of it, all by the same distance from the lamp. What reached the screen was a disc of brightness with the room drawn on top of it — which is a decal. Light is what you get when something interrupts it.

The control was already there. blocks light, on any 2D node, has been in the Inspector explaining what it would do since 2D lighting shipped. It does it now:

• auto — a tilemap casts exactly where it is solid, from the colliders its tileset already declares. A level's collision is its light occlusion, from one piece of data, so the cover that stops a bullet is the cover that stops the light. The dark wedge behind a block is the safe spot, and a player reads it without being told.
• on — anything casts, including a sprite batch that collides with nothing.
• off — a collidable tilemap stops casting.

Two things it gets right that you would notice if it didn't. A light that skips a sorting layer is not blocked by it — a torch you kept off the background must not have the background throwing shadows into the room. And a wall's lit face stays lit; only what is behind an occluder goes dark.

Nothing is rebuilt when a light moves, which is what makes this usable in a game where every light does — the player's follows them, a muzzle flash is at the gun, a death burst is where something died. The cost follows the lit area, so a pixel outside a light's radius does no work for it, and a scene with no casters pays exactly what it paid before.

For a glow that isn't meant to be a light source, untick casts stop this light on it, or shadows = false from a script.

A light in the shape you want

Two new controls on a 2D light:

• full out to — full brightness out to this radius, and only then falling away to nothing at the light's range. 0, the default, starts the ramp at the light.
• falloff — the exponent of that ramp. 2 is the curve every light has always had.

local torch = find("Torch")
torch:setLighting2D{ inner = 6.4, falloff = 2 }   -- range 8: a clean, hard pool

If you posterize, this is not a nicety. Quantizing a smooth radial ramp to N levels draws N concentric rings, and the only way out is to shape the ramp so the whole of it lands inside one band — which you cannot do while the ramp always spans the full radius.

A warm light stops turning into coloured rings

This one is a plain bug, and it cost a release.

Posterizing quantizes each colour channel on its own. A light's falloff is a ramp, so each channel crosses its band boundary at a different radius — and a mild warm white at {1.0, 0.86, 0.62}, which is the colour of a torch, a lamp, a fire and a muzzle flash, therefore landed as a stack of rings in colours nobody chose: an olive one where red and green had stepped and blue had not, a maroon one where only red had.

Measured across a light's whole radius, that colour produced no clean brightness step at all. Only hue rings. The report it generated was "it just looks like a circle around the player", which is a completely reasonable way to describe three coloured rings and no way at all to find the cause.

PostProcess ▸ step brightness, keep colour (posterizeChroma from a script) steps brightness once and carries the colour along, so a light steps in brightness and keeps its hue. Chroma is never quantized, so the failure cannot happen.

Per channel is a real look and stays the default — but an exactly grey pixel comes out identical either way, so switching this on cannot move art that was already neutral. If your tiles are neutral by rule, as a 1-bit tileset usually is, you can turn it on and only your lights will change.

The global dither the bands switch is not the answer to this. It also dithers the art the posterize was chosen for, and it is screen-space — so on a scrolling camera the pattern is pinned to the display while the world moves under it, and at a low internal resolution that crawls.

Upgrading

One thing to look at, and it is deliberate: if your 2D scene has a collidable tilemap and a 2D light, that tilemap now casts. That is what auto has always said it would do, and it is the whole of the change — but it is a change you will see. Set blocks light to off on any tilemap you would rather kept letting light through.

Everything else is off by default. A light with no shaping is the light you already had, and posterize still steps per channel until you say otherwise.

Escape gives you your cursor back while a game is playing, and this time it stays given.

Your mouse is yours again in Play mode

A first-person game takes the cursor — that's the point of one. Getting it back was the problem: Escape released the pointer for a single frame and the game's next update took it straight back, because a camera script calls setMouseLocked(true) on every frame, which is the correct way to write one.

So there was no way to reach the Inspector, the Hierarchy or the Console while your game ran. The only thing that worked was tabbing out of the whole application at the OS level, moving the mouse to where you wanted it, and clicking back in — and the click gave the cursor straight back to the game anyway. Editing anything mid-play was somewhere between tedious and impossible.

Now the pointer has an owner, and you can say who it is:

• Escape takes it. Your game keeps asking for it, and keeps not getting it.
• Click the Game view to hand it over. Your camera picks up exactly where it was; nothing has to be re-established.
• Leaving the window takes it too, so alt-tabbing away and back lands you on a usable pointer instead of a grabbed one.

The Game view says which of you has it, along the bottom edge. That's the part that was really missing: a grabbed cursor is invisible, so the one thing that tells you how to get it back can't be the cursor.

Your game doesn't fight you for it

While the editor holds the pointer, your game reads a neutral mouse — no motion, no buttons, no wheel, and no action bound to any of them.

Freeing the cursor without that is half a fix. The camera script is still reading raw motion, so the view spins the entire way across to the Inspector, and every click on a slider is also a click in the game. Now you can tune a value in mid-flight and nothing moves but the value.

Its keyboard and gamepad are untouched. It's still playing.

What didn't change

input.setMouseLocked(true) still means what it always did — your game says it whenever it likes, as often as it likes. It's a standing request now rather than an instruction, and the editor is the one holding the answer. In an exported build there is nobody to hold it, so the request is simply the answer, exactly as before.

A game that releases the cursor itself — input.setMouseLocked(false), for its own pause menu — ends any override at the same time. A menu that opens two minutes after you pressed Escape gets its clicks.

Upgrading

Nothing to do.

The number you typed is the number that reaches the screen. An opacity, a font, a brightness — this release is mostly about the engine no longer quietly changing your mind for you, plus three things that were visible in the Scene view and missing everywhere else.

Your sprite's opacity is the one you set

A tilemap or sprite batch at alpha 0.72 was reaching the screen at 0.92. One at 0.5 drew at 0.75. This has been true since v0.38.0, in every 2D project, with no light placed and nothing switched on — the 2D lighting pass was compositing your flat surfaces a second time on top of the ones already drawn, so every authored alpha came out as 1 - (1-a)².

Nothing you could look at disagreed. The value in your script was right, the value in the Inspector was right, and only the screen was wrong — which is worse than a wrong number, because a wrong number gets found.

Opacity is now yours, lit or unlit, at every value.

Check any alpha you tuned by eye since v0.38. If you nudged a value down until a glow looked right, it was fighting this, and it will now read lighter than you left it.

Text in your own font

draw.text had no way to name a font, and an unnamed font meant the engine's built-in one — so a game whose UI is a pixel font could not draw a single immediate-mode string in it. That includes an entire game's dialogue.

The symptom is not what you'd expect. It doesn't read as "wrong typeface"; it reads as bad letter spacing, because a layout built on a monospace grid is being drawn proportionally. Wide letters overlap their neighbours, narrow ones leave holes, and the same word is spaced differently depending on which letters are in it.

Two ways to fix it, and the first is the one to reach for:

Project Settings ▸ UI font — a project-relative .ttf/.otf used wherever nothing names a font: every draw.text, every ui.make label, every element whose style sets none. Say it once instead of at forty call sites.

-- takes the project's font
draw.text(24, 24, "HP " .. hp, 22, 1, 0.4, 0.4)
-- …and one that insists on something else
draw.text(24, 60, "CHAPTER I", 30, 1,1,1, 1, "left", "fonts/Display.otf")

draw.text also measures with the font it draws now, so "center" and "right" land where you asked rather than being aligned against the built-in font's widths.

Pixel fonts stay on their own grid

A pixel font's art is a grid, and it only looks like a pixel font when one of its cells is a whole number of screen pixels. What the engine rasterizes at is your text size times the layer's scale — and that scale belongs to the window, not to you. A 1252-pixel-tall window against a 720-unit design is 1.7389, so a size-24 label rasterizes at 42 pixels: 4.2 pixels per cell, every vertical stem softened by a different fraction. There is no size you could have picked instead.

UI Layer ▸ text snap (or layer.textSnap) rounds every rasterized text size to a whole multiple of the number you give it — set it to the cells in your font's em, usually 10. Off by default; a layer that leaves it off is unchanged.

This is the one that gets misdiagnosed, so it's worth saying plainly: nothing is mispositioned. Your layout can be exact integers and the text will still read as badly spaced, because the distortion is inside each glyph rather than between them. If you go looking in your positioning code you will find it correct.

Generating your own pixel font? Check the em, not just the cell. A font built at 1024 units-per-em with cells of 1024 // 10 has cells of 0.0996 em, and then no pixel size makes a cell whole and this setting cannot save you.

A script can dim the room

The 2D base light — the brightness every flat surface gets before any 2D light reaches it — could be authored once in a scene and never read, animated or restored. So turning it down was a decision with no undo, which is a good reason not to make it.

The scene's Lighting node is now an ordinary component:

local env = find("Lighting"):getcomponent("Light")
local was = { env.ambient2dR, env.ambient2dG, env.ambient2dB }

env.ambient2dR, env.ambient2dG, env.ambient2dB = 0.35, 0.33, 0.42  -- blackout
-- …and back, from what you read, not from a constant you guessed
env.ambient2dR, env.ambient2dG, env.ambient2dB = was[1], was[2], was[3]

That unlocks the three things it was blocking: a quality setting that parks every light can put the room back to white, a brightness slider can exist, and a scene can dim itself for a boss entrance and come back up.

The rest of the node came with it — intensity, colorR/G/B, directionX/Y/Z for a day cycle, the shadow knobs, and the whole fog set for a weather system.

Water, painted shapes and switched-off lights

Three things that were right in the Scene view and wrong everywhere else — the Game view, camera previews, render targets:

• A sea or a pool now draws in the game. Water was gathered only for the Scene view, so an ocean was there while you edited and gone the moment you looked through your own camera.
• A vertex-painted primitive is painted everywhere. A painted cube drew painted on screen and plain in every other view.
• Switching a node off switches its light off. A lamp you disabled in the Hierarchy kept lighting the room — and kept one of the sixteen light slots while doing it.

2D lighting costs nothing until you use it

A flat surface is only prepared for lighting if some live 2D light's layer list actually reaches its sorting layer. A scene with no 2D light placed now does no 2D lighting work at all, and a light restricted to one layer costs nothing for the layers it doesn't name.

That was worth doing because the old answer was everything: one bullet-hell project was preparing 366 sprite batches and about 500 sprites every frame against lights that could reach none of them.

perf.counts().flat2d is that number, so you can check rather than infer. It reads 0 for a scene that hasn't opted in.

Upgrading

Nothing to do.

Two things to look at if they apply to you:

• A translucent tilemap or sprite you tuned by eye since v0.38 will now be as transparent as its number says — which is more transparent than it has been.
• A tilemap or sprite batch that a 2D light reaches is no longer also shaded by the 3D sun; the 2D lights are what light it. If you wanted the 3D lighting, set that node's 2D light mode to 3d.

Two fixes to 2D lighting, both from the same report: a scene with one tileset and one light in it, where the tileset went invisible and blinked in and out as the camera moved.

Placing a light no longer darkens your scene

The base brightness every 2D surface got was full white while your scene had no 2D light in it, and dropped to the scene's 3D ambient the moment you placed one. So your first light took a whole level from fully lit to about 12% brightness in a single step — and the cliff sat exactly where somebody tries the feature for the first time.

That's backwards. Adding a light should only ever add light.

The base is now its own setting: 2D base light, on the Lighting node beside the 3D ambient it was being confused with. It defaults to white, so placing a light can only make things brighter. Turn it down when you want a dark room for a torch to carve a circle out of — which is the thing you'd go looking for anyway when that's what you're building.

Your scenes are unchanged: anything saved before this loads with the base at white.

Tilemaps no longer blink in and out

A lit tilemap could flicker between lit and unlit while the camera moved, in the Scene view especially.

The lighting pass draws your flat surfaces a second time to work out what to light, and then has to agree with the main pass about exactly how far away each one is. The main pass promises its numbers are computed identically every time; the lighting pass didn't make the same promise, so the two could land a hair apart and disagree about which was in front — differently, pixel by pixel, as the camera moved. Both promise it now.

Also

There is no 2D directional light. Only PointLight is on the 2D path — a Lighting node's direction drives 3D shading only. For a flat scene the 2D base light above is what a "sun" would otherwise be, and it has no direction. This was already true; it now says so in the documentation instead of being something you find out.

Upgrading

Nothing to do. If you had turned your scene's 3D ambient down to compensate for 2D lighting darkening things, you can put it back — the two are separate settings now.

Your sky can answer to your game. Shaders can work in angles. And four things that were quietly costing you something now say so out loud.

The sky is part of your game now

A procedural sky is a shader, and the whole point of it being a shader rather than a picture is that it can change. Until now it could only change as a function of time — so a sky that catches fire during a cutscene ran on a timer, and revealed the burning city in the middle of whatever sentence the reader happened to be on.

find("Skybox"):setShaderParam("burn", story.progress)

That's it. The value lands the same frame you write it, with no recompile. Drive weather from the match, a day cycle from your clock, a boss arena's sky from the phase, a lightning flash from a hit.

The post chain too. node:getcomponent("PostProcess") reads and writes bloom, bloomIntensity, bloomThreshold, vignette, vignetteStrength, vignetteRadius, aoStrength, aoRadius, posterizeBands and posterizeDither — so a cutscene can push a vignette or dim the bloom without authoring a second scene.

Shaders can read an angle

atan2(y, x) gives you the angle of a vector over the full circle. It sounds small and it isn't: it's the first thing you reach for in a radial wipe, a cooldown dial, a radar sweep, a swirl, a whirlpool, a skyline laid out around the horizon, or an equirect sample done by hand. None of it was possible before.

let p = uv * 2 - 1
let az = atan2(p.y, p.x) / 6.2831853 + 0.5   // 0..1, once around
output color = vec4(vec3(step(az, fill)), 1.0)

atan, asin, acos, exp2 and log2 came along with it. So did mod(x, y), which wraps at any period where fract only ever wraps at 1 — and wraps correctly for negative numbers, which matters because half the angles atan2 hands back are negative.

Seeing a sky change over its range. A sky whose whole purpose is that it progresses can't be judged from one frame, and the editor shows one value at a time. There's now a contact sheet: point it at a shader and a uniform and it renders the whole range side by side.

cargo run -p floptle-render --example sky_sweep_probe -- <outdir> myshader.flsl burn 8

One thing to know about color uniforms. uniform tint: color = #0B0A16 arrives as the raw hex bytes, and the frame buffer applies its own encoding afterward — so dark colours render lighter than the swatch you picked, by quite a lot. Square the value, or scale it by hand. This is what every colour in Floptle has always done, so a shader's #0B0A16 and a material's agree with each other; it's now written down in the shader docs rather than being something you work out.

Two ceilings that used to be invisible

Sixteen lights reach the screen at once. Past that, the ones that survive are the ones contributing most where the camera is — so the choice holds still between frames instead of shifting as things spawn and despawn, which used to show up as a torch going out for no reason the room explained. A light turned down to nothing no longer takes one of the sixteen, so keeping a handful of lights and parking the spares is a pool that works.

node:setPointLight{ color = {1, 0.8, 0.5}, intensity = 2, range = 8 } makes a light from a script, which you couldn't do at all before — you could only edit one that was already in the scene.

One-shot effects have a limit — 256 live at once. spawnEffect had none, so a per-frame spawn budget cost more than twice as much on a 144 Hz monitor as on a 60 Hz one, and nothing said so. Over the limit the oldest effect goes rather than the newest, because the one you just asked for is the one the player is looking at.

And you can see both. perf.counts() now answers lights, lightsDropped, effects, effectsDropped and voices alongside the rest. The dropped pair is the point: nonzero means the engine is cutting your look, and that should reach you as a number rather than as a screenshot.

Profiling can see particles and audio

perf.ms("particles") returned a confident 0.0 — forever, while collection was switched on. There was no such thing as perf.ms("audio") at all. Both are real now, and perf.buckets() lists audio in frame order, so anything iterating that list picks it up without changing.

Editing while your game runs

Moving a node during Play looked like it worked and vanished when you pressed Stop — not undoable, never marked unsaved, nothing said. A red ▶ PLAY banner now sits across the top of the viewport for the whole session, saying exactly that.

It's still allowed, deliberately: nudging a camera while watching a cutscene run is how you find the framing. To keep what you found, open the … menu on the Inspector's Transform, pick Copy values, press Stop, then Paste values. The component clipboard survives Stop, so it lands as a real edit you can undo and save.

2D lighting and sorting reach scripts

node:setSorting{ layer = "Characters", order = 3 }
torch:setLighting2D{ mode = "2d", layers = { "Terrain", "Characters" } }
crate:setLighting2D{ blocks = "on" }

Sorting layers shipped without any way for a script to touch them, which ruled out a character stepping behind a counter or a picked-up card lifting above the hand. A misspelled mode tells you what the accepted values are instead of quietly meaning auto.

Smaller things

• Big tilemaps cost less every frame. The grid was being copied for scripts twice a frame whether or not any script looked at it — 160 KB a frame for a 200×200 map. It's only copied when the map actually changes now.
• The documentation stopped promising pages you can't read. Thirty-three links across the docs site pointed at working notes that aren't published, so a page would tell you to see a roadmap with no roadmap to see. They all point somewhere real now.

Upgrading

Nothing to do. Every scene, shader and script behaves as it did.

If you have a sky driving itself from time as a workaround, you can stop: set its auto-advance to zero and drive it from your game instead.

2D lights. Put a light in a flat scene and it lights your tiles and sprites, with a real falloff, and only the sorting layers you point it at.

Plus: an autotile shape can hold as many tiles as you like, and one tile can draw as many shapes as you like. Both were impossible before, and both are things you need constantly.

2D lighting

Add a PointLight node to a scene whose active camera is orthographic and it is a 2D light. It lights tilemaps and sprite batches; it does not light meshes. A light belongs to one system or the other, so a 3D prop that wanders into a flat scene is not washed over by your torches.

A surface with no light near it is drawn at the scene's ambient, so a dark room is dark and a torch carves a warm circle out of it.

Nothing is guessed twice

Every node has a 2D light setting in the Inspector: auto, 2d, 3d.

Only auto is decided for you, and it tells you what it decided and why — auto → 2D — the active camera is orthographic. Set it to 2d or 3d and that is never revisited, whatever else changes about the scene. A light you deliberately made 3D will not quietly become 2D because somebody added an orthographic camera later.

The rule is one fact per side, so it fits in your head: a light is 2D when the active camera is orthographic; a tilemap and a sprite batch are 2D, a mesh is not. Mixing the two is something you ask for, never something you discover.

Which layers a light reaches

A 2D light lists the sorting layers it lights. A new light reaches all of them; untick one to keep it out.

That is the one thing every 2D game wants and nothing else here did: a torch passing over a background without lighting it, so the background stays flat while the foreground moves through the light.

This is not the collision layer mask. A background that collides with nothing and a player that does sort — and light — independently of that.

What a light costs

The lighting is computed once per screen pixel rather than once per surface, so stacking parallax layers does not multiply the work. A light stops exactly at its range instead of trailing off across the whole frame.

Sixteen lights reach the screen at once. Past that, the ones that survive are the ones contributing most where the camera is — so the choice holds still between frames rather than changing as things spawn and despawn, which would show up as a torch going out for no reason the room explains. A light turned down to nothing doesn't take one of the sixteen, so keeping a handful of lights and parking the spare ones is a pool that works.

Not in this one

Normal maps, shadows and height. A tilemap already has a blocks light setting and already says what it will do — on auto, a tilemap will cast from the collision it already declares, so your level's collision is its light occlusion — but nothing casts yet.

Scripts can't reach any of it yet, the same gap sorting layers have. Both close together.

Autotiling: duplicates, in both directions

One tile can draw as many shapes as you like. A plain fill square is usually the answer to several neighbourhoods, and a sheet with a single hand-drawn inside corner wants that one tile in four shapes. Click the shape, click the tile, as many times as you need.

Before this, assigning a tile to a second shape silently moved it, and the first shape went blank. Reported as exactly that: "if I've already assigned it to another rule it removes the previous one."

One shape can hold as many tiles as you like. They are variants — four grass squares that all mean "surrounded" — and which one a square gets is decided by where that square is. So a field varies, and it varies the same way every time you open the level, on every machine. Listing the same tile twice makes it twice as likely, which is how you get a rare flower without drawing nine plain squares.

A shape holding alternates is marked ×N in the RULES grid. Arm it and its tiles appear underneath; click one to take it back off.

The next shape after the first tile checkbox is what makes both work. It moves on only when a shape goes from empty to having something, so your second click stays on the shape you are looking at. Turn it off to stay put entirely.

Assign preset understands variants too: select a whole multiple of the preset's length — 32 tiles for the 16-shape preset — and it reads them as pass after pass, giving every shape two.

Selecting a tile now lists every shape it draws, each one clickable. That replaces the old single-neighbourhood editor, which could only move a tile from one shape to another — the control that made duplicates impossible in the first place.

Upgrading

Nothing to do. Tilesets written before this convert when you open them and keep drawing exactly what they drew; they are saved in the new shape from then on.

A scene that has never touched 2D lighting is unchanged in every particular — including its file, which gains nothing until you use the feature.

A scene in a folder saves back to the file it was opened from. Until now it didn't, and the edits went somewhere nothing loads.

If you keep scenes in folders, read the next paragraph — you may have work sitting in a file you have never opened.

The bug

Open scenes/cutscenes/Opening.ron, change something, press Ctrl+S. The editor wrote scenes/Opening.ron — a different file, at the top of your scenes folder. Reopen the project and the original loads, unchanged, so every edit looked like it had been undone.

Nothing warned, because from the engine's point of view nothing failed. The save refuses to run during Play, it logs failures loudly, it only clears the unsaved marker when the write succeeds — and the write did succeed. It said saved and it meant it. It just meant a file the game never reads.

Reported as: "I save it, close the project, reopen, and the lava is too high again and my movement of the map is back to how it was before." Both edits were in the stray file, intact.

Only the folder was lost — the editor kept the file's name and rebuilt the path from that, so a scene sitting directly in scenes/ was never affected. Scenes in scenes/maps/, scenes/cutscenes/, scenes/rooms/ and the like all were.

Your work is probably still there

Nothing was deleted. Every edit went into a real file; it was just the wrong one. If you have been editing a scene in a folder, look for a file of the same name directly inside scenes/ — that one holds the work you thought you were losing, and it is almost certainly the newer of the two.

Floptle now tells you. Opening a project names any scene that has a stray copy like this, in the Console and as a notification. It does not move anything: there are two files, both plausibly the one you want, and an editor quietly choosing between them is how this happened in the first place. Compare them and keep the one you mean.

What changed

Scenes save to the path they were opened from, at any depth, and the folder is created if it does not exist yet. A scene's name is unchanged everywhere it is shown — the hierarchy header, the window title, and scene.current() in a script all still say Opening, not cutscenes/Opening — so a game reading that name keeps working exactly as it did.

Upgrading

Nothing to do, and nothing changes about a project whose scenes all sit directly in scenes/. If yours don't, check for stray copies once — Floptle will point at them when you open the project.

A 2D level draws in the Game view. A tileset carries its own art instead of borrowing a Material's, and holds as many sheets as you drop on it. Setting up an autotile is clicking a shape and then the tile that draws it. And what draws in front of what is a named layer rather than a Z you nudge by hand.

Nothing to do on upgrade.

Your 2D game is visible in the Game view

A tilemap drew in the Scene view and the Game view showed an empty background. Nothing was reported and nothing was wrong with the tilemap.

The editor works out what to draw twice — once for the Scene view, and once for every other view: the docked or split Game view, camera previews, render targets. The second one had never learned about tilemaps or sprite batches. So a 2D game was invisible in the one view that is the game, and the Scene view insisted the level was fine.

It has been that way since the 2D layer arrived, and the same thing happened to blockout geometry before it. The list of things that second path knows about is now exhaustive: a new kind of object cannot quietly fall out of it, and a test catches the other half — something drawn on one path and not the other.

If you read v0.36.0's note about an orthographic camera clipping at its own depth: that was a real bug and a different one. This is what was biting.

A tileset carries its own art

A tileset described a spritesheet it did not draw. The picture came from the tilemap node's Material, so every tilemap needed a Material repeating the same image and the same grid, kept in agreement by hand — and a tileset on its own rendered nothing at all. There was even a warning for the two disagreeing, which was a warning about bookkeeping the engine was imposing on you.

Now the tileset is the authority. Point it at an image and it draws. A tileset that names no image still falls back to the node's Material, so nothing you have already built changes.

Sheet 0 sits in the SHEETS list with the others and can be set there, which it never could — that is the whole reason a tileset could not carry art.

Drop images in. Drag one from the asset browser onto a sheet row, or onto the panel. The grid is worked out for you: from the filename if it names a cell size (tiles_16x16.png, dungeon-32.png), and from the image's pixel size otherwise. Each row shows its cell size in pixels and says so when the grid does not divide the image evenly — which is the seam bug, before it is a seam.

Fixed with it: nothing ever uploaded a tileset's sheet to the graphics card. Only Material textures were, so a tileset's image arrived only if some material happened to name the same file. The extra sheets added in v0.36.0 have never worked on their own.

Setting up an autotile

An autotile is a set of tiles that pick themselves by what is next to them — draw a wall, it grows its own corners. The engine has had them for two releases and the instructions described the idea rather than what to click.

Underneath, the only way to teach a group its rules was to select every tile in the palette, in the preset's own order, and press one button. That is right for a sheet drawn in that order and useless otherwise, and a preset can want up to forty-seven rules. Nothing showed which tile had been given which shape, and one wrong tile meant doing all of them again.

A group now shows its rules as slots — one per neighbourhood, each drawing the shape it matches over the tile currently assigned to it. Click a slot, click a tile: that rule is set, and the next empty slot arms itself. Filling a preset is one run of alternating clicks, every rule is visible as art rather than a count, and stopping halfway leaves something that works for the parts you did.

Painting is just painting. Click any tile of a group and you are painting the group; it retiles as you draw. Click a tile that is not in a group and you are back to ordinary painting. That used to depend on a checkbox elsewhere in the panel — and with it unticked, selecting an autotile silently placed one fixed corner piece everywhere, which is most of what "autotiling doesn't work" looks like.

The bulk assign-a-whole-preset button stays. It was never the wrong tool, only the only one.

Sorting layers

What draws on top of what, in a flat scene, was depth: the floor at 0.001, the player at 0.002, a prop at 0.003. Wanting something between two of them meant editing every number above it, and none of the numbers said what they meant.

Name them instead. Project Settings ▸ Layers ▸ Sorting layers, back to front, and each node picks one in the Inspector with an order inside it.

• Layers are referenced by name, so reordering the project's list can never silently re-sort a scene.
• order cannot climb out of its layer — set it to a million and it still draws behind the next layer up.
• Nothing moves. It offsets what is drawn, not the node: the collider stays where you put it and a script reads the position it set.
• A node that has not opted in is on Default at order 0, which is exactly the depth it always had. Scenes that do not use this are unchanged.
• A layer you delete leaves nodes that named it drawing in front rather than vanishing behind the background — visibly wrong beats mysteriously missing.

Not in this one

Scripts cannot read or set a sorting layer. It is authoring-side for now, so Y-sorting characters as they walk is still done by moving Z. That works and composes with all of the above; it is just not the nice version.

2D lighting. Nothing yet lets a light be a 2D light. Being designed now.

Sub-emitters and particle collision. Still the two real gaps in what a particle effect can be, and still next.

Upgrading

Nothing to do. Existing scenes, tilesets and images open unchanged. A tilemap that has been getting its sheet from its Material keeps doing so until you give its tileset one.

Animated characters stop flickering. A 2D level built the obvious way now draws in the Game view instead of nothing. A tile layer can be cut from more than one image. Per-tile collision and autotiling stop hiding. The image editor's brush shows the pixels it is about to change, and a tileset's grid can be drawn over the art while you draw it. And a particle effect will tell you what it costs and how many particles it is actually making, instead of only what you typed into it.

Nothing to do on upgrade.

Animated characters stop flickering

v0.35.0 moved skinning onto the graphics card. It also, without saying so, left one of the passes reading the pose from one frame ago.

The depth pass runs first and works out what is in front of what. For a character it was posing the skeleton from the previous frame — so it decided the shape of a character standing where they had just been, and then the pass that actually draws them put them where they now are. Triangles lost that argument one at a time, differently every frame. A character standing still looked perfect, because last frame's pose and this frame's pose were the same one; a character in motion broke up.

It reached further than the characters. That same depth is what the scene's raymarched geometry uses to know when to stop marching, so a corrupted one made the floor and walls behind a moving fighter flash as well.

Every pass now takes its pose from the frame it is drawing, and there is only one way in for them to do it — a pass added later gets this right without anyone remembering to make it.

Your 2D scene draws in the Game view

An orthographic camera sitting in the plane of your art — a camera at zero, a tilemap at zero, which is the obvious way to set up a flat game — showed the map in the Scene view and an empty background in the Game view. Nothing was reported; the node was visible, the material was right, and the two views of the same world disagreed.

The camera was throwing away everything at its own depth. It is fixed, and the Scene view and the Game view now derive that depth from the same place, so they cannot disagree about what is in a scene again. It affected every flat setup, not just tilemaps: sprites, batches and diegetic UI on the camera's own plane were all being clipped.

A camera with perspective is unchanged.

One tile layer, several sheets

A tile layer took its art from one image. Building a level out of a ground sheet, a props sheet and a decoration sheet meant three separate tilemaps — and that is not a workaround, it changes what the level is. A wall on one tilemap is not a neighbour of a wall on another, so nothing autotiles across the join. The collision merge stops at it and leaves exactly the seam it exists to prevent. Bucket fill, rectangle, stamp and retile all stop there too.

A tileset can now hold several sheets. ◫ Tiles ▸ TILESET ▸ SHEETS ▸ + sheet adds one; give it an image and its cols/rows, and the palette grows a tab per sheet. Everything you place from any tab lands on the same layer, so autotiling, collision merging and every tool work across the whole map.

Adding art never renumbers what you already placed. Grow your first sheet from 4×4 to 16×16 and every square placed from a later sheet still means exactly the tile it meant. A project that never adds a second sheet is unchanged in every particular.

Per-tile collision and autotiling were always there

Both of them. Collision per tile — none, the whole square, a half that rotates with the tile, or a hand-set rectangle — and autotiling with presets that draw their own corners and edges. Both were built, both were reachable, and both were invisible: the sections that need a tileset returned before drawing so much as their own heading, so a tile layer without one showed a panel with no TILE and no AUTOTILE in it at all. That is indistinguishable from an engine that has neither, and it was reported as exactly that, twice.

Both sections are always there now. When they can't act they say what they would do and offer the one button that gets you there. A tilemap with no tileset says so in the Inspector, naming both features. The collision overlay says when it has nothing to draw, rather than drawing nothing — which read as "nothing here is solid".

Fixed alongside: selecting a tile layer with no tileset left the tile and autotile editors pointed at the previous layer's tileset, so an edit could land on a tileset the layer does not use.

The brush shows the pixels it is going to change

The cursor drew a circle of the brush radius, whatever the brush was. Paint pixel art with a one-pixel pencil and you got a small circle floating between texels, while a single square texel landed — a different shape, in a different place, at a different size.

The outline is now the brush's own footprint: the texels that will actually change, on the pixel grid. A soft brush shows two contours — where it is, and how far it reaches — so soft reads as soft and a hard brush isn't given a halo it hasn't got. Very large brushes and very low zooms fall back to a plain circle, where the exact texels tell you nothing anyway.

Draw a tileset against its own grid

Laying out a 16×16 tileset meant counting texels by hand to find where tile 3 starts, and finding out you were one off when the map drew seams.

View ▸ This image is a sheet draws the cell grid over the canvas and saves it with the image — close the file, reopen it, the grid is still there, because how the art is cut is a fact about the art. Set it as cols × rows, or click a cell size (8, 16, 24, 32, 48, 64) and the counts follow. A grid that doesn't divide the canvas evenly draws nothing and says so; a 10.6-pixel cell is a mistake to draw against, not a number to round.

The overlays are yours to set

Whether an overlay is visible depends on art nobody can predict, and every one of them was a fixed colour: a grey checker under grey art says nothing, and the pixel grid was 11% white — visible in a screenshot, invisible over real work at exactly the zoom you need it.

There is a View menu now (the checker and grid didn't have one at all; they were on, always, and unreachable). The checker's two colours and square size, the pixel grid's colour, opacity and the zoom it starts at, and the cell grid's colour are all settable, with Reset overlays to defaults to undo the lot. The pixel grid is two-tone by default — dark dashes over a light line — so one of the two shows against art of any colour without being configured for it.

Moving a bit of art

The transform was already good; getting to it cost more actions than the edit.

• Drag inside a selection to move it. No tool change first.
• Ctrl+J duplicates the selection in place and floats the copy, ready to drag. It doesn't touch the clipboard, so stamping the same piece repeatedly no longer means re-copying it every time.
• A transform in flight gets numbers: output size in pixels as well as a scale factor, 1:1 / 2× / half, degrees, offset. "Make this 16×16 exactly 32×32" is a typed number, not a drag you squint at.
• The status bar names the selection's origin and size, instead of only saying there is one.

Still one undo, and Cancel is still exact.

A particle effect says what it does

Every part of the Particles tab showed what you authored and none showed the result, which is most of why it was hard to tell what a change would do.

A curve says where zero is. The zero line used to appear only once a curve had already gone negative — the landmark arriving after the mistake. Zero is now drawn and labelled whenever the curve is anywhere near it, and when it is genuinely off-screen the edge says which way. A lane that multiplies marks ×1 instead, because that is its no-change value and it sits a quarter of the way up its strip with nothing else to say so.

The graphs stop moving under you. The value axis re-fitted itself every time you let go, so the same curve was drawn at a different scale after each edit and a key you dragged upward sprang back toward the middle. It fits once, then only grows — a key can never be edited off the graph — and re-fitting is a button. Both graphs label their top and bottom.

The tab tells you what the effect costs. Peak particles alive sits in the transport bar, and the timeline draws the alive count over time under its own ruler, so a change to a rate or a lane reads as a change to the effect and not only to a curve. These are measured by running the effect, not estimated.

A full pool no longer fails quietly. Raising a rate past what a track can hold used to give you fewer particles than you asked for with nothing said. Going over is now visible the moment it happens, and it names the track, how many births it lost and what its limit is.

Curves get shapes in one click — linear, ease in, ease out, both, hold — applied so the values you authored are untouched. A curve's shape can also be copied onto another property and lands at that property's magnitude, because a size ramp and a speed ramp are often the same shape at very different scales.

Not in this one

Sub-emitters and particle collision. Nothing lets a particle spawn anything — no effect on birth, on death, or along its path — so fireworks, a rocket that leaves puffs, and an explosion whose chunks trail sparks are all still out of reach. And particles pass through the world: sparks don't bounce, rain doesn't splash, debris doesn't land. These are the two real gaps left in what a particle effect can be, as opposed to what it can tell you, and both are big enough to deserve doing properly rather than halfway. They are next.

Telling the engine your sheet's grid. An image that knows it's a 16×16 sheet still can't hand those numbers to a material and a tileset, so the three can drift apart. The tile tools still warn when they do.

A smaller exported game. A build still carries the whole editor inside it. It works, it costs about 24 MB per game, and it keeps losing to things you can feel.

Upgrading

Nothing to do. Existing scenes, tilesets and images open unchanged, and images saved by this version still open in the previous one until you give one a cell grid.

Animated characters stopped costing what they used to. A mid-detail character used to spend a slice of every frame being reshaped by the processor; now that happens on the graphics card, and fifty of the same character draw in one go instead of fifty. Prefabs can be opened and edited on their own. And when a Lua script is too big to load, the engine says so in words you can act on, instead of pointing at a line you never touched.

Nothing to do on upgrade. Your existing rigged models get the new path the next time you open the project — no re-import, no setting.

Fifty characters, not five

Every skinned model — anything with a skeleton, weights and a walk cycle — was being reshaped a vertex at a time on the processor, every frame, and the result uploaded to the graphics card. That work scaled with how detailed your character was and how many of them were on screen, and it was the reason a crowd got expensive long before the graphics card was doing anything hard.

A character of average detail cost about a third of a millisecond of processor time per frame. Fifty of them ate a third of a 60 fps frame before a single pixel was drawn.

The reshaping now happens on the graphics card, which is what graphics cards are for. The same character costs the processor roughly a thousandth of what it did.

The second half is quieter and matters just as much: identical characters share their geometry again. They could not before — two copies of one model would have overwritten each other's pose, so each one needed its own private copy of the mesh. Twenty guards of the same model were twenty separate draws; they are now one. That is the difference between a crowd being a thing you budget for and a crowd being a thing you have.

Everything you already do with characters is unchanged: attaching a weapon to a hand still works, animation events still fire, painting on a skinned mesh still sticks. Selection outlines still hug the pose rather than the T-stance.

Two cases still take the old route, and both look identical on screen — a model whose custom shader material owns the drawing, and a scene with an implausible number of distinct skinned meshes in it (past roughly eight million skinned vertices, at which point the engine says so rather than deforming something wrongly).

Double-click a prefab to edit it

A prefab is a reusable piece — a turret, a door, a crate — so the natural thing to do is open one and work on it by itself. Until now you could not. Double-clicking a prefab did nothing, and changing one meant dragging it into whatever scene happened to be open, editing that copy, and using Save as Prefab — which never overwrites. The obvious route left you with Turret 2.prefab.ron sitting beside the file you meant to change.

Double-click a prefab now and it opens on its own. The whole editor is there — Hierarchy, Inspector, gizmos, undo, and Play, so you can test a turret without a level around it. Save writes back to that prefab file, in place. Open any scene from the Assets panel to go back to editing a scene.

The Hierarchy header tells you which you are on: ◇ Turret (prefab) in amber, or ⎙ level as before. They save to different places, so they do not look the same. The unsaved-changes prompt guards the switch in both directions, and crash recovery works on a prefab the way it works on a scene.

A prefab is nodes and nothing else, which is worth knowing before you go looking: terrain and blockout map geometry live beside a scene file, so a prefab holding a Map Mesh node shows you the node and not its geometry.

A script that will not load says why

Lua has a hard ceiling: any one function may refer to at most 60 file-level variables. A big controller script reaches it on a completely ordinary edit — one more local at the top of the file that a long function happens to mention — and when it does, the whole script fails to load. Nothing in it runs, and every other script that asked for it silently gets nothing.

The message you got was:

vessel_controller.lua:3669: function at line 2864 has more than 60 upvalues

Line 3669 is not a line you edited. Line 2864 is where the offending function ends, not where the problem is. Nothing tells you a limit exists, or that "upvalue" means "a variable declared at the top of the file".

Now the Console says:

vessel_controller.lua did not load: the function ending at line 2864 closes over more than 60 upvalues, which is Lua's hard limit. Every file-scope local is an upvalue of every function below it, so the fix is to hold related state in ONE table (local s = { … } read as s.foo) or to split the function — not to move the line the error names, which is only where that function ends.

Three more things changed around it:

You get told before you hit the wall. A script that declares 50 or more file-level locals says so when it loads, with how many it has left: nearly.lua declares 55 file-scope locals and Lua allows 60 upvalues per function — 5 to go before the script stops loading at all. The count was previously invisible unless you had the file open in the editor with the linter running; now it reaches you in a build too.

A broken script no longer looks like a missing function. Reading anything off a script that failed to load used to give you exactly what asking for a function it doesn't have gives you: nothing. Two completely different bugs, one symptom. The Console now names the difference, once, for each thing you tried to read.

The failure is reported once, not sixty times a second. A script that fails to load fails on every frame, and the Console used to say so on every frame. It now says it once per version of the file, and repeats it the moment you save a new one. The Scripting tab still lists it for as long as it's broken.

Not in this one

Slimming down what an exported game ships. A build still carries the whole editor inside it — the map tools, the image editor, the shader graph, all of it. It works, and it costs about 24 MB per game plus some startup time, which is why it keeps losing to things you can feel. It stays on the list.

Upgrading

Nothing to do.

A release for building 2D levels. There is a tile editor now: paint a level with a brush, tell a tile once that it is solid and every one of them collides, and let a set of tiles pick their own corners. Plus the orthographic camera 2D has been missing.

Nothing to do on upgrade.

Paint a level instead of writing one

Press 9 and paint in the Scene view. The new ◫ Tiles tab has the tools you would expect and they work the way you expect:

Drag a block of tiles in the palette and the brush becomes that whole block — a doorway, a tree, a whole cliff face. Select a region of the map, Copy, then Paste and the clipboard becomes the brush, so the next click puts it exactly where you aimed rather than somewhere you then have to undo.

↻ ⇔ ⇕ turn the selection when you have one and the brush when you don't. Turning a multi-tile block turns the block and every tile in it, so a rotated pipe corner still points along the pipe.

Ctrl-Z is the ordinary Ctrl-Z. A tile layer is an ordinary node, so hiding, renaming, moving, parenting and deleting one are the things you already know — and the Hierarchy and the Tiles tab can't disagree about whether a layer is showing, because there is only one switch.

Tell a tile it is solid, once

A tileset says what each cell of your spritesheet is — whether it collides, what it is tagged, how it animates — and it belongs to the sheet, not to the map. Press New tileset, tick "full" on the brick, and every brick in every scene collides, including the ones you already placed.

Collision is none, the whole square, a half, or a rect you drag out. The half is named in the tile's own art, so it turns with the tile: the bottom half of a tile rotated a quarter-turn is its left half. Select a run of tiles in the palette and press All solid to do a whole sheet in a minute.

The colliders are merged. A 100×100 solid floor is one box, not ten thousand. That is not tidiness — a character sliding along a row of separate boxes catches on the seams between them, which is the classic 2D platformer bug, and one merged box has no interior seams to catch on. Tick Collision in the tab to draw them over your map; they are the same boxes the physics gets.

Tiles can carry tags too — "ice", "ladder", "damage" — and your game reads them straight off the map:

local x, y = tm:cellAt(node.worldPos)
if x and tm:hasTag(x, y + 1, 'ice') then slippery = true end

Let the tiles pick their own corners

Add an autotile group, drag out its tiles in the palette, press Assign preset, and painting draws its own edges, corners and ends. Two kinds: Edges (16 tiles, for a path or a wall run) and Blob (47, for terrain with inside corners as well as outside ones).

Every tool orders these sheets differently, and a preset that guesses your artist's order wrong tiles your level plausibly wrong — right shapes, wrong corners, reads as bad art. So each tile's neighbourhood is drawn right on the palette as a little 3×3 diagram: if a preset guessed wrong you can see exactly which tiles disagree, and clicking the diagram fixes one.

Put two groups in each other's joins and grass and dirt meet without either growing an edge against the other.

Two rules worth knowing, because both are very visible when a tool gets them wrong: the edge of the map counts as filled, so a shape painted to the border does not grow a coastline against nothing; and a group with tiles still undrawn leaves those squares exactly as you painted them rather than erasing them. The tab says "12 of 47 drawn" so a half-finished group is something you can see.

Tiles that face a direction, and tiles that move

Every square now carries its own orientation — four rotations, each optionally mirrored — so one arrow tile is four arrows and one corner tile is a whole room. It rides inside the tile value, so nothing about your existing maps changes.

tm:set(4, 2, 7, { rot = 90 })
tm:set(5, 2, 7, { flipX = true })
local cell, rot, flipX = tm:at(4, 2)

Give a tile a few extra frames and a rate and every square using it animates together — torches, water, conveyors. It runs while you are editing, not only in Play, so you can watch a torch flicker while you place torches. The frame is never written into your map, so saving doesn't freeze whichever moment you hit Ctrl-S on.

An orthographic camera

Set a camera's projection to orthographic and it draws everything at the same scale at every distance. Under perspective a parallax layer two units further back is drawn slightly smaller, so it changes size as well as speed and two layers cannot be lined up; this is the fix, and it is also what a strategy or isometric camera wants.

find('Cam'):setCamera{ projection = 'orthographic', orthoHeight = 12 }

orthoHeight is how many world units the shot covers top to bottom — with 1-unit tiles, how many tiles tall it is. Render targets have it too, which is very often what a minimap actually wanted.

The editor's Scene view has it as well (⌖ Scene ⏵ ▦ View ⏵ Orthographic), and picking a plane lock turns it on with you. There the wheel zooms the view height instead of moving the camera — it has to, because moving forward changes nothing you can see. A camera gizmo draws a box rather than a cone for an orthographic camera, because the frame really is the same rectangle at every distance.

Your game can ask the map about itself

The tilemap handle grew the things every 2D game was writing by hand:

local x, y = tm:cellAt(player.worldPos)   -- which square is it standing on?
local p    = tm:worldAt(x, y)             -- that square's centre, in the world
tm:fillRect(0, 20, 39, 21, 3)             -- a floor
tm:resize{ rows = 30, offsetY = 8 }       -- grow eight rows on TOP
tm:autotile(0, 0, 39, 29)                 -- fix the corners after a run of edits

cellAt goes through the map's own transform, so a level that has been moved, turned or scaled still answers correctly — which is the part that quietly broke when a hand-written version met a map that moved. Also tm:at, tm:tileSize, tm:solid, tm:tags, tm:hasTag and tm:tileset.

A typo in an orientation is refused where you wrote it: { flipx = true } says so and suggests flipX, rather than placing the tile unturned and leaving you to find it.

What isn't in this

Written down so you don't go looking. Edits to a tileset (collision, tags, groups) are saved to their own file and are not on the undo stack — the map's tiles are. There is no chunked or infinite grid: a very large world is several tilemap nodes. No slope collision, no one-way platforms, and no .tmx / .ldtk import yet.

Two engine tasks that were scheduled alongside this — GPU skinning, and exported games running on the small runtime instead of the editor — are not in this release. Both are substantial and neither was worth half-doing.

Upgrading

Nothing to do. Your existing tilemaps load and draw exactly as before; the new per-tile orientation is off on every square that predates it.

docs/tilemaps.md is the whole suite, start to finish.

A release about the engine telling you things. Options that refuse a typo instead of quietly ignoring it, a camera you can point at a texture, four accessibility settings a game can offer its players, and a physics step that stops asking every collider about every body.

Nothing to do on upgrade — except read the one breaking change below, which is short.

A camera can be a texture

Point a camera at a name, and wear its picture anywhere a texture goes:

find('MapEye'):setCamera{ target = 'minimap', width = 256, height = 256, hz = 10 }
find('MinimapPanel'):setMaterial{ texture = 'rt:minimap', unlit = true }

That is the whole mechanism, and it unlocks the four things people ask for — minimaps, mirrors, security monitors, scopes — plus split-screen, which is two targets shown as two UI images side by side.

The two numbers matter more than they look. A render target is a whole extra render of your scene, so a 256×256 minimap at 10 Hz costs about a sixth of what the same minimap cost at 480×270 every frame. A cockpit screen the player glances at does not need 60 either.

It works while you place the screen in the editor, in Play, and in a build. Eight live targets per scene; a ninth says so in the Console rather than vanishing, and so does a second camera claiming a name another one already has.

docs/render-targets.md has all five recipes.

Accessibility your game can actually offer

Four settings, one Lua table:

access.setTextScale(1.5)                      -- 0.5 – 3.0
access.setColorFilter('deuteranopia', 0.9)    -- protanopia / deuteranopia / tritanopia
access.setReducedMotion(true)
access.setCaptions(true)
caption("a door unlocks somewhere below")

Text scale reflows. It is applied before layout runs, so a box that sizes itself to its text grows and everything below it moves down — rather than painting bigger glyphs into the same rectangle and clipping at exactly the sizes somebody turned the setting up to reach.

The colour filter corrects, it does not just simulate. Red and green that arrive as one olive come back as pink and green. There is also a simulate switch in the editor, for you: tick it to see your game the way a colourblind player does and find the red-on-green prompt yourself.

Reduced motion snaps the engine's own UI transitions instead of hurrying them, because a 40 ms slide is still a slide. Your camera shake has to read access.reducedMotion() — the engine has no shake of its own and cannot tell which of your movement is the game.

Captions are drawn by the engine, bottom-centre, at the player's text scale, and caption(...) does nothing while captions are off — so you write it beside the sound with no if around it.

⚙ Settings → ♿ Accessibility drives all of it, so you can try your game with each one on without writing a line. These are the player's settings, so persist them in the player's save. docs/accessibility.md covers what only your game can do.

Physics that stays fast as the level grows

Collision used to test every body against every collider, twice a tick. Fine for a room; quadratic for a level. Measured over 120 steps:

The gap widening as the scene grows is the point. Nothing to configure and nothing to opt into, and your scene simulates identically — the same collision test runs, on the same colliders, in the same order.

The engine refuses typos now — this is the breaking change

An options table used to ignore a key it did not recognise. So this looked fine and did nothing:

scatter.create{ asset = "trees/pine.glb", perchunk = 6 }

Every options table is closed now. That call is an error naming the key and suggesting perChunk, and every message says three things: the property, the value it got, and what it accepts.

audio.play: `mode = "spacial"` is not a name I know — it takes spatial, 3d,
distance, flat, 2d

Why this is worth breaking. 43% of every bug ever reported against this engine was the same shape — the engine answered something it did not understand instead of refusing it. A collide = true on scattered props that was read by nothing, for two releases, so a game asked for solid props and got props you walk through. A pin = "topCenter" that silently meant top-left. And scene.load(name, { addative = true }), which destroyed the running scene instead of layering onto it, because a misspelling reads as additive = false.

Four more of those are fixed by the same pass: node:setPrimitive("Sphre") made a cube; a misspelled mode in audio.play left a positional sound playing flat at full volume everywhere; a misspelled header in http.get sent the request without it, so the server said 401 and the game reported "the API is down".

What you should do: press Play. A typo you have been carrying now says so on the line that has it, once, immediately. (Checked against every shipped script and both in-house games — none of them passed a key that is now refused, so most projects will see nothing at all.)

A script can export a function called name

materials.name("iron") returning "Iron Ore" is the obvious thing to write, and it was the one thing you could not: the handle answered name itself, so the script could call it and nobody else could, and every other script died at the call with attempt to call field 'name' (a string value). It broke four screens in one game, each at the first moment it had something to show.

Your name wins now. Three names still belong to the handle — node, kind and valid — and exporting one of them is reported when the script loads and underlined in the editor on the line that does it, instead of surfacing later in somebody else's file. Ask kind when you want to know which script a handle is.

Smaller things

Tab reaches your game. The editor was answering it for panel focus, so input.pressed("tab") had been false for the whole life of every project. Only F1, F2 and F3 are still the editor's, and polling one of those now writes a Console line and flags the line that wrote it, instead of reading false forever.

-1 clears a tile. tm:set(x, y, -1) empties a square, as it does in Tiled, Godot and LDtk — and so do nil and the EMPTY_TILE the editor's autocomplete had been offering all along. A cell that is not a whole number in range is now an error naming what it got, never a neighbouring tile.

Nothing behind you is drawn. Meshes, imported models, sprites, tilemaps and scattered props are all skipped when they are outside the view, which they never were before — only terrain was. A skinned character's bounds grow with its pose, so nothing pops out at the edge of the screen mid-animation.

Your game can see its own frame cost. perf.* reports where a frame went, per subsystem and per script, with the worst recent frame alongside the average — so a project can assert its own budget in its own test rather than filing "the engine is slow". ⏱ in the play toolbar shows the same numbers. Off by default and free while off; reading a time while it is off is an error, not a zero, because a budget check that passes on no data is worse than no check.

Upgrading

Nothing to do. Open your project and press Play; if you have been carrying a misspelled option, it will tell you where.

Two fixes for worlds that move: the ground you are standing on now loads before anything else, and a field of props stays on the planet it grows on.

Nothing to do on upgrade.

The ground under you loads first

"I can see through unloaded terrain and it needs to prioritize loading what's right under me."

Terrain arrives nearest-first, which was right, except that "nearest" was counted in each world's own chunks. So a patch of ground three chunks from you on the planet you are standing on counted as exactly as close as a patch three chunks from you on a planet twelve thousand units away — and which one loaded first was arbitrary. On a solar system with several worlds resident, the ground under your feet routinely queued behind a planet you could barely see.

Distance is measured in metres now, which is the only unit two different worlds can be compared in. On top of that, the body you are actually standing on outranks one you are not, so landing somewhere loads the landing site rather than the horizon of the world next door.

…and there is no hole in it while it waits

The other half of the same report. Ground that had been queued but not yet built drew nothing at all, so you saw straight through the planet into space — worst exactly when you were moving fast enough to outrun the loader.

A world that is still loading now fills its own gaps with a plain shaded sphere sized to sit just inside its surface. It cannot show through real ground, and the moment real ground arrives it is hidden. You get the planet's own colour where detail has not landed yet instead of a window into space.

Props stay on the planet they grow on

"The scattered props seem to just be being left behind by the planet traveling in orbit."

Exactly that. A scattered field was pinned to the world when you declared it, and worlds orbit. The spawn planet moves at ninety-nine units a second, so a field reaching two hundred and forty units was entirely behind its own planet in under three seconds — the rocks quietly sliding off the world while you stood on it.

A field can now ride a node:

scatter.create{
  parent = "Umunquo",              -- the world this field grows on
  center = planet.pos, radius = 107,
  lod = { { asset = "rock.glb", distance = 190 } },
}

Following costs nothing per prop. Every rock keeps its identity, its place on the surface, and the ground height it settled at — so a rock you harvested stays harvested, a rock you walked past is the same rock when you come back, and none of it is recalculated as the planet moves. It works for anything that moves, not just orbits: a rotating world, a moving platform, a ship's interior.

Fields on ground that never moves need no change and pay nothing.

Under the hood

Two things that will not show up on screen and are worth knowing about.

The tests now run automatically. Every change to the engine is checked against the full suite before it can become a release, rather than depending on somebody remembering. Its very first run caught a real problem.

Performance regressions are caught by shape. A set of guards measures the engine's core operations at two different scene sizes and fails if the cost grows faster than the scene does. Three separate slowdowns have reached players by exactly that route — each one found by somebody whose game had got big enough to notice.

Upgrading

Nothing to do.

If you scatter props on a world that moves, add parent and remove whatever you were doing to work around it.

Two things that used to answer you instead of telling you. A scatter field now says what it costs before it costs it, and a mistyped UI value stops the screen instead of quietly meaning something else.

Nothing to do on upgrade.

A field of props says what it costs, at the moment you ask for it

scatter.create's knobs read as a look: how far props are drawn, how big a chunk is, how many per chunk. One of them is really the whole budget.

The outermost lod distance sets how many chunks stay loaded around you, as a square that grows with it, and that square is walked every frame. So the cost is about (distance ÷ chunk) squared. A field asked for at 700 metres against a 22-metre chunk came to four and a half thousand chunks and a hundred thousand props — for one source, of four. The game froze on arrival and dropped frames continuously after, and nothing in the API, the reference or the Console suggested that those two numbers were the ones doing it.

Three things changed.

You can ask. scatter.cost(id) hands back what the source wants every frame:

local field = scatter.create{ center = planet.pos, radius = 107,
                              chunk = 34, perChunk = 14,
                              lod = { { asset = "rock.glb", distance = 190 } } }

local c = scatter.cost(field)
log(("%d chunks, %d props"):format(c.chunks, c.props))   -- 121 chunks, 1694 props

And if you don't ask, it tells you. A field big enough to matter prints one line to the Console when you declare it, naming the source, its chunk count, and the two numbers that decided them. Big fields are still allowed — that is your game's look to choose — but you find out in the Console rather than in a playtest.

A planet never costs more than a planet. Asking to see 700 metres of a 214-metre world used to cost thirty times what asking to see 190 metres cost, and piled three quarters of its props on top of each other along one seam. How much is loaded now stops growing once it covers the body you're standing on.

A big field slows down instead of stopping

Props are dropped onto the real ground with a ray, once, when their patch comes into range — so the frame a patch arrives pays for all of its props at once. Walking, or just looking around in third person, moves the camera far enough to pull new patches in, and that arrived as a stutter that got worse the more you looked around.

Ground now arrives nearest first, a few hundred props a frame. A field coming into view fills in from where you stand outwards over a few frames rather than stopping the one frame it appears on. The same ordering means that if a field does overrun what can be drawn, what's dropped is the horizon rather than what's at your feet.

Standing still costs nothing at all now: the list of loaded patches is worked out when you cross from one to the next, not sixty times a second.

ui.make stops answering typos

ui.make has always refused a property NAME it doesn't know, because a declarative screen that silently ignores a line is worse than one that stops. A property's VALUE got no such treatment.

There is no topCenter. So this:

label("FLOOR 1 - ROUND 2/3", 8, GREY, { pin = "topCenter" })

pinned to the top-left corner, silently, forever. In one game every bottom-centre and top-centre element in the HUD — the round readout, the controls hint, the "press E" prompt, every shop message — stacked into one corner underneath the panel that legitimately lives there. It reads as a layout bug. It was a spelling mistake the layout answered rather than refused.

Now it raises, naming the property, the value it got, and the values it takes:

ui.make > Text: `pin` does not take `topCenter`; it takes topLeft, top,
topRight, left, center, right, bottomLeft, bottom, bottomRight, topCenter,
bottomCenter, leftCenter, rightCenter

…which brings up the second half. topCenter, bottomCenter, leftCenter and rightCenter now work, because they are what people write — the other five anchors are topLeft and bottomRight and friends, and the ones that take a bare direction are the ones you have to look up. centre works anywhere center does.

The same silent default was in align, justify, dir, case, overflow, imageFit, textAlign, textValign, sliderDir, scrollbarAxis and part. All of them refuse a word they don't know now, and all of them say what they take.

Upgrading

Nothing to do.

If a screen of yours starts raising on a pin, align or justify it was happy with before, that line was already not doing what it said — the error names the property and the words it accepts.

Sprites you draw in update now reach the screen. Terrain resolves instead of popping. And a scene can hold twenty thousand scripted nodes without taking the editor down with it.

One thing to change on upgrade, in the last section.

Sprites drawn in update were being thrown away

A player of a 2D game put it this way: "I can't see any enemies or bullets any more, it's like they're behind the level." They were not behind anything. They were never drawn.

A sprite batch was emptied after every script pass, and a frame runs three of them — update, then fixedUpdate, then lateUpdate. So anything drawn in update was wiped twice before the frame reached the screen, and lateUpdate was the only place a draw survived. update is where every tutorial puts per-frame work; it is where draw.rect and draw.line go, and those clear per frame, not per pass. The one obvious place to put your renderer was the one place it could not work.

The failure was silent and total — not a flicker, not a subset. Every batch in the game emptied at once, so a project that had just moved its renderer onto batches saw nothing at all and no reason to suspect the pass it drew in.

The frame is now the unit. Draw from update, fixedUpdate, lateUpdate or any mix, and everything drawn since the frame began is what renders. It is still immediate mode: a batch nobody draws to all frame draws nothing, so there is still no pool to grow and no clear() to forget on the frame a wave dies.

A sprite is the size you asked for

size on a sprite batch is documented as the width of one sprite in world units. It was multiplied onto a quad that is 1.4 units across, so size = 1 drew a 1.4-unit sprite and every bullet in a game came out 40% too big — which reads as somebody's tuning change rather than a unit mismatch. size is now the edge length it says it is.

If you compensated for this, remove the compensation. A batch created with size = 1.0 / 1.4 (or a PLANE_UNIT constant of your own) should go back to size = 1.0. Nothing else changes; each sprite's own scale still multiplies it, per axis.

Terrain resolves instead of popping

"The terrain is appearing in front of me and it's obvious when it pops in."

v0.29.0 cut how many chunks arrive at once on a small planet — 109 down to 9 on a 180-unit world. That fixed the hitch, not the pop: each chunk still switched from absent to fully lit between two frames.

A newly meshed chunk now dissolves in over about a third of a second. Its silhouette and shading are correct from the first frame; what changes is how much of it is there. Landing on a planet reads as the ground resolving rather than as slabs of it appearing in front of you.

A chunk being re-meshed does not dissolve — mining a hole, or a chunk changing detail level as you walk toward it, both stay solid. Only ground arriving from nothing fades, or every bite of a mining laser would dissolve the ground under it.

Thousands of scripted nodes no longer crash the editor

A scene with more than about four thousand nodes carrying scripts would crash outright, with a message naming nothing you could act on and taking your unsaved work with it. In the editor that is the worst failure available.

The engine was holding two live Lua values per script instance, against a limit of roughly eight thousand of them for the whole program. It holds none now. A scene of 20,000 scripted nodes runs — measured, and the ceiling is gone rather than raised.

That is a ceiling removed, not a performance claim: 20,000 scripted nodes is still far too slow to play. The difference is that it is now a frame rate you can see and budget against instead of a crash.

Upgrading

One change, and only if it applies to you: a sprite batch's size is now the sprite's true width, so drop any 1.4 you were dividing by.

-- before
node:setSpriteBatch{ size = 1.0 / 1.4 }
-- now
node:setSpriteBatch{ size = 1.0 }

Everything else is nothing to do. Sprites drawn in update start appearing, and if you had moved your draws to lateUpdate to work around this, they keep working exactly as they are — there is no need to move them back.

Scripts stop searching the whole scene to find each other. A world can have biomes. A prop your own script assembled can be scattered like any other. And three things that used to fail in silence now say something.

Nothing to do on upgrade, with one deliberate exception at the bottom.

One script finding another stopped costing the scene

findScript, findScripts and findTagged walked every node in the scene and compared strings, on every call. So the cost of one script asking for another grew with the size of your game — and a project that wires panels to a shared manager pays it per panel, per frame. One real project counted 126 whole-scene searches a frame, none of them carelessly written: there is no cheaper way for sixteen panels to say "the company ledger", and none at all for something spawned while the game runs.

They read an index now, the same way find by name always has.

The 25.7 is more than a whole 60 fps frame spent looking for things. The number that matters, though, is that the two rows are now the same: the cost no longer depends on how big your game has got. findScript still returns the first in scene order, which several games rely on.

A world can have biomes

Scattered props grew everywhere, at one density, so a forest could not end and a desert could not be empty. Palms in the ice cap.

scatter.create{
  asset = "palm.glb", center = planet, radius = 180,
  density = function(x, y, z) return climate.densityAt(x, y, z) end,
}

density returns 0..1 and 0 means nothing is generated there — not hidden, not drawn and thrown away.

Your rule is asked once, when you declare the source, and what the engine keeps is the answer. That is deliberate: where each prop stands has to stay a pure function of the seed, so that walking away and coming back regrows the same world and two machines agree without sending each other anything. A rule consulted per prop could read the time of day and answer differently on the second visit, which would quietly break all of that.

Scatter a prop you built yourself

asset can now be a prefab, not only a mesh file. Each Mesh node inside it is drawn at its authored place within the prop, still GPU-instanced, still with no scene node anywhere.

That is the difference between scattering a tree somebody modelled and scattering a plant your own generator assembled out of a trunk and three fronds — which is what a game with procedural flora actually has.

A planet you can walk around stops hitching when you land

Terrain detail rings were written for worlds where "24 chunks away" is over the horizon. On a walkable planet — 100 to 250 units of radius — it is the far side of the world, so arriving meant rebuilding more than half the planet's surface at full detail through a queue sixteen deep. That is the pause on landing, and the ground filling in afterwards is that queue draining.

The rings now also scale with the body they are on. Standing on a 180-unit world that is 9 chunks of full detail instead of 109. Big worlds are unchanged — this can only tighten.

Not in this one: new terrain still appears rather than fading in. That is the other half of the complaint and it needs a change in how chunks are drawn, not in which ones are queued.

Three silences broken

• A scatter option that did nothing. collide was read, defaulted and stored — and used by nothing at all, so a game that asked for solid props got props it walked through, and no error. Scattered props still have no collision; the option that suggested otherwise is gone. An option scatter.create doesn't recognise is now an error, which is the only reason the dead one could hide for two releases. A typo was the same silence.
• A scene value your script no longer uses. A scene stores tuning per node. Rename or remove the setting in the script and the stored value stays behind — read by nothing, and indistinguishable from a script whose numbers do nothing. You get one line in the Console naming the scene, the node, the script and the value.
• A scene value that is pinning your script's. The harder half, because nothing about it is wrong except its age: the name is real, the value is real, and it silently wins over the number you just edited. The Inspector now marks that row and offers to drop it and use the script's.

Upgrading

One thing to know: if you pass an option to scatter.create that it doesn't recognise — including collide — it is now an error rather than being ignored. That is the point, and it is a one-word fix in your call.

Everything else is either faster, additive, or a message where there wasn't one.

A screen built with ui.make no longer disappears because one part of it isn't showing. That is the fix behind a report we chased for two releases — "after playing once, the UI never comes back" — and it turned out to have nothing to do with playing twice.

Also: a script can make a node a sprite batch, and asking a node that isn't one for its sprites now says so instead of throwing your drawing away.

Nothing to do on upgrade.

A section that's switched off stops taking the screen with it

This is how anyone writes a HUD where parts come and go:

local dead = nil
if not player.alive then dead = deathPanel() end

ui.make(node, { vitals, score, hint, dead })

When a section was nil, the whole screen failed to build — every other part of your HUD gone, and an error naming a position in a list rather than the thing that was missing. Whether it happened at all depended on where the gap fell, which is why it looked intermittent and unrelated to anything you'd changed.

Worse when the gap came early: everything after the first absent section was dropped silently, with nothing in the console at all.

A nil now means what it looks like — nothing here — which is what the engine already did for a section written as a function that returns nothing, and for a nil child inside an element. The list spelling was the one place it was fatal.

And ui.make(node, {}) now clears a screen. It used to leave one empty element behind, so a menu that hid itself left something on screen every time it did.

Clicking one thing stops doing another thing's job

Re-describing a screen installed the handlers it asked for, and never took off the ones it stopped asking for.

Screens reuse elements — that's what makes ui.make cheap to call every frame — so a row that was a Buy button and is now a Sold out label is the same element, with no click handler in its new description. It kept answering the old one. Clicking a row could do the job of whatever used to be in that position, depending on what the screen last showed.

A description now removes what it no longer asks for.

A script can make a sprite batch

There was node:setTilemap. There was no counterpart, so a game whose sprite styles live in Lua — one batch per material, one material per style, fifty of them in a file — had to author fifty matching nodes into the scene by hand and keep them in sync with the script by remembering to.

node:setSpriteBatch{ size = 1.0 }
node:setMaterial{ texture = "sprites.png", sheetCols = 24, sheetRows = 15 }
batch = node:sprites()

And node:sprites() on a node that isn't a batch is now an error that tells you which call fixes it. It used to hand back a handle that worked, accepted every draw, and drew nothing — no error, no warning, no line anywhere to say why.

Upgrading

Nothing to do. Every change here either accepts something that used to fail, or replaces silence with a message.

One thing worth checking if you hit it before: if you worked around the nil problem by filtering your list before handing it over, you can stop — though leaving it in changes nothing.

A pixel-art game can now look the same in every window size. Two settings — whole-number upscaling and a fixed internal resolution — plus the same rule for UI layers, so a pixel font stops being resampled off its own grid.

Also: work a script queued on the last frame of a Play session no longer lands in the next one.

Nothing to do on upgrade. Both settings are off by default.

Your game looks the same fullscreened or not

A player noticed this before we did: "the game visually looks totally different whether I have the game window fullscreened or not." They were right, and it was two separate things.

The upscale was a fraction. With Retro on, the low-resolution image is stretched to fill whatever rectangle it lands in. Fullscreen at 1440p that is about 6×; in a docked Game panel 486 pixels tall it is 2.025× — so some rows of your art land on two screen pixels and some on three. On 1-bit art with an 8-pixel font that is the difference between crisp and mush, and which rows are fat changes as you drag the window edge.

The internal width followed the panel. The vertical resolution is what you set; the horizontal was derived from the window's shape. A 2.0-aspect window therefore showed 12% more of your level than 16:9 — which, for a game you have balanced, is a difficulty setting nobody chose.

Both are now settings, in Project Settings ▸ Rendering:

• Whole pixels — upscale by a whole number, centre it, and letterbox the remainder. Every pixel the same size, at every window size.
• Pixel columns — a fixed horizontal resolution. 0 keeps the old behaviour of following the window.

Turn both on together. A derived width is rounded to a whole pixel, and that rounding can cost you a whole step of scale — 240 rows at 16:9 rounds to 427 columns, and six of those is two pixels too wide for a 2560-wide screen, so it drops to 5× and leaves a sixth of the display black. Pinning the width fixes it.

…and so does your HUD

A UI layer's scale is the window height over the height you designed for — the same fractional number, one layer up. A 240-unit HUD in that 486-pixel panel scaled by 2.025 and its pixel font came out resampled off its own grid.

Tick pixel scale on the layer (Inspector ▸ UI Layer) and it rounds to a whole number.

It rounds down, so the design canvas comes out slightly larger — 243 units instead of 240 — and the extra is margin. Anchored elements stay against their edges, centred elements stay centred, and because nothing is offset, nothing clicks in the wrong place.

The 2D guide has the combination a pixel-art game should ship.

Yesterday's work stops arriving today

Stop lands where it lands: after a script's update has run and asked for something, and before the engine has done it. Those requests belong to the session that just ended — the node they name is gone, and the function they'd call closed over a game that is no longer running.

Most of them were already thrown away at Stop. createNode was not, so one queued on a session's last frame was carried over and built on the next Play, parented to whatever node had inherited its number. For a game that creates nodes constantly — tiles, pools, spawned scenery — that is a stray node and a callback running against a world that isn't there any more, on every second and subsequent run.

Upgrading

Nothing to do. Whole pixels and pixel scale are off, and Pixel columns is 0, so every existing project renders exactly as it did — these are things to turn on, not things that happened to you.

If your game's UI stops appearing after the first Play session, that one is still open and we would like the report: this release fixes a leak that could cause it, but not one we have been able to reproduce from the symptom.

A big scene got much faster. Finding a node's components was a search through every node that had one, so the cost of a busy scene grew with the square of its size — 5,500 nodes spent 60 ms a frame on lookups alone. It is now a direct lookup, and that scene spends 4 ms. Nothing in your project changes; scenes that were heavy are simply lighter.

Two things a game asked for and couldn't have: the cursor back for its own menus, and sprites that can squash and stretch.