Gilph

I believe the Ranger CommLab is the only MKS part that's a lab. It's very small...only 150 data storage

Installed for the first time this morning. Really a beautiful pack. Thanks for the release. Was looking at the settings in CelestialBodies.pdf to design my first rocket to get into orbit. It said the Kerbin had an atmosphere height of 70km but it looks like it should be 85km?

I solved it by lining up the center of thrust indicator in the VAB to make sure it was lining up to the center of mass, both when the fuel tanks were full and when I emptied them. If the center of thrust moves when the fuel is decreasing, I moved the tanks to get it balanced as best I could.

Hi...have you checked the event logs? Windows treats the .exe for TOT differently from a security perspective because it doesn't have a publisher. If Windows were not running it because of security issues, there may be some messages in the Security event logs.

I would look at your path environment variable for the path to the matlab runtime directory. I had many duplicate lines from other installations and cleaned up a lot, including removing the old matlab runtime entry.

I did a few more things with TAC background disabled. It looks like there are 2 NREs: one in the battery part and one in the thermal part. The battery one seems like it happens when a ship is loading and is being modified: ([ERR 15:48:10.979] Exception handling event onVesselWasModified in class ModuleDynamicBatteryStorage:System.NullReferenceException: The thermal one seems to be when you switch away from the old vessel and it's being removed: [ERR 15:50:01.273] Exception handling event onVesselDestroy in class VesselDataManager:System.NullReferenceException: All three sets of logs are linked in my first post

This. It seemed like it was tied to me jumping between different vessels. I'll try to get a better correlation. With TAC background processing on, my orbital stations would seem to be running OK at 10000 warp. Then something would change and my power would jump straight to 0 after a few seconds, where i just had like 170 days of power remaining a few moments before. The bad one was that one station had an NFE reactor that was powered off. I would see the power reserve drop to a 0, NaN almost instantly on the TAC status screen. When I switched to the vessel, I see some messages, the last one being Core Overheated, and the whole vessel would disappear, killing the kerbals. Not sure how that happened with it turned off. If it's useful, I'll try and replicate with debug on and will post is the same directory in my link above. Thanks for your help.

Hi, I found some NRE in DBS. The logs are here. I had DBS debugging mode on to try and find some weirdness in the handling of electricity. I'm using TAC, and there may be some conflict between DBS and the TAC background processing of power. I had to disable the TAC background processing for now, as the two may be conflicting with each other. Please let me know if you need anything else. Thanks

Using v 1.6.3 base version, selected multiflyby porkchop plotter. Sun is central body First waypoint - Kerbin: min 150 days, max 200 to next Second waypoint: Eve: min 800, max 1500 to next Last: Jool all other settings unchanged. Press button. At the computing delta-v stage, error occurs. screenshot and log are Here Thanks

Hi, wanted to try the Multi Flyby plotter and got an error: Not enough input arguments. Error in multiFlybyObjFunc (line 43) Error in flyByPorkchopPlotterGUI>@(x)multiFlybyObjFunc(x,numRevsArr,wayPtBodies,celBodyData) (line 513) Error in flyByPorkchopPlotterGUI>computeFlybyPorkchopPlotButton_Callback (line 514) Error in gui_mainfcn (line 95) Error in flyByPorkchopPlotterGUI (line 42) Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)flyByPorkchopPlotterGUI('computeFlybyPorkchopPlotButton_Callback',hObject,eventdata,guidata(hObject)) Error using waitforallfiguresclosed (line 9) Error while evaluating UIControl Callback. I filled in all of the visible fields, times and waypoint values for everything I could find on the screen. Would you please check? Edit1: It was a Kerbin-Eve-Jool, and start window was Y2D120 to Y10D1

Hi, May I ask the SSPXr users if their greenhouses still work after this update? I just made my first space station for this save and the TAC converters work fine but the SSPXr 2.5 greenhouse does not work. The menu items are all fine, the lights work, but after I start the greenhouse, no conversion takes place. There are no errors in both the logs and tha part compiles fine. Thanks Edit1: Greenhouse is now working. I had to start the Mineral Siphon first, then start the Greenhouse. When I stopped the Mineral Siphon, the Greenhouse kept working.

One of the ways I used to figure that out is to display the resources in the upper right and do a 10x or 50x warp. Very small numbers that display as 0.00 or (0.00) will be multiplied by the warp speed and you will see some actual numbers. Then, just do the math to see how much is produced/consumed.

Done. Also included how to fix.

Hi, I just installed Heat Control in a 1.7 version and noticed the three surface radiators (YF-25, YF-75, YF-150) are installed into the Specialized Electrics CTT node. Can I assume they belong in the Advanced Heat Management node? Edit1: Found the issue. The HeatControlCommunityTechTree.cfg overrides the stock values in the part cfg files. Under the Surface Radiator section: @PART[radiator-surface-2]:NEEDS[CommunityTechTree] should be: @PART[radiator-surface-25-1]:NEEDS[CommunityTechTree] @PART[radiator-surface-3]:NEEDS[CommunityTechTree] should be: @PART[radiator-surface-375-1]:NEEDS[CommunityTechTree] @PART[radiator-surface-1]:NEEDS[CommunityTechTree] should be: @PART[radiator-surface-125-1]:NEEDS[CommunityTechTree] and they go into the Heat Management Systems node.

Hi, What wasn't mentioned was the little Ranger Crush-o-Matic, which is usually sufficient (at least in my designs, ymmv.) You have a few ways to go with fertilizer. Fertilizer is one of the slowest consumed resources, so i didn't need to produce a lot of it. On paper, gypsum gives a great yield. When i used gypsum, it meant that i needed to have a gypsum tank and drill configured. But, gypsum is not used for anything else other than fertilizer, so the extra kit was a bit wasteful. Minerals are one of the largest resources consumed in a self sufficient base, so I had large tanks and many drills collecting and storing minerals. So, using one (or two max) Ranger crushers always seemed to be the most space and mass efficient way to go.

the two I know of are flyby finder and KSPTOT.

Very true...but not applicable in this case. TWR was around 4 and once I lowered it to 1.5 for one test run and there was no difference.

Update: Using less modded version and 862, I landed on Mun. ASL shows 4284m. Using Ascent, the value for turn start is 4.3km, which is historically what I would expect, as previous versions have that value as just above surface ASL. This means the gravity turn starts after a few seconds. I leave all the values unchanged and set a high orbit alt of 500km. The gravity turn starts at roughly 8700, which is twice the starting surface ASL. So, it does appear to be ignoring the surface ASL. If I turn off Automatic Altitude Turn in the Ascent Path Editor and set Turn start altitude to 0.5km, as @El Sancho suggested, the gravity turn started at 4800 km, which was correct. The issue seems to be that the Automatic Altitude Turn part of the Classic Ascent profile is using sea level as a reference, not the ASL, during the ascent. The workaround seems to be to use the manual config, which uses relative to ASL settings which are correct. Please let me know if there is anything else needed.

Blarg...thanks @Tonka Crash I have two 1.6.1 versions: a mostly stock one and a heavily modded one. I originally noticed the problem with the modded one, which is running 862. I copied the craft and reproduced the problem on my less modded one, which is 855. So, the issue seems to be with both versions. I'll upgrade the less modded one to 862 and will update if anything changes.

Hi, having a weird issue with Ascent on 1.6.1 and dev 862. Summary: Gravity turn on the Mun does not start at the proper altitude. The ship heads straight up vertically and does a circularization burn, which is very inefficient. But, Ascent on the same craft worked perfectly on Kerbin. TL:DR section: After landing a simple stock landing craft on Mun, I used Ascent to lift off into a 20km orbit. The Classic Ascent Profile has all of the correct values for altitude, turn end altitude, etc., and I set a 15 deg turn angle. Usually, the craft would ascend for a few seconds and then turn. Now, it ascends straight up for roughly 3km and then turns, but by that point, my Ap is at my peak and it just does a very large circularization burn. The amount of distance it rose vertically (3km) was roughly equivalent to my surface elevation (around 3km). Not sure if that is a coincidence, or it is not accounting for the ASL distance. But, that same craft lifted of of Kerbin and Ascent worked perfectly. It seems like only the Mun is affected, and the Mun is the only body I landed on so far. Craft and logs are here Thanks

Did you also increase the velocity limit?

The USI components look old to me, like 1.4x versions? Have you downloaded the 1.5x compatible Constellation package?

Hi, In the USI LS config, in the PSA Greenhouse25 section (around line 43), this section is repeated twice: MODULE { name = MKSModule eTag = Greenhouse eMultiplier = 1.505 BonusEffect = ScienceBoost } No biggie, but thought you should know.

They do have an algae farm, not sure if it has fish...

That's odd. The SETI converter is not usually part of SSPXr or TAC. I have the same setup and had to Install the SETI greenhouse separately. I did so specifically to not have to deal with Fertilizer on space stations that I'm sending to far planets. I use the SSPXr fish tank and greenhouses on stations around small moons that I can send an ore driller down and back easily (like Minmus).