I have been away from 2024 after uninstalling on week 1, I heard that SU4 was a big step forward and I have to say after jumping back in the improvements are real, especially performance, lighting etc.
However, coming mainly from 2020 the camera system seems to have regressed massively.
After making a few XBOX controller binding changes the Zoom no longer works, even setting it back to Y + TRIGGERS. Apparently any without first duplicating permenantly breaks the XBOX controller binding Asobo code hacks that make things like Y+Trigger actually work.
Then I am not able to click the hotspots with A on the walk around (mouse works fine).
Then I am no longer able to bind Fixed Camera 15 and if I edit them its per livery, meaning I would have to edit every new plane, can I edit a config file, nope thats behind the firewall.
I have been using ChatGPT for support to even get up and running and its been great. After many hours of battling camera bugs and regressions I just flat out asked it why is it such a mess.
I thought it would be interesting to present it here to see if I am missing something, perhaps these are known issues that are scheduled to be fixed. Yes I know I will immediately get moderated or dumped into another forum, but maybe somebody can let me know whether these are logged/planned bug fixes? I would love to know in the next Developer session whether the API will be further opened up, I am considering paying for Chase Plane but I understand the API has been intentionally limited so I would not be able to fly with my XBOX controller and change the views, a major limitation.
Me: To me FS2024 Camera system feels like a bit of a mess.
ChatGPT: You are not wrong. From a systems and UX perspective, the FS2024 camera stack is objectively regressive compared to late-cycle FS2020.
Why It Feels Like a Mess (Because It Is)
From a design standpoint, FS2024’s camera system has several structural flaws:
1. Camera definitions vs camera actions are disconnected
-
You can define many fixed cameras
-
You can only address 10 of them
-
There is no visibility in the UI of which camera maps to which action index
This is classic leaky abstraction.
2. Mode-gated inputs
-
“Next Fixed Camera” only works after you are already in Fixed Camera mode
-
There is no atomic action like:
“Jump to Fixed Camera Set”
-
This makes controller workflows brittle and state-dependent
3. No reordering, no drag-drop, no copy
-
Creation order = binding index
-
Delete/recreate to reorder is not defensible UX in 2024
-
Per-aircraft and per-livery makes it worse
4. Regression from FS2020
Late FS2020 had:
-
Predictable camera cycling
-
Stable mental model (Cockpit / External / Drone / Fixed)
FS2024 replaced this with a Showcase-first model that: -
Hides state
-
Breaks muscle memory
-
Punishes controller users disproportionately (especially Xbox / Yokes)
5. Tooling can’t fix it
-
ChasePlane
-
FSUIPC
-
SPAD.neXt
All hit the same wall: SimConnect does not expose camera indices beyond 10
That is a hard API ceiling.
Why This Matters (Beyond Annoyance)
This isn’t just inconvenience — it impacts:
-
Situational awareness (approach/runway/tower views)
-
Cinematic capture (content creation)
-
Controller users (you, in particular)
-
Training realism (inspection, gear, control surface checks)
The irony is that FS2024 added camera UI complexity while removing functional power.
The Only Way to Make It Tolerable (Today)
This is the least-bad setup power users are converging on:
-
Exactly 10 fixed cameras per aircraft
-
Carefully ordered and named
-
Bound like you’ve already done:
-
Toggle Drone
-
Toggle Fixed Camera 01
-
Next Fixed Camera
-
And then stop touching the Camera UI once configured.
Will This Get Fixed?
Historically:
-
Camera system bugs do get addressed
-
Structural limitations (like the 10-slot binding cap) take years, if ever
If this were on the roadmap, we would already see:
-
10 bindable camera actions
-
Or a “Select Fixed Camera” radial
Neither exists today.
Candid Assessment
From a software architecture perspective:
-
This is a half-migrated system
-
Two camera paradigms are co-existing badly
-
The UX was likely driven by UI consolidation, not controller ergonomics
You are encountering real design debt, not misconfiguration.
