SimConnect_CameraSet with referential WORLD does not work

[MSFS 2024] Bug Reports SimConnect
1

Version: 1.7.6.0

Frequency: Consistently

Severity: Blocker

Context: MSFS2024 SU5 SDK 1.6.4

I have tried the new Camera API with manged code

void Set_Camera()
{
if (!Active)
return;

 SIMCONNECT_DATA_CAMERA data = new SIMCONNECT_DATA_CAMERA();

 data.Referential = (uint)SIMCONNECT_POSITION_REFERENTIAL.WORLD;

 // Fixed camera position
 data.Pos.x = camera_lat;
 data.Pos.y = camera_lon;
 data.Pos.z = camera_alt;

 data.TargetedPos.x = plane_latitude;
 data.TargetedPos.y = plane_longitude;
 data.TargetedPos.z = plane_alt;

 data.Fov = 0.70;

 simconnect.CameraSet(data, (uint)SIMCONNECT_CAMERA_DATA_MASK.ALL_TARGETED);

}

The new Camera API SimConnect_CameraSet does not work with with above managed code.

Bug description:

The camera switch to external view with aircraft moving away. After a few seconds it sets the camera to the correct camera position but does not set orientation to the targeted position. The orientation is set to the ground at the camera position.

Repro steps:

Attachments:

Private attachments: Send a PM to @PrivateContent with the link to this topic and the link to download your content

2

I confirm that there is a problem with the WORLD referential — or perhaps something we haven’t fully understood.

Via referential aircraft:

Via referential world:

3

Hi,

There is indeed a mistake in the referential computation when using the targetted variable in World referential. This will be fixed during SU5 flighting.

About the short delay needed when moving the camera, it is discussed here.

Thanks for pointing out the problem.

Best Regards

Maxime / Asobo

4

Hi,

Following the ongoing tests I’m currently performing, I’m encountering what appears to be a fundamental limitation — but I want to make sure I’m not doing something wrong before reporting it as a bug.

What I’m trying to do

I’m calling SimConnect_CameraSet with the WORLD referential and the ALL_ROTATION mask (POSITION | ROTATION | FOV | REFERENTIAL) to move the camera to a specific lat/lon/alt position at regular intervals. A single call works perfectly. The issue appears when I send updates at a high rate.

I am not using a target.

Observed behavior

Below approximately 500 ms between calls, updates become unreliable. Below approximately 250 ms, they stop being applied entirely — the camera freezes. This happens regardless of whether I use a DispatcherTimer, a dedicated background thread, or direct P/Invoke calls with no UI involvement at all. The issue is not on the client side.

My question

Is there an intentional rate limit on SimConnect_CameraSet when using the WORLD referential? Is the command processed once per sim frame, meaning the effective maximum update rate is limited by the simulator’s framerate (~16 ms at 60 fps)? And if so, what happens when the client sends commands faster than that — are they queued, dropped, or does it cause the connection to stall?

I also tried using the Frame system event to synchronize my calls with the simulator, but the behavior was the same.

Why this matters — multiplayer aircraft tracking

If WORLD referential updates are indeed throttled or capped, this has a critical implication: it becomes impossible to smoothly track a multiplayer aircraft with an external camera.

The AIRCRAFT referential works perfectly for the user’s own aircraft, but it cannot be used for a multiplayer or AI aircraft. WORLD is the only option in that case. If WORLD cannot sustain updates at 25 fps or higher, real-time external camera tracking of any object other than the user aircraft is simply not achievable with the current API — regardless of how the client is implemented.

Is this a known limitation? Is there a recommended approach for this use case that I might be missing, or is this something that could be addressed in a future update?

I’m posting this as a follow-up, but I can open a new topic if needed.

Thanks.

5

I played more with this today, and can confirm the findings that DeelLav described above.

As it is now it is useless for high rate use, i.e for AI aircraft that is flying.

6

The problem with any Simconnect set functions is that they are asynchronous so there’s absolutely no guarantee they’ll arrive when needed.

We learned that the hard way with P3D and they implemented a way to call into Simconnect synchronously for such sets (also for lat/lon/alt on user and AI objects).

That would be ideal if it can be done.

7

Is this problem also affecting just reading the position of the current camera, specifically the altitude ?

I’ve done a small test, using World referential, and while Lat/Lon are perfect as I expect, the altitude is weird:

  • my test airport is located at 106.95 m AGL
  • the user airplane position is reported at 109.406 m
  • I’m on a 737, so the difference between airplane datum and the ground altitude is 2.456 m, so it all checks out normal.

However, the camera position reported when I’m sitting in the cockpit, while absolutely precise in lat/lon, returns this:

161.906 m - in the default VC view
164.730 m - in external view
161.908 m - in showcase view after a reset
150.248 m - if I go down with the drone at ground level, so I can’t go down any further.

Note that, I’m not trying to acquire the camera, I’m only reading the current position.

8

geoid

image
image350×350 6.93 KB

9

Of course, that must be it. Well, I guess it might be easier to use if we could get the geoid correction taken into account automatically.

As a temporary workaround, I’m just reading the airplane absolute altitude and I’m adding it to the camera altitude component returned by the getCamera() using the Aircraft referential, that gives me an accurate value.

10

hi ! can ask if someone noted this … SubscribeToCameraStatusUpdate managed via c# doesn’t work at all …. If yes I fill a bug … thanks

11

Not working for me in managed code.

12

Has someone noted this……. simconnect.CameraEnableFlag((uint)SIMCONNECT_CAMERA_FLAG.ABOVE_GROUND);

not having any effect when using CameraSet with referential WORLD

There also seems to be issues with reading the camera altitude with SimConnect_OnRecvCameraData.

I set up a camera with referential AIRCRAFT and x= 0, y=0, z=0 where a B737 aircraft is on runway that has an altitude of 1124 feet( also read on the PFD), reading the camera altitude from SimConnect_OnRecvCameraData gives not the 1124+ , but an altitude of 313 meter(1029 feet).

Copilot gave me a better understanding of the altitude issue above.

:compass: What CameraGet actually gives you
CameraGet returns the camera’s ECEF position (X, Y, Z) or a derived ellipsoid altitude depending on which helper you use.
That altitude is:
h = height above WGS84 ellipsoid
This is GPS‑style altitude, not MSL.

:airplane: What PLANE ALTITUDE gives you
from SimConnect is:
H = orthometric height (altitude above geoid / MSL)
This is the “true altitude above sea level” used by:
• Terrain
• Airports
• ATC
• Charts
• Most of MSFS’s internal systems

:globe_showing_europe_africa: Why they differ
Because: h is not H

They differ by the geoid height N:

h = H + N

And in most of the world, is 30–60 meters (≈100–200 ft).
That’s exactly the kind of offset you’re seeing.

:white_check_mark: How to make them match
You have two clean options:

Option A — Convert CameraGet altitude to MSL
If CameraGet gives you ellipsoid height h:

H = h - N

Where N is the geoid separation at the camera’s lat/lon.
MSFS internally uses EGM2008, so you need the same model (or a close approximation).
This will make camera altitude match exactly.

13

Confirm that the Camera now work with REFERENTIAL WORLD and ALL_TARGETED setting.

See: https://youtu.be/kjWOJlD2V_4

But, it is not very suitable for viewing user aircraft or AI aircraft in flight as the rendering of the aircrafts are not that good.

14

Hello everyone,

There seem to be different subject being discussed here.
My understanding is that the issue reported originally is addressed with SU5 Beta 1.7.9.0.

If there are other unresolved issues, please create a separate dedicated bug report.
I can move some of the post from this thread to a dedicated thread if needed.

Regards,
Sylvain