Fov is now accessible through javascript.

[DaymareOn]

Oolite.gameSettings.fov (read-only): player game option fov, in degrees
PlayerShip.viewFov (read/write): current view fov, in degrees

Tested with an oxp I'm currently working on.
How could this pull request be validated? Do you want the oxp to test?

[AnotherCommander]

No thanks, the OXP will not be necessary. I'll test the request using the Debug Console.

[DaymareOn]

Perfect, thank you.

I didn't know yet this console. I'll look for it.

[DaymareOn]

By the way, I uploaded here the fisheye oxp I used to test this code:
https://github.com/DaymareOn/OpticsOXP

[AnotherCommander]

There are a few problems with this request, some are more serious than others.I had similar code to enable JS access to FOV ready since a few days ago, but I never committed it because I hit the same problems as we have here. Here goes:

1. Exception in the game options screen if FOV has been set to higher than maximum or lower than minimum via Javascript. I guess this is the easiest of all to fix.
2. The FOV value shown in the gameoptions screen changes as JS viewFov is changed. This is quite serious. As a player, when I set an option to a preferred value, I don't expect and don't want the game to be changing it at any point for me. As a player, if I set FOV to 65 deg in the options, that's what I always epxect to see, unless I go on and change it myself, again via gameoptions. Having scripts being able to change that preference value whenever they want is bad game design and a solution is required if we are to proceed with allowing them to have access to FOV.
   So, what can we do? In the very first request that was submitted, Chris made a comment which, in my opinion, is the only viable way of doing this and should be considered very seriously. I quote:
   "I think it should probably either be a Game Options setting - to calibrate it to display hardware appropriately - or an in-game setting changeable by JS. I suppose you could set the default FOV in Game Options, and then have the in-game setting be a relative FOV which scales around 1.0?"
   Again, assuming we do this, if an OXP applies a FOV multiplier and I go to the options screen while this multiplier is active, the FOV reported there would not be the acutal one on the screen at that time. So we need a way to let the user know that the FOV they see there is multiplied by a factor. We can either show something like a star (e.g. 57.2 deg *) to indicate that the FOV reported is being multiplied by a value or show the actual value (e.g. 57.2 deg (x1.15), with default being 57.2 deg (x1.0)). In any case, the idea is that the user should laways see in gameoptions the value that they have selected, not a value given by an OXP at any random time.
3. If I change the FOV via JS, I can see the value changed in gameoptions (as mentioned above), but in oolite.gameSettings.fovValue I keep seeing my original preference. This is inconsistent.

[DaymareOn]

1: Acknowledged and to fix :)

2: I'm ok that oolite.gameSettings.fovValue should not be changed by js calls, so it's a bug to fix, I'll do it. I developed this code with this idea on mind.

As the viewfov settable by oxp is an angle, I would prefer to let the oxp dev set an angle as they see fit rather than a multiplier.

3: well, i would think it means the real gameSettings.fovValue is not modified, only the display of this option in the GUI. Once the bug #2 is fixed, #3 should be fixed too.

[AnotherCommander]

If the OXP sets a FOV angle, what would the user see when they get to the gameoiptions screen as FOV value? Seeing the user preference value when the actual FOV is different by OXP change, and without any indication that it has changed externally, is not an option. Seeing two angles (like e.g. 57.2 deg (65 deg)) is confusing. Chris' proposal makes perfect sense and avoids confusion as much as possible. At this moment I cannot think of a better way to handle this.

[DaymareOn]

Ok, I didn't understand that you proposed we see two values in the gameoptions screen:
player selected and actual fov as eventually modified by oxp.

I think it's a good idea, and to show it via a multiplier too.

What I am against is to have the player.ship.viewFov as a multiplier rather than an angle.

[Norbylite]

How about displaying FOV after TAF in FPS data table?

[AnotherCommander]

In my opinion, it should be a multiplier relative to currently user selected FOV. Because this one is a user preference, OXPs should be respectful of the player's choice and not apply arbitrary changes. This is why the relative FOV proposal is a good one: It respects the player's desires. As a user, I may not want a FOV of 130 degrees just because the OXP made it jump from my preferred 45 deg to that value, but I would probably be OK with a slight zoom / unzoom function using a FOV relative to what I have chosen (and for this reason, the multiplier should be within well defined limits). It should be kept in mind that the main scope of FOV's inclusion in the code has been from the beginning to satisfy a user need for modifiable view, not to serve as a gameplay function.

I guess what I am trying to say here can be summarized thus: Explicit angle settings by OXP should be avoided because the FOV is already a game option and that's the only place where the explicit settings should be defined.

[DaymareOn]

Ok I understand your reasoning why you would prefer to set a multiplier even for the angle.
It's a good one and I agree, let's do it like this.

Concerning fov not to be used for a gameplay function, well I respectfully disagree.
I totally understand why you wouldn't like the fov zoom/unzoom using two more keys, that and having used it, I think it's not quite well integrated in the gameplay(1).

But I think it should be develop'able through oxp, as oxp are a way to let any in the community do what they wish. So the fov limits shouldn't apply when set by oxp (except verifying that it's positive and inferior to 180°, of course).

Let's take my wip FishEye oxp for example: it's the responsibility of the oxp dev to check that the fov he sets is usable. For example, I predict this oxp will have some problems with an angle of 120°: it's designed and tested for the cobra mk3, not yet tested for other ships.
If the oxp doesn't reach a certain quality level, it doesn't have to be integrated into the oxz downloadable repository.

Summarized, what I'm trying to say is I would prefer to let the original gameplay in the unmodified game, and let the oxp'ers come with a maximum of evolutions, including related to fov(2).

(1): so I'm in favour of removing it and reimplementing the function through several well-defined oxp.
(2): I play with almost all oxz enabled and some oxp too. I like the feeling of wonder when I discover something totally unexpected. Almost, the only oxz I disabled are music-related.

[DaymareOn]

@Norbylite : sorry, what is TAF, and what is the FPS data table?

[AnotherCommander]

@DaymareOn : I understand the merits of being able to use something like field of view within gameplay and that's why I said earlier that the main (emphasis on main) scope of its implementation is to satisfy a modifiable view requirement; that does not exclude its use in gameplay and, in fact, you will find that FOV is the only game option that we are discussing as a possibility for in-game control. All other options are just that: options settable in the F2 screen and that's it. Gamma is not OXP controllable, neither are resolutions and so on and so forth. But, exactly because the FOV is the only option that we are discussing about setting from within game, we need to tread very, very carefully and keep in mind the feature's primary scope. Whatever we do, we should not compromise that scope.

Now, for limits, I am open to discussion and would like to read others' opinions too. Without having given it excessive thought, it just feels wrong to me if game rules can be skippable by OXPs. Still, specifically for FOV, I would be interested to see an implementation as you imagine it and take it from there. It could be something that we can work on.

Regarding TAF: It is the Time Acceleration Factor and Norby refers to the information printed on screen with Shift-F. However, I don't think this is a workable solution, because a) this information does not appear on deployment builds and b) it still causes confusion if a FOV angle is reported with Shift-F and another angle is reported from within options.

[DaymareOn]

I totally agree on everything you wrote :)

Regarding TAF, ah ok, I never used it yet.

Regarding implementation via oxp, let's have a digression on where I am.
I published a wip fisheye oxp setting fov to 120° continuously from gameoptions fov in 30 frames, and coming back to gameoptions fov in 30 frames too.
When changing view, the fov is resetted to gameoptions fov.

I'm now working in two directions:

• 1: "bigger window effect when in torus mode",
• 2: reimplementing fov variation in an telephoto-like equipment, proof of concept to remove the core code using 2 keys. Another equipment I'd like to do is an equipment with fov controled by joystick slider, to be used during dogfights; fov variation would probably be gameoptions fov to 80/90°.

Concerning point 1, I reviewed how the effect was done in Dragon Quest 8 when riding the saber tooth tiger. Well, it's not a fov variation, just a point of view variation: when running, the camera is set some distance behind. That's why I created a topic to know if it was possible to switch view from oxp: to do this, I need to set a custom view on onTorusEngaged() event.
I'd be willing to code the function allowing to switch the view from oxp :) to be able to test if the effect is interesting.

Concerning point 2, I opened another topic concerning key assignment of oxp functions. To be able to remove the fov variation by keys coded in core source, we'd need to be able to let oxp declare functions that players may assign to keys/buttons/axis.

[DaymareOn]

Point 2a and 3 are fixed as far as I have tested.
Remains point 1: "Exception in the game options screen if FOV has been set to higher than maximum or lower than minimum via Javascript. I guess this is the easiest of all to fix."
and point 2b: have the js fov as a multiplier rather than an angle.

[DaymareOn]

Point 1 has been fixed with this commit too, as far as I have tested.

[DaymareOn]

Point 2b is now fixed.

[AnotherCommander]

The request is deferred to post-1.82 due to code freeze, There are still some issues that I would like to discuss and get opinions on, but right now we need to give priority to 1.82.

[DaymareOn]

Good news that 1.82 is coming :-)

Issues/discuss/opinions: with pleasure.

I'm currently very slowly trying to understand what is needed to let oxp devs let a function be assignable to a key. I'm nowhere near done.