rebelcommando1807

As minor of a thing as this is, it would be nice to have. And, realistically, all one would need to do with the drogue chutes for the different icon is have them be a bit thinner than the main chutes. The problem then comes when implementing it - Simply because, AFAIK, the game gives an icon depending on the module (Otherwise, I could totally see air-breathing engines having a separate icon from rockets, as well as a new icon for ion engines), and it would be needlessly redundant to have a 'MainChute' module and a 'DrogueChute' module. Though, I would totally be for having a field added to the config to have the ability to point to a different 'StagingIcon' file, and just defaulting to the module's one. It could be a relatively minor change, but it would be nifty. (Of course, would have to be made in a specific way so it can be reliably applied, but that's the point of having file specifications, no?)

I know. It just seems like something that would be an interesting option for those of us who want to do it. That, and this can potentially tie into a system where you refurbish an intact vehicle/segment of a vehicle rather than 'sell' (I assume that's what's going on, at least) it for scrap right away. And perhaps it can be used, as a save option, instead of the 'press button, recover vessel' system that we currently have. One of the ideas I mentioned for it as well was having it so that it gave the full recovery boost (once returned to base) to all recovered vehicles in an area, as opposed to just one - Which is where the real difference shines through, beyond the 'cheaper to recover bigger things with that team' aspect. So instead of taking a hit in part value for every little part in the area around the crash site (or landing area, if you're clustering landings together), it just takes the single cost to deploy the recovery team to get everything back at full value. ..And I find it somewhat funny, as a side note, how quickly the topic went from 'Make it so intact spaceplanes can fly back for full recovery on their own given enough fuel' to recovery teams.

Hmm. Would it be implemented in a sort of way where, when a sub-assembly is added, it puts those parts in a tag block? And then compare the parts in the block against the parts in the source assembly? ..Might work, actually, depending on how things are set up. Would also account for parts getting jettisoned; would just have to have it ignore resource levels in the parts. Though, if that's done, there has to be some way to easily grab a craft (say, in this case, a shuttle) and save it as a sub-assembly added, if only for the sake of being able to have the shuttle count as something fully-recovered. Elements of the 'variant' system would be nice, though, for SSTOs - In the sense of being able to change the cargo more or less on the fly, and have that be recognized as something that isn't needed for intact recovery. And, again, I would love to have some way of calculating an air vehicle's range so that way one could, so long as they are in Kerbin's atmosphere, have another recovery button - Similar to the Recovery Team's movement, it puts the craft into a similar state (icon moving across the globe, can't be switched to [Well, maybe can. I dunno], and will be counted as recovered after X amount of time. Vehicle would have to have landing gear, an air-breathing engine, an air intake, Some lifting mechanism, and enough fuel (again, via some algorithm) to make it to the space center. ..Also, is it wrong that I totally thought of the XCOM hologlobe when picturing this idea?

Another fun thing about the 'Payload'/'Variant' system? One could set something up, ala Scott's Reusable Space Program series, using the lifter segment as the base. ..That would be really cool, actually. Though, if that does end up happening, we have to make it so that a Falcon-esque thing is viable. Detecting sub-assemblies as a recoverable unit would probably be quite the pain, but it would certainly make things quite interesting - In a good, non-fireball sort of way. Re-usable lifter segments and all.

Hmm. Maybe patched conics and node creation in T1, closest encounter and Recovery Team in T2. Can also see, maybe, Patched Conics having a bit of a margin of error at T1, then being at full precision at T2. One of those "Yup. You are very clearly going to be in that sphere of influence now" for T1 - Improvements in the trajectory projection software or somesuch.

That works, too! Perhaps bit less time, though - Transit time (perhaps with an icon moving across the planet to the selected location), Deployment time (where it's deploying), Re-pack Time (Inverse of Deployment), and then another round of transit time. The deployment range and cost could depend on the player's tech level or the upgrade level of a certain building, along with a strategy. Maybe make it so it costs x amount per kilometer (fuel costs) - So if you're just recovering, say, a relatively cheap pod, then it would be better to eat the cost reduction. Recovering a Jool-5 capable SSTO mothership, complete with all landers, on the other hand, would net a far greater ROI with the deployed recovery team as opposed to the recovered funds reduction. ..Would actually add an interesting dynamic, I think. Could totally see it as something in Kerbal Konstructs, too, come to think of it - Would give a good reason for having smaller bases across the planet.

It's a simple idea, mainly. While, yes, the current system works, an idea came to mind that might make it be a bit more.. Well, interesting. What I mean by this is, mainly, doing an integrity check. Say I have a craft that is fully capable of SSTO stuff, and is meant to deliver a cargo and return.. But I'm off on my aim a bit (And don't particularly feel like flying halfway around the world to the space center). If the craft still has enough fuel to fly to the space center (Probably by doing some math regarding TWR and optimal fuel consumption of air-breathing engines), then instead of taking a hit to the value of the recovery amount, allow it to be refunded for the full value of the parts (and whatever fuel remains from the calculation of fuel needed). An alternate idea to that is to have an option to simply refurbish and refuel (for a lowish cost). Of course, we don't want this to be abused with something that is just barely able to fly - That'd just be silly. There could be a couple ways of doing this.. 1: Variants. This is, essentially, saying that 'this craft is based off of this design, and anything extra is considered payload'. This may be the most flexible option in most cases - Acting similarly to just plonking a payload in that's different each time. Any payload brought back would be refunded as normal, and launching a new craft that's a variant of the base hull just costs the amount for the payload and fuel (on top of the refurbish cost, of course). There would have to be limits, though, on what can be counted as payload, which would probably up the complexity a fair bit. 2: Tagging decouplers/docking ports. This idea could potentially be a fair bit more abusable than the Variant idea - But it might be better in some ways. Namely, shuttle-type craft could benefit from this quite easily (Tag the stuff in the bay and the external tank as 'payload' or 'disposable', whichever works better). So, yeah. Just an idea.. Looking for feedback, as this is one of those 'kinda tired, need to get this out' ideas that I had after derping around in KSP a bit.

Aha, got it! It's a bit wonky, but it works! https://www.dropbox.com/s/130ym18irobxo35/MIRV.craft?dl=0 [REQ: BD Armory, Stock] Part of the issue I was having was with the weapon manager. It still needs to be flown manually for the moment, unless one can, say, tie an action group to the modular missile guidance to use at some point in the future for acting as a multi-warhead munition, but hey. Something to keep in mind that threw me off: The Modular Missile Guidance is still using legacy targeting, far as I can tell. At the very least, it's not using GPS or laser guidance (which would be wonderful!) Instructions are in the craft description. This was more a proof of concept than anything else - It sports 18 AGM-114s as its payload, and it uses cruise missile guidance.. And it's a thing to see when it fires! Sorry for not having screenshots.

Sadly, this doesn't seem to work.. I'll keep trying, but my hopes aren't too high.. Doing this as an AGM, for the record. It may be something that needs manual control for the moment, sadly..

Silly question from someone who enjoys this nod.. Would it be possible to have some sort of system to set up some sort of simultaneous multi-targeting/multi-launch system? Something akin to the multi-AA/multi-AGM missiles from the HAWX games - Essentially, setting targets per-missile without a flurry of clicking and all that. I know, it's probably not terribly realistic, but it would be quite awesome to set something like that up to launch a flurry of missiles or large numbers of JDAMs against, say, the space center. Also, is it possible to make missiles that split into multiple missiles? Just as a point of curiosity.

Just a (sudden) thought.. Perhaps having an exchange system between SCIENCE! and money? So that way you could have a starting pool of money to pull from, possibly have a money reward in addition to the SCIENCE! one for stuff, and being able to have a rainy day fund for when you lack enough SCIENCE! for stuff? Just a thought - Would make things a little more interesting, in a way.. Plus, you could have objectives (Non-stated ones) for money in addition to the kinds of things you do for SCIENCE!.

Is the computer core upgraded? If not, it doesn't generate any SCIENCE!, and the numbers are right for a lab with two smart kerbals in it.

Perhaps even taking into account the amount of light the vehicle itself is giving off? So that, if you're crazy enough, you could make a ring (or half-ring) of really freaking bright satellites in KSO over the dark side.

To be fair, they are probably juggling fifteen things and know how to stage without decouplers effectively. For the average player, it probably will take more than that - As, usually, they don't have everything memorized to the point where they can get a flyby (or landing) of both the Mun and Minmus in one flight at T0, nor do they think to have more than one capsule on a ship, usually. That, and they would have to have enough fuel to burn at the right times to refill the capsule batteries to transmit stuff. Generally. Just my two cents on the issue. When I think 'advanced' in this sense, I think Manley Mode. And, in this case, it's the crazy advanced people that do stuff like this. And the main thing to remember is that money will be a balancing factor in a future update so that people can't just make T0 interplanetary ships right from the get-go.

I, personally, support the cloning idea.. That those three are important enough to the space program to be worth the expense to bring them back. That being said, I support the ability to nominate new orange suits, and I nominate (Special Agent) Kirrim.

Neat idea. ^-^ Perhaps expand it into different kinds of ignition systems, such as launchpad ignition, something that's on the inside of the engine bell that causes the chemicals to react, etc. Also, just curious.. Does fuel still vent even if the engine fails to ignite? Because that could be used as a mechanic for delayed ignition (Waiting for the right fuel/oxidizer mix).

Dare I ask if this could be used with a hinge or something similar? Mostly for use on shuttles to help keep them balanced..

This is just something that I think would be nice to see.. Any chance you can detect if an engine has flamed out or is otherwise non-functional, and have the program detect the change in MaxThrust accordingly? Would make quite a few rockets easier to program for, certainly.. And planes, for that matter.

For the question, use the metric system. It's what's native for KSP because.. Well, it's what's (supposed to be) native to any space program. That, and the imperial system is very, very wonky. This is coming from someone who grew up with the thing.

It's a little oddity with this - You need to activate it in a stage before it works. Dunno why.

Sorry to break it to you, but that's using a well known fuel bug which doubly applies the throttle setting. Just thought I'd point that out.

This is my design (With up-trim) that is currently more than 90KM away.. And this is after pulling up and turning around (And re-stabilizing). Yes, all stock.

I know of that one, but, as far as I'm aware. it only works for standard liquid engines, not the atmospheric ones. Unless the atmospheric ones aren't affected by the bug. In which case, my bad. EDIT: Testing now.. 3:08 for the MK2-MK1 adapter, one engine, full throttle. EDIT: And the same for two engines, half throttle. Good news, the atmo engines have no issue with this bug.

The first one doesn't have nearly enough fuel, and the second one doesn't hit 500 m/s until the tanks are mostly dry. It does keep a steady speed of over 440, though, if I recall correctly. This is actually a good challenge, in my opinion, as it's balancing fuel consumption, power, and the amount of fuel that you have. In many cases, the reason why planes that can circumnavigate don't go so quickly is so that they don't eat up all their fuel. Also, it's a shame that the fuel bug's there, otherwise I could do well with telling it to keep the speed to, say, 550 or so, and save fuel that way. Also, the similarities were intentional, I was originally trying to recreate your design for a proof of concept, in a way. There are probably far better designs out there, and I will fiddle with a different one myself here in a bit. The big issue, in my mind, with this challenge, is simply how long it takes to do it.. Which, in a lot of cases, can be a limiting factor. Perhaps you could have a different category for those that do suborbital hops for their flights?

Posting again for attachments. Attaching the first .craft, as well as a second one that doesn't quite meet the requirements of speed by 4-5 minutes, but has 4 more MK1s and 1 more MK3 fuselage. Hopefully this gets me further. All you need for both, mod-wise, is MechJeb.