Starwaster

Even if someone did, you would have to fly a pretty precise ascent profile. Not just at a particular time and target altitude but a specific turn rate. To put it another way, your down range distance upon reaching your target altitude would also need to be the right distance to put you near your target. There's a reason nobody flies rockets manually IRL.

@ebigunso You could take the easy way out like me and launch into a lower orbit in the same plane then hohmanns transfer to the station.

It's more likely someone confused specific impulse with density impulse.

Damned ninjas...

Was curious about specific performance data after reading the linked article. Couldn't find anything to backup 50% increase in Isp over Hydrazine; more like 13%-25% (which is still an improvement to be sure) Found some documents providing useful information on both performance and proposed usage for anyone interested: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20150021510.pdf https://www.rocket.com/files/aerojet/documents/CubeSat/GPIM AF-M315E Propulsion System.pdf http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20140012587.pdf

I would say not so much proven tech so much as proven tech that was (historically) readily available mid-twentieth century. Even ion engines and nuclear rockets were undergoing actual physical testing back in the 1950s.

Must be backwards to the way I was thinking. I was thinking KSP must request a list of files ending in .cfg but... instead... maybe it's looking at a list of files and then internally picking out the ones that end with .cfg? I can see it failing that way because of how Unity deals with URIs.

@Ako_Vendetta Sounds like you're on Linux or Mac? That's the only reason I can see case sensitivity of a file name being an issue...

That exact config works for me. How are you verifying whether the change took place or not? Checking the cache or in-game? And where are you putting your config file? (needs to be in GameData or one of its subfolders)

Its cost is exactly 600 Funds for me

That is inaccurate information. Stock parts load before Module Manager does a thing. The only effect :AFTER[Squad] will have is if some other modders are scheduling their patches in the :BEFORE[Squad] or :FOR[Squad] passes and the effect is on Module Manager processing order. But actual stock parts and in fact ALL modded parts packs configs that do not contain Module Manager patches are processed by the game before Module Manager starts looking for and applying patches. Clarification Edit: Just a reinforcement/clarification on the above: :AFTER[Squad] isn't something that one has to do because they're trying to patch Squad parts. It's just a scheduled pass that is influenced by alphabetical order. Let's say you want your patch to happen before A_Mod runs its patches. He's scheduling it in :FOR[A_Mod]. If you use :BEFORE[A_Mod] then it runs before his FOR phase. If you want it to run after his patches then it's :AFTER[A_Mod]. If you do it in :AFTER[Squad] then that will also work if you needed it to happen after but it only works because Squad is sorted alphabetically later than A_Mod. Or if you needed it to happen before Z_Mod then it would work because Squad appears before Z_Mod. But those are just because of coincidental alphabetical sorting.

Order isn't relevant to you until you start dealing with multiple mod's configs. Things like part configs (and all resource/tech/etc, etc) in the squad folder have already loaded by the time Module Manager gets to parsing config patches. And I think it would be best if you posted the actual entire config you're trying to apply, not pseudo-config. Otherwise we have no way of troubleshooting what you're doing. (I'm assuming here that 'squadpart' is a figurative rather than literal representation of what you tried) One last thing, make sure that file extensions aren't hidden or your config file might not really have an extension of .cfg

No, you did all that yourself, and you're still doing it. Persisting in personalizing something that was never personal and now you're going even further by making wildly inaccurate and snide assumptions about a perceived age gap. You apparently STILL haven't gotten this whole thing about dealing with and relating with people remotely,, projecting non-existent motives and emotional states onto other people. You really need to work on that. As far as reading 163 pages worth of thread, nobody actually expects that of you and nobody called you out on it. Though since you bring it up, you COULD have used the search function. You might want to consider that in the future.

Are you sure she's napping? She doesn't look like she's napping and I don't think she's pining for the fjords either...

Log file: You either read it to figure out what the trouble is on your own or you show it to someone more knowledgeable who can tell you what's wrong. That's what you do with a log file. If you'd posted one, we'd have at least 75% of everything we could possibly want to know about your installation. (for the rest, there's ModuleManager.ConfigCache. Unless the errors make MM think the cache should not be written. Which can happen) Honestly though, about the log file? This just got covered a several posts ago. SERIOUSLY. Most of the past 10 posts before your first post have dealt with the very thing you're experiencing. Sarbian's signature even says 'no logs no support'

This isn't the first time that pods in pretty much that configuration have come up before and it's been problematic to put through reentry If you want to know more about how objects occlude each other from convection heating you should ask @NathanKell because he wrote that code. All convection heating is handled by stock KSP these days. It decides when and how much something gets heated. The only thing DRE does now with regards to reentry heating is balance max temps either as explicitly decided on a part by part basis or by fallback code that makes sure that parts at least don't exceed a 'sane' max temp. (unless explicitly told not to for that part). And it makes things 'catch fire' if they get within 85% >= of their max temp. I'm not even touching the physics globals this time around in DRE. A few other things I'll address here to make sure there are no misconceptions: Drag is not directly linked to heating. Even IRL you would expect substantial heating high up in the atmosphere before they get low enough to experience significant drag. Although drag isn't directly to heating, an object with high drag has a high rate of deceleration and therefore will experience less heating because it's not travelling as fast for as long a period of time as a streamlined object And is also probably a blunt bodied object which means the superheated shockwave is 'detached' rather than being attached to the object if it were very streamlined. And the shockwave is kept further away from the object as its diameter is increased. IRL, the backshell of a reentry vehicle experiences significant heating and has to be protected. The conical (frustum) portion of the Apollo CM had the same type of heat shield as the bottom of the capsule only it didn't have to be as thick. That last means that you guys actually have it easy in KSP; all you have to do is slap a shield on the bottom of your capsule and it's good to go. IRL the entire thing has to be shielded So, anyway, you want a larger heat shield if you want to be sure the entire thing is shielded there. That said, I did try a vehicle in the configuration you're having trouble with and with an angle of attack/sideslip of exactly 0o I was able to keep the Mk1 pod from experiencing convection heating. There's practically no margin of error there. The more it deviates the more heating it's going to get. But it's not terribly stable aerodynamically speaking so it needs RCS or fins or spin stabilization to keep it steady or eventually in the lower atmosphere drag starts affecting it and it starts side slipping and then the heating will start.

@Murican_Jeb That file is distributed as part of RO cant say more than that without a (wait for it...) log file. Considering how often that file shows up when searched for you should probably bring it up in the RO thread.

Granted, but you get trapped between your double post and are unable to get out of the way in time. I wish I weren't so terrified of the ocean.

Granted, but you get left behind on Duna and you starve to death because you're not Matt Damon. I wish I could afford a better GPU for my computer.

All Module Manager errors ARE logged to a REAL log. An actual log file. If you bother to open the file up and do a search for the text [ModuleManager] (just like that, including the brackets) you will see everything that MM logged. And that log file always exists unless logging gets explicitly disabled by the player. If you're not sure where your log files are read the following post and it will explain in detail how to find them for Windows or MacOS / Linux.

A shield that small is probably not creating enough of an occlusion zone behind it to shield the capsule. It's not going to do a good job at shielding anything except what is directly attached to it. To shield the whole thing would require a larger diameter shield. It *might* help if you can keep your angle of attack at exactly ZERO. Maybe.

You did?!??

I use Notepad++ Give it a try. I bet you won't want to go back. (like... ever) And yes, that patch would propagate to pre-existing craft.

It actually uses the vessel's horizontal speed + landed state. (has to be landed or splashed) The autocut speed is configurable in the editor and can be set as low as 0.01 m/s As far as issues go with staying deployed on the ground, stupid_chris has said flat out they aren't meant to stay deployed on the ground (or at least not once it's below its autocut speed)

Or KSPedia in-game.... maybe some graphically skilled person with decent image editing software might step forward to tackle that.... but probably not.