Split: Oolite Headtracking

[Smivs]

Wow! I like the way the future is looking

[maik]

Click the image below for a sneak peek of Oolite free-view.

Juicy!

[Diziet Sma]

Thanks, Getafix.. that looks just awesome.

I can see one wee problem though, (I think).. since, unlike in ED, there's no cockpit window frame or stationary gunsight to use as a reference, how do you know when you're looking straight ahead? Also, combat might be kind of "interesting", since the gunsight follows your head.. Any chance you could make an example video of using the headtracker in combat?

[Getafix]

First let me share that Oolite free-view was one of my visions that is dated back to 2008! I'm really excited to share this proof of concept with the community. The idea is to warm up the discussions and trigger the interest for keen developers (i.e. the exact opposite of me).

Gunsight, target reticle(s), Oolite fixed views, cockpit view, head-tracked weapons, head-tracked external views, Oolite gameplay, HUD OXPs, free-view as oxp or as Oolite default feature, these are only some of the points to be addressed (not necessarily all at once). The integration points with the rest of Oolite features need to be identified and the impact (as well as the development cost and feasibility) needs to be evaluated in order to start prioritizing.

My idea for the gunsight is to have a fixed reticle as a reference point to indicate the center of the view and have the gunsight always point to the orientation of the selected weapon. This approach will have the gunsight move to the opposite way of where you turn your head to.
Another thought is to move whatever is considered as HUD (radar, gauges, reticles, etc.) as a whole entity to the opposite direction of where the head moves.
Perhaps, the introduction of a moving cockpit could help the pilot's orientation too.

[Day]

Wow, the video is breathtaking, thank you for this !

This functionality was one of those I longed to see developed since I discovered oolite 2 months ago.
(I've got a full list, I've begun by the one I miss the most: https://bb.oolite.space/viewtopic.php?f=2&t=13157 You might want to test it with the free view, hehe).

I'm ok to help the discussion go along.
I'll begin here to draft some opinions (to be destr... amended by others).
Feel free to correct me, everybody.

We have already several views: forward, aft, starboard and (I forget), plus others. "Free view" is another view like these ones.
Like these, it may be selected and deselected.

I take you named it "Free view" rather than "Head view", because narratively it could be anything (the droid view, the copilot view (wow, playing to oolite with a friend shooting the lasers!), one of the "telecommanded ships" view, etc.).

Gunsights: they are linked to an equipment. It would make sense to develop a rotating laser following the free view.
That the main weapons gunsights (not forgetting the aft or side weapons!) appear in the free view would make sense.

I think free view should be available as a tool for oxps (freeview for guiding a missile is a no-brainer :-p).
The standard free view should be enabled via game options, if only for hardware reasons.

I think it would be best to be able to define a hud per view.

I'm all in favor of a 3D cockpit, but I think it is a whole project in itself to be able to propose meaningful modding possibilities.
(I know, once freeview is available, a 3D cockpit will be wanted by everybody...)

PS: is there a delay between your actions and the movement of the camera?

[Wildeblood]

We have already several views: forward, aft, starboard and (I forget), plus others. "Free view" is another view like these ones.
Like these, it may be selected and deselected.

I take you named it "Free view" rather than "Head view", because narratively it could be anything (the droid view, the copilot view (wow, playing to oolite with a friend shooting the lasers!), one of the "telecommanded ships" view, etc.).

It's already possible to script the camera position when in custom views. But it's a bit kludgey to use because of the way custom views are selected: cycled through with repeated key presses, instead of a dedicated key for each.

I'd be in favour of losing the port & starboard views (i.e. demoting them to particular custom views) and completely removing the just-plain-silly side lasers, and having something like button (1) forward view (2) aft view (3) cycle custom views* (4) free view. That frees up one key on the keyboard.

Adjusting the angle of view has to be from the keyboard in real time. If it's only adjustable from the settings screen or JS lots of people will never find it.

* Or preferred custom view, with some obscure procedure to select a preference from the list of custom views.

[QCS]

I'd be in favour of losing the port & starboard views (i.e. demoting them to particular custom views)

Contra. I am using a left-side mounted mining laser and have become very good at this. Without the shortly available LMSS (which I didn't yet come around to install), this was a good way to keep your main lasers combat grade. And even now, every second asteroid belt is infested with not-so-friendly beings, thus having to wait for the LMSS to switch does not sound like a viable option to me.

Also, this is classic Elite feeling, plus makes some actions easier (going around a planet on Jumpdrives outside of the locking zone while keeping the target station visible).

[Wildeblood]

I'd be in favour of losing the port & starboard views (i.e. demoting them to particular custom views)

Contra. I am using a left-side mounted mining laser and have become very good at this. Without the shortly available LMSS (which I didn't yet come around to install), this was a good way to keep your main lasers combat grade. And even now, every second asteroid belt is infested with not-so-friendly beings, thus having to wait for the LMSS to switch does not sound like a viable option to me.

Same here. When I played it was always forward beam, aft military & side mining lasers. But your objection is to losing two laser mounts, not the special status of the port and starboard viewpoints. I think it's obvious a parallel secondary weapon facing forward is preferable to the side weapon mounts. The laser definitions could include a parameter to indicate whether it is a combat or ancillary weapon, and the mounts should be three: forward combat, forward ancillary & aft (either weapon type).

Also, this is classic Elite feeling...

No head tracking or adjustable field of view for you, then.

[Day]

I'd be in favour of losing the port & starboard views (i.e. demoting them to particular custom views) and completely removing the just-plain-silly side lasers, and having something like button (1) forward view (2) aft view (3) cycle custom views* (4) free view. That frees up one key on the keyboard.

I propose that a laser could be attached to a custom view, controled by JS so that modders may come with innovative oxps .
This way, we generalize the oolite code (standard views can become instances of custom views) and open up possibilities.

In fact, i realize that a view is a point in space, an orientation and a fov.
The point may be attached to whatever object, the orientation may be fixed or mobile (freeview), the fov may be fixed or controled.

When a legacy functionality may be coded via oxp rather than objective-c without performance impact, what is the accepted ideal best path?
Is it to reimplement the code in an oxp which will always be loaded? Or to let it in the obj-c code?
(A priori, i would think it is to reimplement it in oxp so that the obj-c codebase decreases in size when possible. There are less obj-c developers than js developers, methinks.)

Adjusting the angle of view has to be from the keyboard in real time. If it's only adjustable from the settings screen or JS lots of people will never find it.

Well, if "fov from keyboard/joystick" doesn't come as a standard function, I'd like to make it available at least through an equipment oxp.

[another_commander]

When a legacy functionality may be coded via oxp rather than objective-c without performance impact, what is the accepted ideal best path?
Is it to reimplement the code in an oxp which will always be loaded? Or to let it in the obj-c code?
(A priori, i would think it is to reimplement it in oxp so that the obj-c codebase decreases in size when possible. There are less obj-c developers than js developers, methinks.)

This. Ideally, you would off-load the functionality to core resources.

[Cholmondely]

Click the image below for a sneak peek of Oolite free-view.

Just curious...

did anything further happen with this?

[another_commander]

We just got a working prototype but that was it - the project did not move beyond that stage. The code is still on github though (headtrack branch), in case anyone would be interested to take it further.