OhioBob

OK, I'll talk to you about it before my next release. That won't be before KSP 1.5.1 at the earliest, however. I think I've got all the math worked out for the NovaPunch SRBs. I now just have to write up the cfg. After I'm finished, I'd like you to look it over to make sure I haven't missed something.

That shouldn't be a problem, I'll take a look at it. (I still need to also look at USI Sounding Rockets.) I don't use CKAN myself, so I have no idea what's involved in getting added to it. That's something I suppose I should figure out.

UPDATE Version 1.0.3 Changelog Changed RT-5 and RT-10 internal names to match KSP version 1.5. See opening post for download link and instructions. Please note that BetterSRBs 1.0.3 is not compatible with KSP versions older than 1.5. For older KSP versions, use BetterSRBs 1.0.2.

GPP in KSP 1.5 The current version of GPP appears to be working correctly with KSP 1.5 and Kopernicus 1.5.0-1. However, you will get an "Unsupported KSP Version" warning. Just ignore this message and click close, everything should work OK. I will eventually fix this, but it's is such a minor issue that I see no reason to rush. Chances are we'll see some further 1.5.x releases coming from Squad in the coming weeks. I'll release an update once the dust has settled.

I just noticed that in the Game Difficulty / Advanced settings, there is a checkbox for "All Part Upgrades Applied in Sandbox".

Kopernicus is version locked, not SVT. Just make sure you have the right Kopernicus and SVT should work.

One caveat with part upgrades is that they only work in Career mode (and I presume Science mode, though I haven't tried it). That's because the upgrade is linked to a technology. In sandbox mode we'll just get the original part specs with no upgrades.

You can look up what the atmospheric pressures of those worlds actually are just by checking they're cfg files. I can comfirm that Tellumo's pressure is indeed 1013.25 kPa, i.e. 10 Kerbin atmospheres. I think @Sharpy has it right.

I don't think the stock Swivel has upgrades. PorkJet's part overhauls added upgrades to several engines, including the Swivel, but that's not the case in stock. @FungusForge, if you just want to get a look at what a config for a part upgrade looks like, you can check it out in my mod BetterSRBs. There are two parts to it. There is a UPGRADES node in the part cfg, and then in a separate file is a PARTUPGRADE node. You can find examples in the files KSP_stock.cfg and Upgrades.cfg.

@Klapaucius, @JadeOfMaar is right, you have to be very suspicious of what you read in the Tracking Station regarding atmospheric pressure. The best way to be certain that you've got the right pressure is to open the .cfg for the planet and find the pressureCurve. It should look something like this: Atmosphere { pressureCurve { key = 0 101.325 0 -0.0150837 key = 1000 87.2020 -0.0132081 -0.0132081 key = 3000 63.9899 -0.0101333 -0.0101333 key = 6000 38.9849 -0.00673315 -0.00673315 key = 9000 22.6271 -0.00429191 -0.00429191 key = 12000 12.5591 -0.00253586 -0.00253586 key = 15000 6.81764 -0.00138393 -0.00138393 key = 20000 2.54022 -0.000487144 -0.000487144 key = 25000 0.998086 -0.000181456 -0.000181456 key = 30000 0.412750 -7.07098E-05 -7.07098E-05 key = 35000 0.180048 -2.89531E-05 -2.89531E-05 key = 40000 0.0818694 -1.27710E-05 -1.27710E-05 key = 45000 0.0370931 -6.02348E-06 -6.02348E-06 key = 50000 0.0159849 -2.79241E-06 -2.79241E-06 key = 55000 0.00644408 -1.21769E-06 -1.21769E-06 key = 60000 0.00242266 -4.88645E-07 -4.88645E-07 key = 63000 0.00131259 -2.70937E-07 -2.70937E-07 key = 70000 0 0 0 } } The first number in each key is the altitude in meters, and the second number is the pressure in kilopascals. So in the example above, the pressure at an altitude of zero is 101.325 kPa, which is 1 Kerbin atmosphere. The pressureCurve is what you actually get in the game, so it's the planet's real atmospheric pressure. What the Tracking Station displays is the setting staticPressureASL. If staticPressureASL is not assigned a value, then the value of the template will be used. It's likely that some of these planets are using a Laythe template, so that's why they're showing 0.6 atm. And as JadeOfMaar said, the pressure is always relative to the home world. That is, the Tracking Station will always show the home world's atmospheric pressure as 1 atm regardless of what it is in kPa. So even if another planet's pressure is correctly displayed as 0.6 atm, that only means that it has 60% of the home world's pressure. The surface gravity displayed in the Tracking Station should be correct. That is, 1g always equals 9.80665 m/s2.

@kerbalmckerbalface, I don't know what could be causing it. I recommend starting over with a fresh KSP installation. Then install just GPP and its essential mods. Test it and see what happens. If all is good, then start adding back your other mods incrementally, testing periodically to make sure it's still working. If at some point it breaks, then you can isolate what mod triggered the problem.

It sounds like it might be a known bug related to deletion of the extra launch sites added by the Making History DLC. Try this and see if it fixes it, Find the file, GameData/GPP/GPP_Planets/Gael_A.cfg, and delete the following line: removeLaunchSites = Desert_Launch_Site, Desert_Airfield, Desert_GroundObjects, Woomerang_GroundObjects

I don't believe so. I'm pretty certain Galileo did everything in 4k only.

I can't get it to work either. I might have to have @Galileo look at it. He's the one who set up the webpage. In the meantime, have you tried using the downloadable spreadsheets rather than the online ones? I think they're working.

91 km is correct. I doubt there's anything you can do about the music. FYI, the height of an atmosphere using SigmaDimensions is, new height = old height * Atmosphere * atmoTopLayer The Atmosphere factor stretches the existing atmosphere, and atmoTopLayer extrapolates it beyond where the existing model ends.

If Gaia it the home world, then yes, that's correct. The Tracking Station data will show it's atmospheric pressure as 1 atm regardless of what it is in kPa. Apparently not. It looks like surface gravity is always in units of 1 g = 9.80665 m/s2. It depends. Gargantua's atmospheric pressure will be displayed as, (staticPressreASL, Gargantua) / (staticPressureASL, home world) So if for the home world staticPressureASL = 50.6625, then Gargantua's pressure will display as 20 atm, but if staticPressureASL = 101.325, then Gargantua's pressure will display as 10 atm. While the logical thing to do for the home world is the set staticPressureASL equal to the actual sea level pressure, that's going to mess up the specific impulse of engines. To get specific impulse to compute correctly, staticPressureASL for the home world must be set to equal to 101.325. -------------------- (edit) -------------------- You've described a scenario in which we have a planet pack with a home world having an atmospheric pressure of 50.6625 kPa, into which other planet packs can be installed. What I would probably do in that case is this, For the home world, staticPressureASL = 101.325. This is necessary for specific impulse to be correctly computed. For other planets within my planet pack, staticPressureASL = 101.325 * (actual pressure, planet) / (actual pressure, home world). For other planet packs that might be installed with my planet pack, I'd do something like this, @Kopernicus:AFTER[otherPlanetPack] { @Body[Gargantua] { @Atmosphere { @staticPressureASL *= 2 } } } In other words, I'd change the staticPressureASL setting for the other planets so that their atmospheric pressure is displayed in the correct ratio to my home world's atmospheric pressure.

It was a long time ago, probably 3 years. I think it was one of the early 1.x versions. Just to clarify, KSP does use the pressureCurve to compute ISP, it just doesn't use it to define the value of 1 atm. PressureCurve returns the pressure in units of kPa, while the ISP curve takes pressure in units of atmospheres. So KSP has to convert kPa to atmospheres. We have, atmospheres = kPa / X, where X is the conversion factor. Years ago, the value of X was obtained from the home world's pressure curve, using the pressure at an altitude of 0. But now X is equal to the home world's staticPressureASL.

UPDATE Version 1.0.1.2 Changelog Revised staticPressureASL for GEP_Primary; engine Isp now correctly computed. This update affects GEP_Primary only. Regular GEP is unchanged, though you will still get the update notification. To stop receiving the notification, you'll have to update GrannusExpansionPack.version. For users of GEP_Primary, this update fixes a bug that caused the specific impulse of engines operating in an atmosphere to be incorrectly computed. Since Isp was previously being computed too high, this update has the potential to break existing launch vehicles. See opening post for download link and instructions.

You're too fast. I have to update the AVC version file before I can zip everything and upload it to GitHub. You just happened to check in the short window of time while everything was being updated. It's all good now, so check again.

That fix use to work back in the old days of KSP, but not anymore. The issue is that the lookup variable for the Isp curves is the atmospheric pressure measured in atmospheres, where the curves are calibrated on the presumption that 1 atm = 101.325 kPa. But in KSP, 1 atmosphere = sea level pressure of the home world. So when the sea level pressure of the home world is not 101.325 kPa, the Isp curves will return incorrect numbers. We have to make KSP think that the sea level pressure of the home world is 101.325 kPa even when it's not. In the old days, KSP got the sea level pressure of the home world from the pressure curve. So to trick KSP into thinking 1 atm = 101.325, we had to perform a little hocus pocus with the home world's pressure curve, doing just what you described. But KSP no longer uses the pressure curve for this. It now uses the parameter staticPressureASL. That is, 1 atmosphere = staticPressureASL, home world. So to get the Isp curves to return the correct values, we just have to do this, staticPressureASL, home world = 101.325 For other celestial bodies, the only use of staticPressureASL is for the planet data display in the Tracking Station. The Tracking Station will always show the pressure of the home world as 1 atm. So for other bodies we just have to set staticPressureASL so that it is in the correct ratio to the home world's staticPressureASL value.

I just revised my JitterCurves (hopefully they look better). The online document is up to date, but if anybody has downloaded the old one, you should replace it.

Although removing Grannus/GEP may have fixed the problem, it's possible they may not be the source of the problem. If you have the time to run some further tests, I'd recommend removing all mods except the essentials: GPP GEP Kopernicus ModularFlightIntegrator ModuleManager Then run the game and see if you have the problem. If not, then something else might be the culprit. You could then add back your other mods until the problem reoccurs. You should be able to isolate what else is triggering it. If you experience the problem with just the bare essentials installed, then I don't know what to tell you. Many other people have been playing the game without having this issue.

I just tested it. The thrust limiter slider always goes from 0 to 100, but the thrust varies from minThrust at 0 to maxThrust at 100.

To a point, yes. But not to the extreme that you can thrust limit them in the game. There are things that can be done with the geometry of the fuel to increase or decrease thrust. Also the fuel formulation can change. A catalyst can be added to increase burn rate, or a suppressant to decrease burn rate, which will increase or decrease thrust respectively. I'm fine with having a thrust limiter, but it would make more sense to me if it were restricted to a narrower range, not the current 0-100%. I may have to investigate to see if that's possible; it would be worth adding to BetterSRBs. I see that there's a minThrust setting in the cfgs, perhaps that places a limit on how far the thrust slider can go. I'll experiment when I get a chance.

That could be possible. The Flea is short and fat compared to a 0.625m sounding rocket. The sounding rocket is going to have a long channel down the middle with a lot of surface area. So it's going to produce a lot of thrust and burn through its fuel quickly. The Flea probably has less burn surface, so it's going to produce less thrust. But it will burn longer because there is more thickness to burn through.