DMagic

You just have to tell KSP which module is going to be varying the drag, otherwise it will just get confused about which drag cubes to use. Anything that implements IMultipleDragCube (ModuleJettison, or ModulePartVariant) can do that. But only one can be active. So you have to set useMultipleDragCubes to false for any module that you don't want controlling it, as it seems to always be set to true by default.

While looking at this same issue for some other parts I came to the conclusion that using the part variants to generate drag cubes doesn't make as much sense for vacuum engines like these. You can either have drag cubes based on the different variant sizes, or have drag cubes based on the shrouded vs unshrouded version of the engine, but not both. For vacuum engines it almost always makes more sense to use drag cubes based on the engine shroud. That way, when the engine is in the middle of a stack its drag cube makes sense and matches that of similarly sized engines and other parts. When using drag cubes based on the part variants you get penalized for using anything except the biggest variant. When the engine is used in the middle of a stack and its shroud is turned on, then it behaves as you would expect it to. Turning off the shroud would cause a interruption in the drag, as you would expect. And when the engine is placed on the end of a stack then it should still, in most cases, work out okay. You can do this by setting "useMultipleDragCubes" false in ModulePartVariants and set it to true in ModuleJettison (you can't set them both to true, if you do it just reverts to using procedural drag cubes and the result is more less the same as setting it true in only ModulePartVaraints). There is also some benefit to manually adjusting the drag cube from there, but that would be different for each engine.

Orbital Science does not use Contract Configurator and the anomaly survey science does, in fact, use the Flying Low situation for any results that are collected with the anomaly scanner while not landed on the surface. The anomaly science does not conform to standard science in any way, including this one.

It tells you the filepath for the part's config file. If you want to write a MM patch targeting that part then you should use the actual config file to verify the part name.

On Windows KSP is a Dx9 game. It can be forced to run in Dx11, but I think there are some problems with that in later versions of KSP.

The stock science parts for Universal Storage are no longer included in Orbital Science. The old parts are for Universal Storage 1, which is no longer supported. A future update to US2 will include new wedges for all of the stock science parts. @_Zee That probably means that the Orbital Science code was the last thing written to the log file before the error. All that code is doing is changing the location metadata for some icons so that they work with contracts. The XRay icon is the last one modified. The log entries from your other post are related to the deprecated US1 science parts.

@MrSystems @BlackHat The FOV value takes into account the celestial body's radius (based on the ratio of that body's radius to the home body's radius), so a scan of Minmus has a much wider scan width than that of Kerbin. But the variance is limited, I think the values are capped at an FOV of about 20, meaning a scan would uncover a 40x40 area on the surface (with maps for all bodies being divided into 360x180 unit grids), and the FOV will never go lower than the value in the config file when scanning at or above the ideal altitude (and below the max altitude). The "resolution" or detail of the maps is basically irrelevant for everything by the low resolution altimetry scanner. All other maps are effectively infinitely detailed; you can zoom in to the point where you're looking at a few meters per pixel, or less. Making the scanning altitude more complicated feels a lot like adding complexity for the sake of complexity. Having fixed altitude ranges means you never have to think about how high or low your orbit must be for a certain body. There are a few edge cases where modded planets are very large, but no MM patches are provided to adjust the SCANsat sensor altitudes, those cases would be best addressed by proving MM patches to do handle that. @eatU4myT I think you would just have to add the other SCANsat parts to the Contract Configurator config files provided by SCANsat. I'm not really sure about the config format for allowing different parts to unlock the contract. Someone more familiar with Contract Configurator would have to handle that. It would probably be best to bring up the issue in the Probes Plus thread.

I think the weirdness that happens when loading sub-assemblies, saved crafts, and reverting has to do with the way the editor loads parts. It handles loading a part very differently from bringing a new part in from the part list. This can really trip things up in some cases, so that probably needs to be looked at. For USModuleSwitch you can target as many fields as you want within one module as long as they are on the same target module. MODULE { name = USModuleSwitch SwitchID = 1 TargetModule = ModuleConnectedLivingSpace //Only one target module per USModuleSwitch TargetFields = passableWhenSurfaceAttached|surfaceAttachmentsPassable TargetValues = true;false;false;false|true;false;false;false } You just have to make sure to separate the values correctly: '|' to separate target fields, ';' to separate the desired value at different switch states.

@_Zee Keep in mind that the values in the config file are only used as defaults for new save files (or existing save files when first installing the mod). The actual values are stored in each game's persistent file. The in-game window allows you to revert to either the defaults specified in the config file, or the stock values.

The API is here, you probably would only need to worry about the first few methods, as the rest concern asteroid science experiments, which is a bit more involved: https://github.com/DMagic1/Orbital-Science/blob/master/Source/DMAPI.cs X Science uses reflection to access some of these methods, you can see it here: https://github.com/thewebbooth/KSP-X-Science/blob/master/X-Science/DMagic.cs

IndicatorLights uses the stock ModuleScienceExperiment module for all of its functions. As that module is inadequate for what I need I use my own (most of which inherit from the stock module). Some of the information could be made available by casting the ModuleScienceExperiment as IScienceDataContainer (which all of my science modules implement) and using the interface methods instead of the class methods. But the interface does not have methods for all of the required information. Orbital Science has a static API that makes it relatively easy to access this type of information through reflection, but it isn't trivial to setup that kind of thing. ModuleScienceDataIndicatorBase would work by casting to the interface. ModuleScienceAvailabilityIndicator would require accessing the Orbital Science API to get the required information. I think ModuleScienceDataIndicator should work fine as is (assuming that its base class were altered to work correctly).

This has been reported a few times starting when MH was first released. One of the reports even has the corrected drag cubes that would at least make the part not cause too much drag. Given how long they've been left in their broken state I wouldn't hold out much hope for them being fixed any time soon. But maybe if everyone up votes those reports it will get looked at.

Well, not so much cut off as cut out and paste it before. But, yes, the idea is that there are obviously ways of handling textures that don't involve loading every single one into memory and keeping them there. There was a mod that did that, but it had lots of limitations and didn't always work correctly. Adding something like that to the stock game would obviously have to be more stable.

I just opened the TextMeshProResolver.cs file and commented the whole thing out. If you aren't doing anything that requires Textmesh pro (and I'm not sure what would really require using it) then you don't need to worry about that file.

@Psycho_zs Have you tried the same setup with KER to see if the same weird behavior is present? That would help to know if the problem has something to do with how the values are calculated, which is basically the same across both mods, or if it has something to with how Basic dV is interfacing with the stock system.

Because KSP loads all of the parts and their textures at startup, you can see it in the loading menu: "Loading Textures.../Loading Models, etc... Though in most cases the old textures take up less space than the new ones, as there are generally variant textures, and sometimes bigger textures for the new parts. It's the easiest way of handling the problem of how any part can be used at any time. If the models and textures weren't stored in memory, then every time a new vessel was loaded, or just came into loading range, the files would have to be loaded from disk again. Imagine if you were trying to dock with a huge station and every time you first approached the station the game would freeze for 5 seconds while the files were loaded. There are obviously better ways of handling these things, but they would require more effort.

@Tonka Crash The short term solution is to just delete that part. It hasn't been used for anything in ages.

Basic DeltaV version 5.1 is out; get it on Space Dock. It fixes a few bugs related to the stage group panels, adds an engine torque value option to the dV toolbar panel, and ignores locked resource containers when calculating the max dV available for a stage, this value is only used to set the maximum value of the slider when using the dV slider option. The actual dV values always accounted for the locked status of resource containers.

@Krakatoa The mod shouldn't care about the actual file. It's only the SCANSAT_SENSOR config nodes that matter, they can be in any file, or patched with MM.

Stock KSP without all of the dV code is pretty clean as far as garbage generation goes. I think Squad cleaned up most of the recurring (generated every, or almost every, frame) sources of garbage allocation when 1.2 came out. But the stock dV is... not good at all. In a bad case it could, by itself, be generating more than 10X what KSP was generating each second without it. Both the dV calculations and all of the UI related to the dV values generate a lot of needless garbage. You can improve the situation a little by not opening the little dV info panels next to each stage icon. You could also try disabling the stock dV all together. Or just replace all of that garbage with Basic DeltaV. Mods range from very good regarding garbage allocation to absolutely terrible. With a few good mods you could be generating just a few 100kB of garbage per second, or less, but with bad mods, you could be looking at 10s of MB per second, which will trigger GC pauses every few seconds.

@Psycho_zs A few things: It's normal that stage 5 doesn't have dV, there is no way to determine when stage 4 would be activated, so all of the dV from stage 5 falls down to stage 3, where the decoupler is. The simulator is basically assuming that once stage 5 is active, then stage 4 will be immediately activated, and all of the fuel will be burned before stage 3 is activated. For stage 1 I'm not sure what is going on, that NaN for the ISP value would definitely screw things up, but I don't know where it would come from. I could roughly recreate this vessel with values that looked about like your 2nd picture. I couldn't get it to behave like the 1st picture. These are all ReStock parts? They should work fine, but you could be causing problems somewhere. Do you have cross feed enabled on any of the decouplers? That always confuses things.

@NikoKun Horizontal and vertical velocity is shown, but unless it is forced on it will only show in certain circumstances, like when you are in atmospheric flight, or sub-orbital flight, or something along those lines. I don't remember the exact criteria. But you can always just force any readout to display all of the time.

How it should work is that if you disable an engine in the active stage, then it will ignore that engine for all calculations. But if you disable all engines in the active stage, or there is only one and you have disabled it, then it will revert to treating all engines as if they are enabled, providing the correct ISP, burn time, and dV amounts (thrust and TWR values represent the actual thrust and TWR).

I don't know what would be causing all those problems. But if you are looking for a way to be notified whenever a PAW is generated then you can let Unity's magic methods and serialization work for you, for once. Find the prefab of the PAW window, attach a simple MonoBehaviour to it with an Awake method, then trigger your own event when that Awake method is run. Then the next time KSP opens a PAW, it will find that prefab, make a clone of it along with the script you attached, then call the Awake methods for all scripts active on that clone. I do this in SEP to add some fields to the PAW when on EVA: Finding the prefab (you might want some logic to make sure everything is not null when this happens, and that you only do it once): https://github.com/CobaltWolf/Surface-Experiment-Pack/blob/master/Source/SEPScience/SEP_Utilities.cs#L131-L142 The script being added to the prefab: https://github.com/CobaltWolf/Surface-Experiment-Pack/blob/master/Source/SEPScience/SEP_UIWindow.cs The event being called in the Awake method: https://github.com/CobaltWolf/Surface-Experiment-Pack/blob/master/Source/SEPScience/SEP_Utilities.cs#L47-L48

Basic DeltaV version 5.0 is out; get it on Space Dock. This version completely overhauls how the mod works. Almost all aspects of the old UI have been removed and the mod has been altered to function through the stock UI. It disables all of the stock dV calculations and replaces them with its own. Several improvements and additions have been made to the stock system, most of which can be summarized in the image below: These changes result in better performance, less garbage allocations, more available information, and a better experience than the stock system allows for.