The implementation conversation
How a maneuver editor became an orrery with spaceships. These are nearly all of my project messages, including typos, paired with retrospective summaries of Codex's implementation work and responses. Outages and machine troubleshooting are left out; omissions within a message are noted.
The format takes inspiration from Simon Willison's published coding transcripts. The summaries here replace the detailed assistant replies and tool output.
We did an initial planning for this just now in a different thread, let's continue from that plan with the initial impl for M0.
Codex · condensed
Built the first browser prototype and a deterministic orbital simulation core, with impulse burns, fuel accounting, canonical checkpoints and independent numerical calibration.
lgtm, continue to next milestone. Only small nit on UI design: lots of unnecessary text like in the footer and subtitles and captions; don't need to repeat details/metadetails of the plan/charter like limitations or caveats.
Codex · condensed
Added the CoaDE-inspired maneuver editor: select a trajectory, pin a preview, then adjust a burn with directional handles. Trimmed explanatory UI text.
Clear; continue validating the rest of M1
Codex · condensed
Continued validating maneuver placement, undo, direction changes and playback against the same simulation used by the preview.
cool this works pretty well as the important parts of CoaDE's UI. The intertial frame switching works well. i think only nit the estimated path should show a dot where the apsis will occur, and if you click close enough to that it creates a manuever snapped at that apsis, so it's also visualized even if you don't put your manuever there; can still leave the snap to apsis in the precision dropdown though. Also would be nice to be able to click the maneuver node itself, then you can adjust its time by moving the mouse left/right until you click again, so as a coarser way move an existing node without having to open precision menu. Otherwise I think good to proceed.
Codex · condensed
Marked apsides along predicted trajectories, added proximity snapping and let existing nodes slide in time by dragging along the trajectory.
ok, this worked, though it seems like the rendezvous target is only available from the initial state of the 'Rendezvous' scenario. if you perturb the manuever too much or delete it and add a new one, the target is greyed out. Which may be by design but it seems like I could make a rendezous trajectory manually but the option to add the correction at the end didn't seem to enable again. A small nit too is that when editing a current trajectory but not actively dragging the control handles, hovering along the estimated path should still scrub the other bodies along with it, so you can better tell what's going on. While there may be something else going on here, in CoaDE when the sim trajectory intersects the sim trajectory of another body, the intersection point also gets marked with an 'match orbit' icon, which when clicked then adds the correction maneuver for that, and then if the phase is close enough also adds a 'intercept' icon to also match velocity. I think that's worth adopting here. Also CoaDE has an affordance that if there's overlapping bodies/markers at the current zoom level/view, clicking on one of the overlapping icons opens a dropdown menu at mouse position that you can select which one you mean, including a "add new manual manuever here" when it's an intercept/match orbit marker, so if for some reason you want that instead of the autopilot, can do that.
Codex · condensed
Expanded encounter detection beyond the prepared rendezvous, added orbit-match and intercept actions, and made trajectory hovering scrub other bodies. Overlapping markers gained a choice menu.
oh I might've misenterpreted the M2 gate/restriction. If that was by design then we can potentially continue with other M3 tasks here too
Codex · condensed
Kept the milestone gates narrow while taking the encounter and marker improvements into the next slice.
i did notice that the original plan deferred match orbit from intercept/rendezvous. i think it's probably still useful since you can then choose to do a match orbit and then do a phasing manuever after that, which might help get to a working rendezvous faster before trying to optimize.
Codex · condensed
Added orbit matching as a useful intermediate operation, separate from the additional phase and velocity requirements of a rendezvous.
Also I'm realizing that while we're now pretty close at matching CoADE's manuever UI, the planned nature of the game for whole route planning/cyclic means that we'll also need to express the rendezvous corrections as dynamic calculations at the time of the manuever too, not just static compilation to burns; we might also need some higher level expression for like a transfer to a particular new orbit that can also be dynamically calculated. Not sure how exactly to do that yet, but something to keep in mind for architecture/UI.
Codex · condensed
Recorded the distinction between a static burn program and a future dynamically evaluated route intent. The prototype continued with inspectable absolute maneuvers.
cool, the m2 refinements and m3 work well. I think small nit for the m3 display, I think make it so you can toggle off the plan line, orbits, and other UI markers to just see the bodies; maybe also use different stroke alphas/widths so even when enabled, change the plan line to a transparent grey once it's followed (so execution line can show up) and also have the execution line maybe fade to a lighter transparency further into the past. I think the functionality is good though, I think we can proceed to m4 and figuring out how to turn this into a puzzle, I guess first with just the absolute maneuvers before we figure out how to make them dynamic.
Codex · condensed
Added display layers, quieter completed plans and fading executed trails, then continued the finite freight/puzzle experiment.
cool, I think this largely works as a 2d version of CoaDE's rendezvous. The UI a bit clunky in terms of placing departures; the way that the manuevers also depends on the dock/undock state is hard to keep track of; once we switch to dynamic manuevers we'll have to redesign it anyway though. I think what we'll probably want is the sort of horizontal timeline interface like in opus magnum so you can see linearly what each body is doing. I think it'll also help to have like a timeline of fuel/delta-v remaining over time so you can see where you're using your budget.
The layers control is good; with the bodies only or just the trail it does match the presentation of the transfer orbit wikipedia animations pretty well and I can see it being compelling once we get looping in.
Let's try to plan out how to design the periodic transfer programming in more detail before proceeding, including astra review, and any additional web search to relevant resources from either real space launch planning or other videogames. I don't really have any direct experience with this (CoADE again doesn't really have repeating missions), so I dunno what will fit best, as well as in the terms of how much is calculated for you vs tweaking the manuevers yourself. Some possible links are https://en.wikipedia.org/wiki/Porkchop_plot which might be an interesting visualization to show in the game to help pick out schedules. And also https://www.overvieweffekt.com/tools/brachistochrone-rocket-calculator ; with more realistic deltav budgets, it seems like the puzzles might collapse into mainly hohmann transfers without much room for expression. if we lift the caps beyond chemical propulsion up to constant acceleration, that might make for more interesting design space. Even if that also degenerates where the max-speed solution is straight shots on simple puzzles, I think later puzzles should still have enough complexity where even with torchships they'll be interesting solutions. Plus even with limited budgets, hohmann transfers are also 'straight lines' in a certain sense.
Codex · condensed
Researched periodic mission planning, propulsion regimes, launch-window visualizations and programming-game precedents. Drafted a periodic transfer-programming proposal for outside review.
Hmm, while I still think this is still feasible I'm still not seeing how this works as crisply as I hoped yet. Thinking about the abstract structure of opus magnum or spacechem or infinifactory, it feels different qualitatively than logistics at this level; I don't know exactly how though, but maybe there is some schematic or analytical way to characterize the difference. There's a lot more transformation and spatial constraints, whereas orbital logistics has almost no spatial constraint. I have played a lot of factorio and its train schedules have a similar feel to this as well as the abstractions on top of it like interrupts and mods like logistics train network. I however haven't played other train or transport simulators. https://www.openttd.org/ is open source, I think it might be worth exploring its source for game design space like how it both does schedules and UI and also gameplay justification for those. There's definitely a continuum between zachtronics programming games and factory automation games; I feel like there's maybe some better way to fit the topology of orbital logistics in that continuum than our current path of "cycling machine with orbital transports inside of it". Please do another research and planning round with this in mind.
Codex · condensed
Compared the transformation/spatial constraints of programming puzzles with the scheduling and network constraints of transport games, including OpenTTD and train logistics.
I think it's actually worth spawning an astra sub agent as well, in a less constrained form than the senior review flow, more of a "game design consultant", with access to its own sub agents/ability to run code and do experiments as it sees fit.
Codex · condensed
Ran a less constrained Astra design consultation with numerical experiments and prior-art research. Its conclusions helped separate an enjoyable operating exhibit from a compulsory optimization game.
ok, I think the proposal is sound and correctly identifies the abstract differences between the other game's design space and what we have currently. I'm realizing that my own desiderata for this game's design are slowly drifting higher level from like actually designing the maneuvers with a CoaDE UI of broad changes + solver to generally having the maneuvers calculated for you (i.e. hohmann) but deciding high level on policies for transfers/loading/refuelling . I'm even realizing that at some level I don't even want to design the policies really, and that it'd almost be fine to have like a linear programmer spit out a schedule, but I still want to be able to observe the spaceships moving around (not necessarily as a baked video/gif, a live viewer would be fine too). so the goal could be more like a virtual model train set but for spaceships, and maybe sets for specific proposed plans like the mars cycler, or maybe the NASA artemis proposals with moonbase/station; in the existing demos it's still fun watching the different inertial frames as the animation plays out even when I had no input/just clicked the solve buttons, so that's evidence even minus the game, an interactive/scrubbable n-body simulation might be enough.
Account and model-CLI setup discussion omitted.
Codex · condensed
Reframed the project around watching prepared orbital model sets. A cross-model consultation also examined the appeal of an operating freight exhibit without required authoring.
I agree that the orbital model set viewer is the right next direction vs trying to make a puzzle game. I think unlike nasa eyes I would like to be able to watch fictional space buildups e.g. lots of space stations at various orbits and traffic between them and planet/moon ground stations with simulated cargo loadouts, at various settings like earth/moon, or earth/mars, or jupiter and moons, up to full solar system, and potentially exotic technologies like torchships/solar sails once we move beyond simple impulse particle ships. or potentially fictional or non-sol systems, e.g. traffic in a binary star system with planets would probably be neat. Some other prior art that's sort of like this are existing viewers for all the satellites orbiting earth (communications and others) but that doesn't have the same logistics/orbital transfer appeal, and is way more dense/cloudy than I imagine for spaceships. And unlike something like Universe Sandbox, the focus is on schematic spaceships vs the planetary bodies, and thus various inertial views and potentially things like gravitational potential fields/rubber-sheet view or energy/porkchop plots as simultaneous views are more important than like planet atmosphere or star or ring rendering.
The research from actual model train culture is interesting; I was unaware of their own breakdown of autonomous loops vs operations roleplay. That's probably also relevant for future extensions here, like even if the maneuvers and planning are automated, it'd be interesting to see somewhere in the UI some level of simulation of e.g. space station or planet/asteroid colony needs like stationkeeping fuel and other upkeep, and if they're manufacturing, imports/exports; though going too deep there approaches turning this into into a solar system strategy/expansion game like Solar Expanse; and certainly don't need that in this prototype stage.
So this does mean we can likely retire the maneuver editing UI from CoaDE (at least from this prototype, if we end up wanting it later for sandbox/editors can recover from git history). And with that lifted it's also more feasible to upgrade the project to full 3D; though I think we can still validate a lot of the desiderata in 2D still so I don't think we need to build that and the extra viewer complexity immediately, though it may be worth adding the 3rd coordinate to the simulation engine and and just restrict orbits to in plane, to make sure the simulation/solver parts still work earlier.
With that I think good to continue with implementation here, ask me any clarifying questions if needed.
Codex · condensed
Retired the maneuver editor from the main viewer and built prepared fictional freight exhibits with shared playback, reference frames, ship inspection and activity timelines.
Nice, I like this a lot. Good validation that this level of interaction is actually what I want vs first having to build maneuvers themselves. The rotating frames are also cool and help build intuition for how e.g. the retrograde orbit looks complex in the primary body frame but actually simple in the rotating frame, or in the logistics case, why the hohmann transfer orbits are efficient. The only real nit I have is when the label layer is enabled, the text labels jump around frame to frame to try to avoid overlap which is distracting; I mostly left them turned off which worked fine; might just need some hysteresis or overlap fade instead (other e.g. map viewer software might have good heuristics for how to choose what to display under dynamic positioning like this)
What do you think is worth building next? I think there are several possibilities here but not sure what to choose yet; since it's late for me I would like something that seems like it could succesfully run autonomously for longer without my feedback to make use of my sleeping hours.
Codex · condensed
Selected a six-state, three-dimensional simulation foundation as the next bounded engineering slice, while retaining the planar presentation for visual review.
agree that 3d foundation simulation is pretty well defined to work on overnight; if that finishes without much uncertainty that you think needs my review, then I think worth proceeding to seeing if the lunar freight network or some other smaller test is faeasible, and if it is, seeing if you can build a set out of it. the label stability feels pretty simple to roll in too yes + synchronized views again if the other work finishes without much uncertainty, but you're right is more up to my taste there so can defer. Before proceeding overnight, use an astra senior-review ; the jump to 3d probably will benefit from stronger architecture taste to make sure we're prepared.
Personal quota discussion omitted.
Codex · condensed
Migrated the simulation and fixtures to spatial states, retained planar compatibility checks, stabilized label placement and prepared a lunar freight exhibit.
nice, the stable labels work well and the new lunar frieght set is good. the orbit perturbations do help since the orbits are no longer perfectly overlapping, and it's interesting in the way I want to check out the different frames and scrub through them. I think the main deficiency with the set is the large impulses/accelerations on some of the rendezvous like Ibis to Meridian at the end of the set. So we'll probably want to model more realistic acceleration limits. But that being the main deficiency I think is a good sign in that it is the core problem of designing good orbital maneuvers and sets, not a limitation of the viewer.
What do you think we should plan/build next? 3d viewer is one possibility since the simulation is working there. more realistic burns is another, maybe in combination with actual ground launches since that also will require similar modeling to balance realism. I guess other 2 nits is that on the lunar freight scene 1x is slightly too fast and 1/4x slightly too slow, so an analog timescale control would be useful, and it would be nice to actually be able to play the scene continuously like a screensaver. though continuous running is probably a larger slice on its own, since that then needs dynamic solving, maybe keeping only a rolling window of history for pause scrubbing/display, and handling when a ship accidentally runs out of delta-v and scapes/crashes or solver otherwise fails somehow.
Codex · condensed
Diagnosed the abrupt rendezvous impulses and proposed finite propulsion, an analog speed control and a later continuous-service runtime.
ok, that plan sgtm continue with the bounded propulsion slice. use astra senior review flow.
Codex · condensed
Implemented bounded finite thrust with acceleration and fuel limits, paid arrival corrections and schematic burn visualization after an Astra architecture review.
Nice, the finite propulsion does exactly address the complaints and the lightweight schematic visualization is pretty good. I think I like the way CoaDE shows future burns better though, rather than just a highlighted line it shows the thrust vector sampled at points along the burn as like whiskers, I think like some curve editors show 'curvature' whiskers in the same way. other small nit is the past burn/trails look the same as the future planned burns, so it's a little confusing with both layers turned on. the fine-grained speed control is good.
Ok, I think the next slice can be continuous traffic; I think your rough plan sgtm but worth an astra review for architecture/storage and design on what scrubbing/playback/rewind means. wrt failure modes, agree that failed planning can try again next window, with maybe some UI indicating the planning failed, and in-flight failure can also show the fault and let the other ships continue (even if that means the simulation could end up in a nothing happening state after a while). I do think extensions where we model some stationkeeping budgets and triggers on like fuel so e.g. if planning fails for a given ship but another ship can make it to the same stations and divide cargo/transfer fuel, or a station needs more supplies, those would generate dynamic scheduled transfers; but yes I think we can validate the architecture and UI on the analytical stations before trying that.
Codex · condensed
Added sampled thrust whiskers and clearer past/future burn styling. Designed a continuous traffic owner with rolling playback history and isolated flight episodes.
cool, the whiskers work well and the continuous service is also fun to watch. However when I switched to the lunar freight set then back to the continuous set I got 'Simulation paused: worker failed' , so there's some bad stat between the fixed vs continuous; but works fin after a reset. Ok, I think the next step can be trying surface to orbit transfers, which again worth an astra review. I think I agree airless is good to start and still 2d/inplane; feels like there's still enough complexity with those to work on and make sure things are visually readable before adding aerodynamic forces; another extension that's probably compelling in this train set framing is multistage rockets + resusable stages like spacex's, but figuring out how to visualize those along with the larger orbital scales and timeframes will be difficult; they are sort of what we're modeling already (where the cargo mass of a ship can itself be a ship with separate deltav), but not sure how best to do that yet (and again can defer for the next slice but something to keep in mind).
Codex · condensed
Fixed stale state when switching between finite and continuous exhibits, then built a reviewed airless surface-ascent demonstration.
cool, I think the visualization is pretty good for the surface freight. being able to crisply zoom all the way in is compelling. and I was able to switch to the continuous set and back without failures so I think that's fixed.
Ok, how do you recommend to sequence the remaining goals like landing/atmosphere/staging? it's also possible we leave just takeoff as is and try to tackle like stationkeeping or the 3d view; not sure what's best.
Codex · condensed
Sequenced airless return and continuous ground service before atmospheric vehicles and staging, keeping physical docking at the position/velocity-capture level.
ok, this sequencing sgtm. I see how stationkeeping does complicate the planning with the other ships and more dynamic maneuvering calculations to correct for that; at this level of modeling we likely don't have to simulate like exact physical docking down to the surfaces, but still have to match location and velocity enough for them to snap. similarly atmosphere does add all those modeling parameters for both set design and dynamic operations. I think we can still round off a fair amount of it to just overall ship statistics (we're not making kerbal space program) but like the orbital dynamics we'll have to strike some balance.
I think I'm still fine deferring 3d viewer; in my mind it still feels fairly straigthforward to do once we're happy with the 2d visuals. continue, using astra senior reviews where it seems helpful.
Codex · condensed
Added finite landing and a complete airless round trip with explicit operations, paid residual capture and resource replay.
cool, landing lgtm. one nit I forgot to mention earlier, I'd like the thrust whiskers to be reversed so e.g. they match the burn indicator schematic and also try to vary the whisker length by thrust (so can see it tailing off); this might be a little tricky to get the scale/range right for (so you can still see tiny thrusts somewhat without the big thrusts blowing up), but CoaDE does this.
continue with the continuous surface service.
Codex · condensed
Reversed whiskers into exhaust direction and scaled them by thrust. Extended the surface round trip into continuous service.
cool, continuous service works, and the exhaust whiskers work pretty well, though now they make the coarseness of the manuevers a little obvious; during the launch and landing, there are only like 5 unique vector directions along the curve; again here I dunno at what level it actually needs to be simulated as smooth vs like lerped for display.
Besidess that though I'm still happy with the direction. do you think we should do 3d viewer first or the stationkeeping pass? 3d viewer might make placement of the ground stations more interesting and have a reason for out-of-plane manueuvers, while stationkeeping will also stress the continuous service/dynamic maneuver calculation more and probably still is evaluatable in 2d.
Codex · condensed
Compared the next stress tests and chose a spatial viewer before additional stationkeeping. Deferred smooth steering to a separate pass.
ok, let's try 3d viewer and controls first, with validation on simple but non-coplanar maneuvers. Noted on the steering keyframes/whisker smoothing, we can defer that for the later pass.
Codex · condensed
Implemented an orthographic 3D camera with orbit, pan, zoom and axis presets, validated on paid noncoplanar transfers.
nice, 3d UI works well enough. I'm ambivalent whether the occlusion of the visualization by the planet's body is good or bad; I think add a toggle for see-through planet bodies so the user can choose, default occlusion on. Otherwise good to proceed with the smooth steering and also a 3d set that has realistic thrust vs impulses so can see how that looks.
Codex · condensed
Added optional see-through bodies and continuous steering laws, plus an inclined finite-thrust transfer exhibit.
cool, works well and looks good in 3d. Some deficiencies with the 3d view though is it's hard to follow term around at a close zoom but still in the inertial frame (vs centered frame). a follow mode for the cam using the current view angle would be nice, though maybe more to the point also some sort of like chase cam; I think there are enough examples for 3rd person chase cams from video games for specifics on how to do that. Maybe also when you have something selected, make the orbit cam orbit around that instead of the screen center; I know 3d controls have always been hard to get right in like cad or 3d modeling programs too, so I dunno what would be best here.
Besides that though no large deficiencies so I think we can roll to stationkeeping along with the 3d view improvements.
Codex · condensed
Added selected-object camera pivots, Follow and Chase. Designed maintained targets whose physical stationkeeping trajectories could be used by visiting ships.
for the stationkeeping worth an astra review on high level approach since it changes a lot
Codex · condensed
Reviewed the stationkeeping ownership, target validity, fuel accounting and attachment boundaries with Astra before implementation.
Nice, works well, both stationkeeping and follow/chase modes. only small nit is the whiskers and also timeline view for the stations can probably deemphasize or otherwise disambiguate the smaller stationkeeping adjustments from the larger maneuvers the ships are doing, else they look a bit busy even though they're just trying to stand still. Ok, I guess the next step is to try to extend this to continuous running to make sure the online algorithms can handle stationkeeping and navigating to stationkept stations, unless you think we should start elsewhere.
Codex · condensed
Made stationkeeping displays quieter and extended the maintained relay into a continuous service with immutable forecasts, bounded retries and historical playback.
ok, this mostly works but this is stressing the scheduling system/planning, where Tern will sometimes sit at the equator station for quite a while without a valid route solve, and then when a solve finally lands it'll be a kind of wacky high delta v slingshot around orison. Not sure how best to make service more regular; I guess as the Meridian station orbit phase changes there will just be less favorable transfers at the expected cadence but it's less regular than I'd expect, or at least still seems like it could find a better transfer maneuver vs skipping. Maybe worth running some longer rollouts to see what happens yourself and try to diagnose. Or maybe the Meridian station should also try to maintain phase instead of letting it drift; I'm not sure of the implications of that or how real that would be from other hypothetical or actual space stations.
Also after letting it run for a while the solver or maybe other state buildup causes the page to hitch/freeze slightly. maybe need to move some of the calculation off the main thread, or figure out what's building up.
Codex · condensed
Ran longer rollouts and investigated poor transfer geometry, rigid dispatch cadence and accumulating work. Separated scheduling constraints from orbit maintenance.
ok, continue. I think flexible schedules/relay dwell makes sense, since otherwise the phases of both the stations involved and the wall clock schedule all have to line up. While there are also some legitimate logistics scheduling reasons for having that "wall clock" schedule be informed by other industrial activities like bringing material to the port during business hours or similar, I think those have more flex in order to keep our little space logistics sets 'busy' or at least 'active'.
Codex · condensed
Introduced flexible departure windows and relay dwell, admitting complete outbound/return plans together rather than forcing every journey onto a fixed wall-clock cadence.
Cool, this does seem more stable and active with more reasonable transfers. However, even at 1x speed, the simulation pauses for seconds at a time while the background maneuver planner does its work (in a background thread so at least the UI remains responsive), which detracts from the background nature. Here's yet another place where we have to decide on some compromise between simulation fidelity and simplification for efficiency. I did read a bit more about stationkeeping algorithms in the literature (for both real and hypothetical satellites) so another research pass there might be fruitful to see what assumptions they make and what algorithms they use.
Also small UI-level error, the selection highlighting/timeline selection on the timeline at certain points seems to flap rapidly between Meridian/Tern/unselected; so might be like some sort of javascript/dom state resetting going on.
Codex · condensed
Fixed focus/selection flapping and investigated planner cost. Researched stationkeeping methods and added a committed-history buffer to keep ordinary playback moving.
ok, the focus flapping issues seem good and yes 1x speed seemed fine, but going faster does still outrun the planning leading to pauses; I dunno if we strictly need to support 16x planning, but given the other research it does seem like there's headroom vs our current approach, where we can meet our train set aesthetic and runtime requirements while also relaxing constraints at this level of detail. So yes let's try that, and if it seems there's still some cap at how fast we can expect our simulation to run (within some performance envelope of expected viewer/browser capability) we can also set a maximum speed, maybe varying that per set.
Codex · condensed
Reused sensitivities during targeting and reduced repeated canonical work, retaining physical admission checks and a set-specific speed envelope.
nice, I think this works pretty well now. I still saw a few hitches at 4x, but largely worked at that speed. I'm somewhat wary of more complex setups with more stations and ships; I dunno how much algorithmic/optimization headroom we still have vs cutting simulation speed or depth.
What do you think is worth pursing next? we could try to scale the fully maintained service with more stations/ships/perturbing bodies, or we could switch back to ground stations and maybe multistage.
Codex · condensed
Measured the remaining scheduling cost and chose an assigned multiship orbital exhibit as a controlled scaling test.
sgtm, let's try the multiship orbital exhibit; we did already have that scale in the ballistic/kinematic station version and it was aesthetically pleasing at 1x. and yes and continue to use astra reviews.
Codex · condensed
Built a two-visitor maintained network with one shared clock, resource ownership, berth checks and bounded physical storage.
nice, this works well even at 2x. only nit: a bit of small UI flicker in the fuel/freight time series on the sidebar, where the current time bar resets to zero.
Oh actually just as I type this I did get a 'Network invariant failed: Candidate physical storage budget exceeded'. so still some robustness issues at either the set design level or sim level.
Codex · condensed
Fixed sidebar cursor flicker and a physical-storage accounting failure, including candidate cleanup and unique-runner accounting.
Cool, works well now. only slight nit I think is the stationkeeping thrust exhaust indicators on the stations are sometimes distracting from the spaceship burns, maybe either reduce size and/or only show when the station is selected.
Ok, what do you think is next? more scaling up to the relay network size, or the ground stations, or something else?
Codex · condensed
Reduced stationkeeping exhaust prominence and planned a small staged ground-operation exhibit before expanding network scale further.
plan sgtm, proceed
Codex · condensed
Implemented the staged launch/recovery demonstration, with separate booster and payload states, bounded thrust and an observable pad return.
Cool, I like this as a sort of model train version of the spacex starship catch on the launchpad. The smooth bounded thrust works aesthetically too. One issue i'm mulling over is that in this case even 1x is too fast; I instead watched at 0.1x speed. So especially in the context of larger networks, the fine details of stage separation are going to go by in like a single step. It's probably fine to have these ground operation sets be small/slow/fine detail, but we can also maybe round off ground operations in lower sets to more analytic/presolved trajectories vs fully modeling stage separation (just as we also don't model final approach/docking in space stations). Any thoughts there?
Only other small nit is the schematic arrow of the stage still matches the velocity rather than the modeled attitude, which looks a little weird, could use a (still schematic) rocket graphic instead.
Codex · condensed
Changed the stage glyph to show modeled attitude and a schematic rocket. Distinguished detailed close-up ground exhibits from coarser network-scale operations.
cool, the new glyph works well enough. and I think that balance makes sense; the computation cost of planning/simulating out the detail only to have it entirely skipped visually was my main concern yes, so that makes sense.
While we're in this scale, what do you think about simulating aerodynamics? I know we currently have point masses. I think my main desiderata at this scale is being able to see aerobreaking approaches for landing primarily. So here we can still choose what level of simulation fits the desired aesthetics.
Codex · condensed
Scoped a schematic aerodynamic model around visible entry behavior rather than detailed vehicle construction.
sgtm, yes I think we can still have a nice schematic view of aerobreaking with also some schematic display of atmosphere density, drag/lift forces (with maybe a visual layer to show those as vectors) and some visual effects like entry glow I think matches the level of detail that I find pleasing, without inventing a whole rocket. On the landing pad too we can also do ocean/less precise reentry if that also better meets the level of detail, though I guess if we're precomputing we can also put the landing location right where we want, maybe more relevant for possible continuous operation expansion (let it splash down wherever and fade away/reappear at a launch pad, no need to model ground logistics).
proceed with astra review and impl.
Codex · condensed
Implemented simplified atmosphere, drag/lift, optional force vectors and entry glow, with a prepared atmospheric recovery exhibit.
nice, this works well, with the subtle entry glow and optional force vectors. I think with this built there's opportunity for some nice sets that are single atmospheric planet scale vs interplanetary which can use these simulations, even if we still precompute them for the large orbital dynamics sets. Or static single ship sets where we can script the timescale so it slows down for the launch and landing, but (optionally) speeds up for the longer ballistic parts, e.g. an apollo or artemis mission. So getting more into the NASA Eyes territory than hypothetical space networks again, but I still like where we're at in design space.
Hmm, I guess next lets try an atmospheric launch with booster to make sure the launch planning can still handle the additional simple aerodynamic forces, and if that seems to be working well, can extend to a full launch, space station rendezvous then splashdown set.
Codex · condensed
Added an atmospheric booster launch and a complete ascent, station rendezvous and return demonstration.
Cool, I like this. Ok, next I think I want to test out our hypotheses about precomputed ground launches and landings in concert with the larger flexible service to see if it holds up, e.g. the existing Orison flexible service set but with equator as a ground station, I guess airless to start, if the precise landing becomes an issue we can likely fudge it with a crossfade ground transport from splashdown back to launch.
Codex · condensed
Integrated prepared ground-operation trajectories with flexible orbital service as a test of caching across different simulation scales.
oh yeah, astra review probably prudent here too
Codex · condensed
Reviewed the cache/live handoff, frame conversion and ownership assumptions with Astra.
Hmm, unfortunately this doesn't pass the aesthetics test; the transition between surface and orbital flight looks pretty artificial vs the fully simulated version, both on launch and landing. We may have jumped to caching too soon; or at least at this scale with single ship, it's probably worth the full simulated airless launch and land to see how it compares to the cached dynamics. even if it can't run at 1 or 2x can maybe identify a better cache or blend of approach for larger scale ground to orbit sets.
Codex · condensed
Replaced the cached ground segments with fully simulated airless ascent and descent to determine whether the visual discontinuity came from caching or the authored trajectory.
hmm, even with fully simulated thrust, I think the parameters of this particular set design just don't look as nice, not that the cached trajectory was wrong. I see that there's only a really short burn for escape velocity and then the "sharp corner" burn to rendezvous rather than a smooth longer burn arc against a lot of gravity. I dunno what exactly would need change there but I guess higher mass ratio, lower orbit.
The other smaller thing that detracts is the way we're aligning the glyph and exhaust; right when the rendezvous burn starts it immediately snaps; it's again probably still fine to only simulate point particles for this level, but maybe lerp the attitude changes.
Codex · condensed
Retuned vehicle and orbit parameters for longer, smoother gravity-working burns. Smoothed the schematic attitude through changes in the requested thrust direction.
yes, this is more aesthetically pleasing, and the rocket glyph is smooth now. Cool, I think we can move back to seeing if caching this launch and landing still works for continuous or larger sets.
Codex · condensed
Returned to caching the improved launch and landing trajectories, checking continuity against the corresponding live flights.
Nice, works well with no obvious discontinuity between cache and live sim. It also occurs to me for some of the subtler effects like stationkeeping, depending on set requirements it may also just be fine to precompute/cache the larger effects rather than simulate those mostly invisible details, e.g. estimate phase drift for stationkeeping but otherwise keep it kinematic. What do you think is worth doing next here? I think my reflex is to try to tie these pieces together with a set with more extensive inter-station logistics and some ground launches/landing, but if there are other pieces we should try or optimize first can do those.
Codex · condensed
Kept prepared/coarse station behavior as an explicit exhibit-design option and planned a broader freight district with ground feeders.
Ok, I think this plan makes sense. One other smaller piece we haven't tested yet actually is non-equatorial ground stations/off-plane launches, so where the latitude differs. However, I'm fairly confident the solvers should be able to handle that; if you think the same can try it out with this next proposed set, but if you/astra think it's worth a test set to validate that before, that's fine too. and yes astra review on this.
Codex · condensed
Validated non-equatorial launch geometry before combining it with more inter-station traffic.
Cool, these both work pretty well. one UI piece that's missing is a faint lat/lon grid on the planetary bodies so you can see their rotation and axis (can be seethrough/wireframe for when see through bodies is on).
Besides that good to keep going. I think we could either try to make the Selene earth/moon sets also run with ground service, and/or try precomputed atmospheric parts, also with some level of nonequatorial stations/nonplanar orbits so see how those look in 3d.
Codex · condensed
Added a faint rotating latitude/longitude grid and a northern atmospheric launch demonstration.
nice, the grid works well plus the northern launch. Ok, I think I'd like to see a multiple body set next like the Selene moon ones but with some combination of ground launches, offplane, continuous service, depending on what you think is feasible/good integration test sequencing.
Codex · condensed
Integrated ground service, inclined routes and continuous operations into a moving planet–moon setting.
cool, this works well, no issues I can see.
Codex · condensed
Validated the moving-body ground-service integration and retained it as the next exhibit foundation.
yes, continue, using astra review if it feels necessary
Codex · condensed
Extended the multi-body ground-service work into a continuous setting while preserving bounded preparation and playback ownership.
huh, it was working well for a while but now it's frozen,, seems in a bad state. other small nit is the fade on the trails doesn't seem to be working, or I can see the end of the trail truncate as the timeline rolling window ended. Maybe just a timescale issue.
Codex · condensed
Diagnosed a frozen continuous-service state and fixed fault/lifecycle handling. Improved the relationship between trail fading and retained history.
the ui is active right now and is still responsive, for buttons but can't pan/orbit the view.
Codex · condensed
Used the responsive controls but stuck camera as evidence to narrow the failure to application state rather than a blocked browser UI thread.
Ok, this seems stable now and running for a while. I think this works fine as is though the maneuver it does to land is pretty high deltav sometimes, burning in a pretty curvy path to catch the station. I'm ambivalent whether we should try to fix that or not; I feel like a real maneuver might allow for more orbits around the body get the right plane but I'm actually not sure if that makes sense; maybe it is optimal and just a set design issue, opinions there?
Codex · condensed
Investigated return geometry and explained why a direct timed surface catch could create expensive, visually awkward burns.
Ok, I think this is worth a pass at that. You're right that the actual optimization criteria here is aesthetics not necessarily minimum deltav, so yes we want the return geometry to change, and we do still want the set to be relatively active instead of waiting forever for the optimal launch window, but yes it sounds like there's maybe room here for that even if we have to change the set geometry a bit. Like maybe it'd be better to have multiple ground stations to choose from to reduce some variance without needing to rotate the moon really fast.
Codex · condensed
Searched return windows and adjusted the ground-service geometry, including multiple destination ports, to balance smooth approaches with an active exhibit.
cool, I think this works pretty well aesthetically as a set. Ok, I think I'd like to see a set with ground service between planet and moon including transfer maneuver between the bodies and air on the planet, with some safety/timing orbits of each body as well, i.e a full apollo. Eventually continuous ideally but finite probably to start, or again if you/astra think a smaller set would be better first could do that.
Codex · condensed
Built a finite Apollo-like expedition: planetary launch, parking coast, transfer, lunar operations, return and atmospheric recovery.
hmm, I can select the expecdition but I think some browser exception or other bad state happens, app stops responding (UI thread is fine though)
Codex · condensed
Fixed an expedition preparation failure that left the application in a nonresponsive scene state.
cool, the set works well. it does require some scrubbing depending on how patient you are but I think that's fine here. only nit is it's missing the planet moon rotating frame to view in.
How feasible does continuous service look for this? I'm thinking that interest wise having this plus either additional activity , maybe lagrange point stations if spaced correctly could better fill out the less interesting balilstic parts so there's something going on elsewhere. I think the other path to explore would be to add in some multistage booster on earth plus lunar lander/orbiter to add a bit more apollo flair.
Codex · condensed
Added the planet–moon rotating frame and assessed continuous expeditions against staged mission detail and additional relay traffic.
Ok, let's try continuous. first and yes we hopefully can cache a lot, or at least do the more expensive planning in the background during the longer quiet periods of ballistic. astra review as needed.
Codex · condensed
Implemented continuous expedition service, reusing expensive prepared flight geometry while keeping live playback and resources coherent.
cool no errors or hitches for continuous service even at 16x. Let's continue with the plan.
Codex · condensed
Added staggered activity around the expedition so long ballistic passages had other traffic to watch.
lgtm, this does help fill out the set a bit. Let's try the libration region station. We do have the live stationkeeping code, though at this level of continuous operation we might not need to simulate it vs a more analytic or precomputed drift.
Codex · condensed
Added a libration-region relay with bounded prepared/analytic behavior appropriate to the exhibit scale.
nice, this is a really compelling set, good at this scale, active enough and you can slow down and enjoy the smaller burns. I think next I'd like to return to the mission detail up to apollo level; we do already have the booster working in other sets but not a separate lander stage. While I think a finite mission is fine to start, I do actually think a booster and lander like rendezvous could work at the beacon relay scale as well; so if you finish the finite mission and it looks good from your tests, continue to try to get a continuous set working with the same level of detail; I think other than finding errors or exceptions/crashes I'm fairly confident I won't have any major steering input, so you can work a longer autonomous round here. use astra reviews where it helps;
Oh other task too I think can work in parallel: the current viewer has a max size, not responsive to the browser dimensions. it was fine on my small laptop screen but is small on my 4k monitor. I think the UI would be nice with the viewer as the fullscreen in the background with the other UI sidebar and timeline and selectors floating on top; if that seems relatively straightforward to do go for it; otherwise can be more conservative and keep the existing UI (which still works fine) but still expand to the browser viewport.
Personal quota discussion omitted.
Codex · condensed
Added an Apollo-like booster, orbiter and separate lander, then extended the staged mission to continuous operation. Reworked the viewer to use the browser viewport with floating controls.
quite nice. One nit though is with the current set design parameters, some of the transfers don't look as smooth, e.g. when odyssey transfers into selene orbit at ~29.7 it sort of pauses at l1 and does a little flip. Which I think is realistic but reads oddly in the intertial frame. When eagle rejoins odyssey it also feels a little deltav heavy; in the aster-selene rotating frame you can see eagle overshooting the odyssey orbit so it has to burn 'back down' towards selene to join.
So I think it's worth an astra review and small parameter search; again the 'aesthetic' quality might be hard to define numerically, but I guess it somewhat rounds out to low deltav/low acceleration and thus low "discontinuity" maneuvers, or at least longer continuous burns at the timescale. While still trying to maintain Outer Wilds/orrery-ish artifical planet scale and distance so it also fits spatially.
the new UI works well; I think one small nit is giving the timescale slider more physical width vs the scrubber, kind of hard to fine tune the timescale with this set.
Codex · condensed
Reviewed expedition geometry with Astra and searched for smoother lunar insertion and lander rendezvous parameters.
Actually, messing with actual NASA eyess interface, it has a nicer timescale control; rather than unipolar slider you can also move it backwards to reverse time, with pause (well realtime which is very slow in real scale, so I think 0x is fine for our center), which I think is worth adopting here. It does also have real apollo or artemis mission data, which while it also doesn't quite match our aesthetics since earth and moon are not outerwilds scale or aster/selene scale, maybe there's some analysis you can do on its geometry as a softer target. I don't think I want actual mission data to be displayed in this UI (since nasa eyes has that covered) but might be worth having those real traces around for analysis.
Codex · condensed
Replaced the one-direction speed slider with a bipolar reverse/pause/forward control. Used real mission geometry as a reference without importing a mission reconstruction into the exhibits.
cool, this set design does read better in interial and rotating frames, and the bipolar time slider is good. one nit on the UI is the planned trajectory dotted line, the dots move as time progresses/based on start of line segment vs being fixed spatially, which adds some distracting motion when observing. also the timeline space for grouped stages like "atlas - odyssey - eagle" overflows/wraps the space for the label; could make it wider, or perhaps show the joined stage burns across the 3 timelines some other way, not sure what'd work best.
Otherwise though I think i'd like to see the staged operation in concert with a couple different ground stations/libration stations and/or other free satellites and logistic routes, i.e. a full aster/selene set. Again with gates if you/astra think they're worth testing first. but it feels like we're pretty good simulation/caching wise. I'm maybe more cautious about the scale stressing either the rendering/UI performance or its density, e.g. might need scrolling on the timeline view or simplification, plus a bit of browser profiling. I dunno well enough to say whether its worth it over the current rendering architecture but if we're running up to the limits of e.g. dom components or svg, could consider canvas/webgl.
Codex · condensed
Anchored planned-trajectory dots to the path, improved grouped-stage timeline labels and built a fuller Aster–Selene neighborhood with profiling and shared-resource gates.
Nice, full service looks great, no issues with performance or UI density. Hmm, I think next still is just more scaling; I think I'd like to see more sun/earth/moon/mars/jupiter like mass ratios in a set, with maybe some proposed mars cycler/spaceX missions as inspiration. That'll likely need a different order of magnitude of timescales to get right activity/aesthetics wise (as well as relaxing/precomputing the smaller interactions that wash out), but I think we have all the parts there for it. As usual with astra review and any recommendations on sequencing to get there vs one shot, but also if the gates look good, go ahead and proceed to a full mars cycler set.
Codex · condensed
Reviewed larger mass/time scales, validated an interplanetary transfer, and built a solar-system-inspired Mars cycler exhibit with reusable trajectories.
Nice, this is a pretty pleasing set to watch. though I think the scale is slightly too large in terms of dynamic range; it's hard to see the tiny transfers from earth/mars in between the longer ballistic transits. I think I'd like to see the same aesthetics of a cycler but done in a fictional smaller scale vs the real mass ratios. Is this feasible? It feels like the general concept of a cycler/free return trajectory can be scaled down, but I don't know how best to describe the aesthetic I want to retain.
Codex · condensed
Separated the visual character of a cycler from real Solar System scale, and proposed a compact powered-cycler witness before a larger continuous exhibit.
ok, this makes sense, and yes 'orrery with spaceships' is a good description of the overall direction of this project currently, as well as the train set framing, which I'm sure has similar body of practice and terms for how train set designers scale down real world routes for display. I'm slowly getting a better intuition for orbital mechanics myself as we build this project too.
Yes, let's try I guess an aster/selene scale mostly ballistic but powered cycler first, before going back to (an analogue) of the sun/mars cycler + jupiter influence. While finite is probably a good gate, given the nature of a cycler, I think if the finite version looks good from your perspective without much uncertainty, try to push for a continuous version; I think I'm fairly confident there won't be much gap between finite/continuous, though as usual use astra senior review for critique.
Codex · condensed
Built and reviewed a compact Aster–Selene cycler, using a finite witness to test geometry before extending it into continuous service.
hmm, unfortunately the aster-selene cycler has lost something aesthetically; with the current design Pipit is able to burn continuously from wayfarer to aster both accelerating and decelerating, so it's like the cycler isn't even necessary, and even the cycler does a long maintenance burn to rendezvous with the beacon. Compared with the other aster-selene sets the mass ratio seems closer, or the distance is; the sets don't strictly have to match in parameters, but it seems like something in the search threw this off enough that the long transfer arcs of the other aster-selene sets were lost.
other small nit: the 'wayfarer - cycler' name is slightly cluttering on the labels, can remove the suffix.
Codex · condensed
Revisited the objective: the carrier should make a recognizable mostly ballistic passage, while short rider transfers should give it a visible reason to exist. Simplified Wayfarer’s label.
thinking about it the 'long transfers' from the cycler is maybe in direct conflict with the cycler concept, so at least for those sets, we can deprioritize that. also if it does help the parameter search, we can change the masses and distances from the other set, doesn't have to strictly match.
Codex · condensed
Relaxed inherited body parameters and treated carrier coasts and rider transfers as different visual roles rather than forcing every route to have a long arc.
Hmm, there's still something missing with the selene cycler. wayfarer still has a long burn to rendezvous with L2 beacon truncating its ballistic orbit at the beginning of the finite set; in the rotating frame you can see it "turning around" to get to beacon. vs the mars cycler can complete its orbit past that of mars. Also pipit's approach to its landing bad is really shallow angle which also looks a bit weird; maybe an orbit around aster before rendezvous with wayfarer could help add some ballistic time to the set as well.
I also read https://space.stackexchange.com/questions/66520/does-a-lunar-cycler-make-practical-sense , which might also help with finding parameters to met the aesthetics. an L1 station might be too different in character from a cycler set to do here, but it does remind me a set with lissajous/halo orbit would be interesting to do in the future.
Codex · condensed
Studied zero-thrust carrier geometry and removed the beacon rendezvous as the defining target. Proposed an Aster parking coast to decouple surface timing from catching the carrier.
cool, yes from that plot the zero thrust trajectory does look like the aesthetics I want. And thinking about the parking coast, yes that makes set both mechanically for relieving terminal descent/ascent phasing from the ground station and aesthetically because it adds more ballistic coast time. I think some of the character for real low impulse/low dv satellite route planning is they do spend a lot of time in phasing orbits/additional gravity assists, so e.g. if Pipit launches early and does a few smaller elliptic hohmann phase adjustments in aster orbit while wayfarer is on its way so the final rendezvous is lower dv, that is also more compelling than one long launch burn.
Proceed with redesigning the set.
Codex · condensed
Redesigned the exhibit around a ballistic looping carrier and rider parking/phasing time, retaining surface launches and landings as local activity rather than long continuous intercept burns.
Cool, this is more compelling in both inertial and rotating frame. Having pipit in an Aster parking orbit does help add some action in wayfarer downtime. However, the Selene maneuvers are still a little constrained by pipit trying to land and take back off to catch up with Wayfarer in the same loop, which lead to high deltav manuevers . I think there it'd be good to also dwell on either the ground or in Selene parking orbit. While this'll stretch the runtime out for a single cycler and rider, I think we could probably extend this set to multiple cyclers, either in the same orbit but different phase (true anomaly, i think?) or offset orbit (longitude? I don't know my orbital elements well enough). so pipit can hop on a different cycler on the way back, and the overall set can always some rider on the ground, parking or riding. If that makes sense to you/astra, give it a try.
Codex · condensed
Added Selene dwell and multiple phased carriers, allowing a rider to return on another cycler rather than racing the same carrier through both surface operations.
Nice I like how this looks. I think I finally get that deltav reduction/acceleration from burn maneuvers is pretty physically a direct proxy for the aesthetic 'smoothness' I usually want; Though, the burns are also part of the 'activity' of a set; if we just had ballistic orbits then we'd have an orrery, not a train set, and ballistic trajectories could be overly long/not 'active' enough. But something to keep in mind when designing future sets, some balance between smoothness and activity.
Let's try to extend the cycler fleet to continuous operation. Depending on much of the simulation can be cached from symmetries, I think even more cyclers and riders could work. The bottom timeline bar could get a bit too tall with lots of ships , but could add a yaxis scroll there and/or resizable height. Other small visual nit: the trails are too short to appreciate the rotating frame loops of the cyclers; this is in conflict with some other sets where the trails were too long, but maybe could try to give the set a recommended trail length (like the recommended time scale) with an slider to increase/decrease if the trails get too cluttered or are still too long for a viewer.
Codex · condensed
Built continuous cycler-fleet operation using recurring symmetry, longer set-recommended trails, and a scrollable/resizable timeline. Kept rider dwell and short burns as the source of activity.
you might already be considering it but could have the riders refuel the cyclers for their maintenance; and also since the explicit payment of maintenance correction might be too small of a detail for this set, could also roughly calculate drift and just artificially stabilize the orbits, if that saves on some bookkeeping somehow
Codex · condensed
Kept explicit resource/service bookkeeping separate from the prepared recurring carrier geometry, so maintenance detail would not erase the cycler’s visual role or dominate runtime cost.
nice, this works great now, including the 2 loop trails. only small nit is the resize handle for the timeline is on the bottom left corner, I think it'd make more sense for the top of it to be draggable since it's docked at the bottom.
Ok, I think the next feature I'd like to build for these coplanar sets is some visualization of the gravitational potential field to get a better feel for the 'landscape' these ships are traversing. The classic 'rubber sheet' is what comes to mind; but maybe other ways might also be compelling, such as colors/isolines, grid of vectors, potentially subtle particles/texture advection along the field (which I think comes up more in other vector valued fields like fluid flow more than gravity but maybe it'd work); here some other literature or animations or viewers might have good ideas, so a research pass and feasability planning before impl, with astra senior review.
Codex · condensed
Moved timeline resizing to its top edge and researched potential-field representations. Proposed color and isolines first, with an optional relief surface rather than a vector-field animation.
ok, agree that color + isolines is first, which aesthetically i think can evoke topographic map rendering, maybe including like little xs at lagrange points. I do think the rubber sheet view is compelling enough too that even with the caveats of it breaking some intuitions about acceleration/velocity/height, I still think it'd be cool to have as an option for some sets/views, maybe as like displaying the 2d view as a texture on a dense vertex-deformed heightmap mesh with bodies as spheres. so yes artificially 'riding the curve' but I think viewers will be discerning enough to know about its caveats. And on vector field, I'm realizing that for our schematic circular bodies with no curl, vector grid or LIC probably won't add much; it'll be fairly obvious what the 'slope' is I suppose from color/isolines alone.
Codex · condensed
Scoped a planar potential layer and optional 3D relief, keeping the physical trajectory and per-vertex epochs independent from the schematic height transform.
sgtm, proceed to impl.
Codex · condensed
Implemented the potential color map and contour layer with bounded worker computation and disposable view-local rendering state.
nice, this does work well. in the non-rotating frames the squared edges of the potential view are kind of distracting. I think to address that can have the low (or high, I guess) end of the color map be the same as the background color and adjust the scale so it can fade out naturally; it is a little low contrast/too bright I think currently so a fade all the way to black would help. since those are just small nits, can go ahead and proceed to relief and the lagrange markers for the next pass.
Codex · condensed
Darkened the map’s outer range into the background and added WebGL relief plus the equilibrium markers supported by the current dynamics.
nice, the colors are good as well as lagrange points, though L4/L5 would be nice to mark too. The relief mode works quite well too. however, just the isolines and potential color aren't quite enough to visualize the relief surface; the color is also sort of redundant, though currently relief mode requires the potential color/isolines too. I think it'd be better if relief mode could be turned on separately from the and either show a rectangular fixed grid, or maybe if possible streamlines/polar lines perpendicular to the isolines; some rubber sheet visualizations use those, though I don't know if that's easy/coherent to draw for multiple bodies. also the color in relief mode should alpha blend when in 3d, currently e.g. a dark/background colored corner will clip in front of the aster gravity well; i.e. I think the relief surface should be transparent so the countours and/or grid show through, vs opaque. oh also when viewed from the side/shallow angle outline the edges of the relief/potential field so it's more prominent; you can currently see the curve near aster from the color of the field but I think an outline would help.
Codex · condensed
Separated relief from the color layer, added a fixed mesh grid and edge outlines, and made the surface transparent so background-colored regions would not occlude the wells.
oh other small nit, in the layers dialog, if you drag the relief height multiplier, the text of the multiplier changes width which changes the slider so it jitters around. Hmm, what do you mean by the l4/l5 not being equilibria in this model? I might be missing some piece of the simulation then, I thought they were 3-body potential peaks in general
Codex · condensed
Fixed the slider readout width. Explained the missing primary-acceleration term in the older fixed-primary model and why geometric triangular points should not yet be labeled physical equilibria.
Defer until the dynamics support them
Codex · condensed
Deferred L4/L5 markers rather than drawing geometric reference points as though they were equilibria of the current force model.
nice, all works quite well. small nits on the grid are it's a little too bright; a slider for the grid brightness/strength would be good. and at the edge of the rectangle in non-rotating frames the rotating edges are distracting, I think a circular fadeout would be fine.
Ok, I guess the next set I'd like to tackle is lissajous/halo orbits around lagrange points, which the potential field visualizers should be handy for. Let's plan out how to sequence those, also with primary acceleration modeled so L4/L5 make sense.
Codex · condensed
Added grid strength and circular edge fading. Planned a spatial circular restricted-three-body foundation, including primary acceleration, before halo/Lissajous content.
Hmm, since lissajous/halo are nonplanar, the potential field will be a bit harder to do maybe; I'd still like a set with them though (so the 3d trail view can show what it's doing in the right frames) .
Codex · condensed
Kept the potential layer as a planar slice and used three-dimensional trails and appropriate rotating frames to explain the nonplanar observatory motion.
sgtm. I think aesthetically we can skin these sets as like a james webb telescope or Gaia then, so earth/sun L2; with again not necessarily the exact distances/mass ratios but might be interesting for the finite sets to have the launch/insertion burns for the orbit as well (once the orbit is established). https://en.wikipedia.org/wiki/Lissajous_orbit also has animated gifs for WMAP as well, which I guess is a good aesthetic target for how what I want the set to express. proceed.
Codex · condensed
Built reviewed L2 halo/Lissajous witnesses with spatial dynamics, trails, rotating frames and a finite insertion proof, using compact observatory-inspired fictional geometry.
nice the l2 orbit sets all lgtm, including the proof of insertion. It would be nice to have the lissajous orbit be able to run continuously so you can see a long trail draw the figures, and I think for the webb, fill out the beginning of the mission with the existing staged launch and orbits; though I think we should change the names of the bodies and station to our fictional scheme; so we're less constrained by like actual launch parameters and can adjust to fit our small system. but can still mention in the set description that it's webb inspired.
The relief grid changes lgtm too.
one odd bug I noticed is in the cycler fleet set at around 8.14 watching nomad with the chase camera, the camera abruptly cuts to a different viewpoint, and if you're in relief mode, the relief map turns upside down. This happens in the rotating frame too, and wayfarer chase cam does the same thing at that point it its orbit (approach selene). this might'e been an older bug vs introduced in the later changes, but didn't notice until now. It seems to happen in the Crossings set too also around selene following odyssey.
Codex · condensed
Added maintained continuous Lissajous motion and a fictional staged observatory launch/insertion mission. Fixed Chase orientation discontinuities near lunar approaches without changing physical trajectories.
Cool, both sets work well. I'm pretty happy with the overall functionality here. I think next is primarily a UI polish pass, and maybe cleaning up or reworking some of the earlier sets whose design is superceded (e.g. when we added smoother burns instead of sharp impulses, or continuous vs the finite version if it's otherwise the same thing). I think we have enough sets that the menu for selecting a set should be a bigger hierarchical menu with short descriptions of each set/category. or possibly a left-docked (collapsible) menu of sets. Then I'd also like some way to view other intertial frames or view modes (chase/relief) simultaneously. I'm not sure how best to do this; a blender-like splittable view pane might work for this; the other idea a stacking window you can spawn for a new view sort of picture in picture style. The other frames I guess do need their own select state; not sure how best to sync that with the timeline/detail pane, I guess maybe follow the mouse for the active view pane. Then also can refactor/clean up the slightly awkward layers/settings/view mode menus. I think all the functionality is good but it's just a little scattered with e.g. trail length not next to enable trails, or the 'surface view' button kind of easy to accidentally hit.
Along with this since I feel like I'm pretty happy with the direction and scope of this project as just a viewer, vs a game or maneuver editor, it's also worth a deeper astra look on refactoring to make sure the architecture fits the purpose, and also optimization to make sure runtime, data storage, rendering all also fit the purpose, and run reasonably on desktop browsers. I think it would be nice to have mobile support too if the rendering budget seems to also fit whatever mobile performance budget is worth targeting these days; though I know that'd require more work/testing to make sure the mobile UI/UX also works, so not a priority, just a nice to have when planning.
Deployment wise I think I like this as a static site that first opens with a description/landing page and maybe a lightweight live set as a sort of 'hero animation', but not the full viewer UI or heavier load. so that way people can first read what's it's about even on a phone before opening the UI. so can also take that into account on architecture/planning.
Ask me any additional questions where it helps sharpen the plan.
Codex · condensed
Audited the viewer architecture and exhibit catalog, reviewed the redesign with Astra, and proposed one shared physical session feeding independent viewports plus docked library, inspector and timeline panels.
I think the main use cases for multiple views will be overview + chase cam on particular ship, or intertial + rotating frame, a top + front orthographic-ish view. So I think selecting a ship should affect the active view, not both.
Codex · condensed
Made selection, camera, reference frame and display settings local to each viewport while keeping the simulation clock and physical resources shared.
can retire from the viewer/tree entirely, just left to git history. At least for the ones that are fully superceded.
Codex · condensed
Curated the public exhibit library and removed fully superseded sets from its navigation, retaining historical studies in the development history.
on the screen layout options, I'm realizing the current fullscreen + floating might be in conflict with multiple views so could consider a more blender like version where some floating controls are duplicated to active viewports, but stuff like timeline or hierarchy/inspector is a separate panel entirely.
Codex · condensed
Chose a docked workspace with per-view controls, a shared bottom player and separate library/inspector panels, rather than multiple floating full interfaces.
ok, the layout sketch generally lgtm. though one other rework I think is since the timeline duplicates the separate scrubber, I think we can remove the separate one and integrate the speed control/textual playback time and timelines into something that evoke like a common youtube video player interface, I think that'll help familiarity. can still have the separate timelines for each ship vs a single scrubber though.
Oh and the other small aesthetic polish I'd like to do is audition some fonts and 'trim' styling, so the overall interface looks a bit more unique (though while still familiar enough to be usable). Given the setting, I think leaning in slightly to the NASA control room/modular panel aesthetic, maybe with some slight skeuomorphism on buttons/sliders. again don't want to go too hard here but just some more unique flair.
Codex · condensed
Unified the ruler, activity lanes, speed and playback time into one player. Auditioned typography and restrained modular control-room styling before applying it to the workspace.
cool, yes I like B styling but I like Space Grotesk better than Barlow. one slight nit: the left border highlight on the selected set/ship is unfortunately really common in ai designs, so just use an active background color. And when designing the real UI, also pay attention to https://godobject.dev/blog/10-tells-of-slop/#redundant-text-due-to-chat-context the redundant text effect (plus the other tells on that site); the real UI is good about this, I think it just slipped in the concept
Codex · condensed
Selected Space Grotesk with Plex Mono telemetry, used background fills for active rows, and trimmed explanatory text that repeated development context instead of helping viewers.
nice, lgtm. proceed with impl.
Codex · condensed
Implemented the reviewed docked observation workspace, independent paired views, curated set library and unified player.
oh if it wasn't clear, also proceed with any deeper architectural changes as planned.
Codex · condensed
Separated session/physics ownership from viewport presentation and lazy exhibit loading. Added lifecycle, storage and rendering-budget checks around splitting views and switching sets.
Very nice overall, works great. just small nits:
1. the "Live/return to live" to the right of the speed slider changes width so it moves the speed slider; I think make the speed slider/label centered in the bottom bar so it doesn't reflow with the button. 2. in firefox the speed slider background doesn't display/can't see the bounds; the center indicator works though. Maybe make the span from the center to the current scrubber a different color so it's more obvious is a bipolar control. 3. The inspector/sets buttons could use a collapse/expand or sidebar symbol to make it more obvios what they do 4. The 'Activity (down arrow)" could also use different styling so it's more obvious it collapses/expands the timeline; looks like a sort column header currently 5. The "about this set" in the bottom of the inspector is a bit too hidden; I think actually can move that about text to underneath the currently selected set in the menu, so it expands into a longer card; Also worth a pass to rewrite the set descriptions from the perspective of a viewer; some of them have weird technical detail from the prompts/bugs at the tim, like "continuous operation retains rolling history", that i don't think is interesting for a viewer. Also would be good to add clickable external links to wikipedia in the description for the concepts that the set illustrates e.g. 'lunar cycler' or 'lissajous orbit'. 6. the view switcher a bit confusing, how the button label changes to the primary view. I think if there's enough horizontal space for the viewer, instead expand it to the view/track/orbit button, and actually move 'surface view' as 'surface' in the view selection menu. 7. The potential map/relief modes are only available in the lunar cycler set at the moment, would be good have available for the rest of the planar sets. 8. the 'lunar ground service' calls the planet just 'Planet' vs Aster. 9. on some sets in firefox like mars cycler, the frame selector dropdown for a view flickers, like its dom element is being reflows every frame; even when the set is paused. 10. The 'mars cycler' set could also use a fictional reskin, and some nits like 'wayfarer - powered cycler' clutter the labels; and the scale of the bodies could be improved like a bigger yellow sun/bigger jupiter (still orrery scale though, not fully realistic) 11. inspector and sets sidebar should be resizable.
Codex · condensed
Stabilized centered playback controls and native Firefox dropdowns, added sidebar sizing and clearer disclosures, moved set descriptions into the library, generalized planar fields and reskinned the solar cycler.
I'm not sure how best to test the firefox issues. it is installed locally so maybe could boot up a clean profile with remote control or remote debugging enabled.
Codex · condensed
Added an installed-Firefox smoke test using an isolated temporary profile, keeping the owner’s ordinary browser session untouched.
nice, these changes work well. Remaining nit is in the 'Camera' menu, change the view or track dropdowns to radio/exclusive selection button panels, so you don't need to click again to open the submenu.
Otherwise quite nice on the viewer. I think we can move to implementing a scaffold for the intro/landing page as discussed before, with a lightweight quick loading visual, brief gloss of features, and an about/FAQ style section covering level of simulation detail/caveats/inspiration/impl; for the main page, draft these sections to test the layout but I will rewrite the final copy in my own words.
For final publishing I think I want to put this at `orbital.hiina.space` using cloudflare pages.
Personal CLI authentication and unrelated deployment details omitted.
Codex · condensed
Replaced Camera dropdowns with native exclusive radio panels. Built a separate lightweight public entry with an offline-sampled cycler preview, while keeping viewer workers and large fixtures out of its dependency graph.
fwiw I don't think we need to maintain the strict compatibility with the #set hash links; and MPA might be a better design there, like orbital.hiina.space/viewer or something; though don't take my exact word for it, i'd research general best practices for how to set this style of app/landing up with vite.
Codex · condensed
Used Vite’s multi-page pattern: the article at the root and a separate viewer document at /viewer/, with relative assets and static-hosting navigation checks.
Cool, pretty nice overall in covering what I want it to. main complaint is it's a bit too producty in presentation still. I think I want it to read more like a blog post or nerfies-ish research paper page or itch.io page, so more linear markdown, some smaller embeds or screenshots of the viewer in the various modes to show off the features like split screen and relief/rubber sheet, and no accordion on the the FAQ questions, just prose instead.
Codex · condensed
Replaced the marketing-style sections with a single reading column, a smaller animation, real split-view and relief screenshots, plain exhibit links and always-open simulation notes.
ok, I did my rewrite pass of the landing page, can you check it for any typos or omissions? I think I got the register in the style I want but might've missed something. Besides that, I'd also like the "Open Viewer" link to be more prominent, maybe as an "Action button" still since it's a little subdued currently.
Codex · condensed
Proofread the owner-written article without replacing its register, clarified a few claims and made Open Viewer a prominent action. The source-publication check found the repository private and unlicensed.
oh yea, for the license, I intend it to be Unlicense, but MIT or whatever is fine too if the libraries would fit that. Please do a quick review too for general publishability of the project; I think it should be fine but if anything particularly sensitive or nonpublic needs to be scrubbed can do that. Actually that reminds me another interesting thing actually might be a condensed form of this implementation transcript, with my owner messages and a condensed summary of your implementation work and responses as a separate page. This won't be interesting for everyone, but can put a link in the section about implementation that the "prompt source code" might be more interesting to human viewers (or agent viewers) for how I built this.
Codex · condensed
Added the Unlicense and retained third-party notices. A reachable-history review found unrelated private context in raw review logs; scrubbed their current-tree bodies and documented a clean-snapshot source-release boundary.
Hmm, I think given the target audience more "nearly every exchange". but can elide stuff like environment technical issues where openai was down or my computers were down.
Codex · condensed
Expanded the public transcript to include small feedback and unsuccessful iterations as well as major decisions. Omitted environment-only interruptions and marked private operational passages removed from otherwise retained messages.
for the transcript view there are some others like simon willison who also publishees their fairly "raw" transcripts on the web. that might be a good source for how to format it.
Codex · condensed
Used numbered prompt links and a chapter index, inspired by Simon Willison’s published transcripts. Generated static HTML and a Markdown download from the reviewed content, with no client-side transcript renderer.