ialdabaoth

Oops! Forgot to include ModuleManager.dll - repackaged the zip with this included, sorry.

Theoretically no, but try it and find out! I would like to know for sure whether that works. Maybe, but something like that would be a ways off. That should be coming soon.

"load priorities" and "wildcards" are a bit out of spec, I'm afraid. However, note that if you have multiple mods, the system WILL roll the patch files together before applying them. Is there a particular reason why you need to specify the order that that occurs in?

Deadly Reentry 2.3 So, I've been banging at this long enough, and need lots of eyes on this. r4m0n has graciously relinquished support of the Deadly Reentry mod over to me. All DRE2.X versions are released under the Creative Commons Share-Alike license. Changes in 2.3: - adjusted sound effects - Kerbals can now catch on fire and die when on EVA. Changes in 2.2: - Slight adjustment to heat and G-force damage: -- Weaker parts given about a 10% g-tolerance boost. -- Engine overheat damage is now more forgiving (requires >95% overheat) -- parachutes will catch fire even if behind the rest of the rocket, if they're deployed or partially deployed. - Damage can now be inspected and repaired on EVA - fixed ModuleManager/B9 bug (ExsurgentEngineering dll no longer included) - you can now set a maxTemp cap in the cfg file; any part with a temperature above this cap has its maxTemp halved, then capped at that value if it's still greater. Changes in 2.1: - Adjusted shockwave physics - Parts can now catch fire and sustain heat and G-force damage. - Engines are now damaged if they are run for extended times at an overheat (> 85% maxTemp) - Fixed shielding bug on Shielded Clamp-O-Tron and small parachutes - Updated and added 1.3 heat shield parts. Changes in 2.0: - KSP's Reentry contrails now render correctly - the contrail shifts from 'condensation' (white) to 'thermal' (red) based on velocity rather than elevation! - directional ablative heat shields are supported! The mk1 pod and space planes all have heat shields on their undersides, which are consumed during reentry to mitigate heat. Pointing your ship in the wrong direction causes DeadlyReentry to ignore the shield! - thermal physics are now more accurate! temperature is now capped based on velocity. - all stock parts will have their maxTemp reduced by 50%, to reflect real-world melting points. Engines also have their heat production reduced to scale, so you shouldn't notice any change until the reentry heat effects start. - all parts now show their temperature in the right-click menu. So, what I need from anyone intrepid enough to try it: download the mod, go places, come back, post a mission report. I want to know your reentry velocity at 70km, your velocity at 35km, and what kinds of thermal effects you experienced. If you exploded, let me know at what velocity and altitude (and what planet, if not Kerbin). Good luck!

Yes, theoretically you should be able to do @module = Part, but because of how I'm interfacing with KSP changing the base type of a Part isn't likely to work. If it works anyway, awesome, but I would be VERY surprised (might be something to put into 0.20.1)

Already solved this part! Right now I'm working on a few fiddly bits, like having DeadlyReentry tell when the Shielded Clamp-O-Tron is open or closed.

Is the space in the name, or the title? Can you paste a part.cfg into this thread, surrounded by blocks? I'd download Karmony but I'm in the middle of writing DeadlyReentry2.0 (r4m0n handed me the project)

Good to know - I'll edit the cfg file now. Also, I'm removing everything from my third-party distributions except for the .cfg files, so that if they update without me knowing it I won't bork all your stuff.

Bug confirmed; this is due to a peculiarity in KSP's code. I'm working on a work-around; so far I can get descriptive fields (like 'cost' and 'description' and 'author') to load, but not gameplay fields (like 'maxTemp' or 'mass'). I'll let you know as soon as I've hammered it out. EDIT: Fixed! New version is 1.01.

Gimme a few minutes to test this and I will get right back to you.

'doh! Good catch! Fixing now.

Oh! No, it doesn't work that way. ModuleEngines normalizes everything before computing the mass pull from Isp. TLDR: 0.9 / 1.1 is identical to 0.45/0.55; I have tested this extensively. Interesting! How far off are they? EDIT: I have just installed a fresh version of 0.20, then installed the Basic version of ModularFuelTanks. Grabbing JumboMax-64, clicking "Remove All Tanks" and then autofilling for 45%/55% fills it with 2879 units of LiquidFuel and 3520 units of Oxidizer, which is only one point off from the default of 2880/3520. Do you already have some LiquidFuel or Oxidizer in the part before you click 'autofill'? Because if you do, it'll partition the REMAINING volume to 45/55, and then add that to whatever was already there.

gaaaah yeah, Xamarin's been a bit of a putz lately. And I'm not actually doubling any of the fuel tank volumes that I'm aware of; also, removing the mod (even the advanced version) shouldn't hurt anything, since the mod is what adjusts the engines *and* the fuel tanks. I'll have to investigate this further.

yes! It's actually called "Mark1-2Pod" in the cfg, not Mk1-2Pod. So you need to do: @PART[Mark1-2Pod] { MODULE { name = MechJebCore } }

Splitting this off from my other mod thread. Modular Fuel System v1.3 - Advanced AND Basic Version, now with B9 support! Changes in 1.3 - fixed a bug where Isp wouldn't set properly when choosing engine configurations - changed TANK_DEFINITION format for proportional tanks from 'maxAmount = number * volume' to 'maxAmount = number%' - added 'utilization' as a synonym for 'efficiency' - added ModuleHybridEngines as a replacement for ExsurgentEngineering's HydraEngineController, with improved fuel gauges - abandoned experimental modular RCS blocks. - removed ASAS from pods, since adding ASAS apparently disables the pod's gyro. Changes in 1.2 - fixed a bug where tanks couldn't be configured empty - fixed a bug where the UI would sometimes glitch Changes in 1.1 - Now comes packaged in a convenient /GameData folder for clearer installation! - Added a 'fillable = false' line to TANK_DEFINITIONS, to support resources like Kethane that shouldn't be fillable in the VAB - Added configurable ASAS modules! Now, when you click on a customizable ASAS module in the Action Group editor, you will have the option to configure up to 3 PID settings for that ASAS module. If you configure 2 or more PID settings, a set of Actions will appear that can be assigned to Action Groups, which will allow you to switch between PID settings in-flight. For example, you could set up an ASAS module with an Avionics setting (Ki = 0.0, Kp = 0.2, Kd = 0.2) and an ASAS setting (Ki = 1.0, Kp = 0.6, Kd = 1.0), and assign the switch to the same button that changes your SABRE rocket settings - so that when you switch to air-breathing mode, your ASAS changes to the Avionics control scheme, and when you switch to rocket mode, your ASAS changes back to the Rocket control scheme. You could also set up two separate control schemes for low-mach and high-mach, or for early-stage and late-stage for rockets that drastically change their control authority as they stage. Changes in 1.0 - merged Advanced and Basic distributions; the Advanced version is now simply a set of configuration files in RealFuels.zip - if you want to play with LOX and LH2 and realistic nuclear engines, unzip RealFuels.zip after unzipping ModularFuelTanks.zip - moved the install folder to /GameData/ModularFuelTanks instead of /GameData/Ialdabaoth (doesn't change anything, but people can read it better) - ditched using Liters in the advanced version, because apparently I suck at the maths. - Xenon is no longer absurdly heavy. - All engine heats are halved, so that they won't explode in DeadlyReentry 2.0 What it does: Advanced Version Only: 1. It redefines the resource density of LiquidFuel and Oxidizer to match the weights of RP-1 (Kerosene) and N2O4 (a real-world oxidizer). 2. It identifies three new resources: LiquidH2, which is an extremely light cryogenic fuel, LiquidOxygen, which is a highly efficient but cryogenic oxidizer, and nuclearFuel, which is a heavy resource used by RNGs and nuclear engines. "Cryogenic" means that you will be able to store slightly less of them (usually 99%) than regular LiquidFuel/LiquidOxygen, and that they will slowly evaporate over time (usually on the order of about 1% per week, depending on temperature). 3. It redefines the fuel ratios for all stock, KSPX, and KW engines from 0.9 LiquidFuel/1.1 Oxidizer to one of four possibilities, each of which are used by real-world rockets (hey, if it's good enough for NASA...) - 0.4 LiquidFuel / 0.6 Oxidizer (for cheap rockets) - 0.35 LiquidFuel / 0.65 LiquidOxygen (for big boosters) - 0.73 LiquidH2 / 0.27 LiquidOxygen (for high-Isp rockets) - 1.0 LiquidH2 / 0.00000000000001 nuclearFuel (for nuclear rockets) 4. It adds a new submenu on the 'Action Group Editor' menu of the VAB whenever you select a liquid fuel rocket, that allows you to switch fuel types for that rocket - so you can change a rocket's fuel type from 0.4LiquidFuel/0.6Oxidizer to 0.35LiquidFuel/0.65LiquidOxygen, which will adjust the rocket's Isp and thrust. In general: LiquidFuel/Oxidizer is what you're used to. LiquidFuel/LiquidOxygen will give you slightly higher thrust and slightly higher Isp, but the fuel is cryogenic so you'll hold a little less. LiquidH2/LiquidOxygen will give you moderately lower thrust but MUCH higher Isp, and again the fuel is cryogenic. NuclearRockets cannot currently be changed, but I might change this since apparently there are real-world mods to NERVA that use LH2/LOX. Advanced and Basic Versions: 5. It adds a new submenu on the 'Action Group Editor' menu of the VAB whenever you select a fuel tank, which allows you to completely customize what (and how much) fuel goes into that tank. Most tanks can hold any ratio of LiquidFuel, Oxidizer, LiquidH2, LiquidOxygen, XenonGas and MonoPropellant that you desire, but some tanks will be more efficient at holding some resources than others. There is also a button for "Remove All Tanks", and a series of buttons for "Configure Remaining Volume to {engine mixture}" which appear whenever you add an engine - i.e., if you add an engine that takes 35% LiquidFuel and 65% LiquidOxygen, a button will appear that allows you to fill any remaining volume with that ratio of resources. Things to keep in mind with this mod: 1. You really don't appreciate how light LH2 is until you start using it. Nuclear rockets require an INSANE amount of space for fuel, although they'll be incredibly light compared to other rockets of the same bulk. Don't be afraid to put some big orange tanks on and fill them with LH2; they'll barely weigh as much as a standard-size tank. 2. Symmetry is automatically preserved as you edit, so if you have 3 identical tanks in a 3-fold symmetry and attach a rocket to the bottom of each, then change one of those rocket's fuel mixtures, all three rockets will automatically match. Likewise with the tanks. 3. With so many options (each with their own advantage and disadvantage), the Advanced version really does put you in "hard mode". Only install this if you're looking for a challenge. Otherwise, if you just want to customize tanks but don't want to worry about LH2 or LOX, download the "Basic" version.

I anticipated this! The system operates in two passes. This: @PART[mk1pod] { ...stuff } goes into pass 1, while this: @PART[mk1pod]:Final { ...stuff } goes into pass 2. Pass 1 is for plugin developers who need to add new modules to existing parts; Pass 2 (aka 'Final') is for gameplay tweakers who want to release game-balance changes.

Also, to revisit your original reply, this is exactly what you'd do: @PART mk1pod { MODULE ModuleGenerator { isAlwaysActive = true OUTPUT_RESOURCE { name = ElectricCharge rate = 0.75 } } @RESOURCE[ElectricCharge] { @amount = 500 @maxAmount = 500 } } That will add an electric generator to your mark 1 pod, and change its ElectricCharge resource to 500/500.

That is an excellent idea. Doing so now. that isn't possible with the way my system works. My system does NOTHING to files, it ONLY modifies root-level ConfigNodes (i.e., PART, RESOURCE_DEFINITION, INTERNAL, or any root-level ConfigNode that a mod might define). By the time my system is loaded, the concept of "files" is a vague memory.

Tanks on existing ships SHOULD keep whatever resources were specified when you configured the tank. Tanks on new ships will simply operate like normal tanks. Also! I've removed gameData.cfg altogether; I discovered a technique for pulling all the mod nodes straight from GameDatabase - so you no longer need to maintain a gameData.cfg - from now on, if a mod has any ModuleManager patch nodes, they'll automatically get applied. The ONLY thing you need to make it work is /GameData/ModuleManager.dll. So, mod authors: if you want to write any kind of mod that needs to change another mod's part.cfg file, just write a .cfg file using the specification in the OP and include /GameData/ModuleManager.dll in your release. Edit: Fixed a minor bug in the interaction between ModuleManager and ModularFuelTanks. New ModularFuelTanks mod here.

Aha, understood. I'll think about this for awhile and get back to you.

So, if you don't want to replace Squad's part.cfg files (because you've also installed FerramAerospaceResearch, for example), here is a version that uses my ModuleManager plugin to "soft patch" the command pods: IonCrossLSS - ModuleManager version (Unofficial)

One minor update: I've moved ModuleManager.dll to /GameData/ so you don't have to go into /GameData/Ialdabaoth/ (that way the redistributable files stay separate from my own mods) So now you should just get: {KSP}/GameData/gameData.cfg {KSP}/GameData/ModuleManager.cfg Users still have to do one line of editing whenever they install a new mod; {KSP}/GameData/gameData.cfg needs an include={ModDirectory}/{configFilename.cfg} line for each ModuleManager config file (hopefully this can change for 0.20.1).

Update: For people who want to install the compatibility version, but don't want to modify Squad's /Parts files, here is a version using my ModuleManager.

Can you clarify what you mean by "wildcards or other selectors"? It might already do what you need, or I might be able to add it.

UPDATE: ModuleManager.dll now resides in the root of /GameData, along with gameData.cfg - this is so that other mod authors can distribute ModuleManager.dll without having to muck with the /GameData/Ialdabaoth directory. This means that /GameData/Ialdabaoth is now entirely the ModularFuelTanks mod, while /GameData/ModuleManager.dll and /GameData/gameData.cfg are now entirely the ModuleManager system. Here is a ModuleManaged version of Ferram Aerospace, as an example of how to distribute your mod using ModuleManager instead of patching part.cfg files.