DMagic

KER by itself isn't generally that bad for memory allocation. It's only when you cover the whole screen with readouts that things can get out of hand. The new deltaV calculator does, disappointingly, seem to be generating a fair amount of garbage. It doesn't run every frame, but it adds up, and it gets worse with larger vessels.

There's no particular reason to use a top-left anchor. If you set the anchor and pivot center to top-left (pivot x = 0, y = 1) then I suppose it's a little easier to position elements; x pixels to the right of the parent's left side, and -y pixels down from the top. If you have a completely static UI, no option to resize the window, no dynamically changing elements or window size, then you can set the anchors to whatever you want. Top-left (or bottom-left) does make some sense for the top level of the UI window, since it makes it a little easier to position the window on screen (though you do run into potential problems with the UI loading off the screen on the right or the bottom, having some code to clamp the window position to the screen helps with this). But for a dynamic UI there are lots of cases where you want other anchors. You might want elements that stick to different corners of your UI when you resize it. Or you want elements to expand to fill the window (using the blue anchor preset options). And there are other more complicated situations, like you want a label to be 1/3 of the way along a resizable bar, then you would need to manually set the anchors. As I think I mentioned somewhere in the tutorial, the rect transform anchors are confusing and the best way to get a handle on them is just to fiddle around with them. This is also a situation where having your code run in the Unity editor is helpful. You could run all of the code needed to add a re-size handle to a window, then just play the scene in the editor and see how the different rect transform anchors behave, instead of having to run KSP every time you need to change something.

To be clear, the Unity Assembly is one that can be imported into a Unity project and used by assets within that project. It only required references to the UnityEngine.dll and (probably) the UnityEngine.UI.dll. This is imported into Unity as a compiled dll, not as un-compiled .cs files, then all of its classes are accessible by Game Objects within Unity. Whenever you create a Unity project it also generates an Assembly-CSharp.dll (and several others). This is not related to KSP's Assembly-CSharp.dll (well, technically this is how KSP's .dll is generated, through Squad's original KSP Unity Project). The new Assembly-CSharp.dll is the default assembly file where any code added through Unity is compiled. This happens when you create a new .cs script somewhere in your project's Asset folder. That code will be compiled into the Assembly-CSharp.dll. In general you should never have to do anything or worry about the Assembly-CSharp.dll generated by your Unity project. The Unity Assembly that you create is an already compiled .dll file that you import directly into Unity. So the answer is no, you should not reference the Assembly-CSharp.dll generated by the Unity project, and you should not include that file with your mod. When you make the KSP Assembly you do so basically the same way as you would for any other mod. You add references to the UnityEngine.dll and UnityEngine.UI.dll, and to KSP's Assembly-CSharp.dll. Then, in this case, you would also add a reference to your Unity Assembly .dll, so that it can be accessed directly from the KSP Assembly. UnityUIAssembly.dll -> this is the Unity Assembly that is imported into Unity | | ---> UnityEngine.dll ---> UnityEngine.UI.dll KSPAssembly.dll -> this is the KSP Assembly | | ---> Assembly-CSharp.dll -> this is from the KSP folder, not from your Unity project folder ---> UnityEngine.dll ---> UnityEngine.UI.dll ---> UnityUIAssembly.dll -> this is your Unity Assembly file Both the UnityUIAssembly.dll and the KSPAssembly.dll files are placed in a folder in KSP's GameData folder and loaded into KSP. The basic problem, and the reason for this whole run-around method, is that you can't import an assembly into Unity that has a reference to KSP's Assembly-CSharp.dll. Unity gets confused, or thinks there is some loop of references, or something, and it will fail to import. So if you want code that you can access from within the Unity Editor, then you have to make a separate assembly and go through some indirect method of tying that back into KSP's code. It isn't absolutely necessary to do this, Fengist has a great tutorial for how to make a UI with a single, standard KSP Assembly. It works well for simpler UI's, but I would have a hard time doing many of the things that I have in my UI's without having code that is directly accessible from within Unity. You can also use this same method for doing other interesting things, like adding custom behavior into KSPedia entries.

OK, I see it now. I will see if it can be worked around.

I'm not seeing this, either by reverting or using undo. What version of KSP is this in?

There are at least 3 bug reports on this issue, some of which have been around since about the time MH was released. Both for the tubes to occlude parts within them, and to fix the trivially simple drag cubes (the problems associated with drag cubes for hollow parts are well known and easy to work around) that make these parts terrible for drag. So it's not like they aren't aware of the issue.

@Kitspace Yes, they basically become SCANsat parts. There is a section in the KSPedia entry that goes over SCANsat resource scanning. @Tacombel Seems unlikely. The only contracts this offers are for conducting scans (ie Conduct a biome/multispectral scan of the Mun).

I haven't seen it mentioned elsewhere. So here is a link to HarversteR's (KSP's creator, for anyone who doesn't know) AMA, up on Reddit now:

@Gordon Dry If the issue happens without Tracking Station Evolved installed, then it is not due to Tracking Station Evolved. I've never seen a problem where an existing vessel either doesn't show up in the list, or doesn't have any functional buttons when selected. There was a problem with the vessel not registering as being selected after one of the 1.4.x updates, which could cause the buttons to not work, but that is fixed in the latest version. There are a few rough edges that might cause weird behavior when there are no active vessels, or when you select one of the vessel categories with no active vessels in it (from the icons at the top of the screen), but that doesn't sound like the issues you are having. All TSE does is take the vessel list from stock, move them off of the UI layer, then copy the data from that list of vessels to populate the new version of the vessel list. All of the vessel data and functionality of the vessel list runs through the stock vessel list (clicking on a vessel button in the TSE list simply passes on that mouse click to the stock vessel button). If a vessel doesn't appear in the TSE list, then it is likely because it doesn't appear in the stock list, also, for whatever reason. Your log file shows that TSE seems to be initializing and loading properly, so I'm not sure where the problem is coming from.

@MDPKH Those images are cropped. The mod doesn't do anything to how or where the target object is focused on screen.

@Gordon Dry Those exceptions are from Remote Tech and they seem to happen in the editor, so I don't know why they would have anything to do with the tracking station. I don't know why the list isn't showing all of the available vessels. There are way too many mods in there to sort it out, so you'll have to try getting rid of mods to figure out where the problem is coming from (and make sure the stock tracking station list works correctly). Any mod that makes any kind of changes to the tracking station or the tracking list is the first thing I would look at. @eberkain Adding extra information is fine, but everyone has their own opinion about what is valuable enough to show in the limited amount of space available for each vessel. So aside from being more trouble than it's worth for me, it would mean trying to figure out the 1 or 2 most valuable things to add, or making some type of list of available info that players can choose from, which is never going to happen.

You need to use the scanner parts.

@TheAngryHulk What did you scan with? I can't see the SCANsat multispectral scanner in the screenshot, and the small map indicators show that nothing is active. @Crixomix The small map has always only been available in the flight view. It is tied to the current vessel and the celestial body that vessel is orbiting. As there are no active vessels outside of the flight scene, and because the small map has no ability to change what body is shown, the small map is not available.

Tracking station threads have been a near constant presence in the suggestions forum for about as long as I can remember. So I wouldn't hold my breath waiting for Squad to actually do something about it (my own theory is that Squad just doesn't do the sort of long term play-testing that would be required to really show the deficits of the current tracking station). Tracking Station Evolved is basically an amalgamation of several of the tracking station suggestions that have been floating around for years. So it's probably the best you're likely to get, though I would love to be proven wrong.

@Tricky14 A picture of your setup would probably be more helpful.

Basic Orbit 8.3 and Basic DeltaV 3.2 are available on Space Dock now (GitHub seems a little backed up, so the latest versions aren't posted there yet). Both have fixes for the toolbar icon being fuzzy in some cases. Basic Orbit has fixes for the closest approach and radar height calculations. Basic DeltaV shows the current thrust and TWR for the active stage readout panel in flight.

@rakol That's one of the things I've already changed for Basic dV in flight for the next update. The display for the current stage will show the actual TWR (and thrust), and the max values in parenthesis.

@HebaruSan Yep, I was thinking the same thing. I changed it to double.MaxValue / 10, made it >=, and checked the values individually instead of both at the same time. I have a handful of other small updates to this and Basic DeltaV that I'll release some time soon.

@ZobrAA Do you know what the actual closest approach value is when that happens? It looks like some impossibly large value is getting calculated for some reason. And does the same thing happen if you open the map view? That number is the max value of a 64 bit floating point value in c#. Basic Orbit should be checking for such a possibility, but it looks like an error could have slipped through.

Have you looked at using the IPartMassModifier interface with a PartModule? I'm not sure about it's use in flight, but I think it can be used to adjust a part's mass using whatever criteria you want and will register that change in mass in whatever ways KSP needs it to.

I think the unpopularity of the DLC speaks for itself. It doesn't really need an active poll. Just look at the MH sub-forums, there are about 10 threads that have been active in the past month. Compare that with the challenges forum which has dozens of active threads every week. Or look at the Steam Workshop. There are about 80 missions, only one of which seems to have a rating, and over 11000 crafts. Or KerbalX where there are only a few dozen missions, many of which seem to be different versions of the same mission. Or look at the Mission of the Week. Each one gets basically no attention. Maybe MH fans and mission builders are just very solitary people who build missions for themselves, don't share them, and don't post about them. But that doesn't seem to likely, people tend to share the things they make in KSP, at least the people who frequent the forums or Reddit. I guess there could be some thriving off-line community of KSP sharers, but it seems more likely that mission builder just isn't very popular. Which is a shame, as I said in my earlier post, it seems like an incredible waste of time and development effort to make something that no one really asked for and that not many people seem really interested in.

The basic structure is that the USSwitchControl module provides the UI for all of the variant switching and triggers all of the other modules. It has a SwitchID field which is used to identify it. Then you have the US***Switch modules. These also have SwitchID fields which are used to register which USSwitchControl they are controlled by. When you switch to a different variant in the editor each US**Switch module with the matching SwitchID has its respective CurrentSelection field set and updates whatever it controls (active mesh, part cost, mass, attach nodes, resource setup, drag cubes, etc...). Then when you move to the flight scene each US**Switch module updates to its selected version using the CurrentSelection field, which is persistent.

You could use USDragSwitch to specify which of the included drag cubes to use (using the same CurrentSelection line to specify which variant), but it would accomplish the same thing as just deleting all of the unused drag cubes. If you were to delete all of the drag cubes from the part config then they would be automatically generated by KSP and you would end up with the drag cube for the four-high variant.

Oh, duh, that's because it doesn't know which meshes to turn off. You have to set the line to: MeshTransforms = WaterWedgeSingle;WaterWedgeDouble;WaterWedgeTriple;WaterWedgeQuad then set: CurrentSelection = 0 Change the selection to whichever height you want, starting from 0.

Yes, though the editor part icon will always only show the single height variant. The others are tagged with Icon_Hidden which prevents them from being shown in the icons.