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 <noreply@anthropic.com>

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 <id> class<n> 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 *)
 {

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];
 	};

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.