My decision to place control swithces into InputManagerImpl class was quite bad. Troubles come when switch is needed in another place. For example, DisablePlayerLooking not truly disables mouse, but disables player looking actually - player still able to control camera on preview or in vanity after TVM. All this camera stuff is handled inside MWRender::Player, so I need access to switches inside.
Also, when switches are in InputManager I have to add appropriate methods to World to call MWRender::Player methods through RenderingManager. That's ugly and I'm sure these switches aren't part of the game world itself.
In addition, there are places where I need access to some data stored in MWRender::Player such as actual player pitch angle (for move in appropriate direction). It's wrong to fetch this data directly from camera and it's better to hide player camera structure at all. The same problem with managing player height.
My suggestion is to add class (accessible from Environment) somewhere that can directly access MWRender::Player and manage control switches. Or to add separate classes for switches and player. Or to do sometghing else - discussion is welcome.
Player data interface
Re: Player data interface
More like "Or to do something else". Let me think about it.
Re: Player data interface
Player data required (angles, height) can (and should, perhaps) be moved to MWWorld::Player and accessed when needed.
Re: Player data interface
Still not sure about the angle, but don't we get the height from the model data?