emerald

... and it also disappears when switching from map mode to normal mode, which typically happens when doing rendezvous ... The maneuver nodes are a lot of fiddling, when carefully aligning the prograde and retrograde vectors will also get you very close to a ship. But this requires knowing the distances, and also frequently switching to map mode and back. ... I really need to find a picture to illustrate my point

Indeed it is, I was not aware of that. I always know there was a small display (might have been a mod in ksp1) which showed the distance to target right next to the navball, that made rendezvous handy, now I'm always searching for the target craft to look at the distance, I've not only missed the final rendezvous burn just once while fiddling with the distances (vectors, closest target distance in map mode) and the actual craft distance (normal mode). This get lost when switching back to normal mode when searching for the target again, and then the nodes stick that close together it's hard to pin one and actually see what's written there... I might have to do some screenshots to show the issue.

Please add a highlight of the vessel selected as target in map mode, as well as a highlight in normal mode as well, it's hard to know which one is the target if there are (e.g. station building) multiple vessels float around close by. And, if possible also a target distance display at close range, so when trying to dock one knows the distance to the docking port/vessel. Some better distance display in map mode would be much appreciated as well, it's hard to fly the craft while always hovering the mouse over the potential rendezvous node markers in order to see the final distance.

I'm running KSP2 reasonably well on a Xeon E5-2699A v4 (22 core, 2.4 GHz), 384 GB RAM, and a Geforce GTX 1070 8GB at 1440p, under Linux using wine 8.21 and dxvk 2.23. The thing I observed while getting the game to run (took like 2 days of experimenting) was that KSP2 handles out of VRAM situations not gracefully, but it just closes without any message or anything if VRAM allocations fail. I'd assume in such situations it might be helpful to leave a message, or possibly try to free unused/cached stuff on the GPU and not just quitting silently. I know it's Early Access, but in case of an error any message is better than no message at all.

Just let people specify how many quick saves they like to have and rotate them accordingly, then everything is fine.

Some parts seem not to scale with the NearFuture Electrical Mod installed, so the ELF Engine still requires 6 GW, and the Computer Core 5MW as they do without NFE.

Using WarpPlugin with B9PartSwitch together with Nerteas CryoTanks breaks installed TalisarParts fuel tanks and USI Kontainers liquid tanks (e.g. C3_RTank_06): ModuleCryoTank is being added twice to the config: MODULE { name = ModuleCryoTank CoolingCost = 0.09 CoolingEnabled = False BOILOFFCONFIG { FuelName = LqdHydrogen BoiloffRate = 0.05 } } MODULE { name = ModuleCryoTank CoolingCost = 0.09 CoolingEnabled = False BOILOFFCONFIG { FuelName = LqdHydrogen BoiloffRate = 0.05 } It seems CryoTanksFuelTankSwitcher.cfg from CryoTanks adds the ModuleCryoTank and the same file from WarpPlugin does so too. ModuleManager.ConfigCache: https://drive.google.com/file/d/1pXRW0zEX3-5z8Nlpb81MUXariH10eTTs/view?usp=sharing I tried to fix the TalisarParts using this: @PART[TAL.*.Tank.Fuel]:FINAL { -MODULE[ModuleCryoTank] {} ModifiedByEmerald = True } @PART[TAL.*.Tank.*.Fuel]:FINAL { -MODULE[ModuleCryoTank] {} ModifiedByEmerald = True } it's preventing the Part from breaking but it's not working with the fuel tank config it should be (from WarpPlugin).

The optics are good only for the stock (or a similar sized) system, a system modifying mod with kopernicus (other worlds, ...) will easily reach distances where the optics magnification is not enough. Ideally there should be another optics with a much higher magnification but very expensive and/or very energy hungry so one has the possibility to operate it under higher difficulties.

I experience the same frame rate issue, documented with plain KSP 1.4.2/1.4.3 with the only mod installed ShowFPS (https://forum.kerbalspaceprogram.com/index.php?/topic/172692-141-showfps/) and either once without Kopernicus and once with Kopernicus. https://imgur.com/a/hpxaBwm The frame rate is displayed in the top right corner.KSP 1.4.3 with Kopernicus displayed a considerable frame rate drop. Player.log of 1.4.3 with Kopernicus https://drive.google.com/open?id=1e1LicezgB0y3tLhitYMCqlavAJaUAlYQ

It will probably not prevent a memory crash, since 24GB of RAM is not so much anymore, applying some padding will easily increase the RAM usage of KSP (with many mods) to 50+GB.

Yes, since it's April 1

the uninstall it, and you're back to step one

Just use the CKAN menu and set compatible version to 1.3.0, install it, be happy. it will not be automatically uninstalled even if compatible version is restored to 1.3.0 not being compatible again.

The integration patches should exclude all parts with WBIConvertibleStorage module installed, so !MODULE[WBIConvertibleStorage] is missing in the list.

Its a problem in KSP itself, not the parts on their own (every crewable part without a hatch has the same risk), a mod 'KSP Rescue Pod Fix' by shadowmage45 fixes this.