DMagic

That's essentially what the new UI does. You define all of the attributes of the UI element when you create it, or before, then the canvas system just passes it to the GPU every frame, rather than recreating everything. I see some things that look like cached UI objects in UbioWeld, but I think those are just workarounds for a the lack of any built-in drop down menu (another thing that the new UI does nothing to solve, along with tooltips; thankfully there are lots of helpful extensions available for things like this). Everything is event-driven, so instead of testing whether a button is being pressed multiple times per frame by calling GUILayout.Button, you just assign a listener to the Button onClick handler, then when you click the button it detects the mouse click and invokes the event and all of its listeners. You can still update things on a regular basis, using the Update method, or a CoRoutine, or something similar, but you don't have to. Indeed it is. Even before Unity 4.6, the IMGUI system was never really sufficient for any kind of complex game UI, and basically unusable for mobile. Before that everyone was basically completely reliant on third-party UI system developers (one of which, I think, was used as the basis for the current system) to produce anything workable. KSP used 1 or 2 of these systems in the past, along with IMGUI, replacing all of that was a major part of the upgrade from KSP 1.0 to 1.1. Click through is another are where IMGUI falls apart completely. All of those UI elements live in a different world from the rest of the Unity objects, so a window, or button, or any other UI element does nothing to stop the mouse click events from passing through to other objects. The fact that all IMGUI elements are drawn on top of everything else doesn't help now that all of the stock UI has moved to the new system. ClickThroughBlocker, or similar systems used by individual mods, is a workaround that helps. But the new UI system avoids the problem completely, the UI elements behave the same as other objects in the game and block mouse click events (if the element doesn't need interaction you can make them transparent to raycasts, if you want to). The exceptions here would be for text input fields, where you need to manually lock out KSP controls so that you aren't turning around, or activating the lights or something while typing. And something like keyboard shortcuts for you window, where you might only want the shortcuts to work when the mouse is over the window, or something along those lines. The thing about using CanvasGroup isn't really related. If you set the alpha for the canvas group to 0 if makes all UI elements invisible, so you generally wouldn't want them be blocking mouse clicks anymore; you could if you wanted to, but I can't think of many cases where you would.

That's the whole problem with IMGUI. You recreate the entire UI multiple times every frame. I'm not sure what this means as it relates to IMGUI. All of the UI elements are generated by calling the GUI and GUILayout functions somewhere within the OnGUI method attached to a MonoBehaviour (don't ask me about all of that SCAN_MBW/MBE stuff, I didn't write that, though I know it has its origin in TriggerAu's plugin framework code; it has all since been removed), I don't see how you can cache or store any of that information. Recreating it on every frame is just how it works, unless there is some alternate way of doing it that I am completely unaware of. You can, of course, cache certain components of the UI, strings (or StringBuilder instances), textures, etc... but if you want to draw a button you just have to call GUI/GUILayout.Button on every frame. I don't see where UbioWeld is doing it any differently. It looks like it has a lot of data stored in constants, but its UI code is still being drawn with GUILayout, and not every bit of text, or component of the UI can be cached at compile time like that. This sounds suspiciously like the Unity UI. Generally when a scene is loaded in KSP you would either start a MonoBehaviour to control your window, or just add a toolbar button. Then when you open the window you create everything, which, for a UI generally means instantiating a bunch of GameObjects, either tediously through manually coding everything*, or by loading a prefab created in the Unity editor from an asset bundle. Then your UI is in the visible state, the Unity canvas system just draws whatever is on screen each frame. Scripts attached to those UI objects can handle updating the UI or processing events, etc... * For most of my UI's I destroy everything when the window is closed. Creating and destroying the UI isn't generally that intensive, and it simplifies some things. For some, like Contracts Window +, the opening process is particularly intensive (meaning poorly thought out and coded ) so I just hide it when the window is closed. There are a few different ways to go about hiding a UI. You can just turn off the GameObject using SetActive, which stops all of the attached scripts from running and hides the window, but calling SetActive itself can be a problem. Another way is to use a CanvasGroup script attached to the window. If you set the alpha for a CanvasGroup down to 0, and make it non-interactable and not block ray casts, then (supposedly, I don't think I've every actually tried this) all child objects in the CanvasGroup will be ignored by the UI (they won't generate any draw calls), but the attached scripts will still be running, so it could be a trickier way of handling hiding the UI.

Old versions of Contracts Window + were essentially unbound GUILayout scroll views. You could potentially have dozens of active contracts, each with an unbound number of contract parameters, each potentially having sub-parameters and notes. When using a GUILayout scroll view all of the elements contained within are generated for each frame, even if they are not displayed in the window. So the strings and textures for each element are allocated, and draw calls for each GUILayout element are generated (it's actually two draw calls for each element, I think). For CW+ each contracts had several icon elements, the title button, contract parameter text elements, note buttons, etc... and so could generate dozens of draw calls per contract. Performance problems quickly limited the amount of contracts you could reasonably display for those early versions. The solution for this using OnGUI is to manually position elements withing the scroll view using the GUI controls, not GUILayout. This is also what X Science does, which is a good thing, as it can potentially display hundreds of elements for all of the various possible science results. Then you only have to worry about allocating resources for what is actually shown in the window. A simpler example of this is when I made a window to show all of the XKCD colors, it was just a scroll view with a few lines of text for each color, but since there are about 1000 of these colors it absolutely crippled performance. Just a single window in the main menu screen dropped the FPS down to about 10, presumably because of the excess draw calls. Ironically, of course, the new Unity UI still has some problems with scroll views. The default masking system used to only show what is within the window is inefficient, but an alternative is available that will prevent draw calls being made by elements outside of the window. And there is some potential for problems caused by the Pixel Perfect flag (which aligns all of the image elements with pixels, so that they aren't blurred between neighboring pixels), but those can be worked around. I don't have numbers for any of the scroll view problems mentioned above, the performance difference was obvious at the time. But I did do some garbage generation comparisons when I remade the SCANsat UI. Just having a few of the old windows open would generate 5-10MB of garbage / sec, whereas the new windows generate basically 0 garbage (except for a bug in one aspect of the current version ). The trade-off for not generating garbage constantly is a spike when instantiating all of the UI objects when the window is opened, but that generally only occurs for a single frame and still results in less garbage during that one frame than OnGUI was generating for every frame.

And KSP provides a simple system for doing this that doesn't require OnGUI, the PopupDialog classes. It provides an easy, fast method for creating simple windows, and, if you want, it can be extended and bent to create something more customized, like Astrogator. Of course, for performance effects, little simple windows like this don't make a difference either way. It's the complicated windows with lots of text, or, in the worst case, a scroll view with an unbound amount of elements contained, which can be potentially disastrous for performance, either because of garbage, or just the raw number of draw calls generated by OnGUI and GUILayout.

What I mean is, the only valuable thing learned while using OnGUI is how to use OnGUI. That skill, and the knowledge required to use it, doesn't really translate to any other area of coding. So if you know how to use OnGUI for making KSP mods that's fine, it will probably continue to be supported, but if you don't then you would almost certainly be better off learning how to use the new Unity UI. It relates much more directly to how systems work generally in Unity. Learning OnGUI won't really help you to understand any other aspect of Unity coding, or UI work in general. For instance, as far as I know, the Unreal engine has a UI system that is at least broadly similar to how Unity's new system works. Or for Android, there are a mess of different layout systems, all of which have their different uses (and one of them, the Constraint Layout, is a little bit similar to how a Unity UI is laid out, at least visually), but none of them are anything like OnGUI.

@Gordon Dry I can see how that information could be useful, but neither of these mods would serve that purpose. Basic Orbit is about flight information, and Basic DeltaV is about dV and engine performance, basically. Basic DeltaV should behave the same as KER or VOID when it comes to data calculations, they all use the same vessel simulator code. Unless something has changed in the latest updates for KER, which I'm waiting for 1.4.3 to implement, they should all give the same information.

@Critter79606 This is the wrong thread for that. Have you collected any science using that part before? Are there any records in the R&D Center science archives? @Rohaq The contract is asking for a SCANsat scan using the M700. If you want that scan to follow the same behavior as the other SCANsat scan types you need to disable stock resource scanning in the settings window.

I whipped up a quick example: Each double ring on the cylinder is weighted for the bone that starts at that ring (so the first double ring on the left is weighted to the second bone). Then I uncheck "connected" for each bone in the chain and just translate and scale in the X and Z axes. I also unchecked inherit scale, so this would not strictly work in Unity, but as I said above, there are workarounds. Obviously, if you are going to use a dependency anyway then you should use what is easiest. But if you or someone else wants to, you can make similar inflation animations with just bones. When you select one of the vertices in the cylinder the setup looks like this: On the left, in the properties tab, you can see the Vertex Weights category, this vertex is set to Bone.002 with full weight, you can mix other bones with values between 0-1 (if only a single bone is selected then any value > 0 will be full weight). The Vertex Groups window on the right shows the available weight groups, these can be generated automatically when you parent a mesh to an armature, or you can just add them. The names of the groups match the names of the bones. You can select a group of vertices then use the "Assign" button to assign vertex weights to multiple vertices at the same time. You can also paint on vertex weights by changing the mesh from Edit Mode to Weight Mode.

Armatures aren't usually used for separate objects like that landing leg, assuming those are separate meshes (the little extending foot-pad cylinder definitely is, but the others don't necessarily have to be). That example is using an Inverse Kinematics rig (that yellow bone has an IK constraint) to make all of the joints move together in a way that makes sense. Unity doesn't understand those bone constraints, but this type of animation can just be baked (the location, rotation and scale of all the deform bones keyed at each frame) and it will load into Unity and KSP just fine as a SkinnedMeshRenderer. Normally you would rig a single mesh to an armature, then assign weights at each vertex to determine which bone alters the position of which vertex (this can be mostly done automatically, or in groups of vertices at a time). You can blend together multiple bones at each vertex, but Unity limits it to the four with the highest weights. The reason I'm asking is that I think a similar effect might be possible using only bones. It isn't necessary to have bones be linked together as part of a single chain like you see in that leg example. In the bone properties you can uncheck the "Connected" option which will allow a bone to move freely, it will still inherit the parent bone's rotation and scale (you can uncheck those in Blender, too, but Unity doesn't accept that and will always inherit parent bone rotation and scale). So you might be able to make that inflation animation by (assuming the y axis goes to the right in your example) translating the bones to the right and scaling them up in their x and z axes. Scaling can be tricky to work with in bones, so you might need to make the bones siblings in the hierarchy, rather than a chain of unconnected bones. That might be more trouble for this example, but for anyone not wanting to rely on outside dependencies it could be helpful.

What's the difference between blend shapes and using an armature animation? Or maybe a better question is what can you do with one that can't do with the other?

Features that are "sorely lacking" is always a tricky subject. The features that I consider to be lacking from the stock maneuver node tool are the ability to place the maneuver node at specific locations (not needing to hunt for just the right pixel to place the maneuver node at apoapsis), something to prevent the maneuver node from getting lost in other icons when zoomed out, and something to allow for fine adjustments. Maneuver Node Evolved does the first two pretty well, I think, and while it has a separate window for making exact adjustments, there is probably a more seamless method for adjusting how much the maneuver node gizmo increments dV. But I would consider any kind of auto-generated node adjustment as way outside of the stock behavior. As for the dV readout, stretching the header would be bad, it would just look funny for the stage panels to be bigger than the stage icons, and it would look even more out of place if only the stages with engines and/or decouplers used the bigger icons. It would simpler to just have a separate icon that is stretched vertically, since vertically stretched icons are already used by the staging panels to accommodate extra stage icons. @Gordon Dry What is the middle-click info given by those mods?

@Electrocutor That's an interesting idea. I don't think it would be that challenging to replace the stage icons for selected stages with a modified version of the icon, but space would be very tight to fit two lines of info in there. It would have to just show dV for that stage alone, and then probably TWR on a separate line. I do like the idea of stripping out all settings, windows, and options, though, just making it as simple as possible.

@theonegalen Not really. The RPM maps default to color mode, so if you leave out a color toggle button then it will just always be in color mode. As for tinting, the only thing I can think of would be to see if RPM has some way of putting a transparent green layer on top of a window.

Separate threads aren't always a good idea for Unity. Anything that reads or writes to a Unity object might be a problem if run from a different thread, like reading a vessel position, or writing to database that is being read from something else. SCANsat uses threading for some math-heavy operations, like interpolation for some of the maps, but that works because everything is kept strictly separated, which you can't do when dealing with Unity objects. For that methods there may be simpler ways of improving performance, I just have never gotten around to it.

Those are unlikely to have much of an effect. The foreach loops, and the way that module is written in general, is a bit sloppy, but that section of Update and the other code only runs periodically, I think in response to when a resource scanner is deployed or retracted. In SCANdata that is an enum, which is a value type and shouldn't be allocated. The changes in SCANcontroller could help, that method only runs once every second though, so unless you have a huge number of vessels it wouldn't affect much. That method is, however, responsible for some serious performance problems, just not garbage related. Like I said, the biggest problem in the current version is related to the information that appears when you hover the mouse over some of the maps. It's doing something silly when looking for contract waypoints that generates a lot of garbage. That will be fixed in the next version.

Which loops are generating garbage? There is a bug in how some of the text in generated when you mouse-over a map which generates a lot of garbage, but otherwise I'm not aware of any major sources of garbage in the part modules or scanning system. There are probably lots of garbage generating loops in there, but in things related to loading or saving, or things that only happen once, where extra garbage generation doesn't really matter so much.

@H4ckerxx44 Unlikely, given the complexity of basically having to rebuild the mod in the old version of Unity, as downgrading the project doesn't seem to work.

It's down for me, too, and according to isitdownrightnow.com, for everyone else. Also, when did this thread get moved to the general discussions forum? It seems out of place.

Tracking Station Evolved version 3.0 is out; Space Dock seems to be down, but you can get it on GitHub or Curse. It adds a search box which can be used to search all vessels by name from any of the available list types. It also extends all of the sort and ordering functions to the standard vessel list, along with adding the vessel rename dialog button to each vessel button in that list. Vessels with maneuver nodes are always shown at the top of the list, regardless of sort order. And some bugs caused by vessels being destroyed (or stopping asteroid tracking) have been fixed, along with making the list update more smoothly when a vessel is created or destroyed (generally only happens with asteroids).

There is an OnGamePause event, then the PauseMenu behaviour has an isOpen property that could be used to check if the game opened the pause menu after pausing. The pause menu is just a popup dialog though, so getting to the Settings button to register if it has been clicked would be tricky.

https://github.com/S-C-A-N/SCANsat/releases/tag/v18.4 18.4 is the one you want for KSP 1.3.1.

@HaydenTheKing The latest version of SCANsat for KSP 1.3 is 18.4: https://github.com/S-C-A-N/SCANsat/releases/tag/v18.4 I don't know what specific requirements Probe Control Room might have, but I can't see any reason why any of the dev versions would be needed. There is nothing in those that isn't in 18.x.

Does anyone have a stock or nearly-stock save with a high number of vessels (not asteroids or debris)? I want to test a few things with 100+ vessels and don't want to deal with putting all of that in orbit, changing the names, changing the type, etc...

Hollow parts like decouplers are weird about drag and usually need custom handling to work right. There was thread way back about drag cubes where it was suggested that you would just copy the Y values for the drag cube from a similarly sized fuel tank or other part with flat ends. I guess you could compare it other decouplers, or see what it looks like for the decoupler alone, but that might be a normal value. Looking at the PartDatabase those values seem to be reasonable for a 5m part. And shrouds are another problem entirely. I would guess that the shroud contributes zero drag effects once it's separated from the engine plate, since it's probably not really a part at that point. Maybe it still has mass though and that makes it behave funny, who knows, it's a weird setup.

Keep the popup dialog system in mind for simple UIs. It can be stretched and warped pretty far beyond just a simple list of buttons. Check out Astrogator for a good example.