DMagic

An asset bundle is just a collection of stuff exported from Unity. Just select the assets you want exported, assign them to a bundle, and then run the build script (it puts a menu in the toolbar along the top of the window with a button to build the bundle). I assume that KSPedia files need some specific formatting, but anything else is just an asset bundle, you can load it from KSP yourself without any problems. You can attach a file extension, or not, a .ksp file will be loaded by KSP asset loader, I've never worked with that so I always attach my own extension and just load it myself. Also, the thing about the specific folder in only for this small build script. Any of the other stuff covered in my tutorial (the assembly you make to interface with the UI) might have to go in the Plugins folder, that's where I always put it, but I don't know if it's required.

That's not really a reliable way to install mods. People setup their GitHub repos in all sorts of weird ways (for instance, I never put the actual assemblies in the repos), so it's not surprising that there would be extra folders, files, etc... Just download the zip from the release page, it is setup correctly.

I actually don't even bother with the Part Tools for UI stuff. It's only for KSPedia and parts that really need it. I guess it's probably best to get working correctly, but it's not strictly necessary for UI creation. A simple build script (just make sure that it is in a folder called "Editor", otherwise it won't run) will handle everything you need to get the UI components out of Unity and ready for KSP: https://github.com/DMagic1/KSP_BetterTracking/blob/master/Unity/Better Tracking/Assets/Editor/Bundler.cs Another thing worth pointing out is that learning the OnGUI system basically useless if you don't already know it. It's almost completely esoteric and has no value outside of legacy Unity UI. The regular UI system is just standard Unity stuff, so maybe still not very useful outside of that case, but at least a little more valuable knowledge than OnGUI.

@Tivec Contract parameters work in many different ways depending on what they are trying to do. Regardless, printing messages anywhere whenever one completes is a terrible idea and we can only hope that a 1.4.3 is around the corner.

If you're looking to reduce garbage in mods there are a few places to start. The first, and in most cases by far the worst offenders, are mods using the old IMGUI (anything using the OnGUI method in its code). The old GUI system is horrible, all of its code runs multiple times per frame, it sends potentially huge amounts of draw calls to the GPU, and it seems to be designed to generate garbage. The worst are anything that is constantly updating complex text, or anything that displays a long list of elements, like a scroll view with all of the vessels in game, or all of the science results, something like that with an uncapped number of elements. Replacing the UI for an old mod is hard though, and really boring. But if you want to make a new mod don't waste time with it. The next big source is lots of string manipulation, which is related to the first since this usually happens in the context of a UI. If something is displaying lots of text data and it does so by combining lots of strings this can really create a lot of garbage. So anything that has lots of: string text = "Super wastefull " + vesselname + " more waste" + vesselspeed.toString() + ....; That stuff can be replaced by either string.Format or StringBuilder, depending on how it's created (or even string.join or concat, I think). That gets around some of the inherent problems with string creation. Also be careful to avoid boxing when using string.Format, and consider some kind of cache for StringBuilder if you use it a lot (there is one built into KSP, or you can make your own, search stringbuildercache and you'll find a million examples). For string.Format boxing: Use: string text = string.Format("Do something {0} times to make {1} less garbage!", 5.ToString(), 0.74f.ToString("P0")); instead of: string text = string.Format("Do something {0} times to make {1:P0} less garbage!", 5, 0.74f); If you don't convert those value types into strings the method will convert them into objects first, then into strings, which generates garbage. Then you get down to the Linq stuff and foreach loops. If Linq is used heavily then it could have a big impact, it can usually be replaced by lots of for loops without much difficulty. I think some of the foreach loop problems have been alleviated in versions after Unity 5.5, but I would still just for loops, there is rarely a reason not to. Dictionaries are potentially a problem, but KSP has the DictionaryValueList to get around this. Also, sort of obviously, if you can reuse objects then do so. For instance, if you make a new list for something every time a method runs, then just cache that list instead and Clear it every time you need to use it again.

@Gordon Dry I saw the thing about window positions, I just don't always reply. If the stock contract window toolbar button isn't appearing then something else is going wrong. Also, if the useStockToolbar field is set to False in the settings file, but you don't have Blizzy's toolbar installed then the CW+ button should still show up in the stock toolbar.

@Tivec Credit KSP's latest "update", it includes such lovely things as printing a log message every time a contract parameter changes state, which happens all the time with certain contracts...

That's what I'm saying. The numbers verify the expected results. You don't need them unless you want to verify them yourself. An engine that's visually smaller than a fuel tank will work fine. An engine that's visually bigger won't. An engine where the engine bell is visually the same size as a fuel tank will probably work fine, but you're sort of pushing it. Just look at the old 1.25m engines and compare their bell size to that Skiff. It's obviously a different size class. But nevertheless, the drag effects will probably be minimal, so it would mostly work fine.

For simple vertical stacks the first YP value, the exposed surface area for the "top" of the part in question, is determined by comparing the YP value for that part when unattached with the YN value of the part it is attached to (that is, the numbers directly from the drag cube, not the values printed in the part context window), the fuel tank in this case. These values should generally match their visual size, so all 2.5m fuel tanks would have the same YN and YP value, and all of the old 2.5m engines would have a matching YP value. The engine's with variants would have YP values that vary with the top surface size. So if an unattached fuel tank has a YN value higher than the engine's YP value, then the engine's final YP value will be 0. Which makes sense here, the middle fuel tank's YN is just a flat circle of 1.8m diameter (the units of these drag surface areas are a mystery, they clearly aren't m2) and the engine's YP is roughly the 1.25m top surface plus some overhang for the very end of the bell So the YP value for the engine would be 0. ie, before attaching, the tank YN is ~4 and the engine YP is ~2, so after attaching the engine YP is 0 (2-4=-2, you can't have negative surface area, so 0); the tank YN would be 2. The tank YN is where you have the mismatch. I don't know what affect there is from having a high drag surface area on the trailing side of the rocket. The small value for YP for the engine on the 1.25m tank does sort of make sense, all of the non-smooth surfaces are more-or-less exposed to air coming from above. The small value means it might not have much of an effect unless you start going very fast at very low altitudes. Clearly the Skiff is much bigger than the old 1.25m engines, so it's not unreasonable that it might behave somewhat differently.

@Gordon Dry It works fine for me, though replacing the stock buttons is always a little iffy, so if it doesn't work for some reason just don't use that function. The "useStockToolbar" field in the settings file is what tells it to use the stock toolbar, rather than Blizzy's toolbar. So if you want the button to appear in the stock toolbar you'll need to set that to true. The settings file is only loaded from disk once, it could be loaded more often, there just isn't really a reason for it and the settings file isn't designed to be edited while playing. I did notice one problem though, the default position for the window in the tracking station is behind the vessel list. So if it's hidden back there the only way to get to it would be to go to another scene, increase the window's scale to max, and hope that it makes it big enough to peak out from behind the vessel list so that you can drag it somewhere else. The same happens in the VAB, but the parts list is smaller.

No, you look at the size of the engine and the size of the fuel tank. If the engine has a tank butt or a shroud, then you match the tank butt or shroud to the fuel tank. If it doesn't, if it's a bare variant, then it will never perfectly match any size fuel tank. But it's not hard to guess about sizing. If the engine bell is huge and the fuel tank is tiny then there will be drag and you should maybe reconsider the pairing. If they look pretty close visually then they will probably be pretty close in terms of drag. That dinky three-AJ-10 thing above was pretty stable once the fuel mass was balanced (and gravity was set to ~0.9 to get off the ground). I don't think there is anything complicated about that. For occluding parts below the engine, like an engine in the middle of a stack, just use an engine plate or interstage fairing.

To add to the above, even a more uncertain case makes sense when you look at the numbers: The bare variant of the AJ-10 is fully occluded by the 2.5m and 1.8m tanks, but not the 1.25m tanks. Which visually makes sense.

It's still pretty easy, at least to me the values make sense. If you want to really check you could open the PartDatabase and compare values, but checking in-game works pretty well, too. If you squint you can see what's happening. On the right are 1.25m tanks with different variants of the 1.8m RK-7. Check the YP values for the engines to see how exposed the top of the engine is to airflow (imagine looking down the rocket with the tank at the top and engine bell pointing away). The biggest variant obviously doesn't fit and has a non-0 YP value, meaning the engine is not shielded from the "top", or its positive Y axis. The small shrouded variant has YP = 0, meaning it is fully occluded, as expected. The bare variant has a YP value between the other two, which also makes sense, all those bits and bobs are now exposed to the airstream instead of being hidden inside the smooth shroud as they are in the other variants. If you check the 1.25m fuel tanks above the engines you see that all of the have YN = 0, meaning the bottom of the fuel tank is fully occluded. The 1.8, tanks in the middle are also attached to the RK-7. In all cases the engines are fully occluded from the top, as expected. And for the smaller variants the fuel tanks are partially exposed from the bottom, as expected (the tanks connected to the large shroud engine variant has a small YN value, 0.03, but that probably doesn't really matter). On the left are 2.5m tanks with the 2.5m AJ10. The tank butt version matches the tank and occludes both sides as expected. And the bare version leaves part of the tank exposed as expected.

That's the point I was trying to make, at least partly. For the "bare" variants of an engine they probably won't, and shouldn't, exactly match any tank size, since some of the tank will be left exposed on the bottom surface. For the other variants, either with tank butts or the shrouded versions they should just match the size visually. So if the shrouded Soyuz engine (can't remember the KSP name) looks like it fits a 1.85m tank, then it probably also fully occludes that tank. If it doesn't then maybe that's a bug, or the drag cube for that variant is just wrong.

DebugStuff exposes several aspects of the part model. It shows a wire frame of the collider in blue, a wire frame of the mesh in orange, and the bounds box in pink (the bounds is basically the smallest cube that contains all components of the mesh, they are normally used for camera culling, to determine when an object is onscreen or not so that the camera can decide what actually needs to be rendered, for KSP they also seem to have something to do with drag, since the bounds are specified in the drag cube). As far as I know it shows all of that stuff regardless of whether the corresponding mesh/collider is actually active, so what you see is the overlapping meshes, colliders, and bounds for all variants.

The mesh is what you see. It's the collection of triangles rendered on the screen with a texture slapped on top of it. So if the mesh leaves part of the tank above it bare, then it is expected that the drag for the bottom surface of that tank would only be partially occluded. If the extra aero information is turned on for the part context menu then this would most likely show up in the negative Y axis, which I think is displayed as YN = ##, ##, or NY or something like that (the first number being the surface area not occluded, the second being a value having something to do with the drag applied).

I don't expect people to read the whole thread, or the last 5 pages, but maybe the last 5 posts isn't too unreasonable.

@Apollo13 I don't want to go down that road. I've had or heard reports of about a dozen mods and KSP itself being flagged as false positives by Windows Defender. If you want you could fork the GitHub repo, then change the file extensions yourself and download it. That would have the same effect.

@flart A per-stage toggle for atmospheric calculations would be nice, but Engineer's vessel simulator doesn't really support that (it could kind-of do it, I think, but it would be a lot of trouble). And I'm not sure where to put anymore onscreen controls. The right-click function of the toolbar button is already taken by the toggle to turn on/off the readout panels. I've considered a fourth panel for a long time, mostly for things like vessel information, but have never really gotten around to it. @windmt It's a known problem.

@Apollo13 sep_prefab is the UI file. It won't work without it, and not having it will probably result in errors.

@Apollo13 The science defs files for the expansion planets look fine, but I don't see KSP loading the regular experiment definitions for SEP. Those would be in the SEP Resources folder, next to the other science defs files (the expansion defs just modify the stock planet defs, and so won't work by themselves): https://github.com/CobaltWolf/Surface-Experiment-Pack/tree/master/GameData/SurfaceExperimentPackage/Resources A search for "EXPERIMENT_DEFINITION" in the log file will turn up all of the sources for experiment definitions. So if SEP's aren't there then they may have been deleted somehow.

@Jebs_SY That's weird, everything PS does is pretty isolated to the Kerbal portrait UIs themselves, I don't know why a different UI mod would interfere. I'll try to look into it, though the Kerbokatz stuff is all so interconnected that it makes trying to figure out what it's doing a little tricky.

@Oracle255 There is a line in the settings file that you can change from False to True to enable map filling: CheatMapFIll, or something like that. That opens a section of the Data page in the Settings Window that allows you to fill in all scans or selected scans for a certain planet or all planets. The resource settings window options have to do with how the stock resource scan and the SCANsat resource scan work together. @Neosferatu After checking that the they are installed in the right place (they should be if the parts show up correctly), you might want to check if you have any anti-virus software flagging those plugins as false positives. There have been a lot of those going around recently, including the main KSP files. DMOS contracts all have some type of requirements that must be met before they are offered (unlock certain parts, reach certain progress milestones, etc...), so that isn't necessarily a problem.

@Jebs_SY It's possible that the Community Trait Icons (a dependency of Portrait Stats) plugin is being flagged by Windows Defender. That happened to me yesterday. You can check that folder to see if the .dll is there. If it isn't there the trait icons and some other features won't work properly. You can also double check the settings for Portrait Stats to make sure the trait icons are turned on.

I assume this is caused by the UI assembly for Contracts Window +, ContactsWindow.Unity.dll. Maybe it considers everything after the first period as a file extension and ignores it when checking assembly names.