Starwaster

Please post an output_log.txt file with that. It is in your KSP_Data folder NOT the ksp.log which is altogether useless. output_log.txt

I'm using a 10 year old crappy Logitech mouse myself. Namely because every OTHER mouse I've purchased since 'retiring' the Logitech goes belly up. Corded mice... cords got damaged. Got a really expensive mouse whose manufacturer I forget... the guys that say to 'get imba' whatever the hell that means. Been through two of those crappers. But only this Logitech seems to hold up over the years. Battery cover is gone... no idea where. So the batteries are held in place by a paper shim. Mouse wheel finally cracked a few months ago but it's STILL the only functioning mouse I have. It's uncanny to say the least. Goes through a ton of batteries because my brand new 'imba' rechargeable is a piece of crap. Should be in warranty but they want me to pay shipping to send it back and I just gave up on it. Probably try to repair it myself. There was a point to this but it escapes me now. Something about my old faithful Logitech that I purchased during the Pleistocene era.

Updated download files tweaked docking ring attraction force tweaked docking ring attraction torque even more tweaked truss adapter ring battery charge to more sensible stock values instead of realism values. (a separate optional MM config file will be released that adjusts resource levels to realism values later) Tried to adjust attach node sizes to take advantage of joint reinforcement that depends on node sizes but that's making it hard to attach pieces like the hab adapter so I scrapped that for now. On that subject, I'm not getting any feedback from people and that's one area that I need it. I am not personally experiencing any structural issues with these parts but I need to know if that's true for other people. If not then I need to do something about those node sizes. Anyone have anything to contribute...? Opinions...? something? https://www.dropbox.com/s/hwxonsya6cnvlrz/Copernicus-Beta1.zip More craft file will be put up later today for the 5 meter pieces using stretchy tanks for launchers.

What's happening is that halfway through parsing the RealSolarSystem.cfg file, it's looking for that file you renamed. Not finding it, it generates an error that you will see if you go look at the output_log.txt file. It does not parse anything after that. That's why half of your solar system is munged. Don't rename things. Especially don't omit extensions. Edit: Oh, you downloaded a file and you had to rename that. Ok. Make sure it matches EXACTLY the name of the file that you're replacing. That file is named in the RSS config file and it better find it if you want to see your solar system ever again.

Why the heck do your Kerbals look so happy in the OP screenshots??? Mine always look terrified. Is it because I build death traps???

As of 0.23.5 this is no longer true. Larger nodes mean more connection joints and strength. KJR has also made use of node size as a determining factor.

I'm not willing to code everything on your list for you but here is enough to get you or someone else started coding: It will change the existing altimeter GUI (external view) to display distance to terrain or distance to sea level, whichever is higher when below 8000 meters. No configuration file parsing is coded so this requires alteration in the source and recompiling. Will display text notifying that radar altimeter is active when below 8000 meters. Requires no parts. Link to compiled DLL and source: https://www.dropbox.com/s/ncrncunxs25u5pe/RadarAltimeter.zip License: This is released into the public domain // Radar Altimeter modifies the altimeter to display altitude above terrain instead of sea level. // This KSP plugin code is released into the Public Domain by its author, Starwaster // Code from Real Chutes, MechJeb and Ferrams Aerospace Research was researched as examples // of gathering world information and altimeter UI modification. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using UnityEngine; namespace RadarAltimeter { [KSPAddon(KSPAddon.Startup.Flight,false)] public class RadarAltimeterUI : MonoBehaviour { public void awake() { } public void start() { } public void LateUpdate() { updateAltimeter(); } //public void FixedUpdate() //{ // updateAltimeter(); //} private void updateAltimeter() { CelestialBody body = FlightGlobals.getMainBody(); if (body.ocean) { double ASL = FlightGlobals.getAltitudeAtPos(FlightGlobals.ActiveVessel.GetWorldPos3D(), body); if (ASL < 8000) { double realAltitude = ASL - FlightGlobals.ActiveVessel.PQSAltitude(); if (realAltitude < 0.0) realAltitude = 0.0; FlightUIController UI = FlightUIController.fetch; UI.alt.setValue(realAltitude); ScreenMessages.PostScreenMessage("Radar Altimeter Active", Time.fixedDeltaTime, ScreenMessageStyle.UPPER_CENTER); } } } } }

No, it's not going any higher, though anyone could replace or modify the pressure curve data if they wanted to customize their personal files. (but never forget to terminate the curve with a 0 pressure key or you'll experience atmosphere all the way out to SOI edge )

Delete the extra texture files.... I think they are in pluginData? If not root around for them and delete them. However, you will also have to edit RealSolarSystem.cfg and comment out any lines that refer to those texture files. (just search for png)

As a work around, switch away from the craft. Exit to Space Center then back to that craft again. That's what I do when the RCS starts doing that.

No, it does not. It means that you need FAR to accurately detect if parts inside of a fairing are shielded. Otherwise it relies on raycasting like any other part. The problem with raycasting is that sometimes it misses the fairing. At certain orientations the ray fails to collide with the fairing. And that might (might) only apply to procedural fairings and not static parts like KWR's fairing. I think the collision body on the procedural part doesn't cover the whole thing? Or doesn't scale properly? Not really sure, just know that I had a devil of a time trying to use PF fairings as a Mars reentry aeroshell.

yes. We could have taken it even higher but it affects putting your craft on rails. (i.e. no non-physics timewarps) I've tried it with pressure curve data that models the atmosphere all the way to ISS altitudes. Definitely an interesting experience. Incidentally, this particular set of data uses NASA's atmosphere model here: Earth Atmosphere Model (metric units) So although we still have an arbitrary cut off point (necessary) this is about as close as you're going to get. Edit: One caveat: Other mods still assume a cutoff of scaleHeight * 1e-6. MechJeb for example will assume the max atmosphere altitude is lower than it really is. I've opened an issue on the MJ2 github site with a couple of suggestions for handling it.

I think some parts, if they intersect each other just right treat each other as shielded. Since each part thinks it's shielded, neither takes damage....

I've actually had a concern recently about this. It's been a few versions since I glanced at either your code or Ferram's so maybe something's changed I don't know about, but FAR recently started calculating density based on assigned atmospheric composition. I didn't even think of this until someone mentioned it in the RSS thread, but to cite the example given there, Venus has an atmospheric pressure of almost 90 atm. But its density is only about 55x Earth's. (assuming this is the lack of nitrogen at work). The very latest RSS tries to model Eve's atmosphere based on Venus and has a pressure value of 90 now. (we're using pressureCurve data instead of the old legacy atmosphere calculations). Pretty sure FAR can handle drag appropriately since it calculates density separately but how will this affect Real Chutes? Can it actually query FAR on density values? And does it?

Maybe it's just my imagination but I'd swear that Kerbal looked just like Sandra Bullock. Except green.

That looks like a center of mass issue. Center of mass is affected by the part's origin. If part origin is not 0,0,0 (probably X/Z are more important in this regard) then the center of mass will be off by that much. I've noticed a lot of the same problem in a lot of Bobcat's work such as HOME and American Pack. The problem there is even more severe, specifically in the latter, if you try to launch an Ares 1, straight up vertical as in your test it will veer off sharply eventually even somersaulting. And that's WITH SAS on. It's literally not even possible to compensate at all. That's what I think is happening to you, but I don't know why the effect would be present in 0.23.5 and not earlier versions. If you install the RCS balancer and set it to engine mode I think you'll probably see that part is off balance.

Correct. There's a limitation in the game that prevents us from really having tilted planets so we have to work around it. There's an alternate config for one in the OP Or use the texture compression tool and keep your parts. The Gamedata folder in my RSS install is a page full of extra mods, mostly parts.

So my dreams of 'Parachute in a Can' must remain unrealized?

Actually, get him the log information he asked for. No sense in reporting bugs and then not following the request for more information. Better than alt-F2, when it 'slows down' exit the game immediately. Go to the KSP_Data folder (in your main KSP_Win folder or whatever you call it if you renamed it) Find the output_log.txt file and put it somewhere it can be downloaded, dropbox is a good choice. Get a dropbox account if you need one provide the link in this thread so that e-dog or any other knowledgeable member can help you.

I think it's going to merge them into a single pull request no matter what. I don't think you can control that. I'm not even sure that you really need to either....

The fix is probably that it's going to need a larger fuel tank. Might also make a config that switches the engines over to H2/LOX and change the fuel tank to use that. But I doubt that by itself would be enough. Needs a bigger tank at the least.

If the part shows as red (clipping) try pressing X (for symmetry) a second time while holding the part where you want it. That usually clears it.

Your link is broken. (not sure why; looks sound but I had to manually correct it in the address bar after clicking it)

Are you sure you didn't accidentally use the fuselage piece instead of the fairing?

Chris, I'm not so sure now that it's just a graphical/animation issue. Did some more extensive testing and the secondary definitely is just not fully deploying.