Yaivenov

Unsure if it'd be of help to anyone in smashing that particular bug, but I noticed a correlation between when the launch clamps jump to your ship and the automatic altitude achievements from the stock KSP contract system. Ie., it happens roughly at those same altitude points (hard to tell exact as my Mark 1 Mod 0 eyeball doesn't exactly come equipped with a stop watch )

Okay I've got another bit of a goober question. I'm trying to do plan of action for cooking up the configs for Universal Storage, but I'm just not sure what sort of values I should be hunting down here. Should I just start sourcing quantity info from say the Apollo spacecraft and use that for setting volumes and such on the USI parts (like the slush H2 and O2 tanks and fuel cells) or should I just resize them and then crunch the numbers for volume and mass based purely off the physical size of the module? Beyond that I'm unsure what sort of numbers I should be using to determine the mass of the framing, miscellaneous hardware, aero-shells and what not. Basically I don't want to give you guys a crap config that isn't grounded in reality and could use a little nudge in the right direction to get rolling on this.

I would imagine a Gregorian calendar mod would secretly be operating off the day zero Julian date that already exists. The player just gets to choose an arbitrary start point and the mod could calculate out and display the "correct" G-date as extrapolated from the starting point and the elapsed J-date. The progression of time remains mathematically correct for the purposes of the game, but is just displayed differently on the player's end, much in the same manner as the changing of your speed display from m/s to MPH.

I hope it isn't too overwhelming but, well, there's more. I started a general idea thread and dumped a bunch of ideas in there. http://forum.kerbalspaceprogram.com/threads/132113-Abstracts-and-Concepts-for-Various-Potential-Mods

KeepFit is great for modeling the physiological changes on the body but in this case I wanted to focus on the mind. KabinKraziness seems to be in the direction I want to go but it is dependent on another mod I've already discarded (see below) and seems to be oriented around modeling the system via the resource pool rather than individual attributes tied to particular individuals. I tried AmpYear, Fusebox and TAC Fuel Balancer. Only TACFB came close to the prioritization I desired (I could rig some fuel tanks to always want to flow in and then rig a fuel line from SM to CM to make a one-way resource route and in that manner the crew capsule always was topped off for oxygen and water) but it doesn't offer the level of control and persistence I'm looking for, and near as I can tell they all treat electricity as an ubiquitous resource not in need of wiring and thus is rather difficult to control the flow of (such as, if the power fails in the service module I want the battery backup in the command module to ONLY power the command module's life support and a few systems and nothing else, but I can't with the current system). ResearchBodies: Outstanding! ....now I just have to figure out how to integrate it into RO. Post-Rollout Fueling, I could also just use the TAC Fuel Balancer to click and edit the fuel back into the ship, but there is something amusing to me about the anticipation of fueling it up. As mentioned this is something that I've already found a simple solution to and implemented (launch umbilicals, bless you FASA for all you've given us) but on reflection now I think it could be expanded further: Growing cryogenic effects, boil off apparent at the junctions and vents of the rocket, frost forming over the surface of the LOX and LH2 tanks, etc. For Staging I've been testing out smartparts and as I mentioned you darn near can make a nice IU using them, but growing part count will always be an issue. Just spitballing here but lets say that's between 6 and 10 smartparts per stage to handle all the timing issues, that's between 18 and 30 extra parts just for a three stage deal. Even with that set aside there is still the desire to be able to remove things from the staging list so it can not be inadvertently activated and the like. TACLS - Thanks for that info, I was playing around with watching power drain via AmpYear earlier and I wasn't able to discern any changes as the spacecraft proceeded through different environmental regimes. I'll just tentatively scratch this one off the list then. And yeah, that's why I tried to split the ideas between RO specific and those that I thought could help flavor (mostly) stock games.

I don't know about you, but in manual flight for a rocket launch my eyes are glued to my navball and instrumentation.

If you are chronically TL;DR, then this isn't the thread for you. Here are some of the mod concepts and improvements that have popped into my head while playing KSP. I do know that some of these ideas may have already been implemented, so if you see me writing about an idea that someone else has already put into practice please tell me so I can go ahead and cross it off the list. Beyond that I'm just looking for feedback on which (if any) of these is interesting and should be looked at further and additional suggestions on how any of these ideas (or just some of your own if you like). Some of the ideas I can implement, others are a bit beyond my ken. They are not in any particular order, I just happened to write them down here and there and then compiled them all together. Anywhoo, on to the list... Player Created Ground Stations: My first time playing RO I didn't have the remotetech transmission sites updated, so in order to launch unmanned craft I first had to built a base control station. It was an oversized ground vehicle with six kerbals on board along with the necessary antennas to communicate with the craft. I drove it about 5 km away from the launch complex but still with line of sight to the pad. This kept the vessel outside of the loading range from whatever active rocket the player is trying to launch (assuming the player still has the stock loading distances in place). This could be parlayed into another aspect of the game where not only are you setting up satellite constellations, but you are also responsible for setting up your initial ground control stations both local (at the cosmodrome) and remote (think Alice Springs, Australia during Mercury). This is achievable easily via reducing the number of static ground stations and/or severely limiting their transmission distance and providing enough parts early in the game for the player to make their ground stations. See the RemoteTech Additions section for relevant information concerning non-Line-of-Sight radios. Mood and Sanity: A psych or "sanity" state for the kerbals as part of the life support system. Sanity being affected by things such as living conditions, enviroment, overall duration in a given enviroment type (no "change in scenery"). Factors: Mood - As a sanity affecting factor mood is weighted more heavily, happy people don't come unhinged as fast as unhappy people. Mood in general is an amalgam of the following factors, however other special events can have an immediate and overriding impact on the Kerbal in question. For instance they might be as happy as can be under STP, but for the 5 minutes they spend hurtling through the atmosphere on re-entry they could still have a rather significant emotional event. -- Interaction - Social critters need to social. If there are no other critters nearby to make pleasing noises with then the next best thing is calling up other critters on a communication device and making pleasing noises by remote transmission. Basically don't leave your Kerbal alone and out of radio contact for very long, you never know what kind of mischief they might get up to. Very short clock on this one. Radio communication ameliorates isolation but is an imperfect solution and only decreases the penalty. -- Habitat Volume - How was your last airline flight? Much elbow or leg room? Want to stay in that seat for the duration of a 2 week mission? Well that was about the sum of things for the Gemini pilots. For very long duration missions you'll probably want more than a phone booth's worth of living space per 'naut. This factor is largely static and is directly based on the available crew volume in a vessel divided by crew members, perhaps done non-linearly. Two 'nauts might have to share the extra space, but at least it's still extra space so it isn't just a straight division. -- Diet - Luxury or specialty food items selected by astronauts on the ISS are used to break up the monotany of the available food stuffs on board. I imagine a Kerbal equivalent would be a "Mint Dessert" to break up the constant snackage. MD are prepackaged in single serving units and the Kerbonauts would be "instructed" by ground control to "open science mission package 327b and execute contained instructions..." which naturally would be "Eat me." with an appropriate number of MD cakes (cake (mint dessert type), one (1x) per) would be consumed giving the 'nauts an appropriate boost to mood and will also reset a "snack clock". At first the diet will have a net positive affect on sanity, however after a period of time (as the snack clock climbs) it will decrease, flatten out for a while, and then begin negatively impacting the sanity. As mentioned this can be reset with the application of suitable luxury food items. -- Gravity - Major mood killer if you can't get out of your rack because Eve's gravity has you pinned to the matress like a cat to a car window. Low/no gravity can be initially very fun and a mood boost, but will gradually slide to slightly negative in zero-G as the physiological effects begin to take their toll. A centrifuge habitat can be used to raise it up to just a neutral effect. Heavy gravity is immediately fatiguing and so is an immediate and constant negative effect to mood. -- Duration - How long has the 'naut been away from home, and also how long have they been in a given biome? Overall duration starts neutral and then eventually evolves to negative both in mood and in a slow but cummulatively relevant direct affect on sanity. The closer the local environment is to home, the slower this clock runs. Time in a given biome starts out with a positive boost to mood, and a slightly positive direct affect on sanity and then progresses to neutral and flattens there as the local scenery becomes common. -- Distractions - Food for the eyes and mind. New movies, messages, pictures. Anything novel and interesting that can be digitized and delivered at 2.4GKz. Behavior similar to the desserts for diet but gives a slightly longer (but less intense) mood boost and also a direct positive sanity increase if the distraction is emotionally significant for the 'naut (letters from family, etc.) -- The practical effects of mood and sanity states could be displayed in a cross-grid, and possibly include spontaneous transmissions, varying levels of command compliance, positive/negative effect on craft and systems, et alii. Integration of Craft Parts Into Avionics Mods: In short limiting the information available to the player via MechJeb (or others) while in flight based on the available onboard (or offboard) hardware. As an example, MechJeb not being able to display the local temperatures without an on-board thermometer. Perhaps certain higher order maneuver planning is unable to be performed with the on board craft hardware and instead you need a radio link back to mission control where the ground based super computers can chew on the problem for you. Other aspects would include integrating other mods together, such as the KerbalGPS system with RemoteTech and Mechjeb. Early hardware may prove insufficient for accurately plotting the ship's trajectory out beyond a certain distance and so instead of a nice orbital line being displayed the player instead sees an ever expanding cone from their current position to the point where the plot just ends because it has become excessively inaccurate. Ablation Resource for Engines and Regenerative Cooling Failure: Inspired the cooling selection mod but primarily for those using RO or similar engine mods that already make large distinctions between fuel types and engine hardware. Add the ablation resource to ablatively cooled engines in much the same manner as for command pods thus giving them a very much finite run life. This could be the single major limiting factor in the reused of hypergol engines that are otherwise not restart-limited. On the other side for regeneratively cooled engines, perhaps some catastrophic failure (due to rapid and extreme overheating, so technically the failure bit is already in game, we just need a way to activate it in particular situations) if the engines are run to propellant exhaustion and thus are deprived of coolant flow through the engine prior to flame out. So the player would either need to balance the tankage to be a little coolant heavy (so the engine flames out before losing coolant flow, assuming only one of the bi/tripropellants is used in cooling, not an available strategy for monopropellant engines like NTR's) or shut down and/or stage before total propellant/coolant exhaustion (probably the better idea). Additions for SmartStage Mod: Additional triggering parameters such as G-load, unifying the different parts into a single part with menu selectable triggering parameters (and attendant texture change to match), and perhaps allowing remote placement such as putting a tank resource Smartpart in the interstage IU and then just telling it which tank to monitor. Additions for RealismOverhaul Mod: If the improvement is specific to another mod RO alters that mod is listed in italics and underscored. -- Being able to switch from the day 0 Julian-style calendar currently in game to the more familiar and thus intuitive Gregorian Calendar. -- Control Moment Gyroscopes of various gimballing function as a later upgrade from the basic (and extremely low torque) Reaction Wheels. In practical application this means just making a heavier reaction wheel module part with stronger torque. -- A change to the saturation of reaction wheels, instead of having a torque consumable resource that slowly regenerates they could display the current reaction wheel speed and also its maximum and minimum speeds. As the reaction wheel does work it will be gradually speeding up or slowing down the wheel as needed and once it reaches the limit of its speed range it is no longer able to provide torque in that direction. At that point the player can execute a desaturation burn using the onboard RCS engines and thus "reset" all the momentum wheels back to their starting speeds. Single reaction wheel/single gimbal CMG's to start with. Low mass, placeable as the player desires, and only able to affect a single axis of rotation (based on their mounted orientation). Combo units to follow after unlocking higher tech nodes. Single gimbal CMG's provide better torque, but you'll need more of them combared to a multi-gimbal CMG. -- Flow limits on propellant lines. If you're feeding a big engine from another tank via a fuel line it would need to be sized up (and thus also it's mass) as appropriate to permit the volume necessary to run the engine. The size of the fuel line/utility tunnel would also affect the rate of resource transfer from one area of the ship to another if it is channeled through such a bottle neck. Flow rate from balloon tanks limited by the rate of tank pressurization (can't let the structure collapse because we're sucking the propellant out of it faster than the pressurization system can manage, this could induce players to choosing heavier tank types if they're feeding big engines or using tankage in a mass/volume restricted application.) -- Treating electrical charge like any other resource and requiring the appropriate resource connections to channel it around resource break points (decouplers) and the like. -- TAC Life Support - Resource consumption rate documentation so space craft can be appropriately designed for specific missions and duration (I'm looking at doing an RO config for Universal Storage and will likely be looking up this particular information on my own and can probably just release whatever notes I write down for that purpose.) -- TAC LS - Cabin CO2 needs to changed so it's displayed as a percentage of the cabin atmosphere, and not an alterable resource (you can't magically reallocate the CO2 out of the air in the cabin without either a chemical scrubber or atmospheric fractioning equipment, which would be heavy). CO2 needs to be constantly and immediately scrubbed so the CO2 absorbers need to be planned to last the entire mission. Any build up in the crew cabin would be detrimental to their health. CO2 gauge should be from 0.00% to 1.50% (or whatever is considered lethal). Kerbal suits should have their own built in systems and crew should be able to get into their suits if the spaceship life support isn't working (this idea is repeated below as it would be appropriate in a non-RO game as well). -- TAC LS - "Life support" electricity should be broken down into detail so that select technology upgrades can be implemented and cause the astronauts to use less through more efficient lighting/heating/cooling. Crew capsules should also be temperature controlled, which would require greater amounts of electricity if the craft isn't setup to handle its own waste heat efficiently (radiators, etc., more energy used if you have to use a lot of heat pumps to move the waste heat somewhere else to be radiated, so on) Apparently already does this. -- TAC Fuel Balancer - Should not be able to randomly dump certain resources (such as solid waste). Also needed are persistent settings per craft resource so that the tankage and such can be set up to operate in a specific manner (such as drawing RCS fuel from earlier stages so you don't inadvertently drain the tanks for your reentry control earlier in the mission) and the ability set them while still in the VAB/SPH. This second aspect would be beneficial for TAC FB in general, and not just in RO, and is repeated farther down for that reason. -- Landing hazards presented by residual toxic resources on board, ergo, the necessity of dumping your remaining RCS propellants and what not before touching down on the ground. Failure to do so would render the craft "toxic" and subject to a long and possibly costly reclamation process (basically a cool down timer and a cost penalty before you can recover the craft, the crew on board could still button up their space suits, get out and go get picked up on their own so they don't die from starvation and the like while the timer is still going.) Heat hazards after reentry might also be a consideration. -- RemoteTech - Remote operations center (ie. any ship with six kerbals and a radio) kerbal skill requirement (ie. 3 engineers, 2 scientists and 1 pilot for a remote station, and a needed XP level for each). Perhaps a new type of kerbal, the support Technician necessary for certain things. -- More RemoteTech - Directional antennas that need to be pointed at the target. Some with auto-tracking (similar to solar panel sun tracking, but oriented to the designated target) others without either need the spacecraft to point at the target (Voyager, New Horizons, etc.) or some other mechanism (Infernal Robotics?). -- MOAR RemoteTech!! - Different radio bands, some that do atmospheric bounce and scattering to allow non-Line-of-Sight communication on a planet without relays (void where prohibited and/or lacking an ionosphere and troposphere), and their associated propagation effects, transmitter power requirements (user adjustable on the fly, why put out enough RF wattage to reach Pluto when you only need to talk to Mars right now?), receiver sensitivity. -- Multistage Engine Start Up and Operation: spin up turbomachinery first via compressed gas or gas generator, when the pumps are "at speed" or the propellant lines read a certain pressure available then open the fuel valves to the injector and activate the ignitor system if seperate (the H-1 engine bled off gasses from the solid rocket motor gas generator that spun up the pumps and used it to also ignite the combustion chamber). On/off status should be independant of throttle setting and require a deliberate action (shutting the propellant valves). Some issues with start-limited engines in the KSP game are there are instances where the game may either bug out momentarily setting throttle to 0 and then back to the previous setting and there are instances with mechjeb (such as switching off the launch guidance while still in powered flight) that will also change the throttle setting and interfere with proper operation and often cause a failed launch. The game "hiccups" can be resolved by allowing the automatic re-ignition and continuation of an engine that is already at speed (pump wise) and temperature (combustion chamber wise). Being able to build an appropriate IU (Instrumentation Unit) for the different stages. Almost possible currently with smart parts. Being able to add additional tanks of high pressure helium and/or TEA/TEB to change the number of times an engine could be restarted. The Saturn V S-2 engines (five J-2's) only needed to light once, versus the S-IVB's engine (also a J-2) would need to be able to start at least twice. This will let players further tailor their rockets to their own designs. -- Stage System Overhaul: Any command that could otherwise be placed into an action group can be optionally placed into the staging queue. Each "stage" can be broken down and different parts can be assigned different times of action to be executed as a stage. Example: Stage 1 (launching) T+0 seconds = fire gas generators starting turbomachinery for engines. T+6 seconds = open fuel valves to combustion chamber. T+6 seconds = activate ignitor. T+10 seconds = after achieving full thrust (not an instant thing in real engines), release launch clamps. T+n seconds = close fuel valves to turbomachinery and allow to spin down on own, thrust drops off gradually. T+n+5 seconds = initiate staging -- Procedural Parts - Different battery chemistry and break-down (loss of capacity) over time. Disposable vs. rechargeable, varying capacities vs. weights and so on. -- Virtual Parts - Flight hardware that can be incorporated into crewed capsules and takes up a set amount of internal volume, such as the on board CO2 scrubber, radio transceivers, various flight instrumentation. The "parts" can be swapped out based on mission needs, upgraded for ability and miniaturization. On-board parts will also affect what flight information is available to the player via MechJeb and the like. Some other example parts include a radar altimeter (which gives you an exact true altitude) a barometric altimeter (which gives you a mostly accurate sea level altitude, but only if you're in an atmosphere to measure), a star tracker (which tells you where you are in space), attitude gyroscopes, a non-resetting mission clock (that basically just records how long that particular capsule part has been in use and doesn't get reset by things like docking and undocking) and the list just goes on and on with the only real limit being player desire for how far they want to take it. Capsules and probes would have a set internal volume for flight hardware as distinct from the volume set aside for tankage with realfuels. Excess hardware volume could be made available for crew habitat use (note the Mood and Sanity need for habitat volume above). Additions for MechJeb Mod: Smart A.S.S. control mode that uses engine gimbal to "center" the engine thrust through the center of mass of the entire spacecraft, and to orient the navball so that prograde is parallel with the thrust vector. This should help players deal with minor craft imbalances at the later stages of flight where the issues become more and more pronounced as craft mass decreases. Additions for FASA Launch/Umbilical Tower: A unified common tower model from which the umbilical arms and boarding gantries are suspended from. Perhaps put it on the VAB side of the launch pad and have the tower base mounted on rail bogeys in those existing track models so it appears to be part of the roll out system and stands off from the launch pad proper. Umbilical arms and boarding gantry should be procedurally adjustable for length in order to have the reach for the larger rockets that have a wide diameter or lots of boosters at the lower stages. Additions for TAC Fuel Balancer: Persistent settings per craft resource so that the tankage and such can be set up to operate in a specific manner (such as drawing RCS fuel from earlier stages so you don't inadvertently drain the tanks for your reentry control earlier in the mission) and the ability set them while still in the VAB/SPH. Additions for Procedural Parts: Toroidal propellant tanks. Similar to the fillet cylinder, but with a hollow cavity in the middle and an "Inner Diameter" adjustment for it. Basic mounting hardware at the top where the tank attaches in the stack and with the second stack node just below it so engines and other parts can be nested inside the tank (ie. lunar ascent and descent stages for the LEM). Additions for Kerbal Attachment System with Kerbal Inventory System: Spacesuit change to crew inventory item that they can choose to wear (option to wear available both inside and outside the craft). Suit life support values independant from the spacecraft at all times (with the player controls to refill from ship resources.) Wear of a space suit while inside the craft will put that person's life support requirements on the suit thus giving them an option in the event of ship life support failure. Additions for Procedural Fairings: A "see through" mode for procedural fairings akin to the stock fairings so you don't have to pull them off (and thus break some action groups) to get at the parts underneath when setting stagings and action groups. This could be accomplished by having the fairing simply be mostly transparent and non-clickable/collidable (except for a small bit where it mounts to the support ring) while in the VAB/SPH. Smaller/skeletonized thrust plates and cargo/interstage adapters. The adapters become excessively tall at larger sizes and being able to reduce that height (and also mass) manually would be helpful. Thrust plate load capacity (and thus overall mass, again) as an independantly adjustable setting that affects the visible thickness of the structure. Images of skeletonized thrust plate concept to follow. Bird-cage/lattice style fairing panel for early interstage junctions. Examples can be found on the Soviet SS-8 and SS-13 missiles. Having most of the part objects consolidated into 2 or 3 distinct parts and then use selection menus to specify and customize. Procedural fairings pieces with selections for exterior texture, interior texture, shape geometry, material selection (extra insulated, metal vs. composite, reentry tiles, etc.), a single "mounting adapter" that is selectable for Engine Thrust Plate, Cargo Mounting (specially selectable for the height of the payload mounting, depressed/flush/elevated and how much), interstage and so on. Additions for TestFlight: For the TestFlight mod: What about test stands that let you evaluate and develop engine reliability without risking them in flight? Test stand can be as simple as your rocket stage being mounted to extra-strong, non-releasing launch clamps that also act as the probe core for control. As an addon for KCT, you could develop engines on a test stand to reduce their dynamic failure rate (rather than flying them to do so), and then also incorporate a minimum "material defect" failure rate. To counter this you would test unique engines on the stands, verify they are good, and then install them on the rockets for use. A few special areas don't allow this though, such as the Lunar Descent Engine on the LEM. Due to the corrosive hypergol propellant and the ablative cooling it could only be fired once and allowed for no pre-testing, so while you might reduce the tech development failure rate with R&D and live fire tests you will be unable to avoid the material defect failure rate in certain cases. Additions for Airlock: Unable to exit the crew capsule unless it is depressurized first, can only depressurize if everyone in the capsule is suited up. Airlock code module for crew capsules large enough to support them, airlocks allow ingress/egress without depressurizing the whole capsule, but will vent an airlock's worth of oxygen to space if a scavenger pump isn't available/used. Airlock possible extra item to add to ships or stations that don't yet have one. Existing-mod-based Parachute Parts Pack for RealChute: A model pack of all the available (permission pending) parachute models rolled together and made available for use by the RealChute mod in order to add more variety to the game. Possibly also practical effects based on chute selection. Other addiction for RealChute: Collision mesh (?) for parachutes so they push each other aside (and maybe deform/flatten where they contact) while deployed instead of clipping through each other. Astro-Charting and Telescope Experiments: A few previous mods have entertained the idea of needing to physically orient the craft so that the telescope can see things, but this could be taken a few steps further. This idea would necessitate the discovery, observation and tracking of celestial objects that have otherwise been overlooked if you wanted to be able to (accurately and/or successfully) visit them. Astronomy experiments to first discover other celestial bodies followed by plotting their orbits (repeated observations). Perhaps a system to give the player an idea of where to manually look with a telescope (using WFOV IR/Vis/UV as an example), and then repeated static sightings being calculated into orbital parameters. Already fulfilled by ResearchBodies mod (thank you Hab136 for telling me about it.) Spacestation Purposes and Missions: Add in practical benefits and necessities for station placement, such as you can only do certain experiments on an established (time in present orbit requirements?) spacestation orbiting a specific body at a particular altitude and also missions to expand upon already placed space stations with additional scientific, industrial, or mission payloads that expand the capability of that station. Mass Centering Tool for the VAB/SPH: COM centering tool for the VAB (top-down looking indicator showing vessel COM and COT relative to physical center so the player can move payloads around until properly balanced.) Negative Buoyancy: Buoyancy ratings for different craft/returned probes and thus a practical use for additional flotation devices to keep your water-landed craft from sinking. Procedural Utility Tunnels: Essentially fuel lines that can only be placed vertically (and will automatically snap the second part into vertical alignment), and which will contour themselves to the surface of the craft. Menu selections for which resources that can be passed and in which direction. Needed for controlling resource flow across staged part stacks, like from the Service Module to the Command Module, I want the service module's oxygen to feed the CM, but I don't want to just toggle crossfeed on the decoupler because I do not want the SM's fuel cells to be able to rob the CM's crew oxygen in the event of Something Badâ„¢. Contracts and Strategies in Science-only Career Mode: Contracts and administrator strategies should remain open and available during "science only" career playthroughs as both provided a source of science points to unlock technology (a science only career has less science points available to it than a full career, especially early on when the player is scraping together a few points here and there to unlock the initial techs). Additionally a career mode that allows the player to act as a government agency for funding purposes could be interesting, a regular albeit fixed budget that is provided each year/month with the player able to petition for an increase in funding by putting together project presentations, tech demonstrators, etc. or suffer a decrease if they fail to show merit for continued funding. Idea is already being implemented in a couple mods. I love being able to cross things off. Preferential Electrical Grid: A list of all ElectricCharge consuming parts on the vessel and the option to set their priority, ie. the grid control will choose to stop powering certain systems if the on board stored electricity falls below a set threshold, or if the current load demand exceeds a certain point (imagine I turn on the radar mapping device, my power drain jumps and the grid controller reacts by switching off certain non-critical ship components so I don't drain my batteries before reaching the light side of the planet. Accurate time estimations for resource depletion. Post-Rollout Fueling: (I've already done this and have the altered configs set aside) In order to get around part loading lag that was destroying massive rockets in my game I would prepare them in the VAB and then drain all the main LOX/LH2/RP-1 tanks and have a few of the ground support parts (launch clamps, umbilical towers) set as resource generators. The rocket would load in with only a fraction of it's flight mass avoiding lag bug destruction, and then would spend a short while gassing up prior to flight. obviously shouldn't apply to small pre-prepared tanks like the Apollo SM's SPS hypergol tanks, RCS fuel, etc. Only modification needed was to add the resource modules to the launch clamps. Additionally, this reduced the propellant penalty incurred while waiting for the booster engines to spin up to full thrust. Until I released the last of the launch clamps the propellant umbilical on the first stage would try to keep the tank full during start up. A kludge system I used to employ for this issue was an extra fuel tank strapped to the frame of the launch clamps with a fuel line connected to the first stage. The tank I was leaving behind would feed the engines until they were at full thrust and I broke the fuel line connection by releasing the launch clamps.

You are most certainly correct Vorg. I've been trying to write up some of my ideas into some short concept abstracts. Here's the ideas I have had specifically for ProceduralFairings... Additions for Procedural Fairings: A "see through" mode for procedural fairings akin to the stock fairings so you don't have to pull them off (and thus break some action groups) to get at the parts underneath when setting stagings and action groups. This could be accomplished by having the fairing simply be mostly transparent and non-clickable/collide-able (except for a small bit where it mounts to the support ring) while in the VAB/SPH. Smaller/skeletonized thrust plates and cargo/inter-stage adapters. The adapters become excessively tall at larger sizes and being able to reduce that height (and also mass) manually would be helpful. Thrust plate load capacity (and thus overall mass, again) as an independantly adjustable setting that affects the visible thickness of the structure. Images of skeletonized thrust plate concept to follow. Bird-cage/lattice style fairing panel for early interstage junctions. Examples can be found on the Soviet SS-8 and SS-13 missiles. Having most of the part objects consolidated into 2 or 3 distinct parts and then use selection menus to specify and customize. Procedural fairings pieces with selections for exterior texture, interior texture, shape geometry, material selection (extra insulated, metal vs. composite, reentry tiles, etc.), a single "mounting adapter" that is select-able for Engine Thrust Plate, Cargo Mounting (specially select-able for the height of the payload mounting, depressed/flush/elevated and how much), inter-stage and so on. I'm always a little unsure whether an idea of mine would be a widely desired thing versus just me reveling in pedantic nerdery, so, do those seem worthwhile?

Seems like an excellent suggestion for the ProceduralFueltanks, so in addition to cylinder, cone, fillet cylinder and curved cone you could have toroidal type where the player sets the outer diameter, inner diameter and length. The "top" and "bottom" ends could automatically fillet and of course the stack mounting nodes so you can nest things *coughenginescough* inside it. This is also something that I'd like to see in the game. I've been kinda faking it with saddle tanks that hang around the outer diameter of my SPS or descent engines. Thank you for putting it on the forum.

I am also experiencing this problem. It seemed to begin after I installed the SXT (Stock Extensions) mod. I'm working on something else at the moment but I'll try to remember to remove SXT and test it later.

That (and I quite agree) needed legacy support could be produced by releasing the all-inclusive 2 part Procedural Fairings version as an independently installed "2.0" to be used until such a time that all in-flight craft with the deprecated parts have been recovered and the "1.0" can be uninstalled. Of course this all presumes that the mod developer even wants to do this.

Thanks Rothank, that's actually exactly the sort of thing I was looking for. I really wish I could program something higher order than a Ti-83 as I'd like to make an in-game part pruner. Right click, deselect the part in the VAB/SPH and have it go through and redact that part and also any additional files that are unique to that part (not used by any other parts, shared textures and the like) to further reduce the memory load.

A crazy thought, but why do we need dozens (if you have any of the PF part add-ons) of different fairing panels? Why not a single panel part with menu selections for Exterior Texture, Interior Texture, Fairing Shape (Conic/parabolic/hybrid/etc.) and Fairing Material (extra insulation, basic metal vs. advanced alloys vs. composite vs. ceramics, etc.) For the different adapter rings why not a single one with selections for Interstage/Payload Fairing/Payload Fairing with Elevated Frame? You could cram a buttload of content into 2 parts. By the way, totally not digging on this mod. It has well earned its spot in my personal "mandatory mods" list.

Okay, so apparently my Google-Fu skills went on vacation and didn't bother to tell me.... I'm trying to find RO configs for Universal Storage that does not involve using RP-0 and its attendant mods. If anyone can tell me where to go looking for such a thing (if it even exists) that would be greatly appreciated.

Maybe someone could answer something for me.... is there a way to engage a "debug" mode in RO so that the parts shown in the VAB/SPH also list their original names/manufactures? Purpose would be to make it easier to determine which files I need to trim to reduce superfluous parts.

Yup. Bloody CKAN just would not allow me to split KW from the "community fix" and I pretty much had to resort to just going into game data and gutting the CF folder manually.

Should I just assume that none of the ideas I posts are particularly interesting then?

It lets you spin your rocket around and click madly trying to get at those little parts without worry of ripping off a stage or five. - - - Updated - - - I had a bug similar to that with the KW Rocketry parts. The "community fix" that CKAN forced fed along with KWR turned out to be the culprit and was messing with RO's changes to the parts.

Outstanding mod. Now I have a way to self destruct any SRB's for a launch abort.

So whenever I'm playing KSP, or modding KSP, or reading about KSP, or eating, sleeping, driving, etc. well lets just say ideas are always bouncing around and sometimes I actually remember to write them down! So here's just some of those thoughts while I was whittle away the hours in the game. There's no real pattern here, I just jotted down things as they occurred to me. Hopefully a few of them are actually worthwhile ideas and will spur some mod development (awesomeness sold separately). Bugs - Just a few of the more annoying glitches that keep getting in the way of a good space mission. Life support electricity showing "0:infinity" in RO, shows proper time in stock. Built in crew pod RCS is still buggy. The "mercury" pod's rotational RCS thruster fires when the yaw command is given. This continues even if the roll RCS selection is switched off in the VAB. SAS/SASS still needs anticipation/damping to fix the constant "hunting" and overshooting problem. Perhaps the system can be made to examine the position and power of the available manuevering thrusters versus the mass of the craft to determine available angular acceleration and use that to set limits onto the automatic RCS systems so they do not keep accelerating the crafts rotation continuously through out the manuever. Capsule-integrated RCS thrusters still bugging out when being controlled by mechjeb or the stock SAS. Sometimes have to manually disable the mechjeb module in the crew capsule/probe core to restore function. Recommend just removing them for the time being and adding a simple linear thruster part that is available in the starting node. Let the players figure out how best to arrange control thrusters. The launch clamps are chasing the spacecraft (snapping to it's location and sometimes colliding) at some of the same altitudes used for the automatic "altitude record" contracts, namely 6.5km, 13km and 22km (approximate). Needs - Critical bits that are missing. Some sort of starting interstage is needed, procedural interstage and payload fairings unlock far after the player is using multi-stage rockets. As an idea, what about crude forms of interstage design, like the bird cage or lattice arrangements. As better interstage systems are unlocked they will become lighter (for a given size) and also improve in aerodynamics (lattice versus hard shell). Ability to turn down realplume in a more readily accessible manner, selections to exclude entire aspects, such as the smoke plume but not the flame envelope (or even just easily found documentation to instruct players in how to alter settings in smoke screen and elsewhere as they may need to.) Can we get engine lighting integrated into realplume? Clear documentation in game of which tech nodes improve already unlocked parts (such as the procedural fairing sizes and the mechjeb capability modules). Wants - What most of my ideas fall into, "hey it would be great if...." A part trimming tool in game that can be used to "permanently deselect" parts out of the list in the VAB/SPH and upon next reboot they will remain unloaded. Multistage engine starting: spin up turbomachinery first via compressed gas or gas generator, when the pumps are "at speed" or the propellant lines read a certain pressure available then open the fuel valves to the injector and activate the ignitor system if seperate (the H-1 engine automatically bled off gasses from the solid rocket motor gas generator that spun up the pumps and used it to also ignite the combustion chamber). On/off status should be independant of throttle setting and require a direct action by the player (shutting the propellant valves). Some issues with start-limited engines in the KSP game are there are instances where the game may either bug out momentarily setting throttle to 0 and then back to the previous setting and there are instances with mechjeb (such as switching off the launch guidance while still in powered flight) that will also change the throttle setting and interfere with proper operation and often cause a failed launch. Spacesuit change to crew inventory item that they can choose to wear (option to wear available both inside and outside the craft). Cabin CO2 needs to changed so it's displayed as a percentage of the cabin atmosphere, and not an alterable resource. CO2 needs to be constantly and immediately scrubbed so the CO2 absorbers need to be planned to last the entire mission. CO2 gauge should be from 0.00% to 1.50% (or whatever is considered lethal). Kerbal suits should have their own built in systems and crew should be able to get into their suits if the spaceship life support isn't working. "Life support" electricity should be broken down into detail so that select technology upgrades will cause the astronauts to use less. More efficient lighting/heating/cooling/etc. Crew capsules should also be temperature controlled, which would require greater ammounts of electricity if the craft isn't setup to handle its own waste heat properly (radiators, etc., more energy used if you have to use a lot of heat pumps to move the waste heat somewhere else to be radiated, so on) Unable to exit the crew capsule unless it is depressurized first, can only depressurize if everyone in the capsule is suited up. Airlock code module for crew capsules large enough to support them, airlocks allow ingress/egress without depressurizing the whole capsule, but will vent an airlock's worth of oxygen to space if a scavenger pump isn't available/used. Airlock possible extra item to add to capsules or stations that don't yet have one. Preferential electrical grid that allows prioritizing of electrical sources, and lock outs that prevent their consumption before other systems (TAC fuel balancer could probably do this but would need persistent resource storage settings. Also accurate estimations for energy consumption rates and estimated depletion times, TACLS for instance doesn't change the remaining time for life support based on current craft drain, instead that clock just speeds up (electrical estimation clock observed in stock KSP, presently non-functional in RO). Control Moment Gyroscopes to compliment and upgrade from the Reaction Wheels and Reaction Control Systems. Make some that are single gimbal versus full gimballed. Locking out certain in-game information from mechjeb and other sources until suitable parts are unlocked, ie. no exact temperature readings until the thermometer is unlocked and installed on the craft, no exact surface coordinates without a GNSS receiver and constellation or a star tracker. Limited fuel flow rates through lines, fuel flow rate from balloon tanks limited by the available pressurization. Player will need to account for necessary propellant flow rates to meet the demands of the various engines. Procedural "utility tunnels" (fuel lines) that hug the surface of the craft allowing the simplified and low profile of linking parts in a stack. Selectable for which resources it will pass, and also which/both direction (say a one-way RCS propellant line so your CM drains the SM's tanks before its own and a two way electrical umbilical both in the same utility tunnel object). Electrical power being treated like other fuels and requiring a suitable connection across stage seperators. Toolsuite to evaluate the best launch profiles for a given rocket. Overhaul current staging systems. Placing a stage-possible part on a ship and that staging icon should go into an unassigned pool. From there the player chooses which parts to assign to the staging list, if any. Parts left in the unassigned pool are excluded from the staging list (for instance an engine that you want to only ever be activated via control group). Each "stage" can be broken down and different parts can be assigned different action times to be executed as a stage. Example: Stage 1 (launching) T+0 seconds = fire gas generators starting turbomachinery for engines. T+6 seconds = open fuel valves. T+6.25 seconds = activate ignitor. T+10 seconds = after achieving full thrust, release launch clamps. T+n seconds = close fuel valves to turbomachinery and allow to spin down on own, thrust drops off gradually. T+n+5 seconds = initiate staging Contracts and administraction strategies should remain open and available during "science only" career playthroughs as both provided a source of science points to unlock technology (a science only career has less science points available to it than a full career, especially early on when the player is scraping together a few points here and there to unlock the initial techs). Additionally a career mode that allows the player to act as a government agency for funding purposes could be interesting, a regular albeit fixed budget that is provided each year/month with the player able to petition for an increase in funding by putting together project presentations, tech demonstrators, etc. or suffer a decrease if they fail to show merit for continued funding. Collision mesh (?) for parachutes so they push each other aside instead of clipping through each other. To Do's - Things that I think should be within my skills to create/fix. Make a list of engines and suitable models that match (or closely match) them for a "RealEngine" mod. Standalone engine pack to reduce the excess clutter and memory usage from installing entire mod packs just for the engines. Also to correct for tech node misplacement, duplicated engines (RL-10 and J-2 I'm looking at youse) and poor models (stock engines being repeatedly recycled and distorted as place holders and filler). Need to contact mod authors to get permission to repack their engine models together. Search the available mods for the best engine models to match their real world counterparts. Find a way to integrate Kerbal GPS into RemoteTech and MechJeb (no ground coordinates available without a GPS constellation or an independent navigation system such as a Startracker. (Should GPS satellites be required to carry an isotope clock and startracker to be functional?) Being able to build an appropriate IU (Instrumentation Unit) for the different stages. Almost possible currently with smart parts. Being able to add additional tanks of high pressure helium and/or TEA/TEB to change the number of times an engine could be restarted. The Saturn V S-2 engines (five J-2's) only needed to light once, versus the S-IVB's engine (also a J-2) would need to be able to start at least twice. This will let players further tailor their rockets to their own designs. A tech tree based on dates of development with the different branches based on different technology types/engine development programs. Make the doors on the stock science bays deployable radiators like the space shuttle's cargo doors. To Done's - Stuff I've already done. Require bulk fueling to be done at the pad after rollout. In order to get around part loading lag that was destroying massive rockets in my game I would prepare them in the VAB and then drain all the main LOX/LH2/RP-1 tanks and have a few of the ground support parts (launch clamps, umbilical towers) set as resource generators. The rocket would load in with only a fraction of it's flight mass avoiding lag bug destruction, and then would spend a short while gassing up prior to flight. obviously shouldn't apply to small pre-prepared tanks like the Apollo SM's SPS hypergol tanks, RCS fuel, etc. Only modification needed was to add the resource modules to the launch clamps. Random Thoughts - Like I needed to restate that... For the tech reliability mod: What about test stands that let you evaluate and develop engine reliability without risking them in flight? Test stand can be as simple as your rocket stage being mounted to extra-strong, non-releasing launch clamps that also act as the probe core for control. As an addon for KCT, you could develop engines on a test stand to reduce their dynamic failure rate (rather than flying them to do so), and then also incorporate a minimum "material defect" failure rate. To counter this you would test unique engines on the stands, verify they are good, and then install them on the rockets for use. A few special areas don't allow this though, such as the Lunar Descent Engine on the LEM. Due to the corrosive hypergol propellant and the ablative cooling it could only be fired once and allowed for no pre-testing, so while you might reduce the tech development failure rate with R&D and live fire tests you will be unable to avoid the material defect failure rate in certain cases. Questions - Something I'm apparently too stupid to find on the internet. Please help. Does it damage liquid engines to let them run to propellant exhaustion?

So another question, I've been jotting down noted bugs and ideas as they occur to me while playing and I'd like to bounce them off the other RO fellas. Where would be a good spot on the forum to post it all?

Wow, thanks for the fast answer. Will that typically reduce just the voluminous smoke plume, or both the plume and the immediate engine exhaust envelope/flame feather?

Having some performance issues and trying to lower the work load of the computer. RealPlume is listed as being an optional mod however CKAN is treating it as mandatory and I am unable to split them in a CKAN install. So first, how do I properly remove RealPlume without breaking everything else and/or leaving all my engines with no sound or visual effects? Second, if I wanted to keep the very nice engine exhaust, but just turn down the system strain, how would I see about removing the giant exhaust plume that is present below 20km?

How about empty fuel/ox/water/other tanks. You can fill them with any left overs from previous stages.

I think I would have named it the GuenterChecker. I wonder where Guenter Wendt?