JonnyOThan

Again looks like a near/far camera thing, but this time the lighting on the far camera is correct and the near one is not.

@Gameslinxthis might be obvious but just in case: this looks like the grass is only being rendered by the near camera. OpenGL still uses the two-camera setup.

OK, I managed to reproduce the problem and also figured out why I never noticed: it's not related to depth buffer mode, it's caused by scatterer's temporal antialiasing. I always turn that off in favor of TUFX's implementation because it doesn't break the UI.

I think there’s some logic in parallax that moves vessels upwards if they are colliding with things, to make sure they stay out of scatter…I’d bet $5 the ground anchor is colliding with itself. Hopefully an easy fix.

isn't depth buffer the default mode? I'm pretty sure that's worked for me but I'll double check.

Hmm, does the AssemblyFileVersion get printed in the logs? It's really annoying when mods leave their version at 1.0 and then you can't tell what someone installed. But maybe they're not using AssemblyFileVersion.

You can, but you have to go into the cfg file for the trees and enable it.

No, not known at all. Details?

Yep, go into TUFX\TexturesUnlimited.cfg and change MainMenuProfile to Default-Empty. Or make a MM patch that does the same.

You should probably post your ksp.log

RPM and MAS are two systems that do the same kinds of things. ALCOR is an iva/props pack (technically ALCOR is a specific landing pod by alexustas that uses a lot of ASET props, but the MFDs in ASET were made specifically for the ALCOR pod). ALCOR is pretty old, so it's all built on RPM. As far as MFDs go, RPM comes with a basic one and ALCOR/ASET has its own versions (but they're still built on RPM tech). There are 3 different styles of ASET MFD: the 40x20 that looks similar to the RPM one; a bigger 60x30 and the full-keyboard one. I'm the current maintainer of RPM, and I know next to nothing about MAS, so I can speak to the RPM side of this stuff: I believe but haven't confirmed that this happens because the hullcam camera cfgs have an extra position offset in them that isn't duplicated in the hullcam-rpm configs. This page is set up in the ALCOR/ASET MFDs to use transforms that exist on the ALCOR pod. I would not expect any other camera to work with them - if they do, it's because whoever made the camera added a transform that matched the ALCOR name (which is...fine...but super hacky). This should be fixed in the next version of RPM; essentially the FoVs of the cameras was configured in the MFD (so all cameras got the same values) instead of using the value from the camera itself.

I don't know what AMP is. You hide the TUFX button by changing a value in TUFX's cfg file.

D) modify or patch one of the existing MFDs to add a KOS page.

If no one’s done it yet I’m sure there’s an easy way to convert MFD props to MAS ones with a MM patch. Also it just occurred to me that RPM does support some simple post processing but I think the Hullcam cameras aren’t set up to use it…oh but this might be a situation where the post processing config is set up in the MFD itself and not the camera part. I’ll look into it.

Note I'm pretty sure all this does is add the OPTION to disable the maneuver tool into the settings window; you still need to go in there and turn it off.

Sorry, I don't see anything obviously wrong (other than a pretty old GPU). You could try ks3p or reshade instead.

Logs?

Yep: https://github.com/shadowmage45/TUFX/issues/30 If there are TU configs for those parts that don't use the stock shaders, that should also fix it.

Blueshift is fun too. Lots of options.

I meant this one:

Which cockpit is that? It's odd that it has ASET props, but not the MFDs...the tall ones look like they'd be perfect spots for the ASET 60x40 MFD. Regarding RPM vs MAS; you can use both. MAS will convert many props over to its system in that case. I don't think there are any fully-MAS IVAs for stock parts. Some newer cockpits are built only for MAS. And then, right now my VR mod only supports RPM if that's something you're interested in. Turned out to be less complicated than I feared. Next version of RPM will have accurate vision cones, and will use the FOV settings from the camera module on the part: (Note this is the 20 degree cone just used as an example; I will increase the default for this one to 60)

Yes, but I'm also curious - you could use DE_IVAExtension which uses the ASET MFDs and is generally better than the RPM ones. But if you want to use these IVA layouts, you could either write a patch to convert all MFDs to ASET ones or just edit the camera FOVs directly. The fov limits are set in jsi\rpmpodpatches\basicmfd\mfd40x20.cfg on line 240. The configuration for each camera is separated by a | character, and the two numbers are max, min fov.

MAS is the successor/alternative to RPM: If you had MAS installed, the MFDs were probably converted to that system, which would use a totally different FOV. The camera code in RPM hasn't been touched in over 2 years. There are plenty of other plausible reasons why you'd see a sudden change, and it's all down to interactions with other mods. But the way RPM handles the camera FOV is pretty weird, so I'm gonna fix that.

RasterPropMonitor hasn't had an update for over 2 months. Maybe you were using MAS as well?