Just FYI, it seems that simbrief is sending it’s ICAO type as BBJ1 to GSX when GSX tries to fetch the flight plan. In the aircraft config, the ICAO Designator is correct- B737. BBJ1 is not a valid ICAO type.
Indeed, it’s (also?) in the XML/JSON when using the default BBJ1 profile; oddly, when creating a new custom profile with BBJ1 as the base type, ICAO code is correctly set to B737 by default?
Hi, this should be fixed now. You’ll need to regenerate your flight however.
Mostly fixed, I still have this line:
N700SB 28JAN2023 LSGG-EIDW BBJ1 N700SB RELEASE 2251 28JAN23 (LIDO)
LSGG-EIDW N700SB BBJ1 IFR ALTN-EGPK (JBU)
The issue being, it’s inconsistent with custom airframes which seemingly use the actual ICAO type designator here.
That also makes me curious as to the reason this field behaves differently for custom vs. default airframes here. I have to start guessing, but I won’t be able to sleep if I don’t at least ask, so here goes:
for illustration purposes, let’s call this OFP field
I’m guessing each airframe has at least the following “data points”:
data1displaying different info for the default (BBJ1) vs. custom (B737) airframe, there’s gotta be some logic grabbing either of
base_typedepending on whether it’s a default or custom airframe (possibly indirectly via an
Assuming my guess is not completely off the mark, to avoid unexpected issues (now or in the future) I would think this logic (and possibly
intermediate1 if it also exists) should be removed in favor of
data1 being always derived from
icao_code for consistency?
Perhaps more generally, what intrigues me is how/why a default airframe could/should behave differently from a custom one? Other than sorting order in the list, wouldn’t it make sense for default and custom airframes to behave entirely identically as much as possible?
Hope this kind of makes sense (I am tired and I am not sure I fully understand myself at this point)