ArcFurnace

A small comment/suggestion: your MM_AddResources.cfg covers command pods with up to a crew capacity of 6. The Taurus HCV mod (which I use) has a 3.75m capsule with a crew capacity of 7. It was easy enough for me to add another patch to cover it, but you might want to add that to your distribution as well. I can't think of any other command pods with larger crew capacity, so that seems like a good stopping point.

Got a really bizarre error. Most of the stock UI elements, as well as some of FAR's UI elements, were flickering madly on the screen. FAR was partially unresponsive to button clicks (had to click repeatedly to get it to register, suspect it wasn't registering during the flickers). Reproduction steps unknown, will attempt to see if I can reliably reproduce it. At time of bug, had flown a small probe-controlled ship with empty command pod up to orbit to get Jeb out of an on-orbit vehicle without a parachute and was deorbiting. Bug continued until I landed the vehicle, closed game at that time. Posting here because output log implies it was a component of FAR that was throwing the errors. Full output log plus list of installed mods here. Edit: Reopened game and launched another craft as a test. Issue does not seem to have persisted, which is good for playing the game, but less good for determining what caused the bug.

Sure, here you go.

There were a few things missing from the MFD "navball" that existed on the original navball and that I missed when attempting IVA control, so I modified the page to include them. Thanks for the comprehensive documentation, Mihara- it made this a lot easier to do. I added RCS, SAS, throttle (percentage), gear, lights, and brakes state indicators. For anyone else who wants to use it, here's the text that goes in pa_PFD.txt: [@y5] {0:SIP_6.1}m {1:SIP4}m/s $&$ ALTITUDE SURFSPEED [@x2]{0,6:000.0}° $&$ HEADING {0:SIP_6.1}m {1:SIP4}m/s $&$ ORBTSPEED ACCEL {0:ORB;TGT;SRF} $&$ SPEEDDISPLAYMODE [@x-3]{0,6:000.0}° [@x2]{1,6:000.0}° $&$ ROLL PITCH [@y8] SAS: [hw] Gear:[/hw] {0,-3:"[#00ff00ff]On [#ffffffff]";0;Off} [@x8]{1,-4:"[#00ff00ff]Down [#ffffffff]";0;Up} $&$ SAS GEAR [@y8] RCS: [hw] Brakes:[/hw] {0,-3:"[#00ff00ff]On [#ffffffff]";0;Off} [@x8]{1,-3:"[#00ff00ff]On [#ffffffff]";0;Off} $&$ RCS BRAKES [@y8] [hw]Throttle: [/hw] [hw] Lights: [/hw] {0,5:P0} [@x8]{1,-3:"[#00ff00ff]On [#ffffffff]";0;Off} $&$ THROTTLE LIGHTS {0:;" ";""} Burn T:$&$ MNODEEXISTS {0:;" ";""} {1:KDTS.f}s $&$ MNODEEXISTS MNODEBURNTIMESECS {0:;" ";""} Node in T ÃŽâ€V $&$ MNODEEXISTS {2:;" ";}{0,17:KDT+yy:ddd:hh:mm:ss.f} {1:SIP_6.3}m/s $&$ MNODETIMESECS MNODEDV MNODEEXISTS {0:SIP_6.3}m {1:SIP_6.3}m/s {2:SIP_6.3}m/s $&$RADARALT HORZVELOCITY VERTSPEED

I also liked to move the ARP window and have the contracts window open at the same time. I think an option in the settings (mutually exclusive/not mutually exclusive) would be best- that way we can have our resource panel+contracts window, but others who leave it in the original position can have it function like the stock resource panel instead of unhelpfully covering up other toolbar windows.

Ah, so it's supposed to do that, okay. That makes more sense. I think most of my confusion was with the weird stochastic effects (loading things in different orders gave different results), but on reflection, that's because the parachute was the majority of the ship mass, so the changing parachute mass altered the necessary parachute size for the target landing velocity. So the presets are used for storing chute type / case size / target planet / target touchdown speed / sundry other minor settings, right.

Testing things out in sandbox mode, loading the provided presets doesn't seem to be working the way it should. Say I take a RC-001S RGU (1.25m probe core, weight 0.1t) and put the RealChute Cone Chute on it. The cone chute starts off with its defaults (1.25m size, 50m main chute deployed diameter, etc). I go to the Action Groups menu, select the cone chute, click "select presets", and choose the Main 0.625m preset. If we look at the RealChute_Settings.cfg, this preset should give me a deployed diameter of 25m for the main chute. What I actually get is a deployed diameter of 17m for the main chute. If I then click "select preset" and choose Main 1.25m, the deployed diameter I get is now 11m (should be 50m according to the preset). If I then click "select preset" and choose the Main 0.625m preset again, I get a deployed diameter of 15.5m for the main chute. If I click "select preset" and choose Main 0.625m again, the deployed diameter is now 11m. If I remove the cone chute, put a fresh one on the probe core, hit "previous size" three times in the editor window to push it down to 0.625m size, and then select the Main 0.625m preset, I get a deployed diameter of 13.5m. If I put a fresh cone chute on the probe core, hit "previous size" three times in the editor window to make it 0.625m size, and click "apply settings", I get a deployed diameter of 13.5m. If I put a fresh cone chute on the probe core and click "apply settings" to use the automatic chute calculator, I get a deployed diameter of 17m. If I click "apply settings" again the deployed diameter goes down to 15.5m. If I put a fresh cone chute on the probe core and select the 1.25m Main preset, I get a deployed diameter of 17m. If I load the Main 1.25m preset again the deployed diameter goes down to 15.5m. Hypothesis: loading presets is invoking the "apply settings" automatic parachute size calculation code, which is overriding the preset settings.

Tested version 1.1, seems to work now, so thanks for the quick fix.

Blah, looks like I opened the game again and it overwrote that earlier log. Will copy my savefile and try to deliberately reproduce. Will edit this post once I've gotten it. EDIT: Okay, bug definitely reproduces. Steps: Take an easy contract (in this case, test Skipper landed at Kerbin). Slap the engine on to a probe core, launch. Toolbar contracts menu fails to display ship as either "on Kerbin" or "landed", despite being both of those things. Switching to space center and back to the ship fixes this. Hit spacebar to stage the engine, contract reward not given. Switching to space center again and checking contract archives shows that contract is now completed, and is no longer listed in my toolbar contracts menu. Full log, plus a list of my active mods: https://www.dropbox.com/s/mxbhuywfh5r32rd/log.zip

Getting various NullReferenceExceptions. I think these were while in the VAB (multiple instances of this one): NullReferenceException: Object reference not set to an instance of an object at AlignedCurrencyIndicator.CalculatorWidget.SetCost (Double cost) [0x00000] in <filename unknown>:0 at AlignedCurrencyIndicator.CalculatorWidget.RefreshCost () [0x00000] in <filename unknown>:0 at AlignedCurrencyIndicator.CameraListener.OnPreRender () [0x00000] in <filename unknown>:0 this was on launch of a vessel: (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) AlignedCurrencyIndicator, CameraListener: Adding to EZGUI camera (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) AlignedCurrencyIndicator, Failed to find EZGUI camera! (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) NullReferenceException: Object reference not set to an instance of an object at AlignedCurrencyIndicator.CalculatorWidget.FundsChanged (Double value) [0x00000] in <filename unknown>:0 at EventData`1[System.Double].Fire (Double data) [0x00000] in <filename unknown>:0 at Funding.set_Funds (Double value) [0x00000] in <filename unknown>:0 at Funding.onVesselRollout (.ShipConstruct ship) [0x00000] in <filename unknown>:0 at EventData`1[ShipConstruct].Fire (.ShipConstruct data) [0x00000] in <filename unknown>:0 at FlightDriver+.MoveNext () [0x00000] in <filename unknown>:0 this appears to have been just after recovery of a vessel (multiple instances of this one): NullReferenceException at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject () at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 at UnityEngine.Component.GetComponentInChildren (System.Type t) [0x00000] in <filename unknown>:0 at UnityEngine.Component.GetComponentInChildren[TextMesh] () [0x00000] in <filename unknown>:0 at AlignedCurrencyIndicator.CalculatorWidget.SetCost (Double cost) [0x00000] in <filename unknown>:0 at AlignedCurrencyIndicator.CalculatorWidget.RefreshCost () [0x00000] in <filename unknown>:0 at AlignedCurrencyIndicator.CameraListener.OnPreRender () [0x00000] in <filename unknown>:0 and this was while in "flight" (actually splashed down), trying to complete a contract (I think that this error is related to the fact that the contract isn't completing properly when I hit the "run test" button, even though all the test conditions are green): NullReferenceException: Object reference not set to an instance of an object at AlignedCurrencyIndicator.CalculatorWidget.FundsChanged (Double value) [0x00000] in <filename unknown>:0 at EventData`1[System.Double].Fire (Double data) [0x00000] in <filename unknown>:0 at Funding.set_Funds (Double value) [0x00000] in <filename unknown>:0 at Contracts.Contract.AwardCompletion () [0x00000] in <filename unknown>:0 at Contracts.Contract.SetState (State newState) [0x00000] in <filename unknown>:0 at Contracts.Contract.Complete () [0x00000] in <filename unknown>:0 at Contracts.Templates.PartTest.onParameterChange (Contracts.ContractParameter p, ParameterState s) [0x00000] in <filename unknown>:0 at EventData`2[Contracts.ContractParameter,Contracts.ParameterState].Fire (Contracts.ContractParameter data0, ParameterState data1) [0x00000] in <filename unknown>:0 at Contracts.ContractParameter.SetComplete () [0x00000] in <filename unknown>:0 at Contracts.Parameters.PartTest.OnPartRunTest (.ModuleTestSubject p) [0x00000] in <filename unknown>:0 at EventData`1[ModuleTestSubject].Fire (.ModuleTestSubject data) [0x00000] in <filename unknown>:0 at ModuleTestSubject.RunTest () [0x00000] in <filename unknown>:0 at ModuleTestSubject.RunTestEvent () [0x00000] in <filename unknown>:0 at BaseEvent.Invoke () [0x00000] in <filename unknown>:0 at UIPartActionButton.OnClick () [0x00000] in <filename unknown>:0 EDIT: I quicksaved and quickloaded on the vessel I was trying to complete the contract on. Now the contract is gone from my contracts list. It looks like it got marked as completed, but I never received the reward for it. Still can't prove that this mod was what caused it, but that NRE looks really suspicious. EDIT #2: I checked, and while the contract is no longer in my contracts list, I still have access to the experimental engine (that I was supposed to be testing) from that contract (it's still marked as experimental). Weird. EDIT #3: The contract shows up in my Archives of completed contracts. So it looks like the contract got marked as completed, but the code that should have given me my reward/removed my access to the experimental part didn't get activated properly.

Actually, the first post says this mod has been updated for 0.24, and I've been running it with no issues. Saved me 1.2GB of RAM. Of course, I'm still on 32-bit KSP, so I'm not sure how it interacts with 64-bit KSP.

Yep, Squad issued a patch for 0.24, changelog visible here, and one of the things they added was an API for PartModules to change the price of a part.

Perfect. I do love how if something bothers us enough in this game, we can generally fix it (or find someone else who already did the work ).

My personal thoughts on balance and/or bugfixing: The radial jet engine and Spinnaker engine both need the "isTweakable = false" and "hideFlow = true" lines added to their ElectricCharge resource to fix the NaN bug (mentioned earlier in this thread). As is, the Linear Aerospike is pretty much strictly worse than the stock LV-T30. It has slightly less thrust, weighs more, has no alternator or bottom node, is substantially more expensive, and above 3km altitude it has worse ISP. In my opinion a reasonable adjustment would be to increase its thrust, to perhaps 300 kN. This gives it a niche as a high-thrust first stage engine with reasonable ISP. Looking at StupidChris' TWR/ISP balance charts, it seems to be well in line with other stock engines at that level of thrust and ISP. The monopropellant engines might need to be rebalanced as well. They currently have the same ISP (100-260) as ordinary RCS systems, but the new stock O-10 monopropellant engine has a better ISP of 220-290, and a substantially higher TWR. Quick and dirty suggestion (same ISP as O-10, identical TWR across all engines, chosen for simple values of thrust and mass & similar TWR to the O-10): [TABLE=class: grid, width: 500] [TR] [TD]Engine[/TD] [TD]Mass (t)[/TD] [TD]Thrust (kN)[/TD] [TD]ISP (s)[/TD] [/TR] [TR] [TD]MPR-45* (1.25m stack)[/TD] [TD]0.25[/TD] [TD]50[/TD] [TD]220-290[/TD] [/TR] [TR] [TD]MPR-5 (0.625m stack)[/TD] [TD]0.025[/TD] [TD]5[/TD] [TD]220-290[/TD] [/TR] [TR] [TD]MPR-5R (0.625m radial)[/TD] [TD]0.025[/TD] [TD]5[/TD] [TD]220-290[/TD] [/TR] [TR] [TD]MPR-1 (0.3125m stack)[/TD] [TD]0.005[/TD] [TD]1[/TD] [TD]220-290[/TD] [/TR] [/TABLE] (*may wish to rename to MPR-50 to maintain naming consistency) In typo news, "propellant" is also spelled as "propellent" throughout the names and descriptions. The rest of the pack looks good to me.

Just blindly put two radial chutes on a rocket using symmetry, and they worked properly. Encouraging, because when I did that before installing 1.2.2.2 I only got one functioning parachute.

Feature request: NathanKell made a plugin, CrossFeedEnabler, to allow for the easier use of radial fuel tanks for resources that have STACK_PRIORITY_SEARCH flow logic. MechJeb is currently not aware of said plugin and will ignore radial tanks that use it to deliver fuel to engines, thus reporting incorrect delta-V values (the fuel still flows in flight, it just doesn't get things right in the simulation it uses to calculate delta-V). It's not a huge problem (for me the main tanks where this is a problem are the radial Liquid Hydrogen tanks from Near Future Propulsion), but if you could add this feature it would be nice to have.

The changelog for v1.3 says Porkjet updated it for RPM .17, so it should work natively now.

Well, there's two modules here. The first one is for support for Blizzy's Toolbar, which is now integrated into the standard MechJeb release anyway, so that one's irrelevant. The other module is the basic FAR support plugin, which was described in previous posts in this thread as being broken in the previous version, and it hasn't been updated since then, so I seriously doubt the switch from 0.23.5 to 0.24 has fixed it. So, in short, one is unnecessary and the other was broken even before 0.24. In even shorter form: No.

When in vacuum, the amount of heat dissipated by the radiators depends very strongly upon the radiator temperature (proportional to the fourth power of the temperature). The temperature is determined by how much of your WasteHeat capacity is filled. The net effect of this is that in space, if you generate waste heat at a constant rate, the level of stored waste heat on your ship will increase until it reaches equilibrium (the rate at which waste heat is removed by radiators is equal to the rate at which waste heat is produced). Note that no matter how many radiators you add to your ship, if you are generating power in space, you will ALWAYS have nonzero stored waste heat, because your radiators need to heat up in order to function. Adding more radiators will let you push the equilibrium temperature/amount of stored waste heat lower, but it's very hard to push it below a certain level due to how strong the temperature dependence is (to halve the equilibrium temperature, you need 16 times the radiator area). When in an atmosphere, radiators will also dump heat by convection. This is modeled as a fairly large level of waste heat removal that does NOT depend upon the radiator temperature. Technically that's not how it should work in the real world, but it's how it's coded at the moment. This is why you can have 0 stored waste heat while generating power in atmosphere- heat is being removed by convection faster than it is produced by the reactor, so your radiators don't heat up at all. On top of that, if you're using an unupgraded Akula reactor (particle bed reactor), that has an optimum operating temperature- if it heats up above that optimum temperature, its power output drops. Also, generator efficiency is determined by the difference between the reactor temperature and the radiator temperature. Upgraded radiators plus unupgraded fission reactors can cause problems because the maximum radiator temperature is actually above the reactor temperature- if you have very few radiators and they heat up to the reactor temperature, the generator efficiency will drop to 0%. Your reactor won't melt, but you won't get much electricity, either. The VAB thermal helper should let you check that, though- look at the equilibrium temperature/generator efficiency figures for 100% power.

Having used TACLS and Interstellar together in 0.23.5, it definitely takes up a lot of resource-list space, but Alternate Resource Panel does let you sort things nicely, keeping it readable.

The O-10 monopropellant engine is now 0.09 mass, so it no longer has a ridiculous TWR (IIRC in Scott Manley's preview video it was 0.03, but that was presumably an earlier version).

Even ordinary Notepad has a "replace" feature that does the same thing. It's under the "Edit" menu, or the shortcut is Ctrl-H.

The upgraded Thermal Turbojet is exactly this- a thermal turbojet that can switch into thermal rocket mode. Add reactor to taste. Upgrade unlocked with the Basic Fusion Power node. It is indeed very handy.

Relevant portion of first post:

Does your download have the license listed? If it does, the license should specify what's allowed. Otherwise we have to go by what's on the forum post, which is (sadly) nothing, so in that case the license would default to All Rights Reserved (i.e. no doing stuff with it other than using it if you're not the original author, so no uploading in that case).