[1.9.x - 1.12.x] Camera Tools continued v1.35.0 [2024-09-07]

[Entropian]

I'm using CameraTools 1.19.2.0 and Time Control 2.10.0.0.  I only found 1 DLL.  I'm booting up KSP with the verbose logging now.

[Entropian]

Found it!  BetterTimeWarp seems to be the issue.  When I uninstalled it, the entire problem just went away.  I'm guessing that BTW probably saw that the timespeed was below 1x, so it activated its camera controller, overriding CT/TC's camera things.  Thanks for your help!

[DocNappers]

14 hours ago, Entropian said:

Found it!  BetterTimeWarp seems to be the issue.  When I uninstalled it, the entire problem just went away.  I'm guessing that BTW probably saw that the timespeed was below 1x, so it activated its camera controller, overriding CT/TC's camera things.  Thanks for your help!

Well done! I haven't used BetterTimeWarp before, but looking at its source code, I see that it has a "ScaleCameraSpeed" toggle that messes with the flight camera:

//make camera speed not change with time warp
if (ScaleCameraSpeed && Time.timeScale < 1f)
    FlightCamera.fetch.SetDistanceImmediate(FlightCamera.fetch.Distance);

So, it's probably sufficient to just toggle that off. If that works, I can have CameraTools automatically disable it whenever CameraTools is active to prevent the weird interaction.

[DocNappers]

v1.20.0 of CameraTools is now (finally) released. I didn't quite manage to eliminate all of the drift in the stationary mode camera when maintaining orbital velocity, but it's pretty close. Changelog:

Bugfixes:

• Don't reset the zoom value when reverting the FoV.
• Fix the lower limit of the camera shake multiplier when using numeric fields.
• Make the config paths relative to the KSP app location (makes it more relocatable).
• Fix an NRE in the audio controller.

Improvements:

• Add a version number and activation toggle/indicator to the GUI.
• Separate zoom and autozoom parameters for the different modes so that adjusting zoom levels in one mode doesn't affect other modes.
• Tweak the camera shake slider to use steps of 0.1.
• Move the floating origin corrections for the stationary camera to the BetterLateThanNever timing phase to avoid the occasional flicker.
• Remove the 0 minimum of the max relative velocity to allow reverse fly-bys with the stationary camera again.
• Only disable TimeControl's CameraZoomFix while CameraTools is active so as to avoid interfering with that mod while CameraTools isn't active.
• Look for and disable BetterTimeWarp's ScaleCameraSpeed while CameraTools is active, since that also messes with CameraTools during slow-mo.
• BDA Auto Targeting: add an option to not target incoming missiles.
• Corrections to the KrakensbaneWarpCorrection for dogfight and stationary camera modes so that they work (almost) correctly at all altitudes and warp levels.
  • Known issues for the stationary camera when maintaining orbital velocity are:
    • When changing low warp rate at above 100km altitude a slow drift begins, as if the orbit calculation position is slightly wrong. I.e., starting at a given low warp and staying there is fine, but once changed the drift begins.
    • Below 100km altitude, there is a small unsteady drift when not in high warp (and exaggerated by low warp) and once noticeably present continues after entering high warp.
    • Switching in and out of map mode returns the camera to the wrong position.
       

[Entropian]

Found another interesting but minor bug.  If you enter the stationary camera mode while in flight view, switch to map view, then hotkey to exit from the stationary camera mode, it shows this weird projection of the active craft on the middle of the screen.  Here's a quick clip of it happening:

https://medal.tv/games/kerbal-space/clips/eExth-IGF7f1j/d1337MLjlIVh?invite=cr-MSxkOEUsNTcyODIyMDYs

[DocNappers]

8 hours ago, Entropian said:

Found another interesting but minor bug.  If you enter the stationary camera mode while in flight view, switch to map view, then hotkey to exit from the stationary camera mode, it shows this weird projection of the active craft on the middle of the screen.  Here's a quick clip of it happening:

https://medal.tv/games/kerbal-space/clips/eExth-IGF7f1j/d1337MLjlIVh?invite=cr-MSxkOEUsNTcyODIyMDYs

Lol, I didn't think of trying that. It must be a mix-up with the flight camera and whatever camera KSP uses for the map. I'll look into it.

[DocNappers]

v1.21.0 of CameraTools is now released (mostly for compatibility with an internal refactor in BDArmory). Changelog:

Improvements:

• Updated fields/properties for an internal refactor in BDArmory.
• Don't revert the camera when there's no further dogfight targets.

[Sisco]

On 3/18/2022 at 5:10 AM, Entropian said:

Found another interesting but minor bug.  If you enter the stationary camera mode while in flight view, switch to map view, then hotkey to exit from the stationary camera mode, it shows this weird projection of the active craft on the middle of the screen.  Here's a quick clip of it happening:

https://medal.tv/games/kerbal-space/clips/eExth-IGF7f1j/d1337MLjlIVh?invite=cr-MSxkOEUsNTcyODIyMDYs

@Entropian Are you sure it's related to camera tools? 

[DocNappers]

v1.22.0 of CameraTools is now released (mostly for compatibility with the imminent v1.5 release of BDArmory, but also with a speed boost for accessing fields/properties in BDArmory).

Bugfixes:

• Add check for the class type of VesselSpawner due to the current changes in BDA dev.
• Fix BindingFlags for initial reflection due to changes in BDArmory.

Improvements:

• Add a target centroid option for the dogfight mode.
• Replace reflection for BDArmory with delegates for much faster field/property access.
• Lower the log error for not being able to set IVA camera mode to a warning.
   

[Entropian]

Not sure if this question has been asked before (my apologies if it has); is there any way to persist camera positioning through a docking sequence and/or decoupling?  If I use StationaryCamera and target a specific part, it snaps to a different location relative to that part when I dock or decouple.

[DocNappers]

9 hours ago, Entropian said:

Not sure if this question has been asked before (my apologies if it has); is there any way to persist camera positioning through a docking sequence and/or decoupling?  If I use StationaryCamera and target a specific part, it snaps to a different location relative to that part when I dock or decouple.

Did you disable the "Vessel Center of Mass" option? It seems to be working correctly for me, though the camera drifts a little after docking (in low Kerbin orbit) for some reason. 

 

Edited July 25, 2022 by DocNappers

[Entropian]

Hmmmmm, I must have had that enabled.  Thanks for checking it out.

[Entropian]

@DocNappers I've been filming my next cinematic and I've several times needed something like the manual keypad control, but with smoothing.  Is this a possible feature that could be added, if I'm not blind and it already exists?  Thank you!

[DocNappers]

14 hours ago, Entropian said:

@DocNappers I've been filming my next cinematic and I've several times needed something like the manual keypad control, but with smoothing.  Is this a possible feature that could be added, if I'm not blind and it already exists?  Thank you!

It should be possible to add something like that. The easiest way I can think of doing so would be to have a toggle between keyboard input affecting position and affecting velocity, with an extra key that smoothly decelerates the velocity to zero.

[DocNappers]

v1.23.0 of CameraTools is now released, available via SpaceDock or GitHub.

Improvements / Bugfixes:

• Fix some memory leaks detected by KSPCF.
• Refactor integration with other mods into their own files (mostly). Some BDArmory-related settings may need resetting.
• Allow deploying to multiple KSP instances when compiling in Linux.
• Add speed free-move mode for keyboard input (default toggle 2).
  • Toggling this resets the speed to zero.
  • Disabled when in numeric input mode.
• Update numeric input fields when making changes with keyboard input.
• Add display field-width parameter to numeric input fields.

Edited September 3, 2022 by DocNappers

[GoldenCat]

I need some help with the camera tools mod. The numbers on my keyboard do not do anything in terms of movement with the camera. I can re-bind the numbers to that command but it doesn't work . Num lock has nothing to do with this as well. I have had this issue for a long time. Any help would be appreciated.

[DocNappers]

On 9/8/2022 at 2:34 AM, GoldenCat said:

I need some help with the camera tools mod. The numbers on my keyboard do not do anything in terms of movement with the camera. I can re-bind the numbers to that command but it doesn't work . Num lock has nothing to do with this as well. I have had this issue for a long time. Any help would be appreciated.

If you can bind the keys, then you should be able to use them to control the camera movement (note that they'll only affect the camera when CameraTools is active). Also, note that the defaults (written as [0], for example) are for the keypad, not the row above the qwerty row (just in case you're trying to use those).

Maybe you have some other mod that's interfering with keyboard input? Check for lines starting with "[EXC" or "[ERR" in the KSP.log file (in the main KSP folder) for any issues that might be related to CameraTools (or other mods).

[GoldenCat]

11 hours ago, DocNappers said:

If you can bind the keys, then you should be able to use them to control the camera movement (note that they'll only affect the camera when CameraTools is active). Also, note that the defaults (written as [0], for example) are for the keypad, not the row above the qwerty row (just in case you're trying to use those).

Maybe you have some other mod that's interfering with keyboard input? Check for lines starting with "[EXC" or "[ERR" in the KSP.log file (in the main KSP folder) for any issues that might be related to CameraTools (or other mods).

Where do I find the logs regarding Camera Tools?

[GoldenCat]

 

This is what I have found regarding any errors 

 

[WRN 19:05:26.380] Texture resolution is not valid for compression: 'C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\CameraTools\Textures\icon.png' - consider changing the image's width and height to enable compression
[LOG 19:05:26.380] Load(Texture): EditorExtensionsRedux/Textures/AppLauncherIcon-Off
[WRN 19:05:26.385] Texture resolution is not valid for compression: 'C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\EditorExtensionsRedux\Textures\AppLauncherIcon-Off.png' - consider changing the image's width and height to enable compression
[LOG 19:05:26.385] Load(Texture): EditorExtensionsRedux/Textures/AppLauncherIcon-On
[WRN 19:05:26.391] Texture resolution is not valid for compression: 'C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\EditorExtensionsRedux\Textures\AppLauncherIcon-On.png' - consider changing the image's width and height to enable compression
[LOG 19:05:26.391] Load(Texture): EditorExtensionsRedux/Textures/AppLauncherIcon
[WRN 19:05:26.396] Texture resolution is not valid for compression: 'C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\EditorExtensionsRedux\Textures\AppLauncherIcon.png' - consider changing the image's width and height to enable compression

[DocNappers]

8 hours ago, GoldenCat said:

Where do I find the logs regarding Camera Tools?

They're just part of the main KSP.log file and show up as lines starting with "[LOG 04:32:44.830] [CameraTools]: ...", but they're fairly sparse unless you set DEBUG = True file in the GameData/CameraTools/PluginData/settings.cfg (which will also display some debugging info on-screen).

The warnings about texture resolution and compression aren't a problem.

Btw, you do have the "Keypad Control" toggle enabled near the bottom of the CameraTools menu, don't you? (enableKeypad = True in the settings.cfg file.)

[OrbitalManeuvers]

If I may throw out a suggestion ... I'm picturing something I'd call a Landing Cam, might be useful for vertical landers only, but here goes. The options you have are X and Y offset, and Z AGL.  So when engaged, the camera is positioned at Z meters above the ground at the current location, offset by X and Y (obviously there are range limits here). It's fixed in that position, with focus on self. So the idea is you get close to the landing spot, engage the camera, engage an autolander, hide the UI, and you get a simple but nice landing shot. 

Is something like that even possible?

[DocNappers]

9 hours ago, OrbitalManeuvers said:

If I may throw out a suggestion ... I'm picturing something I'd call a Landing Cam, might be useful for vertical landers only, but here goes. The options you have are X and Y offset, and Z AGL.  So when engaged, the camera is positioned at Z meters above the ground at the current location, offset by X and Y (obviously there are range limits here). It's fixed in that position, with focus on self. So the idea is you get close to the landing spot, engage the camera, engage an autolander, hide the UI, and you get a simple but nice landing shot. 

Is something like that even possible?

That sounds like something that would fit within the stationary camera mode as a "landing shot" toggle. I think it should be relatively easy to implement by clamping the stationary camera's position to Z metres above ground level. I can envision two modes for it:

1. Without "Maintain Vel." enabled, which would work as you describe it where the camera's X,Y position is based on the craft's position + offsets when it's first enabled.
2. With "Maintain Vel." enabled, which would predict where the craft is going to land (it may be a bit tricky to calculate this accurately, but shouldn't be too hard if assumptions are made about constant vertical deceleration and reasonably flat terrain at the landing spot) and use that as the camera's X,Y position + offsets when it's first enabled. This should allow for landers that aren't particularly vertical, though it'd become more imprecise the less vertical the landing is.

[Entropian]

I definitely support adding something like that.  I've used the stationary camera mode for things like this, but it's incredibly annoying and time-consuming to make sure that the camera isn't clipped into the ground (you can't tell if it is unless it's pointed at a low angle).  A landing mode would make it far easier to deal with things like this.

[DocNappers]

So, something like this: 

That's with the "Maintain Vel." enabled where it's trying to predict where the landing will occur if the craft follows a ballistic trajectory. Without "Maintain Vel." it'll use the craft's current X,Y position. The altitude above the terrain of the camera is the "Up" component of the "Manual Flyby Position" and any extra offset is specified with the "Fwd" (aligned with the vessel's horizontal velocity when activated) and "Right" components.

Also, don't mind my poor flying skills...

[Entropian]

That looks awesome!