Phineas Freak

@BirchMonkey857any logs?

@DDEthe default Scaterrer UI access keys are "Mod+F10/F11" (Mod is the modifier key, it is the Alt key on Windows for example). After you open it click on the "Ocean Settings" button (on the top of the UI) and then click on the "Rebuild Ocean" button (on the bottom of the UI).

@dafidge9898your orbit is a very tight one and the craft is (probably) light so you will see a fast decay rate.

@kyodendo you have KJR installed? Judging from the stock engine interstage fairing around the engine i would imagine that you are trying to mount the second stage to the first stage via the engine only. This will not work all times (as you have found). It is better to use the ability of the engines to surface - attach: at first mount the second stage at the interstage adapter node and then attach the engine on the second stage. Physics and rigidity in KSP are affected by the part mass: if you attach two heavy objects via a (relatively to them) light object then a wobbly Kraken will ensure.

@DDEknown bug with Scaterrer, affects all mods that can "teleport" crafts (KCT, KRASH, Hyperedit). A workaround is to rebuild the ocean after every craft "teleportation".

@JewelShisena couple of internet-search seconds later: https://spacedock.info/mod/128/DMagic Orbital Science

@TK421dno, KJR does not implement progression restrictions.

Wait, what? KSPAPIExtensions is deprecated in the 1.1 KSP release branch, why is it installed? Question not aimed at MOARdV of course.

@JewelShisenif you search inside the "GameData\DMagicOrbitalScience\Plugins" do you find a "DMagic.dll" file?

@NexxusWolfplease make sure that you have installed both RealPlumes and SmokeScreen.

@Comet Tailunfortunately almost none of these things would work because RO does not currently support resource harvesting (not even the stock "Ore"). These will be replaced some day by the RealISRU mod.

@Requiaopen this link and attempt to save the page. Does the browser prompt you to save it as a .prnl file?

@tajampino, the rest some of them are copies and they need to get a reflection module separately. Let me see what i can do. Update 1: the names of the reflection GameObject meshes (that are responsible for the reflections) are not the same as the ones that are defined inside the "PartRevamp_TextureReplacer.cfg" file. For now removing the mesh definitions (mesh = <GameObject) will do the trick. Update 2: i fixed (at least i think) the reflections. They now use the new mesh names but because of the way VSR patches them for TextureReplacer (:NEEDS[TextureReplacer]:FINAL - a really bad strategy) it is impossible to do it with just an MM patch. You have to dig in the VSR TR patch, remove all mesh definitions from the solar arrays and then apply the following MM patch: // ================================================== // OX-2L 1x3 Photovoltaic Panels. // ================================================== @PART[1x3SPanels]:FOR[TextureReplacer] { @MODULE[TRReflection] { @meshes = Panel1 Panel2 Panel3 } } // ================================================== // OX-6L 2x6w Photovoltaic Panels. // ================================================== @PART[1x3WPanels]:FOR[TextureReplacer] { @MODULE[TRReflection] { @meshes = Panel1 Panel2 Panel3 } } // ================================================== // ST1 Solar Panel // ================================================== @PART[solarPanels5]:FOR[TextureReplacer] { @MODULE[TRReflection] { @meshes = Cells } } // ================================================== // ST2 Solar Panel. // ================================================== @PART[solarPanels5HiTech]:FOR[TextureReplacer] { !MODULE[TRReflection],*{} MODULE { name = TRReflection colour = 0.3 0.3 0.3 interval = 2 meshes = Cells } } // ================================================== // ST3 Solar Panel. // ================================================== @PART[LgRadialSolarPanel]:FOR[TextureReplacer] { !MODULE[TRReflection],*{} MODULE { name = TRReflection colour = 0.3 0.3 0.3 interval = 2 meshes = Cells } } // ================================================== // XT1 Solar Panel Array Mk1. // ================================================== @PART[solarPanels4]:FOR[TextureReplacer] { @MODULE[TRReflection] { @meshes = Panel1 Panel2 Panel3 Panel4 Panel5 Panel5_002 } } // ================================================== // XT1 Solar Panel Array Mk2. // ================================================== @PART[solarPanels3] { @MODULE[TRReflection] { @meshes = Panel1 Panel1A Panel1B Panel2 Panel2A Panel2B } } // ================================================== // XT3 Solar Panel Array Mk1. // ================================================== @PART[largeSolarPanelEarly]:FOR[TextureReplacer] { !MODULE[TRReflection],*{} MODULE { name = TRReflection colour = 0.3 0.3 0.3 interval = 2 meshes = Cells } } // ================================================== // XT4 Solar Panel Array Mk1. // ================================================== @PART[largeSolarPanel] { @MODULE[TRReflection] { @meshes = Cells } }

@smartdummiesit works perfectly.

@mileshatemacquiring more data units allows the engines to be pushed a bit "harder" but always under the "burn - through" time limitation, while making sure that the engine will operate correctly (i.e. no loss of thrust, explosions, shutdowns) for it's rated burn time. Burn time is "hard - coded" parameter for all rocket engines (not talking about KSP but for the real life). A design meant to last for 2 minutes cannot be expected to operate without problems for 3 or 4 minutes. You either improve the engine or use a different one.

Of course, what else? Well, it also changes the masses, crew capacities, resource storage volumes and many more. Basically, the part is not the same after ROfication. To answer the OP question: aside from the few stock parts, SXT and Habitat Pack are supported (SXT not so much it it includes some large hard - shell hab modules). Now, if your aim is colonization then no, you won't find a lot of compatible mods (i think none of them exist for RO).

You can open the MM cache and search for an engine that has a TF config defined.

@CoriWthe specific .cfg file is only a patcher (formatting the reliability parameters into the TF modules). The TF parameters themselves are part of the global engine configurations. This is a custom RO setup since we need to patch a ton of different mods that provide the same engines. RO currently has TF configs only for the engines (and even then only for some of them). Other parts are not yet supported.

Remember that ISP is measured in SI seconds because it is more difficult to convert between imperial and metric than to use one single global measurement unit. Mass may be measured in kilograms or pounds, speed may be measured in meters per second or in feet per second but then you have to convert the units.

@hargnthe satellite parameters cannot be not controlled 100% since they have to cover all possible eras (from 1951 to 2050+). You have to check each satellite contract before commiting to it. You can compare it to the "Sounding Rockets - High": some of the altitudes are impossible to reach without advanced liquid engines/solids but these are offered as soon as you reach space (1953 - 1954). Some of the contracts are set up so to give the player a feel of progression without overwhelming him/her (and also follow the real life history). The rest are randomly generated, just like the stock game.

Also, MM does not do anything after the initial KSP loading screen (after patching) so there is no possibility that MM can be the problem. However, the patches that it applies can do all sorts of things if the mods are incompatible.

Lunar Module Descent Engine (LMAE) - page 8. And this is not the only example. The RD-275 engine can only be started once (being a booster engine - someone could argue that it is because of the dependency to the ground equipment), most variants of the AJ10 had 1 to 5 ignitions (the Apollo SPS was rated for 50 ignitions - later variants depended only on the onboard Helium supply), the XLR81 (only the later variants could be reignited) and many more that i forget.

Being hypergolic also does not mean that it can support multiple ignitions.

@kendoka15do you have MechJeb installed? IIRC it has a "Smooth Throttle" option that will force all engines to throttle up or down with a bit of a delay (applies also to the visual indicator).

At first i had the same issue but then i tweaked a bit the wheel parameters and it worked (dropped the Friction Control and increased the Spring and Damper strength values). Be careful with the landings though since they like to explode if you push them too hard (compared with the previous KSP versions).