Poodmund

The more ground scatter objects that you have on screen the lower your game performance will be as these ground scatter objects are, relatively, incredibly taxing. If you currently have this set to 100% you will be rendering hundreds and hundreds of trees and rocks on the ground surface which is likely tanking your FPS. Turn this setting down to a value much lower, if you currently have it on 100%, and see how it improves your performance.

Your server is obviously vacuum optimised if your Isp performance is so low in its current state.

This planet pack (much like any other system/planet pack) can be altered by Sigma: Dimensions. Whatever Sigma: Dimensions configs you decide to use it up to you; if you want to use "Rescale's" configs then by all means... I personally use a modified version of the Rescale 2.5x config.

@R-T-B I think your server may be down, 17:40UTC, its causing CKAN to throw a paddy.

Most likely due to you having Modular Flight Integrator already installed as a dependency of another mod. Uninstall MFI, via CKAN (which will also uninstall mods dependent on it), then install Kopernicus BE 1101_58, then reinstall the other mods that got uninstalled.

Yes, it is. And as a supplementary question in this regard, could there be a possibility of better handling of the Tooltip that shows when hovering? I think currently, it shows the Root level folder name (inside GameData) of where the first instance of that part config is located, however, if a subsequent mod is installed that patches that part significantly, the 'name' of the mod that the part belongs to does not change. This is easily seen when using mods such as Ven's Stock Revamp or ReStock that heavily patch existing parts to the extent that they appear to be new parts but are in fact an existing part (in this case the Stock part). Install Ven's or ReStock and Janitors closet and hover over the parts. They will all still say 'Squad' because they originate from the Squad folder as Squad parts even though Ven's or ReStock are redoing them extensively. Is there a way that this could be communicated to the end user?

Good is a relative term. It means different things to different people.

I would ask people what scatter density they have set first. The 100% density is not realistic to achieve good performance. Tell people to turn it down to 10% or something before making sweeping changes that affect all users.

They have community made patches bundled with them to integrate functionality with USI to an extent. Obviously, this does not extend to WOLF at the time of posting.

It only wasn't working for cells L14:M14, all the others were being affected by the Rescale Factor, however, thank you for bringing this to my attention, I've fixed that. With respect to your other point, O5 is a modifer for all antennae and P5 is a modifer for the DSN, just like the stock settings.

https://bugs.kerbalspaceprogram.com/issues/17005 Known issue with Vanilla KSP, the North Pole vertex is whatever the South Pole vertex altitude is, so make sure the North Pole region blends into the same altitude as the South Pole region.

It would probably be more useful for high altitude wind data as it takes no terrain into consideration but you could lower the bands and speeds right down to simulate crude Stratosphere and Mesopshere movement.

You realise there's a slider that allows for scatter density? Did you previously have it on 100%? If so, try turning it down to something like 15% and see if you can get a reasonable refresh rate.

This is one of the coolest KSP related things... I have ever seen. @cmet24 your site is amazing too.

Tekto is the only moon in OPM with a considerable atmosphere that would show visible clouds... Thatmo has an extremely thin atmosphere. With regards to contract lengths, I have made some changes to Neidon and Plock's (and their moons) recovery values which will increase their science yield from these bodies (but by the time players have reached this places, I fully expect science not to be that much of a concern by this point), please see below: Contract (Years) Contract Type Contract Weight Jool Sarnus Urlum Neidon Plock Test 426 6 7 8 10 12 RoverConstruction 852 12 14 16 20 24 VesselRepair 852 12 14 16 20 24 OrbitalConstruction 852 12 14 16 20 24 Flag 2130 30 35 40 50 60 Recovery 2130 30 35 40 50 60 Satellite 2130 30 35 40 50 60 Research 2130 30 35 40 50 60 Sentinel 2130 30 35 40 50 60 CometDetection 2130 30 35 40 50 60 Survey 2130 30 35 40 50 60 Tour 2130 30 35 40 50 60 DeployedScience 2130 30 35 40 50 60 ROCScienceArm 2130 30 35 40 50 60 ROCScienceRetrieval 2130 30 35 40 50 60 GClass6 2982 42 49 56 70 84 Base 2982 42 49 56 70 84 Grand 2982 42 49 56 70 84 ISRU 2982 42 49 56 70 84 Station 2982 42 49 56 70 84 Basic Hohmann Transfer Lengths (long travel times) Kerbin Jool 4yrs Kerbin Sarnus 6yrs Kerbin Urlum 12yrs Kerbin Neidon 25yrs Kerbin Plock 65yrs You probably won't take Test contracts out at the outer planets so those contract lengths are pretty redundant. The next 3 types are the new contract types added with KSP 1.11.0 and they all generate fairly timely contracts due to their low contract weight value (these are also bugged as of KSP 1.11.0 and are generating at a length of around 2yrs for all bodies)... this is something that is inherent within Vanilla KSP so theres not a hell of a lot that can be done about this without screwing up Science balance. All the other contracts have pretty generous contract lengths and you should be able to get there and back if required within the contract times. Ensure that if you're using something like Transfer Window Planner to create your Hohmann Transfers, don't always use the most dV efficient transfers as they will take an extremely long time. Usually, for just a few hundred m/s more, you can get transfers that will shave a significant amount of years of your transfer times.

Hi ExtremeSquared, I know it has been over a year but did this change provide any positive outcome for you with regards to contract lengths? EDIT: I've just done some testing and found that this is indeed the case. This testing would suggest that contract deadline times are determined by... SetDeadlineDays = scienceValues.RecoveryValue * this.contractDestinationWeight. In Vanilla in a Satellite contract for Jool has a 6yr deadline date once accepted and if you look in the Contracts.cfg this equates to a DeadlineDays = 2130 value, therefore a Science Value of 6 multiplied by a contractDestinationWeight of 2130 equals 12,780... divide by 426 days and you get 6yrs. I changed Jool's Science Recovery Value from 6 to 100 and which would expect a Satellite contract deadline date of 500yrs and indeed in the Mission Control screen this is what appears. So its a case of finding the correct Science Recovery Value for the outer planet bodies to allow for long enough contract periods to complete them.

For me I'm sticking to 2560 x 1440.

See Blackrack's response 16 hours before your post. Also, is this just on the Title Screen, how does it appear in game. I know, from personal experience, I don't usually play much of the game on the Title Screen so it could look like the inside of a Potato for all I cared.

Could you not use dummy part upgrades that are located in your tier nodes? That way they would not be empty but they wouldn't contain anything that mattered.

Just use the 10x config from here: All the Rescale! configs are fine and still work.

3) This has already been raised as a request on the bug tracker. Can't promise anything there. It's a case of cost/benefit. Could you not consider all parts to be stored in 'cardboard boxes' and just calculate the storage volume of parts based on their mesh bounds? https://docs.unity3d.com/ScriptReference/Mesh-bounds.html

Just for clarity, @Well was the brilliant artist who did the work for the Spherical Capsule parts. You can find out who did each part by looking in the configs under the 'author' parameter.

There is no real need, Porkjet's plane parts are the aesthetical standard that ReStock was based on.

@R-T-B, I appreciate the work you are doing on MFI to get it to cater for Kopernicus-BE's functionality but rather than bundling it in with your releases via the CKAN distribution, would you consider preventing it from being supplied via CKAN and then creating a supplementary MFI-RTB indexed CKAN entry that supplies this version of MFI and also has a: "provides": [ "ModularFlightIntegrator" ], relationship to it? Currently, the only way to install Kopernicus-BE via CKAN for KSP 1.11.0 is to uninstall ModularFlightIntegrator and then install Kopernicus independently, this has the knock on effect of forcing uninstallation of all other mods that rely on MFI like FAR and B9 Aerospace Procedural Wings for example. I'm not sure how your discussion with Sarbian with regards to working on MFI has been progressing... maybe its been mentioned that it may cause issue to create more instances of MFI like it has done with Liasis' MM fork for example(?). Secondarily, I think CKAN also got confused by the version naming of the different KSP version distributions, being 191, 1101 and 111. Due to numerical size, it considered this to be the order that the versions should exist: 1101, 191, 111 and so considered the 1.11.0 version to be below the others. Maybe it would be best to keep them underscore separated: 1_11_0, 1_10_1 and 1_9_1? I've been installing manually with no issue now for a while but I thought that, in case you weren't aware, there are some outstanding teething issues with this installation process which I know that you're keen to support.

A dumb interim solution would be to get the cargo patches to NEED something that is only present in 1.11... like needing the SQUAD folder with a part named Twin Boar V2 (can't remember the exact name of it)