ss8913

You'll want to look at your ksp.log and see what it says near the end. Probably will want to post it and make it available to FreeThinker too, or he (or anyone) will likely not be able to help.

@FreeThinker - new update has done a few things for sure, maybe 1 other thing: 1. Framerates are a lot better. Not sure why, but they are. 2. This was mentioned on the other forum - electric charge bug. Electric generators stop generating electric charge after any dock/undock operation. F5/F9 save/reload fixes it, but this is definitely a new bug. 3. (this was 2 updates ago) - Umbrella radiators no longer deploy automatically in automated mode. have to deploy them manually now in all cases. 4. The game is... very crashy. After the EC bug is hit, that F5/F9, about 25% of the time will crash KSP completely - this is the one that I'm not 100% sure is a KSPIE issue - the logs are no help, just normal normal normal <<CRASH>> with no evidence pointing a finger at *any* specific mod.

It's possible that there are voxelization issues with some part packs(?) I know a lot of developers are putting FAR compatibility on hold until there's an official release - for example, K.Yeon plans to release an updated patch for OPT wings, but not until FAR is officially released. You may be running into such an issue. Likely not a lot you can do except wait, or uninstall those parts. I can confirm that the following part packs behave themselves with FAR however: - stock plus all mk2/mk3 expansion part packs - B9 - KSPIE - KW - Mk4 - *NOT OPT* - CoL is way off, wings produce no lift - MKS (although not really any aero parts)

i don't know for sure if the latest update is responsible, but... my framerates are significantly better since this last update. used to be any time I used any KSPIE parts I'd take a 50%+ hit in framerates.. not anymore.

wait, why is the dV calculation using STANDARD_GRAVITY - that's not valid outside of Kerbin near the surface, is it?

scansat is a surface scanning mod that has been around for a while.. predates the stock scanning mechanic, and many, myself included, still feel that it is superior to the stock scanning.

so is Lamancha fixed? Does it look on the ground the way it looks from orbit now? Last time I went there, the actual ground didn't match up *at all* with either the visuals from orbit nor the scansat scans that I took...

This happens with a lot of engines. It's a roundabout way of KSP telling you that you don't have enough intakes on the craft. Ideally the Tory's built-in intake should be sufficient for itself, but... add some more intakes and that will usually solve it.

1. I've literally never used stock radiators. I've been using KSP Interstellar since before stock radiators existed, and I just kept using yours. 2. Many stock wings such as the Big-S Delta wings which I use for pretty much everything, already have fuel storage (stock) and IFS lets me put hydrazine in them, so that's what I'm doing ie, I think you've already accomplished your goal here, via IFS. What would be really useful is a scalable skin that fits over the Big-S stock wings, and acts as a radiator. ... or, dare I say it... procedural radiators?

here's my secret formula for nuclear spaceplanes... I use antimatter reactors which get pretty hot... so here's what I do: Get the winged edge medium radiators, place them INSIDE your wings.. like clip them into the wings so they just poke out the front. maybe 3 on each side, offset up and down so you have like a stack of three inside each wing. you'll need to tweakscale them to fit of course. Then, put the large folding radiators on top and bottom of each wing (ie two on each wing, one ventral, one dorsal) - and disable automation so they don't extend on the ground and break on the runway. This gives you enough heat buffering to get into space, where you can extend the folding radiators and go from there. You'll have 50%-75% wasteheat buildup by the time you get to orbit usually, but that's fine, you can just dump the heat in space

Ever since the most recent update (yesterday, I believe), I cannot get KSP to start at all. This was the only mod updated... I can load the save but when it gets to the main KSP scene, screen stays black and it just sits there and churns. I have to kill KSP with the task manager to regain control of my system. End of the log is filled .. and I mean *filled*, with millions of lines like: [EXC 21:33:49.966] NullReferenceException: Object reference not set to an instance of an object GalaxyCubeControl.Update () [EXC 21:33:49.967] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () [EXC 21:33:49.980] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.First[StarComponent] (IEnumerable`1 source) Kopernicus.StarLightSwitcher.Update () [EXC 21:33:49.982] NullReferenceException: Object reference not set to an instance of an object GalaxyCubeControl.Update () [EXC 21:33:49.983] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () [EXC 21:33:49.988] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.First[StarComponent] (IEnumerable`1 source) Kopernicus.StarLightSwitcher.Update () [EXC 21:33:49.990] NullReferenceException: Object reference not set to an instance of an object GalaxyCubeControl.Update () [EXC 21:33:49.992] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () [EXC 21:33:50.013] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.First[StarComponent] (IEnumerable`1 source) Kopernicus.StarLightSwitcher.Update () [EXC 21:33:50.015] NullReferenceException: Object reference not set to an instance of an object GalaxyCubeControl.Update () [EXC 21:33:50.017] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () [EXC 21:33:50.029] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.First[StarComponent] (IEnumerable`1 source) Kopernicus.StarLightSwitcher.Update () [EXC 21:33:50.032] NullReferenceException: Object reference not set to an instance of an object GalaxyCubeControl.Update () [EXC 21:33:50.033] NullReferenceException: Object reference not set to an instance of an object Kopernicus.Components.KopernicusStar.LateUpdate () I tried a brand new save since I had some craft on Thallo, I thought that might be part of the problem, but... no luck, same behavior. UPDATE: It's a confilct with Stock Visual Enhancements/stock visual terrain. If I remove those, the problem goes away. However, this is a new conflict since the last update to this mod.

because I didn't know about the refrigerator I will try that out... thanks Any idea why Thallo and other extra-Kerbolular planets don't have complete atmospheric composition numbers, as per the screenshot I posted a few days ago showing the GC/MS window on Thallo? It's important because the ISRU won't work there if KSPIE doesn't know what gases are in the atmosphere, and it appears that is the case...

@FreeThinker remember a while back I was talking about atmospheric composition on planets outside of the Kerbol system... well I know you're familiar with the Interstellar Adventures pack - I tried analyzing the atmosphere of Thallos, which orbits TRAPPIST-1 ... the atmospheric composition is incomplete. I'm not sure why but this is representative of what I find on all non-stock planets: See the GC/MS Atmospheric Composition window just to the right of the craft in this picture.

@FreeThinker - reproducing my issue is fairly easy. Launch a craft. Observe the dHeat/dt rate at 1x timewarp. Accelerate to Nx timewarp where N > 1, note that dHeat/dt is the same, where 't' is in realtime. Seems pretty consistent. You can look at the stock resource window too and notice that the delta value does not change with timewarp. It might be because WasteHeat is a consumable resource that's not intended to change with non-physics timewarp, since you can't burn fuel in that mode (usually, at least as far as stock KSP is concerned)...? That's just speculation on my part, however.

also it would break. Anyone else having the same problems in recent builds with the existing umbrella radiators that I am? See a few posts up...

@FreeThinker something seems to have been broken recently with the Graphene Umbrella Radiators. These things default to Automation=ON, and that's been fine for several iterations. However, now, they never deploy on their own, where they used to deploy automatically at a certain dynamic pressure. It's not like they shouldn't see a *need to*, I've got several antimatter reactors and a QSR putting severe thermal demands on the craft... Deploying them manually... I think they're working? This also seems to be a bug. If I deploy them manually, I get a value for "power radiated" .. about 96GW each... but it also says "Cooling; Idle" whereas the fixed radiators (such as the graphene radiator winged edge units) show a % value for Coolilng: I can't tell if they're actually working or if they're just dead weight on the craft. I'll tell you one thing though, even at 10% power, QSRs produce some serious heat... One other thing I noticed, WasteHeat dissipation seems to happen at 1x (real time), no matter what your time warp value is. ie, you will lose X heat per second (relative to real seconds), no matter what your time warp is. This is somewhat of a problem. aand, just now a third thing... I'm using a gas core fission reactor + QSR to drive a 7.50m heavy alcubierre drive at 250c. I also have antimatter reactors onboard for the sublight engines which are currently idle. My antimatter quantity is going *up*. how is that a thing? I don't have any antimatter scoops on board, but the stock resource usage window is showing a -0.09 consumption rate with the sublight engines idle.. where's that coming from??

Alright, so anyone interested in compressed air, I finally made it work... that's 20 2.5m gas tanks set to Air mode, with the compressedair <-> intakeAtm slider set to full left (-100), 4 ATILLA thrusters scaled to 1.875m, several resistojet RCS thrusters. Cargo bay contains 2x 2.5m charged particle generators and 2x antimatter reactors and a tank of antimatter. organized as gen-reactor-gen-reactor-tank. Requires TCA to fly this thing (balanced thrust), but it can operate indefinitely in atmosphere with the secondary radiators (not pictured on this screenshot) extended. ie, it can generate compressedAir faster than the atilla and RCS can burn through it. Intakes are 8 B9 SABRE-M intakes (default 2.5m scale) - there's 4 on the back that you can't see, but those are the biggest intakes I have access to, so they get used. Works well on Kerbin, likely Laythe as well due to similar gravity and atmospheric density. Weighs about 94t or so and has plenty of thrust and control authority.

Landing guidance only works (for me) under the following circumstances: 1. Only engines with instant response are used. Anything with a graduated response (such as any KSPIE engines except the ATILLA thrusters) it doesn't handle correctly 2. You don't use KSPIE electric engines such as magnetic nozzles or ATILLA (which countermands #1, so therefore no KSPIE engines can be used - electric engines, MJ2 will always immediately burn and not wait for the correct time, it's like the burn-time calculation doesn't work for these engines?) 3. You have JUST ENOUGH RCS authority. Too much and it will overshoot and wobble indefinitely, too little and .. well, obviously it can't turn fast enough to make maneuvers in time. 4. No atmosphere is present; this is triple-true if using FAR. You said Mun and Minmus though so that's not an issue. I've taught myself to land my spaceplanes manually... which basically amounts to, "set the landing target with MJ, tell it to show landing predictions, then on mun/minmus overshoot your target with the blue cross by at least 20km, maybe 30, set your smart ASS to SVEL- and burn to 0 m/s target relative when you're directly over your target, and allow the craft to descend vertically from there". Timing can be tricky, esp. if you have less than 2G acceleration.

I installed the beta.. just overwrote what was already there... there's no adjustable height nor are the chutes opening at 700m... is there something going on where I need to delete the entire thing before installing the beta?

Usually when companies release paid DLC there's a patch accompanying that updates things to support the DLC, sometimes adds some free things, etc... if kerbal chutes become a thing in stock, it'll probably be outside of the purview of the DLC, so 1.3+no DLC will *likely* still contain the chutes.

OPT wings have *never* worked right with FAR, although there is/was a patch for that. The maintainer of OPT has said that when FAR goes official, he may include the MM patch to make his wings work correctly. I'm venturing a guess here that FAR may not go official until 1.3, however, since that will require more work/etc... in the meantime, the dev build seems to work as well with 1.2.2 as the previous official version worked with 1.1.3. My opinion, anyway. It seems release-quality at this point.

@linuxgurugameri did some more tests, 700 is definitely a good altitude for far @ferram4 it seems the big s delta wings are producing significantly less lift in the later dev builds? seems specific to these wings, if I build a 737-alike craft from mk3 and FAT parts it flies as expected... is the big s lift correct now, or was it correct before?

Follow-up to RCS issue.. @FreeThinker it seems to happen when I've got a skycrane setup... ie launching two "ships" connected by docking ports, with RCS on both for balance. stock RCS handles this, but is too weak. KSPIE RCS is strong enough, but some of the RCS units just refuse to work in this condition. I'm baffled as to why. Problem is, with not all of them working, RCS authority isn't symmetrical, and that has the predictable set of results.

I'd use 700. That's what realchute uses and it works for lighter craft, and a single Kerbal counts as "light". maybe make it lower for Jeb and the other BadS Kerbals since they live dangerously? ... nah, that'd be more difficult to code, I'd just go with 700.

I noticed another interesting bit of behavior last night, @FreeThinker ... set up a craft.. it's on the launchpad.. using resistojet RCS. normal, right? OK so it launches, flies out of control and boom. ok.. revert to launch... turn on RCS, let's test control authority here... only some of the RCS work. The 'power' button is checked on all of them, some of them claim not to be powered, and the Forces: output is blank all the time, whereas others work normally. Cycling the 'power' state on the broken ones makes it say IsPowered? YES, but they still don't do anything. This is a fairly small craft with a decent-sized AM reactor and CP electric generator, over 9000MJ available, it's definitely not out of power, nor out of hydrazine. Yes, the fuel mode was set to hydrazine on all RCS ports. Reverting, reloading, and restarting KSP entirely did not fix this. I see nothing KSPIE related in the logs.. not sure if this is a new issue or not. Please let me know what info you might need from me to diagnose. Oh - replacing all KSPIE RCS with stock RCS thrusters and adding a monoprop tank, all thrusters fire in that case. I can't seem to tell what specifically causes it though; it only happens on SOME craft designs. Not on spaceplanes so far, only on things launched from the pad.. but I may not have enough datapoints on that yet.