@wraitii @vladislavbelov I believe you two can review this.

Is this something we want also for the engine? Well maybe for campaigns and cinematics but we have smth similar in Atlas.

Just for reference. This is the only use of GetCameraPivot I was able to find the public mod.

This patch would change the code to something closer to

function jumpCamera(index)
{
	let position = g_JumpCameraPositions[index];
	if (!position)
		return;

	let threshold = Engine.ConfigDB_GetValue("user", "gui.session.camerajump.threshold");
	let camera Engine.getCamera();
	if (g_JumpCameraLast &&
	    Math.abs(camera.pivot.x - position.x) < threshold &&
	    Math.abs(camera.pivot.z - position.z) < threshold)
	{
                camera.moveTo([g_JumpCameraLast.x, g_JumpCameraLast.z]);
	}
	else
	{
		g_JumpCameraLast = camera.pivot;
                camera.moveTo([position.x, position.z]);
                // alternatively one can implement more getter/setter to make this work
                // camera.pivot.x = position.x
                // camera.pivot.z = position.z
	}
}

There is some related code in D3507.

In D4660#198273, @edoput wrote:

I haven't been able to wrap my head around the pyrogenesis Script interfaces but I found some for Spidermonkey development that were enough to write this patch. I'm sorry that it doesn't fit at all with the rest of the engine but hey it works :)

I think your main problem has been that we don't generally create the wrapper objects in the engine. We either just have straight functions, which are fairly straightforward, or Proxy objects, which are less straightforward.

This patch also improves the current developer experience. JS developers come from the web background and expect some form of objects to be available and their runtime representation be connected to the native counterpart. Is this something we want also for the engine?

So to answer that ^: Not really that common right now.

Having a camera object might be useful if having some permanent state is relevant, or if getter properties are regularly accessed, which is maybe the case. But if so, I think it would be better to implement it as a proxy object, like the GUI objects.

On the patch itself: 'phi' and 'psi' are not really obvious names, and in general we probably want 'position' / 'rotation' & just some 'positionAt', 'lookAt' functions.

Thank you all for the feedback and the time.

Do you have an example for a proxy object that I can take a look at?

I saw the GetCameraRotation, SetCameraRotation pair is already available in another differential and I am happy to submit that instead of this.

Should I open another differential with only that changes?

In D4660#198512, @edoput wrote:

Should I open another differential with only that changes?

I think the simplest would be to create a diff for solely the functions, so that we can merge those. That should be easy.

Then you can expand this diff, but at least your mod is supported by native 0 A.D.

Do you have an example for a proxy object that I can take a look at?

So, the example in the current code is at source/gui/scripting/JSInterface_GUIProxy.h, and also the _impl.h & .cpp files. They are complex, not gonna lie. Depending on your familiarity with C++, you might try to read through them and understand what's happening.
For the case of a Camera object, you would mostly just need a subclass from js::BaseProxyHandler and to override get/set appropriately.