Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CSM] Add function to set the FOV of the local player #5797

Closed
wants to merge 4 commits into from

Conversation

bigfoot547
Copy link
Contributor

No description provided.

@paramat paramat added @ Script API Feature ✨ PRs that add or enhance a feature labels May 22, 2017
@nerzhul
Copy link
Member

nerzhul commented May 22, 2017

Thanks but you missed the feature merge window, it will be delayed on next release

@bigfoot547
Copy link
Contributor Author

I understand. :'(

@nerzhul nerzhul added this to Feature PR in Minetest 5.0.0 blockers May 23, 2017
@nerzhul nerzhul added this to the 0.5.0 milestone May 26, 2017
* Act as if `message` was typed by the player into the terminal.
* `minetest.run_server_chatcommand(cmd, param)`
* Alias for `minetest.send_chat_message("/" .. cmd .. " " .. param)`
* `minetest.clear_out_chat_queue()`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why remove this ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nerzhul It was a mistake when copying stuff... I will fix it in a future commit.

src/camera.h Outdated
return m_cache_fov;
}

inline f32 getZoomFov()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all getter should be const functions

@SmallJoker
Copy link
Member

What about the zoom feature we've already got? This PR in combination with a key press getter function will make the required privilege superflous.

@Desour
Copy link
Member

Desour commented Jun 1, 2017

@SmallJoker The minimum value of zoom fov is much lower than the one of the normal fov.
Or aren't the added functions limited? That would be great IMO!

@nerzhul
Copy link
Member

nerzhul commented Jun 3, 2017

Okay for me

@nerzhul nerzhul moved this from Feature PR to Ready to merge in Minetest 5.0.0 blockers Jun 4, 2017
src/camera.h Outdated
inline void setFov(f32 fov)
{
m_cache_fov = fov;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quite nonsense to have getter and setter functions for m_cache_fov and m_cache_zoom_fov. If there were boundary checks, this would be acceptable but how it is right now you could make them public as cache_zoom.

@nerzhul
Copy link
Member

nerzhul commented Jun 4, 2017 via email

@bigfoot547
Copy link
Contributor Author

@SmallJoker the range is limited because of this, right here.

@SmallJoker
Copy link
Member

@nerzhul Well, we already have public members for objects. The best example for this is the Player class.

@bigfoot547 I'm talking about limits when setting the cache_fov/cache_zoom_fov variables to a new value. The range limit is done in each Camera::update call and does not affect the saved settings at all. That's why I would prefer to expose this variable as public instead of adding functions.

@nerzhul
Copy link
Member

nerzhul commented Jun 4, 2017

@SmallJoker yes i know we have that ugly interface in player; i started to cleaning up years ago by moving some attributes to PlayerSAO/RemotePlayer or LocalPlayer for client, but not finished yet. Having getter and setters has no performance impact on code (they are inlined in majority cases), and we respect properly the difference between a struct and a class (class intend to have private members and struct public members)

@@ -842,16 +842,25 @@ Please do not try to access the reference until the camera is initialized, other
* Returns with same syntax as above
* `get_fov()`
* Returns:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you fix those spaces ?

* `save_fov()`
* Sets the "fov" setting to `get_fov().actual`
* `save_zoom_fov()`
* Sets the "zoom_fov" setting to `get_fov().zoom`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just add a persist boolean argument to the FOV setters.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@paramat
Copy link
Contributor

paramat commented Jun 17, 2017

A description in the first post would be nice, makes review easier.

@ShadowNinja ShadowNinja moved this from Ready to merge to Feature PR in Minetest 5.0.0 blockers Jun 17, 2017
@nerzhul nerzhul moved this from Feature PR to Ready to merge in Minetest 5.0.0 blockers Jun 17, 2017
@nerzhul nerzhul moved this from Ready to merge to Feature PR in Minetest 5.0.0 blockers Jun 17, 2017
@paramat
Copy link
Contributor

paramat commented Jun 20, 2017

SmallJoker wrote:

What about the zoom feature we've already got? This PR in combination with a key press getter function will make the required privilege superflous.

@SmallJoker did you get a response to this?
Since this is CSM, altering FOV must surely need the 'zoom' priviledge? The current Z key zoom is clientside which is why a priviledge was added for that.

The zoom priviledge needs discussing first.
If the 'zoom' priv is not checked in this PR these functions would need to be restricted by the flavour PR @nerzhul .

@red-001
Copy link
Contributor

red-001 commented Jun 20, 2017

why do we even have a zoom privilege in the first place?

@paramat
Copy link
Contributor

paramat commented Jun 20, 2017

See the PR thread that added zoom. Zoom adds a 'superpower' to a player so a restriction was required for survival such that a player would need to craft a telescope type item before being able to zoom.

@bigfoot547
Copy link
Contributor Author

What's wrong with the current implementation?

@paramat
Copy link
Contributor

paramat commented Jul 17, 2017

Sorry didn't see the line above, seems ok then.

@bigfoot547
Copy link
Contributor Author

Thanks @paramat

@@ -841,17 +841,25 @@ Please do not try to access the reference until the camera is initialized, other
* `get_camera_mode()`
* Returns with same syntax as above
* `get_fov()`
* All values are in degrees
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation should match other lines in this section.

* Pass true to the second argument to save the zoom fov to the setting.
* `set_zoom_fov(fov_degrees, [persist])`
* Sets the FOV for the local player when zoomed in
* Pass true to the second argument to save the zoom fov to the setting.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation should match other lines in this section.

y = float, -- Vertical FOV
max = float, -- The maximum of x and y
actual = integer, -- What the FOV of the player would be (not adjusted for zooming)
zoom = integer -- What the FOV of the player when zooming would be
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the meaning of 'would be' in these lines? How is it different from x,y? This needs clarifying.

@bigfoot547
Copy link
Contributor Author

@paramat: I have rebased and addressed your reviews, so can you please review again?

Conflicts:
	src/camera.h
	src/script/lua_api/l_camera.cpp
@bigfoot547
Copy link
Contributor Author

needs a rebase again...

@bigfoot547
Copy link
Contributor Author

Rebased. @SmallJoker @paramat Please review. I don't want this PR to sit doing nothing :L

Copy link
Member

@rubenwardy rubenwardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be added to CSM flavours.

@bigfoot547
Copy link
Contributor Author

Ok, I'll look into it

@paramat
Copy link
Contributor

paramat commented Nov 30, 2017

👎 nerzhul this can't be merged because it conflicts with the zoomFOV changes being made by lhofhansl and me, and has errors.
See #6650 , this PR is low priority and should wait until that is merged, and then reworked around the new approach.

In this PR camera FOV is now restricted to 7 to 160 when it needs to range from 1 to 160.
Per-player ZoomFOV has to be overridable by the server when it is set by #6650
Client-settable ZoomFOV must be limited to a minimum of 15 degrees as in #6650 , because zoom now loads distant terrain which puts a load on the server and gives the player an advantage of being able to generate and load terrain beyond the server's maximum generate and send ranges.
Client-settable zoom should not affect the server and cause it to generate or load terrain beyond these ranges.

Is this useful for server-provided CSM? That is our new decider on CSM features, as CSM has to be as minimal as possible. If it is, it needs to be controlled by flavors as it is something that gives a player an advantage: if the client has distant mapblocks loaded, it can look at those and magnify them.

@paramat paramat added Action / change needed Code still needs changes (PR) / more information requested (Issues) @ Client Script API Low priority labels Nov 30, 2017
@paramat
Copy link
Contributor

paramat commented Dec 2, 2017

👎 Actually, sorry but the zoom FOV parts of this can't be merged in any form, because zoom now loads and/or generates distant world like a telescope, a powerful ability that must be under complete server control and shouldn't be added to CSM. It also conflicts with the intentions of recent zoom changes by lhofhansl and myself.

If you split off the normal FOV feature that might be fine.
A description in the first post is needed, it's not a simple or trivial change so it should have a clear summary. I've asked twice before, you may not get reviews or attention without a description.

@paramat paramat added Won't add The feature request was rejected and will not be added. Action / change needed Code still needs changes (PR) / more information requested (Issues) and removed Action / change needed Code still needs changes (PR) / more information requested (Issues) @ Script API Won't add The feature request was rejected and will not be added. labels Dec 2, 2017
@bigfoot547
Copy link
Contributor Author

:/ well, I guess there's only one thing to say.
https://youtube.com/watch?v=cdEQmpVIE4A

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Action / change needed Code still needs changes (PR) / more information requested (Issues) @ Client Script API Feature ✨ PRs that add or enhance a feature Low priority One approval ✅ ◻️
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants