Well, I dug into that question for a while and it is very twisty and a lot of threshold adjustments. But there's this one block that, if FFF8AAE2 is set to false, ends up seeming to
maybe disable LTFT processing. I wish I could be more certain; still, it's extremely suspicious finding a block of RPM/MAF/speed/load logic with thresholds right at the top of several blocks of LTFT math. Someone could log FFF8AEE2 (on K00G) and see if LTFT only changes when it's true, perhaps.
Code:
uVar2 = FFF8CA24_if_zero_else_four();
fVar3 = QUERY_2dtable(engineRpm,&2dmtable_000bb0f8);
if (((BYTE_fff8aa97 != 1) || ((1200.0 <= engineRpm && (engineLoad < fVar3)))) ||
((((!bVar1 || ((engineRpm < 500.0 || (900.0 <= engineRpm)))) ||
(((BOOL_fff8aae2 = (uVar2 & 0xff) == 4, !BOOL_fff8aae2 &&
((engineSpeed < 0.0 || (BOOL_fff8aae2 = engineRpm < 900.0, !BOOL_fff8aae2)))) &&
((0.0 <= engineSpeed || (BOOL_fff8aae2 = engineRpm < 2500.0, !BOOL_fff8aae2)))))) &&
((((bVar1 || (engineRpm < 0.0)) || (10000.0 <= engineRpm)) ||
((engineMaf < 1.6 || (BOOL_fff8aae2 = engineMaf < 200.0, !BOOL_fff8aae2)))))))) {
BOOL_fff8aae2 = false;
}
The above is from K00G; fvar3 is 0.1 at all rpms. I checked a few different calibrations and these exact values and this exact logic seem unchanged from A01G onward.
No luck determining whether CELs disable it or not, but at least there's a possibility of something interesting.