NathanKell

FennexFox: Yes, we're working on RO for 1.0. It's getting there, see https://github.com/KSP-RO/RealismOverhaul/issues/250 AFAIK all dependencies are either released for 1.0 or "WIP but testable" in 1.0.

Dr. Jet: You said "RealFuels/Fuel_Conversions.cfg" which made me think it was in the RealFuels folder. I have no idea what it does, so can't offer advice as to whether it's "ok to use". If it leads to acceptable results then...I guess so? At first blush that config looks mostly Ok. You really should be setting maxThrust though, you can pull it from the engine module with MM's variables. Also, the EngineIgnitor stuff is wrong; inside a CONFIG it looks like this: https://github.com/KSP-RO/RealismOverhaul/blob/9370ef763c5126ec6dbe5fed21731583d6880ba1/GameData/RealismOverhaul/RO_SuggestedMods/AIES/RO_AIES_Engine.cfg#L85 But note you also have to add the MODULE for it outside the ModuleEngineConfigs module (see the entirety of that example).

jsimmons: Yep, you can use a Finalize {} node. That has a whole separate parser that will let you modify existing PQSMods rather than replace them, and it runs by reflection so it will support anything. Example: https://github.com/KSP-RO/RealSolarSystem/blob/master/GameData/RealSolarSystem/RSSKopernicus.cfg#L4532 (starts there) Note that finalizeOrbits may or may not be needed; have it true for RSS-like behavior. You definitely want removeUnused set true, however, as that will clean up by removing unused maps and textures (freeing RAM).

ConfigNode myNode = getNode(); // get as appropriate foreach(ConfigNode.Value val in myNode.values) otherwise as Diazo says.

This sounds like a bug to make RoverDude aware of.

Also, could you update to ModuleRCSFX 4.1? I fixed a gigantic bug with thrust... Congratulations being the only engine pack RFv10 complaint though!

Thanks all! Dr. Jet: 1. Yes, since regular fuel tanks are set to type 'Default' or (infrequently) type 'Cryogenic', you have no way to store any highly-pressurized propellants without some tanks being made type 'ServiceModule'. RCS tanks seem the obvious choice, since pretty much all RCS propellants are highly pressurized, and if you can store them, you might as well store everything else highly pressurized too. 3. I don't see that file in RF. What is it, and why did you not follow the install instructions? 4. You definitely need to add the ignitor. Even hypergolic engines don't have inifinite relights, and even hypergolic pressure-fed engines (which usually have effectively infinite relights) are still subject to ullage concerns. The only things that don't have to worry about it are RCS, since they spend extra mass on bladder tanks to avoid ullage concerns. This myth just. will. not. die. 5. Works the same as it always did: if part temperature is > boiling point, you lose (tDelta) * lossRate percent of your tank.

Lilienthal (and sorry for the extra L last time): the current texture set is here: https://github.com/KSP-RO/RSS-Textures We've added Dione, Rhea, Tethys, Enceladus, Iapetus, and Mimas. The heightmaps should be black = lowest point, white = highest point. The normal maps can be created from heightmaps quite easily, so don't worry about them (but if someone does have a normal map, it'll already be in the correct format or can be easily converted). Note that the color maps for KSP are (a) flipped horizontal and ( offset, so don't be surprised if they look weird. Thanks so much!

Yep. Also you might like the new emissive module (which can be precisely controlled by the engine solver), and the precise control over engine FX.

The FXGroups are placed on the thrust transforms IIRC.

Heat loads don't vary with entry angle, they just vary with velocity. Yes, due to the drag increase, convection isn't as deadly as it was. My guess is the major improvements to thermal won't come until 1.1, but let's hope 1.0.3 is a bit deadlier.

FennexFox: no worries. Niemand303: We've configured most solids so far for non-Tantares packs; you can look at what we did for FASA for the LES and for Gemini bits. However, there's no real harm in keeping things as SolidFuel; it's certainly still supported, it's just you won't have the right thermal mass (when hsp is added for all resources, SolidFuel's will be some 'average' hsp). It's like LiquidFuel: you can use it if you need to. frisch: Oh, the save breaking is in good part the fault of RO. We've taken the opportunity a few times to synergize with KSP updates and make save-breaking changes to RO. The forthcoming RO for 1.0 is another example of this. However, the way we break saves can usually be solved with a bit of text editing work (mostly changing names of resources, or engine configs). Stockalike RF engine configs may be what you're thinking of? If not, there's RftS, but I haven't had a chance to update it in about a year (!)...

Easy, folks, easy.... :] Lillienthal: thanks! Regarding small bits of math, RSS is doing ok*, but one thing RO really needs is setting appropriate thermal bits to parts. Like, their emissivity, what their mass specific heat capacity should be, the fraction of thermal mass in the skin vs. the interior (for Deadly Reentry), etc. *Kopernicus is pretty solid now, we have color maps for most everthing, and so far nothing's crashing. However, we do need help finding (or making) heightmaps and normal maps for the moons of Saturn, and for Triton (moon of Neptune). So that's another thing.

SolverEngines is by NathanKell and blowfish, based on the work of camlost for AJE. Installation: Merge the zip's GameData folder with your KSP/GameData folder. After installing, inside KSP/GameData should be a SolverEngines folder (and inside that, Icons and Plugins folders). Note: Unless a mod you are using requires this, do not install it. It's for developers, not end users. Download GitHub (source) License: LGPL. SolverEngines is at its heart a replacement paradigm for how KSP deals with engines, splitting engines into a partmodule and an engine solver. Instead of a single engine module that does everything, or that is specifically geared to a single type of enigne, and instead of needing to keep a stock engine module present but then override its values every tick, SolverEngines decouples the engine module from the code that handles performance (the solver). SolverEngines consists of five parts: the engine module and the engine solver, a replacement for the intake module that is geared to work with SolverEngines, a GUI for various flight and engine stats, and a replacement for ModuleAnimateHeat. The engine module derives from ModuleEnignesFX (and therefore is visible to MechJeb and KER), and handles all direct KSP interaction. The solver gets input data, and exposes various public methods for the module to get information back. The intake module derives from ModuleResourceIntake. ModuleAnimateEmissive replaces ModuleAnimateHeat with a more flexible, configurable module. It can either be linked to a part's temperature (the default) or be told what state it should be each frame (so SolverEngines can control emissive animations directly). NOTE: With the exception of ModuleAnimateEmissive, SolverEngines is **not a mod for end-users**. It is a mod for developers, who should derive classes from ModuleEnginesSolver and EngineSolver (as AJE and RealFuels do). It will do nothing on its own. To use SolverEngines, implement two classes: a class that derives from EngineSolver that handles all calculation of thrust, Isp, and fuel flow given the passed-in parameters (and any new ones necessary), and a class that derives from ModuleEnginesSolver and overrides CreateEngine() to create an engine solver of the new type (and passes it any creation stats). Also override the info methods so proper info is displayed. You may also need to override other virtual methods in ModuleEnginesSolver (like UpdateFlightConditions and UpdateThrottle) depending on your engine's need for more status information or other requirements, and methods like OnStart or OnLoad to deal with more complexity. Note that SolverEngines uses the [KSPAssembly] tag. Add this line to your AssemblyInfo.cs file to make KSP aware that your assembly depends on SolverEngines: [assembly: KSPAssemblyDependency("SolverEngines", 1, 0)] (Example, in AJE.) SolverEngines will also automatically create overheat bars if engineTemp approaches maxEngineTemp, and will set all ModuleAnimateEmissive modules on the part to solver.GetEmissive() each tick. SolverEngines includes a GUI to display useful information about engines in flight, and additional info about air-breathing engines using SolverEngines when they are present. The GUI will display an icon on blizzy87's toolbar if available, or on the stock toolbar if it is not. All fields in the display GUI can be disabled in the settings window, and the display units can be changed in the units window. See AJE or RealFuels for examples of how to implement SolverEngines in practice.

v4.1 Fixed bug in thrust calculation (was 2% what it should be...) When in fullThrust mode, don't switch to full thrust unless thrust ratio already starts out at fullThrustMin (configurable).

Well, it's finally here! Changelog: v10.0 SAVE-BREAKING. KSP 1.0 support. Remove thermal fin and radiator. Use Community Resource Pack for our resources, don't add resources in RF. Xenon tank type is removed; all of these tanks use ElectricPropulsion now. Now have multiple different solid fuel resources, and thus multiple different solid fuel tank types. Add module info in the editor tooltip for tanks Engine info / configuration info will only display for the master ModuleEngineConfigs on the part. Disable MEC event firing on configuration change (was killing FAR). Updating an engine config will properly propagate to symmetry counterparts. Updating the engine config of an isMaster=true module can propagate changes to isMaster=false modules on the same part (and will propagate properly across symmetry counterparts). Example: Change the main engine config and the vernier config will auto-update. Done by, for each CONFIG, adding an OtherModules {} node. Inside are key-value pairs, where key = engineID of other module and value is config to switch to. Separate settings for RF engines (RFSETTINGS) and tanks (still MFSSETTINGS). Remove deprecated old version of hybrid engines (the one that is essentially MultiModeEngine). Speed up ModuleEngineConfigs a lot, cut the excess bits from ModuleHybridEngines. Fix issue with heat multiplier Rewrite floatcurve-modder to respect tangents. Massively refactor engines code. RealFuels, like AJE, will use an engine solver now. The new engine module (ModuleEnginesRF) handles thrust curves, throttle speed, emission and internal engine temperature, automatically extending Isp curves to 0 Isp, etc. MEC (and MHE) default to using weak typing: type = ModuleEngines means apply to ModuleEngines or anything derived from it (same for ModuleRCS etc). You can disable this feature per-module if needed.

Andrew_C: The easy way is to write something to generate the cfgs. I use excel. I put in the old and new texture paths for all changed textures, and I get an MM config out of it. That's how I wrote the patcher for SXT for use with Stock Revamp, before Stock Revamp switched to not overwriting files.

It's much more cfg work than C# work to be honest. In fact, there's very little code that needs to be written for RP-0, it's all either configuring the tech tree or configuring contracts or configuring science.

It's because scaled space distances are 1/6000 regular distances (Kerbin is 100 units in radius in scaled space).

Fixed in .24 IIRC. Surely fixed now.

They're static relative to the part. As sarbian says, the position of the origin changes. Five units right of the part will always be five units right of the part: relative positions are preserved. But absolution position is not preserved, because the very origin of the universe shifts (to avoid FP issues). Always rely on relative positions, not absolute positions.

Doesn't sound like a problem with persistence but rather with determining when to poke your stored values at ModuleProceduralFairing? I.e. your module's values may be fine but if you don't always apply them to the MPF module you sit next to then sometimes it'll look like the values don't get saved. Or am I misreading?

Launch a ship with >= 6 kerbals and a large remote guidance unit. That is a remote control station.

It's an 80% Earth atmosphere (as boiled down into a floatcurve). See this thread. Note that pressure is invariant, but density (which depends on both pressure and temperature) will vary based on latitude and time of day. By 80% I mean "pressure at 8km on Kerbin is the same as at 10km on Earth". Here's a calculator: http://www.digitaldutch.com/atmoscalc/

Fixed, thanks. And yes, there is a RO for KSP 1.0 in progress. See this checklist here, and everyone, please, help if you can!