been getting back into my hobby renderer / engine project and have done basically nothing to the rendering itself for a week or two (after fixing a fun GPU race condition that caused memory faults and flickering); I’ve been all in on infrastructure and editing, turning it into less of a “one viewport to look around in” toy and more of a workbench.

the mildly interesting data-model thing I’m doing, which is also a source of some grief, is that the entire world state is a value type: it’s a struct containing more structs, so there’s no lifetime stuff to handle—if you have a World then you can do what you want with it without affecting anything else. this makes concurrency kind of a non-issue since I can just hand the renderer a copy of the current World to chew on. it also makes editing the world—dragging things around, or editing properties in the inspector panel—a little funky because somebody has to own the “real” world and handle propagating changes between that and the UI. which adds a little complexity compared to just handing around reference types, but hopefully will produce fewer bugs.

there’s still lots to do on this editing infrastructure—those inspector fields aren’t editable yet, obviously, and they also don’t yet respond to changes in the world like moving the camera around—but once that’s done I’ll be able to get back to the fun part, and will hopefully have some more interesting pictures.

One silly RPG system idea I've been kicking around is character design by ranking skills from best to worst, which ideally lets you pick a character type quickly while presenting some interesting choices in which weak spot you have to plan around.

Implementing this with a halfway sensible UI requires a reorderable list widget in the vein of Sortable.js - some UI frameworks have this, but Godot does not (AFAICT), so it's a good opportunity to figure out how to make it work as a custom widget.

A reorderable list is not a super complicated component, but a few edge cases come to mind:

• How do you implement the "target" which shows where your choice ends up if you drop it?
• How do you deal with people swapping between controllers and keyboards?
• How do you ensure the choices retain their relative order correctly while you're moving the choices around?

Having used TLA+ previously, I thought it might be a good exercise to make a lightweight formal model of the UI flow before implementing it. While TLA+ is designed for modelling distributed/concurrent systems, there's nothing stopping you from just using it to model a plain state machine - it may be overkill but it works!

I finally ended up with this TLA+ spec, which:

• Creates the "target" once dragging has started, moves it in place when we mouse over/select another choice, and swaps it with the held element when dragging stops
• Only assumes that the inputs are "start/stop dragging" and "move to another choice"
• Checks that there is no action which accidentally duplicates or removes choices

I might have arrived at these answers regardless if I'd tried to implement the widget right away, but writing the formal spec did help simplify the design, and getting failed traces¹ from the model checker was a nice debugging tool.

---

1. I halfway remember at least one preprint article which tried to infer the state history by having the program add state markers to the log files, would be interesting to see how viable that approach is

but then i decided i wanted to set up my bigger vise (the small one with the swivel base from before kinda sucks for hacksawing. the swivel mechanism keeps unlocking)

then i saw it had gotten a little rusty sitting unused in the attic for several years. so i took it apart, degreased it, and put it in phosphoric acid deruster. also put all the thrift store files i bought in there for good measure.

so that ended up being most of my evening. forgot to take a picture and i'm not going back out. sorry

I use a script to post screenshots to @cassie-gundam, and tonight I taught that script to pre-populate the alt text with the caption, extracted directly from the subtitle file. I still get a chance to edit that so I can add the actual scene descriptions but now I don’t have to additionally transcribe that caption.

I’m sure this will save me seconds per post. I bet my time investment will have paid off by the time I finish watching every Gundam series ever released.