ABZB

uploaded to my dropbox: https://www.dropbox.com/s/u8613vowon38jpf/KSPIISRU.cfg?dl=0 EDIT: The above is my stock-ISRU integration patch for KSPI.

hmmm - how are you considering doing that? Are you going to add KSPI drills or modules? Looking at the stock drill, the surface resource extraction module has a field for resource-extracted: ResourceName = Ore and for what resource is used to drill, just a simple: INPUT_RESOURCE { ResourceName = ElectricCharge Ratio = 15 } For my own current game (I am using the New Horizons pack) I added several converters to the stock ISRU to pull the basic KSPI (all regularly minable stuff) from Ore, at reasonable rates. For a true release, I would think that the following should be done, in order to have variety among planets without ridiculously large menus or parts. 1) Add a few new Ore types, with each type being proccessable into a different 'class' of products - for example, one type would be needed for metals, say for example lithium, Aluminium, & Uranium, one for the various gases generally extractable from rock (say CO(2), O2, H2...), one for the very light elements for fusion (H2 (again), He3, He4, the new Boron thing, I guess, maybe lithium here also or only...). There might be sufficient CRP ore-types to satisfy this in the first place... This way planets with explicit resources can have or not have various (surface) resource classes in various amounts, and Global_Resource nodes can throw those in randomly for any planet packs. 2) Add [stock] modules to the stock drill to extract the different ore types 3) Add [in-code? KSPI] modules to the KSPI ISRU to extract the various elements from the various ores. 4) Add scansat support for the ores 5) The 2.5 meter and the 3.75 meter ISRUs would now be the same, so to re-differentiate them, perhaps the 3.75 one can be given a bonus to its processing. I guess I could do all of those relatively easily, except for 3), as that would presumably be part of the KSPI pop-up window. If you confirm that this plan sounds good, I could get to work on the rest of them

that would be pretty nice - at the moment, I am putting the regular KSPI reactors into cargo bays. If you make a stock-based reactor, I could put together MM configs to convert them to the KSPI reactors - there are two different generator parts, and at least 4 different reactor types in KSPI, so I would end up with 6 parts with the same model then... although, truthfully, I think the reactor-in-cargo-bay may make more sense in a realism sense. Also, practically speaking, I am also then able to attach small convenient parts (science experiments, antennaes, the smallest radiators) to the reactor in the protection of the cargo bay. The Electric Engines parts pack has Mk2-form batteries (they seem to not quite match up to either Squad's or your mk2 parts). That said, that parts pack mainly has some decent electric propellor parts, and some electric-turbojet parts. They are all of the regular cylindrical persuasion though. They are weaker than similar fueled parts (being basically really advanced propellors, rather than something like a nuclear thermal turbojet), but have the advantage of working in any atmosphere, and not requiring fuel (great for spaceplanes ). I would LOVE to have aerodynamic solar panels - I love making tiny little electric planes in early career for Kerbin (or later for a Duna lander and the like) (or just for fun), and all the current options either have terrible drag profiles, or require me to land to recharge [without ripping off the panel].

WRT to the Mk2/3-form engines - Might we see an ion engine model in the future? I am making a MM file that converts the nuclear engines to be the KSPI nuclear engine types - the VISTA and the nuke thermal turbojet are reasonable for your existing engine models, I would like to add the ion-y engines too.

If you have updated to the latest realfuels - the way engineconfigs has to be written seems to have changed. basically, all instances of ModuleEnginesFX and ModuleEngines have to be changed to ModuleEnginesRF (both the actual engine module and the engine type thing on moduleengineconfigs) to work properly. Also, the ullage thing is now a single line in the config itself - not through engineignitor

OK, no worries. I know what you mean - My current game is using New Horizons, sadly with a number of its. the planets cut out due to memory/speed issues. I then moved the remaining planets around, to mantain interesting configurations, and made Kerbol many times bigger and moved all the bodies orbiting it further out (by 1.5x). Getting even that functioning took an abominable length of time... I noticed that Serran in particular seemed to eat a relatively large amount of memory... I ended up having to take it out. Is there any way that a [perhaps sadly less interesting/beautiful] low-memory-impact version might see some future release?

I might have missed this - was there ever a decision on modifying the central star?

The HexCanDeutTritLarge has the following error: In the radioactive decay module, the decay-to resource is still: decayProduct = LqdHelium3 instead of decayProduct = LqdHe3 this is also the case for the two upgraded Large Fusion Reactor configs.

I stumbled across the following theory (I will just post the relevant links, rather than copy-pasting everything to here): http://www.livescience.com/1398-early-earth-purple-study-suggests.html https://en.wikipedia.org/wiki/Purple_Earth_hypothesis https://en.wikipedia.org/wiki/Haloarchaea https://en.wikipedia.org/wiki/Retinal http://www.space.com/3680-colorful-worlds-plants-planets-green.html

Does the pre-cooler need to be between the air intake and the engine at some point, or does the pre-cooler just need to be attached to the intake part in any way, without any parts in-between them?

This is what I did: // run program as follows: ->program name ->LL(Start ALTITUDE for Gravity Turn) i.e: RUN LL(5) starts altitude turn at 5 km PARAMETER StartTurnAt. LOCK WantedPitch TO MAX(MIN((90 - (90*(Ship:ALTITUDE/BODY:ATM:HEIGHT)))*(90/(90 - 90 * (StartTurnAt / BODY:ATM:HEIGHT))),90),0). LOCK STEERING TO HEADING(90,WantedPitch). Basically, I lock my orientation to due east, with the pitch scaling as an asymptotic curve from 90 to 0 between the start of the turn and the end of the atmosphere. If I need to launch to a different plane, then I could edit the '90' directly (although that is really more finicky - you really want to head a little to the side of due north/south, as to cancel the unwanted velocity due to rotation of planet). in the LOCK statement, the MAX prevents the ship from turning back down towards the planet (pitch < 0) if I am above the atmosphere. The MIN statement is what allows the altitude turn start height to work (Basically, the function part returns pitch > 90 until the desired height is reached)

I have uploaded a folder containing the new FX from MP_Nazari's upload to curse (CC 4.0) and my MM patch here: https://www.dropbox.com/s/1iuobps7mnwayvr/KSPIFX.zip?dl=0 Assuming this is to be added to the main install of KSPI, the paths in the FX would need to be CTRL+R'ed to reflect the new folder path (assuming the FX are then placed in the WarpPlugin/FX folder)

currently unknown: Hydrazine,LqdMethane,LqdAmmonia,LqdCO. I know CO2 gas is a pale white - it's used in some neon sign mixtures.

Is there a good source for the dominant emission spectra of various elements and compounds???

Hello - love this idea. I noted that you said that the part has a landing leg thing appear in the part menu - I notice that the last module in the .cfg is a landing leg module. Is that supposed to be there?

Fractal: I saw this just now on curse: http://www.curse.com/ksp-mods/kerbal/232367-hotrockets-fireworks-pack I don't know if you want them, but I think they might be useful for you. I tried to message you this, but it says your inbox is full...

They are very slightly different there - the closeness makes sense. At the moment of your screencap, you are basically pointed (and moving) straight up - so your surface speed is [mostly] your vertical speed - your horizontal velocity component is almost 0.

There seems to be a stock bug that is causing part temperatures to become 'infinity' in certain scenarios (mostly during high RAM use do to many mods). Would it be possible to construct a fix module that watches for that and resets those temps to something sane?

I'll request it on the stock bugfix thread - they do this kind of thing

EDIT: I also noticed that the regular procedural wing has 'Lifting Surface Lift Rating: 2' twice in the part info... I am certain. I posted a pic of this in the SPH, as well as a pic establishing the version of RF and this mod to my dropbox and IMGUR: https://www.dropbox.com/s/k3rkt1g4vjyimbo/BP%20RF%20problem.zip?dl=0 - - - Updated - - - Hah! I found the answer to both problems. There is a file GameData\B9_Aerospace\Patch.cfg It contains the following: @PART[B9_Aero_Wing_Procedural_TypeA] { @module = Part !dragCoeff = 0 !deflectionLiftCoeff = 0 MODULE:NEEDS[!FerramAerospaceResearch] { name = ModuleLiftingSurface useInternalDragModel = True deflectionLiftCoeff = 2.0 dragAtMaxAoA = 0.5 dragAtMinAoA = 0.0 } !MODULE[ModuleFuelTanks] {} MODULE:NEEDS[modularFuelTanks] { name = ModuleFuelTanks volume = 3.84 basemass = -1 utilizationTweakable = true utilization = 0.5 type = Default } } It adds a ModuleLiftingSurface (on top of the one in the main .cfg file) if FAR is not present, removes the .cfg file's modular fuel tanks module - and then only replaces it if MFT, but not RF is installed. Assuming this current file structure is necessary, this patch file should be amended to read: @PART[B9_Aero_Wing_Procedural_TypeA] { @module = Part !dragCoeff = 0 !deflectionLiftCoeff = 0 !MODULE[ModuleLiftingSurface]{} MODULE:NEEDS[!FerramAerospaceResearch] { name = ModuleLiftingSurface useInternalDragModel = True deflectionLiftCoeff = 2.0 dragAtMaxAoA = 0.5 dragAtMinAoA = 0.0 } !MODULE[ModuleFuelTanks] {} MODULE:NEEDS[modularFuelTanks|RealFuels] { name = ModuleFuelTanks volume = 3.84 basemass = -1 utilizationTweakable = true utilization = 0.5 type = Default } }

lol anything I can do to assist with that?

huh - I just looked in the cfg folders, and it is as you said. However, the in the VAB/SPH, no MFT stuff is appearing in either the right-click menu or in the action-group mode. I am using RealFuels, and I am running 1.04 - might there be a problem from one of those? My ProceduralParts fuel tanks are functioning perfectly well... - - - Updated - - - I notice that the right-click menu has a 'next configuration' button that does not seem to be doing anything... what is that supposed to do?

was there a mod somewhere that added MFT/RF tanks to these wings?

KOS: We heard you like crashing, so we put a computer in your rocket, so you can crash while you crash

That's funny - I do the latter, myself (I prefer to have GoT or a nice game of Yugioh up in the other screen, though (Card games in SPACE)). I must have missed the PARAMETER thing - Thanks!