The mode lamps follow the mode

Selecting NOV, STD, VET or EXP on the Upper Right MFD lit nothing and
dimmed nothing. Two separate faults had to line up for that.

SetControlsMode announced the change as
L4VTVControlsMapper::NotifyOfControlModeChange - explicitly qualified,
which suppresses the virtual call and lands on the base class no-op. The
code that drives the four lamps is VTVRIOMapper's override, so a mode
change never reached it. Its neighbour has always gone out unqualified
from VTVControlsMapper::SetConfigurationState, which is why the
configuration lamps behaved and these did not.

previousControlMode is the lamp the next change dims, and nothing wrote
it after construction set it to -1. Even once the call arrived, the dim
step would have matched nothing and the panel would have accumulated
lamps rather than following the selection.

The one call that did dispatch is the one in VTVRIOMapper's own
constructor, where the vtable is already the derived one - which is why
NOV lit at the start and then nothing ever moved.

B / S / V / M are gone from the Thrustmaster mapper's key handler. The
driving mode is a panel decision, four buttons carrying the lamps that
say which one you are in, and a bare letter key changing it behind the
player's back is not that. It reads worse in 4.12 than it ever did in
the pod: the whole letter board is the MFD banks now, so on that path
those four letters would have fired their bank button and silently
changed the driving mode as well.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

RP_L4/RPL4MPPR.cpp

@@ -444,9 +444,18 @@ void
 	//----------------------------------------
 	// Notify of mode change
 	//----------------------------------------
+	//
+	// Unqualified, so the platform's override is the one that runs. The
+	// RIO carries the four mode lamps on the Upper Right MFD and lights
+	// them from here (VTVRIOMapper::NotifyOfControlModeChange); naming
+	// the class suppressed the virtual call and landed on the base's
+	// no-op instead, so the lamps never followed the mode the pilot had
+	// just selected. Its neighbour has always gone out this way - see
+	// VTVControlsMapper::SetConfigurationState.
+	//
 	if (previous_mode != controlMode)
 	{
-		L4VTVControlsMapper::NotifyOfControlModeChange(controlMode);
+		NotifyOfControlModeChange(controlMode);
 	}
 	Check_Fpu();
 }
@@ -874,18 +883,18 @@ void
 		//-------------------------------------------------------
 		// Set driving modes
 		//-------------------------------------------------------
-	case 'b':
-	case 'B': SetControlsMode(BasicMode); break;
-
-	case 's':
-	case 'S': SetControlsMode(StandardMode); break;
-
-	case 'v':
-	case 'V': SetControlsMode(VeteranMode); break;
-
-	case 'm':
-	case 'M': SetControlsMode(MasterMode); break;
-
+		//
+		// B / S / V / M used to drop straight into Basic, Standard,
+		// Veteran and Master here. The driving mode is a panel
+		// decision - the four buttons on the Upper Right MFD, with the
+		// lamps that say which one you are in - and a bare letter key
+		// changing it behind the player's back is not that. Worse in
+		// 4.12 than it ever was in the pod: the whole letter board is
+		// the MFD banks now, so those four letters are buttons in their
+		// own right and would have fired twice.
+		//
+		// Nothing replaces them. Press the mode you want.
+		//
 		//-------------------------------------------------------
 		// Configuration stuff
 		//-------------------------------------------------------
@@ -1614,6 +1623,18 @@ void
 			modeLamp[lamp_number]->SetState(L4Lamp::LampStateOn);
 		}
 	}
+
+	//----------------------------------
+	// Remember what is lit
+	//----------------------------------
+	//
+	// previousControlMode is the lamp the NEXT change dims, and nothing
+	// used to write it after construction set it to -1. Every mode
+	// therefore lit its own lamp against a dim that matched nothing, and
+	// the panel accumulated lamps instead of following the selection.
+	//
+	previousControlMode = controlMode;
+
 	//-----------------------------------
 	// Invoke ancestral method
 	//-----------------------------------