[CameraAPI] CameraGet behavior requires clarification

I would like a clarification about SimConnect_CameraGet(). Assume the add-on doesn’t want to control or set the camera, but just read its position, the documentation starts with:

The SimConnect_CameraGet function is used to get the current add-on camera properties, regardless of whether it has been acquired or not.

However, it later says:

This function will generate a SIMCONNECT_DATA_CAMERA struct which will contain all the information about the current camera, unless the camera has not been acquired, in which case a SIMCONNECT_EXCEPTION_CAMERA_API exception will be sent.

And in fact this is what happens: if I don’t acquire the camera, calling CameraGet will return the exception 46 (CAMERA_API).

But I found it doesn’t seem to be required to have the camera currently acquired, as long you acquired it at least once from your app so, by doing this during startup:

SimConnect_CameraAcquire(hSimconnect);
SimConnect_CameraRelease(hSimConnect, "");

I can then call CameraGet() for the rest of the session without exceptions.

Is this the intended behavior ?

Hello @Umberto67

I moved your post to a dedicated bug report as it will require some tracking from us.

The “whether it has been acquired or not” in the description is indeed confusing.
It’s rather “whether you have acquired it or not”.

The camera needs to be acquired by someone for the CameraGet to work. This is not a function you can use with any camera from the sim, it only works for the dedicated API camera.

The function returning a position when you have previously acquired it but it has been released since is not the expected behavior and will return the last active position.

We will fix this and review the documentation.

Regards,
Sylvain

Thanks for the clarification but, now I need another one:

It is fundamental for me being able to read the current position of any camera, including all the default ones and, in fact, it seems to work if I acquire/release on start, the CameraGet() it’s not stale if I call it after releasing it, and it returns the position of whatever stock camera is in use, and it is updated each time I call the function so, it all works.

This is just what I needed, with the only quirk I had to acquire/release on start.

So, can you confirm that, after the fix, you’ll only remove the need to acquire/release, but CameraGet() would still continue to work with any camera (default or custom) to allow getting the current camera position in real time ?

2 Likes

The problem is still there in the current 1.7.17.0 Beta, I noticed the following:

Calling CameraGet() will cause an exception 46 if the camera hasn’t been acquired in the current flightsim session. I guess this because the requirement is that in order to work, it must be acquired by some client, so restarting my client in the same flightsim session would work even if I acquired the camera in a previous run.

Acquiring the camera will cause the same exception 46 (which is the generic CAMERA_API exception) if the current camera is the First person/Avatar.

So, in order to JUST read the current camera, without any intention to modify it, any add-on should:

  • Subscribe to any camera changes, and don’t try to acquire the camera if it’s in Avatar mode, to prevent the exception preventing the acquisition
  • Perform a fake acquire/release JUST to allow itself to subsequently call GetCamera(), to prevent the exception on GetCamera() itself which would happen if nobody ever tried to acquire any camera in the current session.

All of this is caused unnecessary complications and potentially bugged (and needlessly replicated) code in all add-ons that only want to know the camera location.

In the first beta of the Camera API, before the restructuring, there was no need to acquire the camera just to call GetCamera(), so I really don’t understand why this requirement has been added.

An add-on that needs to just check where THE current camera is, in a purely read-only mode, regardless if it’s stock, customized or created by any previous acquisition, should be able to do so, without having to be involved in its acquisition, it will make all code simpler and bug-free, for all the usage case when changing/creating the camera is not needed.

2 Likes