Fractal_UK

I need to do some testing on this issue because I don't have the same problem myself but, in principle, there is some limited file IO involved in testing whether a part is upgraded in the VAB, how much that file IO occurs depends exactly on how KSP handles the loading of parts in the VAB, it may be that it is reloading all of the parts every time the symmetry settings are changed. Generally, I develop, run and test Interstellar on an SSD to minimise loading times (pretty important when you have to reload the game every time you recompile the plugin) but a delay that is not really perceivable to me may be causing some kind of small and annoying delay on magnetic drives.

It's all integrated into the stock science system now. Upgrades, for the most part, will be done automatically when you buy new tech nodes, existing craft already in space are the only parts that need to be upgraded manually when you unlock new techs.

I have no idea what you are talking about here, it already follows exactly the same rules as LiquidFuel. Drop tanks of Methane work perfectly.

Northstar: you don't need to repeat the same exact comments every few pages, especially when I already explained all of this the first time.

Technically, that is not correct. Gamma ray spectrometers cannot be used to detect the presence of water, water is detected by neutron spectrometers which measure counts of fast and fast+thermal neutrons to infer the thermal neutron rate which is indicative of the presence of water moderating those neutrons. On several science platforms, neutron spectrometers are integrated into the same science package as gamma ray spectrometers and those packages are, for some reason, collectively referred to as the GRS instrument. However, there is no way to infer water content using gamma spectroscopy. There will, in future, be a neutron spectrometer part for measuring the presence of water.

Yes, those were the models from before version 0.8, in fact they were some of the first models made for Interstellar.

You have not deleted old versions of the mod when updating.

Are you experiencing this only in career mode or does it happen in sandbox mode too?

In stock KSP, the aircraft are so overpowered they fly far more like rockets than like aircraft, you'll be hard pressed to find an aircraft that doesn't have TWR > 1, often it might be multiples of this. Realistically, you'd expect a fighter to have a TWR of ~1 (often marginally greater than 1) while an airliner might be ~0.3. To go a bit more space oriented, Skylon in atmospheric operation would be ~ 0.75. The fact that the thrust of the stock aircraft engines is so high is one reason that it appears that reducing the isp by ~16x isn't sensible. Once you bring the thrusts into a sensible regime and kick out the velocity curves, it all begins to make sense. All this work here represents a much needed change in my opinion.

I'm not in a position to test this myself at the moment but you could try removing 1) MODULE { name = ModuleDecouple ejectionForce = 10 explosiveNodeID = top } 2) MODULE { name = cBBp_GenericAnimate animationName = umbi_dettach startEventGUIName = Umbilical detach endEventGUIName = Umbilical attach startDeployed = False customAnimationSpeed = 1.0 availableInEVA = true availableInVessel = True EVArange = 5 layer = 1 useActionEditorPopup = false moduleID = 3 playAnimationOnEditorSpawn = False defaultWindowRect = 550, 300, 150, 100 } and 3) Both. All of these from the Dragon Trunk part.cfg file in cBBp_dragon/Parts/Electric/cBBp_Dragon_Wings. Does that give better results? If so, which options work and which don't?

That's not a bug report, you are a having a problem and suspect for whatever reason that this might be related. If you think there is a problem, please actually test it and provide me the precise details of what happens, I'll need KSP.log files and exact information about how I can reproduce it. I do not have the time to test guesses at the moment.

You have installed the mod incorrectly. The most common mistake is having two GameData folders, you should have the WarpPlugin, OpenResourceSystem and TreeLoader folders inside your KSP/GameData folder. If you don't, it won't work.

Interstellar doesn't have a heat wall, it sets part temperature based on velocity to a proportion of the part max temperature. In any case, he's not going anywhere near fast enough for that to be a problem. I have a theory however, I recall hearing that DRE halves max temperatures for some parts, assuming this hard sets part temperature, a halved or reduced maximum could be a real problem.

It's best to use the gamma ray spectrometer to find some location with high abundance before attempting to mine, otherwise the process can be very slow. Put something in orbit with the GRS so you can find those locations, preferably in a high altitude and inclined orbit so that you have a good field of detection. On minmus you'll want to go for something water derived for your plasma thruster, so LiquidFuel for complete self-sufficiency or Monopropellant if you can ship the ammonia in.

You can consider Interstellar to be "example code" for ORS because it demonstrates referencing a version specific ORS install as well as how to make certain useful parts. The idea is to keep the part modules contained in ORS fairly simple because it's tough to code for every resource extraction system someone might imagine. I think it's better to simply provide API functions to let people make the part they actually want via an easy process. If you look at the interstellar ISRU scoop source you'll see there's only a few lines relating to the ORS API, it's really easy to get the resource quantities, the majority of the code is density calculations and similar.

Let me explain in more detail, the default turbojet engine contains this: velocityCurve { key = 0 0.5 0 0 key = 1000 1 0 0 key = 2000 0.5 0 0 key = 2400 0 0 0 } See the 0,0.5 and 1000,1.0 lines? They mean that at 0m/s the engine produces half the thrust compared to the thrust produced at 1000m/s *but* if you watch the fuel flow rate when transitioning between these velocities on a test flight in KSP, you will see that that although the thrust changes by a factor of 2, the fuel flow rate doesn't change at all. That means, using a real world definition of specific impulse, the specific impulse has also changed by a factor of 2 but the game does not report this to the player. The game will tell you the engine is achieving the same specific impulse in both circumstances, even though they differ by a factor of 2 by definition. Specific impulse is thrust/mass flow rate so if you double the thrust without changing the mass flow rate, specific impulse should double. In other words, at 0m/s the specific impulse is only half what the game is claiming (or only 8x greater instead of 16x greater once you take its poor handling of intake air in isp calculations into account).

Yes but the fundamental problem in KSP is that we are using specific impulse to define a mass flow rate rather than the reverse. We also have the problem that while there are different definitions for exhaust velocity (effective and actual exhaust velocity) there is no such distinction for specific impulse - KSP hasn't really got its definitions right. I would say the solution is to simply divide the atmosphere curve values by the intake air:fuel ratio then perform a corrected isp calculation and write that to the realIsp field so that the player sees the correct value. We know from our previous testing that the turbojets are also seriously overpowered in terms of thrust as well as having dodgy velocity curves that stealthily affect the isp and that both need to be corrected before we have a realistic fix but I presume this mod can handle both of those changes.

They're scaled relative to the radius of the planets so they should remain in the right place.

Each command pod and each probe core has a different rad hardness rating which determines by what factor the radiation is scaled down compared to what an EVA kerbal would receive. These values are automatically generated based upon the mass of the capsule and the number of Kerbals it contains but could be overridden in specific cases. The main radiation shielding mechanism I'm interested in initially is a magnetically confined plasma to deflect charged particles like cosmic rays though I'm interested in propellant tanks performing a similar role for both cosmic rays and neutrons. Nuclear reactors and rockets will, in future, have some effect but it will be quite a small one. At which point, the dose will be inverse square so, yes, distance will matter.

This has been slow moving due to the many facets of Interstellar and me being extremely busy at the moment but some progress has been made. I now have a system in place to track Kerbal lifetime radiation dose, i.e. as a Kerbal travels around the solar system the exposure to radiation that it experiences is recorded with an adjustment for the Kerbal's natural ability to repair any damage done to its body by radiation. The current system for this is fairly simple, there is a 50mSv/year limit for completely safe, consequence free, radiation exposure. If a Kerbal is exposed to more than that, which they generally will be in space, the dose will begin to accumulate over time. Likewise, if a Kerbal is exposed to less than this limit, then their body can actual begin to recover from prior radiation exposure, effectively reducing their total accumulated dose and allowing them more mission time in future. The result of this is that large doses are disproportionately effective at creating an accumulated dose that is hard to ever recover from while slightly elevated doses can be recovered from with relative ease. Very high doses that cause accute damage need to be handled seperately but this is fundamentally a straightforward process in comparison.

The other problem with using IntakeAir density = 0 is that ModuleEngines uses the fuel density to calculate thrust so setting IntakeAir density = 0 makes a jet engine require IntakeAir for operation but prevents expelling it from actually producing any thrust. That means all the requested thrust is instead produced by LiquidFuel and that changes the fuel flow behaviour further.

They are there for backwards compatibility but should not be used. Just use normal intakes. Mechjeb works perfectly for thermal rockets in the VAB when that thermal rocket is powered by a reactor. It cannot work for microwaves, obviously because those results are time and position dependent.

It should be easy enough with a plugin like this to change the atmosphere curve values which affect the internal engine performance to produce proper fuel consumption behaviour while maintaining the correct displayed values by manual setting the realIsp field.

Eve and Laythe have less water in their oceans than Kerbin but are still predominantly water. I don't know if there is any way for me to distinguish that but I'll have a look.

The "problem" with thermal rockets is that people test them on the launch pad and assume that they will function exactly the same in space but atmosphere affects a lot of things in Interstellar so testing on the launchpad often produces bad results - heat dissipation is a particularly good example of that. Using mechjeb or engineer or just looking up thrust values on the wiki is a better method of getting accurate readings on what the thermal rockets will actually do.