From ed7843b89ff54da3c370a4e3faba122268f4c7f1 Mon Sep 17 00:00:00 2001 From: Cyd Date: Tue, 28 Jul 2026 08:34:44 -0500 Subject: [PATCH] BT410 5.3.49: first renderable answer -- BTPlayer, and the pod stops complaining BTL4VideoRenderer now overrides MakeEntityRenderables. Class 3035 resolves to BTPlayerClassID (the BT enum block starts at 3000 in VDATA.HPP), and a player carries no graphics -- exactly what the engine already does for its own PlayerClassID with an empty case. Everything else chains to DPLRenderer, so the override can only add answers. On the pod: the 'couldn't figure out how to MakeEntityRenderables' complaint is gone and the run no longer exits, it keeps running. It still renders nothing -- the wire fifodump grows at ~24 bytes/sec, keep-alive rather than a frame stream -- which is expected, since only the player has been answered and the mech and arena still have no renderables. Banked a practical problem worth fixing before the next session: a pod run that does NOT crash produces no readable log, because the conf redirects the game's stdout and DOS buffers it. Every readable log this session came from a run that crashed and had its buffer flushed by the fault handler. The RC.TXT marker (a separate command) survives that, and the com3/serial3=file trick from the emulator notes would give live unbuffered output -- worth wiring in, otherwise progress is invisible precisely when things are going well. Co-Authored-By: Claude Fable 5 --- restoration/source410/BT_L4/BTL4VID.CPP | 42 +++++++++++++++++++ restoration/source410/BT_L4/BTL4VID.HPP | 13 ++++++ restoration/source410/RENDER-ROADMAP.NOTES.md | 38 +++++++++++++++++ 3 files changed, 93 insertions(+) diff --git a/restoration/source410/BT_L4/BTL4VID.CPP b/restoration/source410/BT_L4/BTL4VID.CPP index d292f74b..28e91767 100644 --- a/restoration/source410/BT_L4/BTL4VID.CPP +++ b/restoration/source410/BT_L4/BTL4VID.CPP @@ -68,6 +68,48 @@ BTL4VideoRenderer::~BTL4VideoRenderer() // engine and only the CONTENT comes from the donor. //############################################################################# // +// +//############################################################################# +// MakeEntityRenderables -- the game level of the renderable factory. +// +// The engine's DPLRenderer::MakeEntityRenderables (L4VIDEO.CPP:4151) knows +// the ENGINE entity classes and calls DOWN to +// VideoRenderer::MakeEntityRenderables for anything else, which only prints +// Entity class couldn't figure out how to MakeEntityRenderables +// So every BT class has to be answered here. +// +// FIRST ANSWER: BTPlayer (class 3035) carries no graphics. The engine +// already does exactly this for its own PlayerClassID -- an empty case -- +// and BT's player is simply a different id it cannot know about. This is +// the class the live pod run complained about. +// +// Everything else still chains to the engine, so this override can only +// ADD answers, never remove the ones DPLRenderer already gives. +//############################################################################# +// +void + BTL4VideoRenderer::MakeEntityRenderables( + Entity *entity, + ResourceDescription *model_resource, + ViewFrom view_type) +{ + Check(this); + Check(entity); + + switch (entity->GetClassID()) + { + case RegisteredClass::BTPlayerClassID: + // + // No graphics -- the player is a control/scoring entity. + // + break; + + default: + DPLRenderer::MakeEntityRenderables(entity, model_resource, view_type); + break; + } +} + void BTL4VideoRenderer::LoadMissionImplementation(Mission *) { diff --git a/restoration/source410/BT_L4/BTL4VID.HPP b/restoration/source410/BT_L4/BTL4VID.HPP index 6bb841b2..93c7ffb6 100644 --- a/restoration/source410/BT_L4/BTL4VID.HPP +++ b/restoration/source410/BT_L4/BTL4VID.HPP @@ -40,6 +40,19 @@ void LoadMissionImplementation(Mission *mission); + // + // The bottom of this virtual chain is + // VideoRenderer::MakeEntityRenderables (VIDREND.CPP:231), whose own + // comment says it is only reached when nobody above could figure out + // what to build -- and it just complains. The engine's DPLRenderer + // layer knows the ENGINE classes; the game's own classes are ours. + // + void + MakeEntityRenderables( + Entity *entity, + ResourceDescription *model_resource, + ViewFrom view_type); + protected: int reserved[16]; }; diff --git a/restoration/source410/RENDER-ROADMAP.NOTES.md b/restoration/source410/RENDER-ROADMAP.NOTES.md index 3dc3ceef..58402692 100644 --- a/restoration/source410/RENDER-ROADMAP.NOTES.md +++ b/restoration/source410/RENDER-ROADMAP.NOTES.md @@ -434,3 +434,41 @@ i.e. walk the mission's entities, read each one's .SKL skeleton notation pages and load the .BGF geometry per node. Content for the BT-specific renderables comes from the BT411 donor (game/reconstructed/btl4vid.cpp, 3188 lines: BTReticleRenderable, BTTranslocationRenderable, the pending-wrecks map). + +-------------------------------------------------------------------------------- +FIRST RENDERABLE ANSWER: BTPlayer -- and how to read a NON-crashing pod run +-------------------------------------------------------------------------------- +BTL4VideoRenderer now overrides MakeEntityRenderables. First answer: +class 3035 = BTPlayerClassID (VDATA.HPP: the BT block starts at +BTL4ApplicationClassID = 3000, so counting down the enum gives 3035) carries +NO GRAPHICS -- exactly what the engine already does for its own +PlayerClassID with an empty case. Everything else still chains to +DPLRenderer, so this override can only ADD answers, never remove one the +engine already gives. + +Result on the pod: the "couldn't figure out how to MakeEntityRenderables" +complaint is GONE, and the run no longer exits -- it keeps running. But it +renders nothing: the wire fifodump grows at ~24 bytes/sec (1.4KB total), +which is keep-alive traffic, not a frame stream. Expected -- the mech and +the arena still have no renderables, only the player has been answered. + +A PRACTICAL PROBLEM TO SOLVE FIRST NEXT TIME: a pod run that does NOT crash +produces NO readable log. The conf redirects the game's stdout +(> OUTREC.TXT) and DOS buffers it, so the file stays 0 bytes until the +process exits normally; every log this session that was readable came from a +run that CRASHED, because the fault handler flushed. Killing the pod loses +the buffer entirely. + +Two ways out, both already in the toolbox: + * `echo GAME-RC=%errorlevel% >> RC.TXT` after the game line -- a separate + command, so it lands even when the game's own buffer is lost. Already + added to gauge_arena_rec.conf and it is how the clean GAME-RC=0 exit was + confirmed. + * the com3/serial3=file trick from the emulator notes -- live unbuffered + game output. Worth wiring into the pod conf before the next renderables + session, otherwise progress is invisible while things are going WELL. + +NEXT: the mech (MechClassID 3001) and the arena/terrain entities are what +actually need renderables -- MakeEntityRenderables -> ReadSKLFile / +RecurseSKLFile over the .SKL skeleton pages (VIDEO/*.SKL are in the mount), +building a dpl_DCS hierarchy and loading the .BGF geometry per node.