99030e4aacd356f8c66aecc7add3e2c4757dff17
134
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CydandClaude Opus 5
|
99030e4aac |
The track plans are the map screen's own drawing
The first version of these plans was a scatter of scenery positions - an
impression of a track rather than a picture of one. The game already draws
the real thing: the map screen in the pod renders the track from above every
race, so the plans now reconstruct that instead of approximating it.
NavDisplay::DrawStatic walks the static entities, looks up each one's
L4GaugeImage by resource id, and draws it through localToWorld x
worldToView. navmap.py does the same offline. The pieces that made it
possible:
- a map instance carries its model's GaugeImage id at +44, beside the
position at +48 and the quaternion at +60;
- a GaugeImage is a vertex array plus per-LOD polylines through it, in
world units - cn3 is an 89x5 wall segment, pit1 a 500x300 pit;
- a placement whose model has no gauge image is skipped here exactly as
DrawStatic skips it, which is why a card can report fewer placements
carrying map art than the track contains.
The difference is not subtle. Wiseguy's Wake and Paingod's Passage resolve
into twin canyon walls running their length, Brewer's Bane into an L-shaped
route through junction chambers, and both arenas into a lattice of obstacles
inside a boundary wall. What is still missing is the driving surface: the
map draws what lines the route, never the tarmac.
tools/pages/navmap.py carries the reader, and the README documents both the
instance record and the gauge image stream. Regenerating from the committed
generators reproduces the committed page byte for byte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
6c3127a94d |
Every track, seen from above
docs/tracks.html joins the roster page: all 18 tracks with a plan view, what the console calls them, which scenarios offer them, and how big they are. There are no track maps in the game's files. The console had pictures of them and those pictures did not survive - RPConfig.xml still points at "images/red planet maps/Wiseguy's Wake.bmp" and the folder is gone. So the plans are drawn from the tracks themselves. A map's instance stream places its scenery: 76-byte records carrying a position at +48 and a unit quaternion at +60, a few of them longer, so the reader resyncs on an unexpected class id rather than trusting the stride. The quaternion doubles as a checksum - a mis-read almost never yields a unit one - and 17 of the 18 decode every instance the header promises. Trough gives up 631 of 633 and the card says so. Seen this way the tracks have obvious shapes: Brewer's Bane turns two corners, Tour De Mars is one 23,000-unit run, and both arenas are a regular lattice of obstacles rather than a route at all. The eras come from the resource-file archaeology rather than a guess: 9 tracks shipped in the 4.10 cabinets, headoff and headmf arrived with 4.11, and 7 were built by the community afterwards. Scenario legality is read out of the front end's own kMaps and kFootballMaps, so the page cannot claim a track is offered when the menu does not offer it. tools/pages carries the generators for both reference pages, with a README covering the two formats they read and the id-alignment the listing is needed for. They were scratch scripts until now, which made a committed page harder to regenerate than to rebuild by hand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
6df309e9c4 |
Vehicles and hulls get the names the console gave them
The roster page called vehicles by their resource key and hulls by their two-letter art code - PUCK, "Hull PA". TeslaConsole's RPConfig.xml is the only place either is named in words, so it now supplies both: the card says ARMADILLO with the key beneath it, and the hull says "Armadillo hull" rather than "Hull PA". The class comes from the picture the console showed for each machine, so vehicles sharing a picture share a class, and each hull is named by majority vote of the vehicles drawn with it - one mis-set picture cannot rename a whole class. Which matters, because two are mis-set: the console shows a Bug picture for Blacker Broccoli and Blacker Tarantula, while the game draws them on the Mule and Bull hulls. The page says so on those two cards instead of quietly picking a side. Every other vehicle agrees. RPConfig.xml and RPStrings.xml are copied into tools/console-config: the front end's catalogs already came from them by hand, the roster page reads them now, and they were only living inside the airlock archive. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
17bbcb2049 |
Every VTV on the roster page, resolved by id
The page listed 34 of the 38 vehicles in the resource file. The four missing were community variants, and I had written down that they shared another vehicle's mapping streams. They do not - they have their own, of 17 to 33 records. The decoder just could not find them. Streams are stored as resources named plainly L4 and Thrustmaster, so nothing in a stream says whose it is. The old decoder guessed by taking the nearest preceding vehicle name in the file, which works while vehicles are laid out one after another and fails quietly when they are not: it lost vole outright and mis-attributed four blkr variants. The file answers exactly if asked properly. A vehicle's ControlsMappings List holds the resource ids of its two streams. Ids are not quite positional - this file leaves 53 and 56 unassigned - so the directory walk is aligned against RPL4TOOL -l, skipping the ids the listing marks Not Used. That gives 1077 ids with zero size mismatches, and every stream lands on its owner. Subsystem names now come from each vehicle's own Stream of N Subsystems, checked against the count in its header instead of being pattern-matched out of the bytes. Nothing already verified moved: lepton, dark, blkspk and neut decode exactly as they did when checked against the 4.10 retail file, blkspk still putting its third booster on the thumb-high in preset 4 and dark still spending preset 5's HORN slot on its second demo pack. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
b3ed7bc141 |
The drop-down boxes stop being Windows-coloured
CBS_OWNERDRAWFIXED only hands over the item area, so while the list rows came out green on black, the closed box kept the system's frame and drop arrow - a white/grey Windows control sitting in the middle of a black panel. The closed box is painted here now: black field, dim green border, bright green text, and a plain green triangle instead of a themed button. The control keeps doing everything else, including dropping its list, so this is a subclass over WM_PAINT rather than a reimplementation. Still system-drawn: the scrollbar inside a dropped list, which only appears on the two lists longer than twelve rows - vehicle and track. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
44f5a2c6fd |
The pilot name heads the loadout column
It was tucked under the vehicle and colour boxes, which put the one field you type into below three you only click. It now sits at the top of the second column: who you are, then what you are driving. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
3ed6498183 |
The setup menu picks from drop-downs
Every list group is a combo box now: track, time, weather, length, vehicle, and colour/badge or team/position. Scenario stays as visible buttons because it decides what the other lists contain, so it should not be hidden behind one of them. This ends a problem I had been solving the wrong way. The menu was flat lists of everything, which was fine when the content was short enough to see at once - the quality that made it feel like the pod panel. The promoted resource file roughly doubled it, and I answered with two columns, then better margins, then a general column flow, each time keeping an idiom whose justification had already gone. Eight controls replace ninety-odd rows. At 800x600 the columns go from 131px to 323px, so nothing ellipsizes any more - the longest name wants 158. The whole menu now needs 310px of the 492 above the buttons there, and 529 of 900 at 1080p, so adding vehicles or maps cannot crowd it again. The boxes are owner-drawn - green on black, highlight inverted rather than tinted - so they read as part of the panel instead of arriving in system colours. They are rebuilt rather than moved when the scenario changes, since it swaps two of them outright and reshuffles the track list. Built and run at 640x480, 800x600, 1280x720 and 1920x1080. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
da7f675cca |
The setup menu flows into as many columns as it needs
I fixed the wrong column twice. The overflow was never the vehicle list: it was the settings column - scenario, map, time, weather, length - which sat within 11px of the bottom at 800x600 before any of this, and went 115px past it once seven maps were added. At 1080p it wanted 1174 of 1080. Fixed columns cannot hold this menu any more, so the groups flow: they fill a column, start the next, and the layout takes as many as the content needs, sizing them to share the width. Two passes - one to count the columns, one to place the items - so nothing has to know the count in advance. Adding a map or a vehicle can no longer push anything off screen, which is the actual property that was missing. Every column starts two rows down so the pilot name box has the same home whichever column ends up last, and the bottom is reserved for LAUNCH and the lobby buttons. AddGroupItems is gone; the flow places items directly. Verified by arithmetic at 640x480, 800x600, 1024x768, 1280x720 and 1920x1080 in both scenarios - nothing exceeds its width or its bottom - and by running the front end at four of those plus a mission at 800x600. 800x600 is honestly dense: the content genuinely needs five columns there, and the longest few names ellipsize. Lowering the row-height floor does not buy a column back, so the rows stay at 18px and legible. Dropdowns would end this class of problem outright and are worth considering. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
ff0e98a7a5 |
Four columns get margins that suit four columns
The wrapped layout inherited the three-column fractions, which are generous for three and wrong for four. At 800x600 that put the last column hard against the frame - 19px of slack across the whole right edge, with the longest vehicle name needing all but 2px of its 160px column. The wrapped case now spreads its four columns evenly on its own margins, and the unwrapped case keeps the proportions it always had. At 800x600 the columns go to 168px with 40px of slack; 1024x768 and 1280x720 land comfortably too. 640x480 cannot be made to fit: four columns of long names want more width than there is, so names there are drawn with an ellipsis rather than sliced through a glyph. That applies everywhere, so any window too narrow for its content degrades the same readable way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
cf90698159 |
The vehicle list wraps instead of running off the bottom
Adding eleven vehicles to the setup menu made the column longer than the window. At 1920x1080 it used to end at 994 against a 1080 client and now wanted 1324, so the bottom of the list was simply off screen - and the rows cannot shrink to absorb it, being already at the 18px floor that keeps them legible. The list now wraps across two columns when it does not fit, split evenly rather than filled-then-spilled, and the loadout column - colours and badges, or team and position - moves one place right along with the pilot name box and the launch, host and join buttons. A roster short enough for a single column lays out exactly as it did before, so this only changes the screen when it has to. Four columns still fit the width everywhere we ship: the right edge lands at 623 of 640, 1250 of 1280 and 1877 of 1920. The tallest column is 19 rows, ending at 428, 502 and 754 against those clients. AddGroupItems grows a 'first' argument so a group can start partway through its own list. The items stay contiguous in fe->items, so the header still draws once above the first of them, and each item keeps its true index - selection and hit-testing already work off item->index rather than position. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
3ba79476fc |
The setup menu offers the vehicles and maps that came back
The front end's catalogs are hand-written from the console's RPConfig.xml, and the promoted resource file brought content they did not know about. Eleven vehicles added - dark, blktrn and neut, which the console names Blacker Puck, Black Tarantula and Neutrino, plus the eight community Blacker variants - and seven maps, keeping the console's own convention of bracketing non-arcade tracks in dashes. The football map list is deliberately untouched. The console config has its per-scenario invalid lists commented out, so it says nothing about whether the new tracks are football-legal, and guessing would put players on a map with no scoring zones. A note where the catalog is declared, not a check: validating the keys against RPL4.RES at menu time crashes, because the front end runs before the resource file is opened and GetResourceFile has nothing to search yet. That drift is real - this menu offered blkspk for a while before any vehicle resource backed it - but the place to catch it is offline against the built file, not in the boot path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
f7c7000694 |
The cut vehicles come back, and eight more besides
assets/RP411/RPL4.RES is now the 1.25MB resource from the airlock archive, a 2014 community build, replacing the 785KB file RP412 inherited. It verifies as a strict superset of ours: nothing is lost but two unnamed Not Used placeholders, the format version matches, all 26 base vehicles' L4 and Thrustmaster mapping streams are byte-identical to the ones we shipped, vole matches resource for resource, and it boots against our own GAUGE, VIDEO and AUDIO with a log identical to the baseline. Its L4GAUGE.CFG comes with it. That file is ours plus the new vehicles' blocks and one fix: dragonInit gains twoBoosterInit, so the dragon's two boosters finally have gauges - it always had them in its subsystem list and the panel simply never drew them. dark, blkspk and blktrn are back with the tables they shipped with in 4.10, checked against the retail file: blkspk still puts its third booster on the thumb-high in preset 4 alone, dark still spends preset 5's HORN slot on its second demo pack. The archive also brings neut, a four-booster Lepton class with an Eject subsystem, eight community Blacker variants and seven maps. The black mystery turned out to be a renaming bug rather than a vehicle that never existed. RP411's gauge config carried a blackInit block nothing could select, because the lookup is <model>Init and no model is named black. The airlock config calls the same block - byte-identical body - blktrnInit, which is the model's real name. disk is now the only genuine orphan: a panel layout with no vehicle behind it in any resource file, and no entry in the console's own config either. The roster page regenerates to 34 vehicles. Four of the eight community variants have a ControlsMappings List but no streams of their own, pointing at another vehicle's by id, so they carry no preset table and do not appear. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
8e2e00d8d3 |
The resource pipeline builds again
RPL4.RES is compiled from authored sources by RPL4TOOL -b, the original 1996 resource tool, which still builds in this tree. That pipeline did not work: the tool aborted on the very first model, so the resource file could only be consumed, never regenerated. Content could not be changed at all. It died in PlugStream_FindEntryAndWriteObjectID resolving resource= Translocation01 from AUDIO/PLYINT.SCP, a name defined in no file under CONTENT/RP. The obvious suspect was the AWE32 soundbank path, since AudioCard::LoadSBK is stubbed to return 1 by the Win32 port - but that is a red herring. Supplying the banks changes nothing because nothing reads them at build time. CreateStaticAudioStreamResource opens audio\static.scp, which declares all 154 patch resources as plain text mapping each name to a bank and patch number, and CONTENT/RP simply does not have that file. The sda4 developer drive does. Two more scripts included by 27 vehicles, VTVINT.SCP and VTVEXT.SCP, were missing the same way. All three are kept in recovered/ because they are the keystone and are small. No engine change was needed. The pipeline was missing content, not code. build-res.ps1 assembles a build tree from the 4.10 content, those three scripts, and the soundbanks and ~547 VIDEO files that RP412 ships complete and the content tree does not. It never overwrites an authored file with a shipped one, so archival content stays authoritative where it exists. A model missing a skeleton is dropped SILENTLY - the tool logs and carries on, producing a resource file with fewer models rather than failing. Check the model count, which is why the script reports unresolved inputs. -RestoreCutVehicles uncomments dark, blkspk and blktrn, three vehicles taken out of the .bld after 4.10 shipped with their model ids left in place. All three build clean and take the count from 42 to 45, exactly retail's, each with its full subsystems, segments, damage zones and control mappings. What this cannot do yet: eleven maps have no source. Five survive only on the sda4 drive in a 1996 state older than retail, and otto, frstrm, burnt, brewers, headoff and headmf are gone entirely - the .CAM cameras and .XST existence boxes are here but the .MAP files are not. So a build from these sources yields 45 models and zero maps against RP411's nine, and is not yet a drop-in replacement for assets/RP411/RPL4.RES. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
cf59ac9f4b |
Every VTV and its presets, in a page that ships with the game
VTV-PRESETS.html joins the handbook in the dist: all 26 racable vehicles, each with its hull plan view, what it carries, and the six control presets on its stick. The data is decoded from RPL4.RES rather than transcribed - each vehicle's own subsystem list names its systems, and VTV::BasicSubsystemCount fixes list index i as subsystem 9+i, so every subsystem id in all 26 mapping streams resolves with nothing left over. The gauge config could not have been used for this: it is only artwork, and it lies. The dragon has boosters and a chute with no art declared, and the burro's chute sits in a different panel slot than sequence would suggest. Both come out right this way. The plan views are each vehicle's own damage-gauge silhouette, redrawn from the three-colour original as an alpha mask so it takes the page's colour in either theme. There is no per-vehicle art to use instead: vehicles are grouped into hull families that share both the silhouette and the mesh in VIDEO/, which is keyed by the same two-letter code. Each card says which hull it is and who else races the same one. The page does not mention the intercom PTT. Its hardware never went past prototype cockpits, so naming a control nobody can press would only raise questions; those cells are simply blank. CONTROL-PRESETS.md carries the full account, because anyone re-decoding the resource will find message ID 13 on the pinky and needs to know why the tables show it empty. Two things in the shipped assets settle it: the tool panel's fourth quadrant is bare where every other system has a legend, and the two finished intercom station screens are referenced by nothing at all. The edge strips are referenced - but gated on ModeIntercom, which nothing ever sets, so they have never been on screen either. The block that would have wired the buttons is inside #if 0 and still names L4ModeManager, a class that no longer exists: cut before the RPL4ModeManager rename and never revisited. The doc also now explains the mode-mask gate itself, since that is what makes the dead intercom legible: one 32-bit word, seeded 0x201, read by both the controls dispatch and the gauge renderer's active/inactive sorting. A drawable whose bit is never set is parked in inactiveList for the life of the process and never complains. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
05f993b9aa |
Picking a preset no longer blinds the mode lamps
The six PRESET switches down the map's right flank stored their lamps in modeLamp[], which holds four. Indices 4 and 5 ran off the end into presetLamp[0..1], so the whole thing stayed self-consistent by memory layout and nobody noticed - but it overwrote the four control-mode lamps made moments earlier, and BASIC/STANDARD/VETERAN/MASTER on the upper-right MFD were never lit again. presetLamp[], meanwhile, went unused. The preset pass now fills the array it was always meant to, and the lamp work moves out of the switch handler into a virtual NotifyOfPresetChange that PresetEnable announces itself. That closes the second gap in passing: keyboard 1-6 changed the mappings without touching the lamps, leaving the flank showing a preset that was no longer in force. Both routes now go through one place. The lamp arrays are also cleared in the constructor - only the mapping loops ever filled them, and NOMODES skips those. Verified by dumping the commanded RIO lamp states out of the running game (PadRIO, TEST.EGG, at rest in Basic mode). Before and after are identical except lamp 0x33, BASIC, which goes from 14 dim to 3c lit. The preset lamps are unchanged: they worked by accident, and now work by construction. docs/CONTROL-PRESETS.md is the research behind it. The presets are not a map feature at all - each is a complete factory layout for the four mappable stick buttons, one mode-mask bit apiece, with all 26 vehicles carrying their own six-preset table in RPL4.RES for both the pod RIO and the Thrustmaster. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
f83f56e14d |
Stop sending expired testers to an empty page
Both the README and the dialog an expired build puts up pointed at the Gitea releases page for the next build. That page is empty now - releases come through another channel - so in a fortnight's time the one message a tester is guaranteed to read would have sent them somewhere with nothing on it. No address in its place: whoever handed them the build is who to ask, and a URL that goes stale again is worse than no URL. The Source: line stays, because the repository it names is still there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
f44cdbacca |
How a hit becomes lost armor and lost score
The damage model, end to end, read off the authentic surviving RP source (VTV.cpp, WEAPSYS.cpp, RIVET.cpp, DEMOPACK.cpp, RPPLAYER.cpp) rather than inferred. Companion to the BT doc of the same name; the shared engine layers are the same and only summarised here. The finding it is built around: RP's damage model is a physics and score economy, not a subsystem-failure simulation. One armor pool at zone 0, no criticals, no per-zone cascade. Collision armor is not authored at all - it is calibrated from the vehicle's own mass and MaxImpactSpeed so that a full-speed hit spends exactly the whole budget - and deathConstant converts damage to score at that same exchange rate. Every point of damage is simultaneously a transaction between two players, through a two-second revenge window. Martian football, not a mech duel. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
303758cb52 |
Testers' crash dumps stay out of the history
Crashdmp\ is where a dump sent in by a tester lands. Read it with cdb against the matching Release\rpl4opt.pdb - the PE timestamp recorded in the dump says which build it came from, and the symbols mean nothing unless it matches. Not tracked, because a minidump is not ours to keep: it carries process memory and the sender's own file paths. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
12f9ebefab |
A quiet sound at the wrong distance no longer kills the game
From Nathan's crash dump: an access violation reading 8093e920, fourteen minutes into a session, on 4.12.115. rpl4opt!PatchLevelOfDetail::SetupPatch+0xbb rpl4opt!Static3DPatchSource::StartImplementation+0x50 rpl4opt!AudioRenderer::ExecuteBackground+0x9e The faulting instruction is g_buffers[index] with index = 0x20000000 - 536 million - and the array base in eax at 0093e920, which is exactly the address it died on. So the index was garbage, and the dump says where the garbage came from: the stack slot holding info.bufferIndex. PRESET_getSampleInfo builds a SAMPLEINFO to return when it is asked for a zone the preset does not have. It sets chan, file, implemented and loop - and not bufferIndex. Every caller tests bufferIndex >= 0 before using it, so "no such zone" was meant to be rejected there; instead the test read whatever was on the stack, and passed whenever that happened to be positive. AL_getBuffer then indexed the array with it, unchecked. Why it asked for a zone that is not there: the loop runs to sourceSet.count, which was fixed when the audio source was built, from whichever level of detail was selected at the time. SetDistance re-picks the level of detail by distance on the line immediately before SetupPatch runs, and the zone counts across the recovered banks are nothing like uniform - of 200 presets, 46 have no zones at all, and the rest run 1 to 4. So a sound that moved far enough to drop to a quieter patch could ask that patch for a zone it never had. In the dump: count 3, died asking for zone 2. Fixed at all three levels, because any one of them alone would have held: the default carries bufferIndex = -1 so the existing guard works, AL_getBuffer returns AL_NONE rather than reading past its array, and SetupPatch asks for no more zones than the patch it is actually using has. Verified: the dump's own numbers reproduce arithmetically, and two full races run clean. The distance-dependent trigger itself was reasoned from the dump rather than reproduced here - it needs a sound to cross a level of detail boundary into a shorter patch - so the belt-and-braces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
a417175da8 |
The handbook explains why the sound changed
The volume and bass keys were not on the keyboard diagram, and nothing told a returning player why the game suddenly sounds different. Adds a short section on what came back out of the original soundbanks - pitch, the missing layers, distance, reverb, doppler - written for someone who wants to know why their collisions have weight now, not for someone reading the source. It closes on the knobs, because "it is too much" is a fair reaction and the answer should be next to the explanation. PgUp, PgDn, Home and End now light up on the keyboard diagram in their own colour, with a legend entry, rather than sitting there as dead keys. And volume.cfg and bass.cfg join the list of files in the folder that belong to the player. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
943a15cef4 |
A second race no longer takes the stack with it
Reported by a tester and reproduced here: finish a race, come back to the
lobby, start another, and the game dies a few seconds in.
It is a stack overflow, from CockpitShellProc calling itself. The cockpit
subclasses the game window to catch WM_SIZE and re-fit the canvas, and
kept SetWindowLongPtr's return as the proc to chain on to. But the game
window is not the cockpit's - it outlives it, and carries the console
screen from one race to the next - and nothing ever unsubclassed it. So
the second race subclassed an already-subclassed window, SetWindowLongPtr
handed back CockpitShellProc itself as the "original", and from the next
message onwards the proc chained to itself until the stack ran out.
Nothing in the log, because nothing in the game had gone wrong yet.
So the destructor puts the window's own proc back, and the install site
will not subclass the same window twice even if it could not.
While there: the destructor also left activeCockpit pointing at the
object it had just freed, so GetCockpit() handed CockpitShellProc a dead
cockpit to lay out. Harmless until someone resized or maximised the
window at the lobby between races, which is not a hard thing to do. Now
cleared.
This came in with the cockpit resize work in
|
||
|
CydandClaude Opus 5
|
cdccb16251 |
Keep AUDIO.RES; a Windows ? matches nothing too
The bank exclusion used AUDIO?.RES, which also swallowed AUDIO.RES - the one-byte stub that has been in the audio folder since 1995. A '?' in a Windows wildcard will match zero characters, not just one. Name the two banks instead of pattern-matching them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
a5faa6cf9b |
Stop shipping seven megabytes nobody reads
The original AWE32 soundbanks are the source the shipped sound effects are generated from, and they belong in the repo for that, but the game has no use for them at run time - the LoadSBK path died with the sound cards and AUDIO.INI's [AudioResources] section is commented out alongside it. They were going into every download regardless. Also drops four wav files that nothing references: two leftovers named temp, one of them empty, and two stale zone files orphaned when the preset table was regenerated from the banks. Together about 8MB off the package. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
25e25260b1 |
Home and End are the bass knob
The volume keys wanted a partner, and the bass trim could not be one as it stood: it scaled the sample data as it loaded, so by the time anyone pressed a key the audio was already sitting in OpenAL buffers and nothing short of a restart would move it. So the trim is now a per-zone gain applied in the mix instead. Each buffer's depth - how much of the low band it occupies - is still worked out once at load from its playback rate, but the trim itself is read every frame, which is what lets Home and End move it while sounds are playing. It is the better form regardless: no rewriting of sample data, and no quantisation on top of audio that has already been through one gain stage. Home raises, End lowers, in steps of 0.05, and the setting is written to bass.cfg beside the exe exactly as the volume writes volume.cfg. Together with PageUp and PageDown that is the amplifier and the crossover the cabinets had in hardware and a desktop does not. Builds clean, runs, and neither knob fires unprompted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
4e8392fcfb |
PageUp and PageDown are the volume knob
The cabinets had no volume control - they ran at unity and left level to an external amplifier - so a player without that hardware had nowhere to turn it down but environ.ini and a restart. PageUp and PageDown now step the master volume by 0.05 while you play, from silent to double, and whatever you leave it on is written to volume.cfg beside the exe and used from then on. The environ.ini figure decides where a machine that has never been touched starts out; the keys are the knob, and a knob stays where it was left. Page keys because they produce no typed character, so they cannot collide with the character-keyed commands the engine already answers to, nothing else in RP binds them, and they are on every keyboard including tenkeyless. They are polled rather than read off the key-message path, which is worth recording because the message path looked like the obvious home for them and was tried first. RP's keyboard pump only takes WM_KEYUP, WM_SYSKEYUP and WM_CHAR off the front of the queue, and the front end runs message loops of its own, so key messages get raced for and lost: six deliberate, well-spaced presses arrived as two. Fine for the abort chord, useless for something you tap repeatedly to find a level. Reading key state directly costs nothing and cannot be dropped. That losses figure is a pre-existing property of the input path, not something this change introduced, and is worth knowing before anything else gets bound there. Builds clean, runs, and does not fire unprompted. The step function itself is proven - it was driven end to end through the message path before the switch, stepping the right way, clamping, and persisting. What I could not test from here is the polling trigger, because Windows would not hand the game foreground and injecting keys without it would have sprayed them across whatever else was open. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
523f713a30 |
Volume and bass knobs, for players without an amplifier
The cabinets ran the game at unity and shaped volume and tone outside it, in an external amplifier and a 3-way crossover. That is why there is no master volume anywhere in the original code and none in AUDIO.INI - an operator turned a knob on an amp. A desktop player has no amp and no crossover, and the recovered soundbanks are a good deal livelier than what 4.12 shipped with, so the game has to offer the two controls the pod got from hardware. RP412AUDIOVOLUME, 0.0 to 4.0, is the amplifier: a listener gain, which the port had never set at all. RP412AUDIOBASS, 0.0 to 1.0, is the crossover's low band. Both default to leaving the mix exactly as the pod played it, so neither changes anything for anyone who does not go looking. The bass trim is not a filter, and the reason is worth writing down: the OpenAL we ship is Creative's, not OpenAL Soft, and it implements only AL_FILTER_LOWPASS. It rejects highpass and bandpass outright. A bandpass would have been the tidy answer, carrying the authored brightness model on GAINHF and the trim on GAINLF across the single direct filter a source gets. It is not on offer. So the trim scales sample data as it loads, which suits how this low end is actually built: the weight lives in discrete deep layer zones whose per-zone tuning bakes out to a very low playback rate - thirteen zones below 8kHz, three to five octaves under their recorded pitch, against four fifths of the set at 22kHz and up. Baked rate is a dependable proxy for band, so pulling down the low-rate zones is a real low-band trim and not a blunt cut. It eases in below 22kHz and reaches full depth at 5.5kHz. Caught while building this, and the reason for the probe: EFX_Initialize checks alGetError after configuring the scratch filter, so asking for a filter type the driver refuses leaves an error pending and takes the entire bridge down - reverb included. The bandpass attempt did precisely that and would have silently killed the reverb and brightness work. Initialize now survives losing the filter and says so. Builds clean, runs with both knobs set and with neither. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
e133d4c993 |
Sounds recycle their voices instead of churning through them
Recovering the soundbanks took voice demand per sound from about one zone to about two and a half, and the audio path allocated an OpenAL source for every sound event and destroyed it again on release. Sources are a hard per-context resource - this driver grants 256 - so that churn doubled at exactly the moment it got more expensive. Sources are now generated once and recycled through a free list: measured, three sources generated across twelve thousand acquisitions. The BT tree reached the same conclusion the expensive way, from field logs full of failed acquisitions: raising the source budget is not the fix, because the ceiling also acts as a governor and more voices mixing is real CPU during exactly the busiest moments. Recycling is the fix, and it costs nothing. Two older bugs were sitting underneath, both reproduced against the driver rather than assumed: Releasing a set leaked it. alDeleteSources is atomic - one bad name in the array and nothing at all is deleted. ReleaseSourceSet handed it the whole fixed-size array and then parked the slots at -1, so any partial set, and any double release, leaked every source it held. Sources are now handed back one at a time and slots park at 0, which is never a valid name. A source set began life uninitialised. The constructor set only the count, and the acquire path decided whether a slot was already filled by asking OpenAL about uninitialised stack garbage. Garbage that happened to match a live name meant two sounds silently sharing one source. Pooling would have made that more likely, not less, since it keeps small names in circulation. Recycled sources are scrubbed before parking - stopped, buffer detached, looping, gain, pitch, relative flag, position and velocity reset, and the EFX filter and reverb send dropped. Without that last part a dry cockpit sound inherits the wet send of whatever 3D source held the name before it. Verified: a deliberately dirtied source comes back clean. Builds clean. Runs with memory and handle count flat. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
d361a0b8be |
The sound effects play at the pitch they were written at
Red Planet's original AWE32 soundbanks are back in the tree, and the game's sound effects are now generated from them instead of from an incomplete one-off extraction. AUDIO1.RES and AUDIO2.RES come from the 1996 release in the TeslaRel410 archive, hash-identical. AUDIO.INI has named them all along - they were simply never carried into the port. tools/rp_sf2extract.py reads them and regenerates both the WAV set and RP_L4/WTPresets.cpp, so the assets are reproducible from the banks rather than hand-maintained. Two things were wrong with the old set: Pitch. Every shipped WAV was flat 44100 Hz with the banks' tuning discarded, so 202 of the 219 zones played at the wrong speed - the worst by nine semitones. The EMU8000's per-zone root key and tuning are now baked into each file's declared sample rate, which is exact and needs no engine change. Layers that were meant to be deep now are: a collision sub-thud that lasted 18 milliseconds at the wrong rate is a 0.66 second one at 1228 Hz. Missing layers. 93 presets were short of zones and 176 were missing outright, 219 of 395. Nothing was lost recovering them - the 46 preset slots that disappeared were all empty placeholders. The old files were also over-read, running past the end of their sample into whatever PCM came next; WellheadDrill02a was six seconds where the bank says eight hundred milliseconds. Every one of the 395 files now matches its bank record exactly. Also baked in: per-zone layer attenuation, and the static resonant low-pass the EMU8000 applied in hardware. Measured while doing it, and worth knowing: RP's banks contain no key-splits at all - every multi-zone preset is a pure layer stack - and no preset has more than four zones, which is what the engine's own "AWE appears to only play 1st 4 voices" warning has been asserting since 1995. Still to do: loop regions and the release fades, which 349 zones ask for and which need new SAMPLEINFO fields. And voice demand per sound has gone from about one zone to about two and a half, so the per-event alGenSources and alDeleteSources churn roughly doubles - the BT tree measured pooling as the fix for that, and a CPU win besides. Builds clean. The extreme baked rates, 1228 Hz up to 88200, were checked through the real path - libsndfile, alBufferData, alSourcePlay - and all load. Not yet listened to on the pod. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
ce1b0ab9c3 |
Sounds fade, dull and doppler with distance again
The OpenAL port kept the whole authored audio model and then threw most of
its output away. Every frame the engine computed a distance-attenuation
curve, a high-frequency rolloff, doppler cents, a reverb level and a
front/rear placement, and every one of those consumers had been commented
out when the two AWE32 cards were replaced. What reached the speakers was
OpenAL's own defaults instead: a straight-line fade to silence, no
filtering, doppler at the wrong constants with an inverted velocity, no
reverb, and every cockpit sound dead centre.
Restored, per AUDIO.INI, which is byte-identical to the file that shipped
in August 1995:
- the authored knee/rolloff distance curve, replacing AL_LINEAR_DISTANCE.
This also un-blinds the transient cull, the voice-steal weighting and
the mix ducking, which all key off it and were treating far sources as
full presence
- the CC7 squared volume law; writing the scale linearly ran everything
about 6 dB hot at mid-scale
- brightness and distance muffling, and the wet-exterior/dry-cockpit
reverb split, both through a new OpenAL EFX bridge
- doppler on the moving-source path only, as the original had it
- front/rear placement from the authored position enum
The larger find is that AL_PITCH was never called anywhere in the tree, so
the entire pitch chain was inert - not only doppler but pitch_mix_offset,
which our own sequences author 97 times. Doppler alone would have changed
nothing audible.
Note pitch is applied for parity with the BT engine but is identity here:
our content predates NoteAudioControlID, so every source runs at note 60.
Builds clean on VS2022 Release|Win32. Smoke-tested against vRIO on COM1 -
reaches gameplay and holds a steady frame loop. ALC_EXT_EFX is present on
the build machine with all nine entry points, so the filter and reverb work
is live rather than inert. Not yet listened to on the pod, which is the
real test: the volume law changes the level of everything.
docs/SOUND.md documents the original two-card quadraphonic design, where
the surviving original assets are, and what remains.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
6ce729bab5 |
Lit cockpit buttons keep up with the sim
BT411's f99003c, brought across. Its playtesters reported the cockpit lighting going slow or stopping altogether while the 3D view stayed smooth, and RP412 has the same structure exactly: the on-screen vRIO buttons light themselves from PadRIO::GetLampState, but what FILLS that store is lampManager->Update() in GaugeRenderer::ExecuteForeground - once per full gauge cycle. Which is the cycle the previous commit was about. Measured on a starved frame budget it now completes 3.1 times a second, and completed 0.7 times a second before that; either way far too slow to carry a flashing lamp. So sweep the lamps once per frame from the main render instead, which runs regardless of how little frame is left over. It is cheap, and AssertNewLampValue already drops anything unchanged, so this pushes no extra traffic - it only stops changes arriving late. Only when a PadRIO is active, i.e. cockpit-less play, and only while a mission is actually running. With real serial hardware selected the pod keeps its authentic bandwidth-paced cadence, untouched. RP412LAMPSWEEP=0 restores the once-per-cycle behaviour. BT411's other half, 02ce9f5, does not apply. That one is about Windows throttling WM_TIMER and paint messages for background windows, which made the glass panels' flash crawl whenever they did not have focus. RP412 has no timer-driven repaint anywhere - the MFD windows are D3D devices presented from SVGA16::Update, and the panel strips repaint from there too - so there is no throttled message path to bypass. That path was starved rather than throttled, and the previous commit is the fix. Verified: no regression at either budget, 20.0 display sweeps/s at a normal frame budget and 3.1/s starved, both unchanged by this commit; mission runs clean. The lamp win itself is structural - the sweep is now an unconditional per-frame call - and would want a busy multiplayer mission to see directly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
f4fef29428 |
The map keeps drawing when the view gets busy
Two testers reported the map and the countdown clock freezing, one of them only on larger, more complex maps, and one of them until a death. Both details point at the same place. The gauges and the cockpit displays are redrawn in whatever time is left after the 3D view. The background loop is guaranteed a single pass per frame and gets more only while time remains before the frame is due, and one pass drew exactly one gauge. So a full sweep of ninety-odd gauges needed ninety-odd passes - free when there is spare frame, but on a busy map the 3D view eats all of it, the loop drops to its one guaranteed pass, and a sweep takes ninety-odd FRAMES. Seconds. A death makes the renderer skip every static object, the budget frees up, and the backlog drains at once: the display appears to come back to life. Worse, the copy phase that follows ended after a SINGLE display, so the map - one of three - came round only every third sweep. So: draw gauges to a 2ms slice rather than one per pass, which ties the refresh rate to elapsed time instead of to how much spare frame there happened to be; and copy every display before reporting the sweep done. Measured on a deliberately starved frame budget, which reproduces the reported symptom: 0.7 sweeps/s before, 3.1 after. At a normal budget 20/s, against 18-19 before - no cost to the healthy case. RP412GAUGESLICE tunes the slice and 0 restores the old behaviour, which reproduces the 0.7 exactly. RP412GAUGEDIAG=1 logs the rate; watching the screen cannot tell a display that has stopped refreshing from one whose picture simply is not changing, which is what made this hard to see. Also fixes the constructor calling Update() three lines before it initialised mDisplayToUpdate, so the first pass indexed the D3D device and surface arrays with whatever was on the stack. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
eb17220dd5 |
Test builds go stale after a fortnight
A tester still racing a two-week-old binary reports things that were fixed a week ago, and the afternoon spent chasing them is gone. An expired build now says so and stops: a dialog naming its version and expiry date, pointing at the releases page, and an exit before anything else runs. The log carries the same line, so a report from an expired build identifies itself. $expireDays at the top of stamp-version.ps1 is the shelf life, sitting next to the product line it belongs with. It counts from the day a build was MADE rather than the day the code was written - rebuilding an old commit to chase something should hand back a usable binary, not one born stale. SET IT TO 0 FOR A REAL RELEASE. A shipped build that expires is a catastrophe, and that one line decides it. It is called out in the script, in the generated header and in BUILD.md, because it is the kind of thing that gets noticed exactly once, too late. The date is what makes rpl4build.h differ from one day to the next, so the first build of each day recompiles RPL4.CPP and the rest do not. This is a nudge, not a lock. The date comes from the machine's own clock and anyone determined can wind it back; the point is to stop an honest tester wasting a day, not to stop anybody at all. RP412NOEXPIRY=1 waives it for us and logs that it did, so a waived build is never mistaken for a current one. It is deliberately absent from environ.ini - a bypass every tester can see is a bypass every tester will use, and then it never goes stale for the one person it was meant to stop. Verified all four ways by backdating the shelf life rather than touching the clock, which is what a negative $expireDays is for: a fresh build runs untouched; an expired one raises the dialog, exits 1, and logs "Build expired on 4 August 2026 - refusing to run"; the same expired build with RP412NOEXPIRY=1 runs and logs the waiver; and a build with two days left runs and logs two days left. Two things that only showed up by running it. Negative days first meant "never" rather than "already expired", so the refusal path went untested on the first pass - only 0 means never now. And the days-left count was anchored at midday, reporting one day fewer than the build had; it is anchored at the end of the expiry day, which is the rule the check actually enforces. The packaged README tells testers the build expires, where to get the next one, and that unzipping it over the folder keeps their four files. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>v4.12.103 |
||
|
CydandClaude Opus 5
|
8ba2d4fc86 |
Zipping a release no longer costs you your own settings
The file-preserving repack landed with the restore before the zip and skipped entirely under -Zip, to keep somebody's callsign and key bindings out of a release. It worked, but at the price of -Zip quietly wiping the settings out of dist\ - captured, then discarded. Both properties are available at once by moving the restore after the archive is taken: the zip is built from a folder with none of the player's files in it, and they go back into dist\ immediately afterwards. A fresh unzip still looks like a first run, and cutting a release costs the person cutting it nothing. Verified: edited all four files, packed with -Zip, and confirmed the archive contains none of them - 1003 entries, nothing loose at the root - while all four are still in dist\ with their edits intact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>v4.12.102 |
||
|
CydandClaude Opus 5
|
a0a0ad51d1 |
Repacking dist keeps the player's files
The game stopped shipping environ.ini so a new build could land on an existing folder without replacing anyone's settings. pack-dist.ps1 then went on rebuilding dist\ from nothing every time, which threw away environ.ini, bindings.txt, pilot.cfg and mfd_layout.cfg on every repack - the one place the promise did not hold, and the folder we do most of our own testing in. They are now carried across the rebuild. -Fresh wipes them too, for checking what a genuine first run does. Restored last, after the tree is rebuilt, so nothing the pack writes can land on top of them. Not restored at all under -Zip: the archive is taken from dist\, so a preserved file would otherwise travel to whoever downloads the release, and a release should always be built from a folder with none of them in it. Also fixes three paragraphs of the packaged README that have been saying the opposite of the truth since the change: that environ.ini ships, that it is the only one of the four that does, and that bindings.txt is the only one never overwritten. Those edits were made at the time with PowerShell .Replace() calls that silently matched nothing - which is exactly why the same corrections here are made with an editor that fails loudly instead. Verified by editing all four files, repacking, and reading the first line of each back out of the rebuilt folder; then again with -Fresh to confirm all four are gone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
82e733c1a6 |
Replicants reckon from when an update was sent
Simulation::ReadUpdateRecord threw away the sender's timestamp and
stamped lastUpdate with its own arrival time. The line carried the
original authors' own note: "HACK - should be based upon
message->timeStamp".
The dead reckoner extrapolates a replicant over
(lastPerformance - lastUpdate), so starting that clock at ARRIVAL rather
than at SEND leaves every remote vehicle exactly one network latency
behind where it should be. On the 1 ms LAN inside an arcade that is
nothing. Over Steam Datagram Relay it is 50-150 ms of positional lag on
every other player - a constant bias, not jitter, and the information
needed to remove it was already in the packet.
The timestamp cannot be used as it stands: both machines run
QueryPerformanceCounter since their own boot, so the two clocks share no
epoch. The offset is estimated per peer instead. Each record gives
sample = ourNow - theirStamp = trueOffset + oneWayLatency
and latency is never negative, so the smallest sample seen is the
closest to the truth. A rolling minimum over 128 samples follows crystal
drift and re-adapts when a route gets slower, rather than being pinned
forever by one lucky packet; a shorter path is believed immediately.
Applied with two clamps: never ahead of our own clock, and never further
back than 500 ms. Past that the packet is stale or the estimate is
wrong, and throwing a vehicle half a second forward does more damage
than the lag being corrected.
Entity::UpdateMessageHandler is the only point on the receive path that
knows whose update this is - records carry a timestamp but not an owner -
so it publishes the sender around the loop, and only for entities
somebody else owns. Offsets are forgotten in CreateMission: the hosts in
the next race are not the hosts in the last one and a HostID gets reused.
RP412NETCLOCK=0 restores the arrival-time behaviour, documented in
environ.ini, so a test machine can compare the two without a rebuild.
The estimate is logged per host when it first settles and whenever it
moves more than 50 ms, which is what a three-machine session should be
read against.
WHAT IS AND IS NOT VERIFIED. A full single-player race runs unchanged -
the path is never entered without replicants, which is the regression
risk that reaches everybody. The behaviour this exists for needs real
latency between real machines and is therefore untested: a two-instance
loopback race would only have exercised the zero-latency case, where the
correction is a no-op by construction. Expect remote vehicles to sit
further forward than before, and watch for overshoot when somebody
changes direction sharply - that is the tradeoff this makes, and the
clamp above is what bounds it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Opus 5
|
68f5780efa |
The cockpit clock counts the console's clock
A race ends when the console says so, but the countdown on the map display was computed from the engine clock and its own idea of when the race started - QueryPerformanceCounter from Application::gameStarted, against the console's GetTickCount from gRunStartTick. Two clocks, two epochs, two threads. They agreed to within a frame in the ordinary case, which is why nobody noticed. They do not agree at all when RP412MISSIONSECONDS is set: the override shortens the CONSOLE's length and leaves the egg's alone, so a 25-second test race displayed a clock counting down from 5:00 and was stopped with 4:35 still showing. gMissionClockHook (APPMGR.h, alongside the gPerFrameHook it mirrors) lets the console answer for the countdown when it is marshalling. NULL, or a console that has no answer yet, falls back to exactly the old computation - which is what the arcade -net pods, lobby members and mission review all take, none of them running a console locally. A member's clock is anchored by the console's RunMission arriving over the wire anyway, so it starts within one latency of correct and only drifts at the rate the two crystals differ. Two things come out of it beyond the clock itself. The camera directors switch behaviour at "30 seconds left" (DIRECTOR.cpp, RPDIRECT.cpp) and were reading the same free-running number, so the dramatic end-of-race camera and the actual buzzer were on different clocks too; they now share one. And the countdown holds at 00:00 instead of going negative - the console polls at 250 ms, so zero always arrives slightly before the stop is dispatched. The hook is guarded on gWatchedApp == application. Nothing ever uninstalls it, so a player who hosts a race and then joins somebody else's lobby still has it wired up, and in that race the console is a bystander holding the previous mission's gLengthMs and gRunStartTick. Verified by running a 25-second race with the menu still set to 5:00 and photographing the map display: 00:17, 00:01, then 00:00 held while "time expired - stopping mission" went to the log. Captures use PrintWindow rather than CopyFromScreen - the first attempt grabbed the desktop sitting in front of the Map window, which is somebody's screen contents written to disk, and those files were deleted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
4f34684b16 |
environ.ini is written on first run, not shipped
Packing one into every zip meant a tester who unzipped a new build over their folder got their configuration replaced. bindings.txt has never had that problem, because the exe carries the template and writes the file only when it is absent. environ.ini now works the same way, so a new build can land on an existing folder and every setting survives. The 245-line template moves out of pack-dist.ps1 and into RPL4ENVIRON.cpp as the exe's own literal, which also means the exe alone can produce a working install. It was lifted mechanically rather than retyped, and the file it writes is line-for-line identical to the one we have been shipping - only the line endings changed, from a mongrel 243 LF plus one stray CRLF that PowerShell's Set-Content left on the end, to the uniform LF the game already writes bindings.txt with. It cannot simply become optional. Without environ.ini, L4GAUGE is unset - which disables the gauge renderer and takes every MFD with it - and L4MFDSPLIT is unset, which is the packed-window arcade layout rather than the glass cockpit. The shipped values ARE the desktop game; the built-in getenv fallbacks are the 1995 pod. So the game writes the file rather than tolerating its absence. The cost of a file that is never overwritten is that a tester carrying one across many builds stops being offered new options. Nothing breaks - an option added later defaults to "behave as before" - but it goes unnoticed, and "the podium does not work" is a confusing bug report when the real answer is that their environ.ini predates RP412PODIUM. So the load names every template key the player's file has never mentioned, and says they are at built-in defaults and that deleting the file brings the documented one back. A stale seven-line file lists all 40. The file is read, never rewritten. The mention test is deliberately generous - a key counts as known if it appears in any form, commented or not - because the failure it guards against is worse than a missed notice: environ.ini is applied line by line, so a second copy of a key appearing later in the file would silently override the player's own. The version line also moves to the top of WinMain. It used to print after the environment was loaded, so the first thing in rpl4.log was a message about environ.ini rather than which build wrote it. Verified: the written file matches the old shipped one line for line; an edited file with a hand-added comment survives another run untouched; a seven-line file from an older build boots and names all 40 options it has never heard of; and a full mission on a self-written file brings up the glass cockpit at 125% with the virtual RIO active and nothing alarming in the log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
72bb3b394f |
The controls map becomes the handbook
It stopped being a controls map somewhere around the display arrangement and the joystick wizard, and a page called CONTROLS.html is the wrong place to look for what a file in the game folder does. So: docs/rp412-controls.html is now docs/rp412-handbook.html and ships as HANDBOOK.html, titled to match. The new section answers the question the page could not: what is in the game folder and which of it is yours. Four files are - environ.ini, bindings.txt, pilot.cfg, mfd_layout.cfg - and only the first ships, so a fresh unzip has none of the others and deleting one simply starts that part over. A second table covers the shipped engine data, which nobody should edit but everybody eventually wonders about: which INI the gauge canvas comes from, why there are audio mixer tables for hardware that has not existed since 1995, and that JOYSTICK.INI is the legacy path rather than anything the new joystick support reads. The callout carries the two that actually catch people, both of which have caught us during this work: environ.ini is applied OVER the environment, so a variable set in a shell loses to an uncommented line in the file; and bindings.txt is never overwritten once it exists, which is what protects a player's edits and also why an update's new defaults do not appear until it is deleted. CONTROLS.txt keeps its name. It is the controls half in plain text for Notepad, which is still exactly what it is, and the README now says so rather than describing the two as the same thing. Verified by rendering the packed HANDBOOK.html headless: both tables and the callout sit in the page's own components, the footer names the new file, and the version stamp still flows through - the shipped copy reads 4.12.96 from the build it was packed with. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
a1d2de591c |
The patch number is the commit count
A hand-maintained version says what somebody remembered to type. Pinning it to the repository means a binary always names the commit it came from, so a log from a test machine settles which changes are in it. stamp-version.ps1 runs as RP_L4's pre-build step and writes the generated RP_L4\rpl4build.h: #define RP412_VERSION "4.12.96" #define RP412_VERSION_LONG "4.12.96 (a1b2c3d)" The hash beside the number names the commit exactly; a trailing '+' means the tree had uncommitted changes to TRACKED files when it was built, which is the state a puzzling bug report usually comes from. Untracked files do not count - one scratch document in the tree would otherwise mark every build dirty and the marker would stop meaning anything. Generated rather than committed, and gitignored, because a hardcoded number cannot work: the commit that records "4.12.96" is itself commit 96, so the file is stale the moment it lands. The header is rewritten only when the stamp changes, so ordinary rebuilds do not drag RPL4.CPP through a recompile. pack-dist.ps1 reads that header instead of asking git again - a commit between building and packing would otherwise have the zip claiming a version the binary inside it does not report - and warns when the build it is packing came from a modified tree. The README banner, the zip name and the shipped CONTROLS.html all take the same number. Numbering stays ordered: 95 commits so far, so 4.12.95 follows 4.12.7 and every future build sorts after it. Only the "4.12" line is set by hand, at the top of the script. Two things the wiring turned up: Windows PowerShell turns a native command's stderr into ErrorRecords, so with $ErrorActionPreference = 'Stop' git's routine "LF will be replaced by CRLF" warning threw straight past the dirty check and stamped a modified tree as clean. Every git call now goes through cmd, which keeps stderr out of PowerShell's error stream entirely. The script ended on "git diff --quiet", which exits 1 to mean "there are changes" - as a pre-build step that failed the build on exactly the tree a developer builds in. It exits 0 explicitly now. Verified: deleting the header and building recreates it; a second build reports "(unchanged)" and leaves the timestamp alone; a build on a modified tree succeeds and stamps 4.12.95 (c1729e4+); and the packed game logs "Red Planet 4.12.95 (c1729e4+)" on its first line while README.txt and CONTROLS.html in the same package both read 4.12.95. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
c1729e40c7 |
The callsign and loadout outlive the session
The loadout has always survived a race - gPersistSelection is why the setup screen reopens the way you left it - but only for as long as the process lived. Closing the game was a reset, and the callsign is the one thing on that screen a player types rather than picks, so it was the one they had to type again every launch. pilot.cfg beside bindings.txt now holds both, KEY=VALUE like environ.ini, one line per group. BT411 solved this first, in fe_last.ini, and its own comment says why RP412 never grew the file: BT411 relaunches the process between missions and would otherwise forget the loadout mid-evening, while RP412 stays in one process. That made the gap invisible from inside a session and total across two. Same idea, two differences worth naming: BT411 saves only on a launch - it returns before SavePersisted when the player quits. That loses a callsign typed by somebody who then changed their mind, which is exactly the moment this feature exists for, so this writes on the way out however the menu is left: launching, stepping into a lobby, or EXIT GAME. BT411 takes the stored name as-is. A callsign here is quoted into frontend.egg, joined into a comma-separated list for the results screen, and published as Steam lobby member data, so a comma alone would split one pilot into two on the score sheet. SanitizeCallsign drops what could end a token early and is applied to what is typed as well as to what is read, so the file cannot hold what the game will not accept. Every index is range-checked on the way in, against the group's real size rather than a constant - the track list is the one that moves, since football and the death race carry different maps, so it answers for whichever scenario is selected. The track is re-checked after the whole file is read as well, because the file is parsed in the order it happens to be written and the scenario may arrive second. Written unconditionally rather than only on a change: it is a few hundred bytes, and writing every time means a value hand-edited out of range comes back corrected instead of being quietly re-rejected on every launch forever. Verified by round trip. A callsign typed and then abandoned via EXIT GAME is in the file and back in the box next launch. A file carrying Ba"d,Na#me loads as BadName; an empty one falls back to Pilot. A full loadout round-trips value for value; vehicle=999 and color=-3 come back 0 with the rest untouched; and track=9 under football falls back to 0 both when the scenario is read first and when it is read second, which is the case the second check exists for. One correction to my own test rig on the way: cross-process SetWindowText on an EDIT updates the cached caption, which an external GetWindowText then reads back happily, while leaving the control's own buffer alone - so the harness looked right and the game correctly saw the old name. WM_SETTEXT is marshalled properly and shows the truth. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
f20547cb25 |
Controls page covers the joystick setup
CONTROLS.md gained this in the port; the page that ships beside it did not, and the page is the one people actually look at. A "Bring your own stick" section before Rebinding: what DirectInput is and why it needs telling what its axes are for, joyconfig.bat as the answer, and the four beats of running it. The callout carries the reason the wizard reads direction rather than asking you to know it, since that is the part that looks like a quirk until it is explained. Then what it writes beside the grammar that produced it, and a table for the two rules the pod's shape asks for - the signed Pedals axis working the pedal pair, and a real lever owning the throttle channel. The reference tables were left incomplete by the port and are now whole: Pedals joins the axis list, the joy rows join the grammar block, and DirectInput's own axis names get a row of their own. Written in the page's existing components - glance, callout, two-col, tbl-scroll - rather than new ones. The two <kbd> elements I reached for first are not styled anywhere on this page and would have rendered as browser defaults, so they are <code> like every other inline literal here. No version change: 4.12.7 is republished with the page in it. Verified by rendering the packed CONTROLS.html headless at 1280 wide and reading the section back - heading, lede, the four-panel strip, callout, both code blocks, both tables, and the reference rows all sit in the page's own idiom, and the tag balance is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
52da65bc0d |
Release 4.12.7
Flight sticks, HOTAS throttles, twist grips and rudder pedals, none of which the game could see before: they arrive through DirectInput rather than XInput, and PadRIO only read XInput. joyconfig.bat is the setup: the wizard asks you to move each control in turn and derives the sign convention from the direction of the move, then writes the joystick rows of bindings.txt between marker lines, leaving anything you have edited yourself alone. Confirmed on the Logitech Extreme 3D: a full pass wrote all four axes, six buttons and the hat, with X and the throttle lever inverted to match the pod's convention and Y left alone - and the deadzone on the twist grip was then hand-tuned from 0.08 to 0.18 in the file, which is the workflow the marker section exists for. Version strings bumped in RPL4.CPP, pack-dist.ps1 and the controls page that ships in the zip. Built clean, packed, zipped (1004 entries, nothing loose at the root) and smoke-tested from the dist: boots reporting 4.12.7, virtual RIO up, and no DirectInput enumeration at all on a default bindings.txt - the joystick layer only opens when the profile asks for it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>v4.12.7 |
||
|
CydandClaude Opus 5
|
91420b5cb2 |
Flight sticks, HOTAS and pedals, with a setup wizard
Ported from BT411, which needed the same thing for its glass cockpit. PadRIO reads XInput, which covers Xbox-class pads and nothing else. A flight stick, a HOTAS throttle, a twist grip, rudder pedals or a wheel arrive through DirectInput instead, and until now the game could not see any of them - the only generic-joystick path left was the 1995 single- device DIJoystick behind L4CONTROLS=DIJOYSTICK, which is untouched here. L4JOY is the reader: up to four devices as normalized state blocks, hot- plug re-enumeration on the same ~3 s cadence PadRIO uses to look for a pad, and a device lost mid-race zeroed rather than left holding whatever was pressed when it went. XInput-class devices are excluded by VID/PID against the RawInput paths carrying the "IG_" marker - without that an Xbox pad arrives through both APIs and every button counts twice. bindings.txt gains four rows in the grammar it already had, using its own vocabulary (deadzone/rate) rather than BT411's: joydev <slot> [product-name substring] joyaxis <src> axis <axis> [invert] [deadzone <d>] [rate <n>] joybutton <n> button <addr> [toggle] joyhat <n> <up|down|left|right> button <addr> Slots resolve to a live device every poll, by name substring or ordinal, so unplugging and replugging does not rewrite anyone's file. Two things the pod's shape forced that BT411 solved differently: Pedals - a signed composite axis that decomposes into the pod's two pedals, positive right and negative left. The pod has a pedal each side; a twist grip or rudder bar is one signed control, and pressing one or the other but never both is exactly what it wants to say. It is a channel name like any other, so a pad stick can drive the turn too. A joyaxis on Throttle with no rate is a real lever and OWNS the channel - full travel maps onto the 0..1 the pod runs on, instead of nudging the accumulator that a spring-centred pad stick has to use. RP412JOYCONFIG=1 (joyconfig.bat) runs the capture wizard before the console screen: it asks the player to move each control, and derives the sign convention from the DIRECTION of the move. That is the point of it - a stick that reads positive pushed right and one that reads negative are equally common, and no amount of documentation gets a player to work out which they own. It writes only its own section, between marker lines, so hand-edited keyboard and pad rows survive re-running it. The wizard also prints every axis at rest before it starts. A driver that refuses the +-32767 range we ask for reports its own, and an axis then sits hard over instead of near zero; seeing "X +1.00" on an untouched stick is the difference between a five-minute fix and a bug report that says it configured itself. Each capture reports the move it saw for the same reason. Verified on the Logitech Extreme 3D on this machine. Enumeration finds it and excludes the Xbox pad, which still arrives separately through XInput. Every row shape parses - 7 axes, 2 buttons, 4 hat directions - and three deliberately malformed rows (a bad axis name, button 99, a "sideways" hat) are each rejected by line number rather than silently dropped. The wizard lists the device with its axes at rest reading X +0.00 Y -0.01 RZ -0.04 SL0 +1.00, waits on the first prompt without self-triggering, and with a hand on the stick captures X to steering, Y to pitch, RZ to the pedals and SL0 to the throttle, inverting the ones that read backwards. Running the captures through to a written file needs a hand on the stick, so that part is the machine's to confirm, not this build's. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
fd61316a40 |
Release 4.12.6
Seven commits since 4.12.5, all about where things sit on screen. RP412MFDLAYOUT remembers window placement across the menu-race-menu loop, in mfd_layout.cfg beside bindings.txt: the game window, the exploded view's display panes, and the plasma glass. Append ,noframe to a line to take that window's title bar and border off - a cockpit filling a monitor edge to edge at a rect you chose, where -fit could only do it by taking the whole screen. That needed a way out of a window with no title bar, so the setup screen carries an EXIT GAME button, bottom left and diagonally opposite LAUNCH. The Steam host/join buttons dim and say STEAM NOT RUNNING rather than disappearing - two buttons quietly missing reads as a broken build. And the Winners Circle camera is framed off the award stand rather than off whoever is standing on it. It had been averaging the filled spots, which moved the shot with the head count: eight finishers put the eye 24 units closer to the stand and aimed it at the middle of the tiers instead of at the winner. The framing constants are untouched, so the shot everybody gets now is the one that was dialled in. Version strings bumped in RPL4.CPP, pack-dist.ps1 and the controls page that ships in the zip. Built clean, packed, and smoke-tested from the dist: boots to the console screen reporting 4.12.6, virtual RIO up, Steam transport up, nothing alarming in the log. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>v4.12.6 |
||
|
CydandClaude Opus 5
|
dce8818273 |
The plasma glass is placeable too
It is a draggable top-level window whenever L4PLASMA=SCREEN, which makes it the last one still being placed fresh every launch. It joins mfd_layout.cfg under "Plasma Display", the caption it already carries - the same key-is-the-title rule the display panes follow. Position only, like the panes: the glass is 128x32 at L4PLASMASCALE, so its size is a setting rather than something to drag. It registers and loads at the point it creates its window rather than leaving that to SVGA16. The glass comes from the gauge renderer and the panes from the video mode, and nothing guarantees which is built first; loading in both places means whichever runs second simply re-applies a placement the first already has. Its window procedure picks up the same WM_EXITSIZEMOVE save the panes have, so a drag writes the file straight away, and the destructor forgets the window before destroying it. Verified by round trip in the exploded view: dragged to 640,880, the file took "Plasma Display=640,880,528,167" alongside the panes and the game window, and a fresh launch in load mode put it physically back at 640,880. The three load lines in the log - one window, then two, then eight - are the ordering doing its job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
a1f9c0e3c0 |
Winners Circle framed off the stand, not off who is on it
The camera was built from the spots that actually got filled: the first filled one for the front, the average of the filled ones for the centre. So it moved with the finishing order and the head count, and would move between machines if a remote player's vehicle was not there to place. Measured on Wiseguy's Wake, where win1 sits at (1199.84, 3, 2.92) and the eight spots run back to z~38 on the high tier: one finisher eye 1199.84,15,-33.08 aim z 2.92 eight finishers eye 1199.82,18.44,-9.03 aim z 26.97 Twenty-four units closer to the stand and looking at the middle of the tiers instead of at the winner - a different photograph of the same podium depending on how many people showed up. The stand is fixed furniture on every map, so the shot comes off the geometry now. The eight dropzones are read once, up front, before anybody is placed; win1 anchors the framing and the axis from the back rows out through win1 gives the facing, so a map that mounts its stand at another angle is still photographed from the front rather than relying on the old (0,0,-1) fallback. Placement then runs as its own pass and is the only thing that cares who finished - the log reports "N placed on M spots" precisely so a changing N beside unchanged camera numbers is visible. The framing constants are untouched and so is the shot they produce: the new numbers for a single finisher are eye 1199.77,15,-33.08 aim 1199.84,5,2.92, which is the old single-finisher shot to within 0.07 in x. That is the case the standoff/height/aim defaults were dialled in against, so the approved photograph is what everybody gets now instead of what one person got. Verified by running a race to the podium: the eight spot positions log as expected, the camera numbers match the calculation, and the frame is the same one as before - rank 1 centred with its callsign, 2 and 3 flanking on the low tier, 4-8 across the high tier behind. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
bfd5fa163e |
EXIT GAME on the console screen
,noframe takes the title bar away, and with it the only way out of the game. The console screen now offers its own, bottom left: half width and diagonally opposite LAUNCH GAME, because it is the one button on that screen you cannot undo and it should not sit next to the one everybody is aiming for. It goes through the same door as closing the window - fe.closed, so RPL4FrontEnd_Run returns False and the race loop breaks - rather than opening a second shutdown path. Two things had to move for it to make sense. The saved placement now loads in RPL4.CPP, right after the main window is shown, instead of only when SVGA16 builds the cockpit. That was not until a mission started, so the console screen came up at the default rect with its title bar still on and the window only jumped to the saved placement once a race began - which, for a flag whose whole purpose is to take the title bar off, meant it did nothing on the screen you land on. RPL4.CPP now owns the main window's registration outright and SVGA16's branches only reload; the reload after CockpitShellProc goes on still matters, since its WM_SIZE is what re-fits the canvas. That in turn made the exploded view's position-only registration incoherent - the startup load had already applied the size - so the game window is simply position and size everywhere now. The earlier reasoning that its exploded size IS the -res render size does not hold: the back buffer stretches to the window in either view, exactly as it does for the cockpit. WM_EXITSIZEMOVE moves from the cockpit subclass to RPL4.CPP's own WndProc, which the subclass chains to anyway. In its old home it only existed once a cockpit had been built, so dragging the window on the console screen - the obvious moment to put it where you want it - saved nothing. There is also a save on the way out of WinMain, for a session that never started a race and so never ran SVGA16's teardown save. Verified: on a bare-framed window the console screen comes up at the saved 1280x760 with client == window rect, EXIT GAME ends the process with code 0, and a screenshot shows it clear of the column content. A console-only session dragged to 333,222 900x640 wrote that on the drag, kept it through the exit, and came back to exactly it on relaunch - without a race anywhere in the round trip. The noframe and cockpit round trips still pass unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
a52fec80a9 |
mfd_layout.cfg: ,noframe takes a window's title bar off
Append it to any line - "RPL4=240,120,1000,620,noframe" - and that window comes up with no caption and no border. For the game window that is a cockpit filling a monitor edge to edge at a rect you chose, which -fit could only do by taking the whole screen; for an exploded pane it is a display photographed without chrome. Per line rather than global, so the shell can go bare while the panes keep their captions, or the other way round. The flag is an instruction rather than something measured off the window, so Save carries it back out - otherwise the first finished drag would rewrite the file and quietly drop it. Windows are always built framed and Load only ever strips, so deleting the flag is all it takes to get the frame back; there is no un-strip path to get wrong. A bare window's rect IS its client rect, so the client area is what survives: a window that had a size in the file keeps it as the client, and a position-only pane keeps whatever client it had. That also makes the round trip stable - once bare, what Save records is already the client, so load-save-load does not creep. WS_SYSMENU stays on. It draws nothing without a caption, but without it DefWindowProc will not honour Alt+F4, and a window with no title bar and no way to close it is a trap. Nothing else can be dragged either, hence the note in the file header and environ.ini: place it first, add the flag after. Verified in both views. Cockpit: the same 240,120 1000x620 line with and without the flag, CAPTION|THICKFRAME and a 984x581 client becoming POPUP with a 1000x620 one, and a screenshot showing the displays hard against all four edges where the framed shot had them inside a letterbox. Save mode with the flag set, nudged with WM_EXITSIZEMOVE, rewrote the line with ",noframe" intact. Exploded: Map bare at 777,333 with its 500x640 client preserved while the shell beside it kept its caption. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
40b00ddde1 |
The game window remembers where you put it too
RP412MFDLAYOUT already kept the exploded view's display panes where they
were dragged. The main window is the one people move most, and it was
still being placed fresh every launch, so it joins them.
MFDSplitView_LoadLayout/SaveLayout become RPWindowLayout_Load/Save, with
Register/Forget taking any HWND rather than the module reaching into a
pane registry. Same file, same format, one more line in it.
What comes back depends on the window, so Register takes it as a flag:
display panes position only, as before. A pane's size follows its
content and its button banks, so an old size from a
different build must not distort it.
the game window position and size in the cockpit view. Nothing
derives that size - the cockpit fits itself to
whatever client area it is given - so a window sized
to suit a monitor should come back that way, and
half-restoring it would be the strange behaviour. In
the exploded view its size IS the render resolution
-res asked for, so there only the position returns.
Registered after the CockpitShellProc subclass is installed, on purpose:
the restore's WM_SIZE then runs LayoutCockpit again and the canvas
re-fits the restored client area. -fit does not register at all - it
owns the whole monitor, so there is no placement of the player's to
keep.
CockpitShellProc gained the WM_EXITSIZEMOVE hook the panes already had,
so dragging or resizing the shell writes the file immediately rather
than waiting for teardown.
Two hazards the panes were small enough to get away with and the game
window is not:
- Save reads rcNormalPosition rather than GetWindowRect. A minimised
window reports a nonsense rect and a maximised one reports the
screen; since the file is rewritten whole, either would have
replaced a good line with a useless one. rcNormalPosition is the
restored placement whatever state the window is in.
- Load drops any placement that intersects none of the monitors
currently plugged in. Restoring the game window onto a display that
is no longer there would leave nothing to drag back.
Verified by round trip in both views. Cockpit: dragged and resized to
240,120 1000x620, the file took it, a fresh launch in load mode came up
exactly there with a 984x581 client - and a screenshot confirms the
canvas re-fit it, displays at the corners and the map centred at the
bottom, nothing spilling. Exploded: the shell came back at 60,60 still
1280x720 from -res while Map came back at 777,333, which is the
size-flag split doing its job.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
CydandClaude Fable 5
|
16ce4dfbea |
Exploded view remembers where you drag its windows
Ported from BT411's BT_GLASS_LAYOUT (29c502d).
The exploded view's panes are draggable desktop windows, but the
arrangement is recomputed on every launch, so dragging one somewhere
useful never survived the menu-race-menu loop.
RP412MFDLAYOUT persists it to mfd_layout.cfg beside bindings.txt:
off / 0 / unset computed arrangement only, no file (default)
load / restore restore saved positions at startup, never write
save / adjust restore, then rewrite on each finished drag
(WM_EXITSIZEMOVE) and on teardown
One "<title>=x,y,w,h" line per pane. Position is restored and the size
read and discarded: a pane's size follows its content and its button
banks, so letting an old size back in would misshape it after any
geometry change - and this port has changed that geometry twice already.
Load runs after the computed arrangement rather than instead of it, so a
pane the file does not mention simply keeps its computed spot. Only the
exploded view registers: the composited cockpit's panes are chrome-less
children with nothing to drag, so they have no position worth keeping.
RP412 needs no equivalent of BT411's "restored" flag. Its re-snap is
LayoutCockpit on WM_SIZE, which only runs in cockpit mode, so nothing
comes back later to overwrite a hand-placed window.
Verified by round trip: dragged Map to 777,333 in save mode, the file
took all six panes, and a fresh launch in load mode put it physically
back at 777,333. The harness also resized the window while moving it,
which incidentally proved the saved size really is ignored - the pane
came back correctly sized from a cfg that recorded 136x39.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|