Starwaster

theres a reason NASA prefers valleys and deep craters when landing on Mars.

I'll post one tonight. edit: wait are you sure it doesn't already have one???

There is nothing wrong with Duna that a decent hypersonic chute won't cure. (Hey just like Mars!) you can make a Duna capable chute with Real Chutes My favorite method is Curiosity style. Use chute for final braking and release ~2km up for thruster landing.

The developer hasn't been around in over half a year now due to real life issues iirc. To those wondering if its ok for them to adopt this mod themselves or use its code: This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

I don't like saying that a thing can't be done.... but I'm not sure I can see a way to accomplish the first. Have to give it some thought and play with it in code. Second one pretty sure that can be done. Probably require a new plugin as I can't think of any existing ones that can do the job. Or it might be more appropriate to modify the plugin that the inflatable habs already use. Have it go through all docking port modules and have it call the Undock() function, which is public. Seems fairly straightforward. Incidentally, while poking around at this, and especially when suddenly having to troubleshoot a pair of FLAT habs I had that got hit by the 'can't undock bug' it seems fairly obvious that Squad put in support for a single part to allow multiple ports on it even though they don't use it themselves. (one of the values in the save file docking port config stores the index of the docking port module on the other part that has been docked to. Without that, the FLAT would not have worked)

Pffff you mean make it less fun

The following will turn off the exhaust damage. If you want to adjust heat output of the exhaust you will need to uncomment the line that reads //@heatProduction = 550 and change it to what you want. TeeGee might also adapt this to his SSME problem, except he would have to change the text sepMotor1 to the name of the engine that he's having trouble with (I don't know what the name of it is; TeeGee will have to open the config file for it and look at the line that says 'name = ...') delete the line @exhaustDamage = False he would have to uncomment and change heat production to something appropriate. @PART[sepMotor1] { @MODULE[ModuleEngines] { //@heatProduction = 550 @exhaustDamage = False } }

I already did, and I posted a code fix for it.. Taniwha replied that he had already submitted similar code for that and other fixes, but the author is occupied by IRL concerns right now and hasnt been able to incorporate the changes. I'm mulling over the possibility of posting my fixed version of the dll as the license allows for it but need to figure out specifics

FAR fundamentally changes aerodynamics in KSP from stock behavior. You know this to be true. So why does it follow, logically, that your stock designs will behave the same under FAR as they did under stock? Put another way: That they worked in stock does NOT prove that they are not flawed. That they fail wit FAR doesn't mean they are flawed. It means that you have to redesign them to work in an environment that is very different from what stock KSP provides. Pfffff @ Scott Manley. I turn DREC UP, unless I'm playing under RSS. Yup. RSS + DREC + FAR. Leaving DREC settings where they're at. One thing about FAR is that it has differing atmospheric densities for the different planets based on the properties of their real life counterparts. There's a lot of H2 in Jupiter's atmosphere so Jool's atmosphere is probably not very dense. You wouldn't be getting very much drag in the upper atmosphere so if you're coming in too steep then you don't have enough decelleration before max Q and that's where you're going to hit the most severe reentry effects.

Hey, building things out of mismatching parts is the bread and butter of this game. then you installed it wrong probably but who can say whats wrong when all you tell us is.... it's not working.

I remember seeing the splendor of RSS sized Kerbin for the first time from 100+km up... then I realized my third stage was empty and I was still suborbital. then I experienced my first RSS DREC reentry.

Or worse...

Huh... I've had a config for awhile that just renamed it to fairing... ....

Can't say that I've seen that happen. But it wouldn't surprise me and it's possible it's happened to me and I just shrugged it off. Because when you dock two ships, you don't end up with two ships docked together. You end up with a single ship. Entirely possible for the maneuver node data to get lost and it wouldn't be an MJ autodock thing either. Question, how often do you manually dock your ship? If you never do and if you only autodock then you might not be in a situation to see it happen with manual docking. Make sense?

Did you check out the FAQ on the first page? See if your problem isn't listed there. If not, post your output_log.txt file. Preferably dropbox. If you don't have a dropbox you should, so now is the perfect opportunity to get one. Install the dropbox software and you'll get a dropbox folder on your desktop. Drop your output_log.txt in there, right click it and there's an option to grab the dropbox link for that file. Then give us the link here. I'll take a look at it. (not now though; have to go do IRL stuff. Cause I don't get to live on Kerbin with Kerbals helping them with their space program IRL, because IRL freaking sucks)

Try this http://forum.kerbalspaceprogram.com/threads/54954-0-23-5-Deadly-Reentry-Continued-v4-7-5-5-14?p=1225945&viewfull=1#post1225945 I have not tested that in non-Kerbin atmospheres. It should be ok though. Probably. DREC itself slashes max temps across the board. I mean, it would be great and all if we had materials that could withstand 3600K without warping or outright melting, but most materials will start slagging long before then.

Ugh, hard to tell with that nighttime shot.... what RSS config are you using? the stock RSS, or one of the alternates? That kind of looks like what I got with the 10x Kerbol system and I had to edit the KSC and I raised it a little too high... but I can't tell if that's what's happening to you. Too high. And.... not sure what's happening with the solar system either. Quite probably an error in the RealSolarSystem.cfg file, specifically in the Kerbin section. It's not that Kerbin is in the outer section, it's that the other planets didn't get parsed so from Duna on out, they're where they are in stock-KSP. That can happen if the RSS Earth texture files are missing. (happened to me when I first deleted them because didn't want Earth and I didnt realize they were being referenced in the RSS config file)

It's not a question of whether people should use it, it's a question of whether modders should use it. Originally it was intended for players to affect their installed mods without overwriting their mod files. But it was also the only way for a modder to ensure that a vitally required patch executed after another specific patch. But now we also have :FIRST, :BEFORE, :FOR and :AFTER. Though, their use depends to an extent on everyone using them. I forget what pass a patch is applied in if no pass is specified. Overwriting a file isn't a bug... and there's no fixing it other than reinstallation. Unless you meant something else when you mentioned 'editing their cfg' but I'm not sure what would do that..... other than overwriting the file.

Can I suggest you make a separate thread for it? And then leave a link to that thread here.

This: You probably need an updated version of ScanSatRPM. Ask in the RPM thread maybe? Edit: Or maybe an older version. .... probably Kethane was compiled against a differet version of the below mentioned DLL which it probably has as a dependency. Uhm.... why is this being posted in Real Solar System's thread....? [COLOR=#333333]Additional information about this exception:[/COLOR] [COLOR=#333333]System.TypeLoadException: Could not load type 'SCANsatRPM.JSISCANsatRPM' from assembly 'SCANsatRPM, Version=0.16.5223.32097, Culture=neutral, PublicKeyToken=null'.[/COLOR] [COLOR=#333333]System.TypeLoadException: Could not load type 'MapMarkupLine' from assembly 'SCANsatRPM, Version=0.16.5223.32097, Culture=neutral, PublicKeyToken=null'. [/COLOR] Edit #2: Oh and ignore the message about hidden patches. That happens because dependencies aren't being met, like if a patch has :NEEDS[someModIDon'tHaveInstalled]

Race conditions affect rapid fire forum posting. Sad but true.

Forgive the double post, but YES. Unequivocably YES, if you have two patches both using :FINAL and both affecting the same node then ordering is very much an issue. Edit: And overwriting their actual files leaves them in a state that is not undone when a player deletes the mod that did the overwriting. Bad move.

That's a good question.... I think the file name.... but I can't say that the folder structure isn't factored in too. You could always make a couple of sample files that modify some made up for this exercise config node. Then check in the log file which one got applied first/last.

Ignore it. It just means that a config patch has dependencies that are unmet. Namely a mod that it is for isnt present. Final is literally the final pass. The only way to override it is a :FINAL in a file that occurs alphabetically after that mod. Mods shouldn't even use final anymore any way but I guess we'll be doing it still for awhile.

The license seems fairly permissive... I could put my build up for those in need...