Poodmund

DirectX is a Windows only API unfortunately.

You'll want to be asking that question over in the Kopernicus Continued thread.

Open CKAN, got to Settings > CKAN Settings, under Metadata Repositories, click 'New', highlight Kopernicus_BE and click 'Ok'. Then close the settings window and refresh the CKAN metadata list... Kopernicus Bleeding Edge will now show in CKAN. Just as it says in the Original Post in this thread.

In a KSP 1.10.1 Vanilla install with ReStock & RS+ 1.2.1 install with MM 4.1.4 I do not experience this same behaviour. When I toggle the Mk1 and Mk2 lights on and off the pivot animation does not play. This is with light in the default configuration, lights placed in the pivoted state and lights placed in both base and pivoted rotation states with varying deploy limits. I've also tested this without RS+ 1.2.1 also and the issue does not occur either, as expected. infinite_monkey, could you provide me with your KSP.log file and Logs folder in the base game directory and confirm exactly what versions of ReStock & RS+ you're using and the behaviour that you're seeing and how to replicate it because I cannot.

Just for reference, OPM-VO does not touch any bodies other than the 3 Gas Giants and two atmospheric bodies of OPM... and even then is only a set of textures and configs to apply Scatterer and EVE configs for said bodies. It has ABSOLUTELY ZERO involvement with Kopernicus and as such will cause no issue in this case. That said, it hasn't been touched in years and its Scatterer configs are not valid for use with the current releases of Scatterer.

Using Sigma Dimensions you can scale up or down to your hearts content. Sure. I can leverage Gamelinx's implementation for the stock planets and use those textures to apply to the OPM bodies where appropriate so that performance/RAM usage shouldn't take too much of a hit. Time is a bit hectic right now, hopefully when COVID takes a step back and we go back to some sense of normality and not-chaos at work I'll have some spare time to do this.

My guess for the next set of new parts is an expanded range of Oscar tanks or additional probe cores/batteries to fill out the size profiles that have none.

I think everyone would rather see it finished properly, with quality and stability rather than something rushed and early that feels rough around the edges.

Ah, no worries, it was the wording in the post that caused a little confusion.

@Angel-125, the thread I nominated did not get the award and I didn't nominate any of the threads linked in the OP so I'm a bit confused as to what got awarded.

The other revamped bodies have this issue also but the channels/lines in the surface texture for this body make it more noticeable. its not as bad when you're actually playing during ascent/descent but zooming in/out like this really brings it to the fore.

The new forum 'skin' looks much more than half-decent with a few small changes:

Unfortunately no terrain geometry or gameplay can really exist below the surface mesh due to the way the PQS system (terrain) is implmented

An upload of your "Kerbal Space Program/KSP.log", "Kerbal Space Program/Logs/ModuleManager/ModuleManager.log" and "Kerbal Space Program/GameData/ModuleManager.ConfigCache" files would be very helpful here if you could supply them. Also what versions of ReStock and ReStock+ are you using?

I think people become confused because the thread titles of the various mods do not reflect this.

The forum got updated but this thread wasn't deleted... @Thomas P.... what's going on?

No worries... basically if you can run KSP, its fine.

Literally:

Not *easily* but: Delete Kerbal Space Program/GameData/OPM/Cache/Eeloo.bin Delete these lines from Kerbal Space Program/GameData/OPM/KopernicusConfigs/SarnusMoons/Eeloo.cfg: https://github.com/Poodmund/Outer-Planets-Mod/blob/master/GameData/OPM/KopernicusConfigs/SarnusMoons/Eeloo.cfg#L44-L48 & https://github.com/Poodmund/Outer-Planets-Mod/blob/master/GameData/OPM/KopernicusConfigs/SarnusMoons/Eeloo.cfg#L159-L205 Then re-run the game and it should remove those procedural craters and also revert back to the stock scaledspace textures. It works with KSP 1.10.1 if you satisfy the dependencies as listed in the OP, specifically, for KSP 1.10.1 this means you need to use RTB's Kopernicus Bleeding Edge edition for 1.10.1.

Arguing with a content creator trying to convince them to create more content is a sure fire way to make them not want to create more content.

Linux, if you date stamped the titles, using verbose dates to avoid confusion i.e. 3rd Oct. 20, then people may not ask as they have a reference as to when the update has occurred maybe?

I wasn't saying that the act of copying the configs from an ethics standpoint is the issue... I was saying that the copying of configs with preexisting issues that then propagate down through to commonly copied configs/templates are the issue.

So if I have Vanilla KSP and install Kopernicus BE, Jool's moons do not use that shader, correct? Kopernicus is not overriding stock behaviour. Specification/usage of that shader is fine on any PQS-based body, it just has to be utilised properly. The plageurism (a bit strong but basically what it is) of configs has always been a big issue with Kopernicus based mods and issues get very widespread without any understanding.

Why are they getting that material shader applied to them? Those stock bodies do not use that shader.

Cheating to orbit 'should' be fine if you completely reset the camera scene, i.e. Cheat to orbit -> Go back to the Space Center -> Go to Tracking Station -> Go back to vessel... then do your testing and make your assumptions.