Lisias

I had a glitch with the JSI Transparent Pods also. Perhaps you should post there too? Perhaps this can be related somehow.

Nice catch! I installed it today! :-) To tell you the true, it's the first time I load this vessel after installing it. But the problem was happening (and was solved) last week, way before the last install mod frenzy. :-) But... Yeah, I think I should test it using a clean KSP install. I will reply about soon. Oh, I had forgot about it. It's a Kerbal Electric Marker Light, RGB(0.4, 0.4, 0.4). They were installed after the problem were solved, so they're not related for sure. It's not (only) for aesthetically reasons, I was having trouble on manually docking by eye, and these lights save my day! (I didn't knew that SSPX added a light to the Clamp-o-tron! First time loading this vessel since SSPX, really!) ] Initially, I was using the K&k 6 Ended Modular Corridor (just because it is pretty! :-) ). Thinking it could be something with the Corridor, I rebuilt it using the hub and got precisely the same result. I didn't tried this workaround on K&K's however. Once it worked, it stayed.

Do you see what I mean now? :-) Now compare the Frontier Developments from nowadays, with this Company at the times of the Elite Frontier and First Encounters. (I had played with these games *at launching* - and yes, they were so buggy as KSP is now on the release! Honest!).

I'm on 1.4.1, and I'm facing some trouble on docking too. But mine appears to be related to some collisions on the collision mesh (pun not intended! honest!). I managed to workaround it using the offset tool, positioning the docking ports slighted offset from the parent part, as in the screenshot (on the left, only one dock accepts a ship, all the others bounce them away!).

I could not agree more. I could not agree less. :-) My expectation level is proportional to the "size" of the service/product provider. If I buy some electronics from the local grandpa shop, I do not expect they have a specialist available for every tech doubt I would have on the product. On the other hand, while buying on a big chain store, I do not expect that their specialist would be interested on my personal needs (as would grandpa's), but on his own commission from the selling. 3:-) Trying a more related analogy: my expectations on Rodina are totally different from my expectations from Elite Dangerous. I do not demand from Elliptic the same I demand from Frontier. You can't have the cake and eat it too. If you want a somewhat indie, non mainstream game, you have to accept the conditions that a indie, non mainstream game producer can offer to you. Internet is a commodity nowadays. I think that something like a Streaming Service (as Netflix, for example) would be a better comparison. Just mine too. :-)

What leads me to the conclusion that you were right from the beginning. So I stand corrected, my apologies, and a thank you very much for your patience while explaining it to me. :-) Well, there's nothing more I can say but "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." © 2018 @DMagic, The Patient. :-)

The thing is not exactly about spending CPU juice, but cluttering the heap. This is a problem even on the old and faithful ANSI C, when we used to write GUI on this thing (and yes, I also wrote programs in TurboVision using TurboC :-D ). By (ab)using from the malloc and free calls, sooner or later (and on a "640k should be enough to everyone" era, the later was sooner than one would expect), the LIBC would fail due excessive heap fragmentation (without virtual memory, and without "indirect pointers", there was no way to defragment the heap!). What IMGUI is doing is, essentially, (ab)using the heap. :-( And on a Mono application (as well Java, another thing that I know very well), abusing the heap is calling the GC for a fight. I will take a close look on all of this. The "transparent" stunt, however, appears to have his days counted. Everybody is (or plans) to use ClickThroughBlocker, I'm right? (I just *hate* when a a click pass through the button and acts on something behind it!)

If I understood the documentation correctly, they are intended for being use outside from a event driven UI main loop. In PHP, you recreate the World each Request (including SGDB connections, unless you use a Connection Manager, that by definition is external to the PHP.exe). Until the moment, I have evidences that on Unity, the IMGUI appears to work on the following life-cycle: you have a Awake(), when your MonoBehaviour is created, then a Start(). A Reset() happens everytime your Behaviours gets the focus, and then later a OnGUI(), called everytime it's your time to draw something in the screen (this sounds a lot as a Stacking Window Manager). But on the very Unity Documentation for OnGUI, you find a example where the GUILayout is used. =/ I know well a lot of things, but Unity is not (yet) one of them - but or someone on Unity's documentation team screwed up epically, or the OnGUI is being handled somewhat heterodoxly by us. However, here we have the Unity's life-cycle, where it's clear that OnGUI is called multiple times (so, it's not my "OnFocus", Reset() is the correspondent one). Ergo, yeah - the example I linked above is... not exactly the best one possible. IMGUI should not recreate everything each time OnGUI is called, it's plain nuts. For a good reason: this thing essentially implements a Stacking Event Driven UI in each GameObject. :-) Since you decided to implement your UI in separated GameObjects, all that clutter is just making your life miserable giving you nothing in exchange. What's precisely the worst possible way of doing things, from the performance point of view. If I need a button, I need a container for it. So, I create a Container, create the button inside it, configure the button attributes (size, position on the container, event handlers as "OnClick"), put everything hooked on a variable on the "Start()" and then, on the OnGUI, just tell Unity to "draw this container on this position". Such container is destroyed on the "OnDestroy" event, or you will have a memory leak. Somewhat more complicated life cycles can be implemented for Widgets that are not necessary all the time. Sometimes you need a Settings, other a Part Atribute Editor, etc, so in order to prevent having everything and the kitchen's sink created all the time (cluttering the heap and increasing the minimum memory footprint for your code), we build a FSM on the OnGUI to handle the mess. Of course, I'm telling you what we did on the Win16, Win32 and even Win64 (QT does the same, Android too - but in a highly abstracted way). Unity appears to be somewhat exoteric, as it appears. Here, on UbioZurWeldingLtd.cs, you can see the original author controlling states and creating "high level widgets" on the object to be reused. Follow all the references for the "_welder" attribute and you will see the guy "caching" some widgets. However, and you have a strong point that I didn't paid the due attention, there's a lot of calls to the methods you are complaining. Speaking frankly, this appears to be a memory bias from my side. =/

There's only one thing better than benchmarks for a old far... I mean... guy like me. Source code. :-) THANKS! :-) I choose to give a peek on a older version than 17.9, since you stated that already made the performance improvements, and I need to see the older way in order to understand what happened. So I gone for the 16.11 version, and this is what I saw: On SCANsettingsUI.cs, there's a function called DrawWindow, that does the heavy lifting of drawing .. the Window. There're a lot of gui_settings_<something> being called, where (obviously) the heavy lifting is being done. And here is where things gone... not the best way possible: The widgets are being created and thrown away every frame! I already had inferred this (really, I used to program C++ and Delphi for Windows 3, and GUIs hadn't changed at all since them, only their abstractions), but know I'm sure: this is not the best way to handle event driven GUIs. Event Driven code needs to control states. So, the window is in "uncreated" state at startup. When you need to show it, you change its state to "creating" and, when this state is completed, you change it to "visible". You can change the state to "hidden" (where it still exists and are being updated, but not drawn on screen) or you can "close" it, when then you delete everything and change the state back to "uncreated". So you need to write "state change handlers" (yes, this is essentially a FSM - Finite State Machine): you code one function to handle "creating", another one to handle "visible", one for "hidden" (if applicable) and one for "close". More complicated FSMs needs 3 handles for each state: phase_in, level and phase_out (this helps to keep the states number to a minimum, but it's not exactly necessary here). So, you just create the widgets in the "creating" handler. And from now on, you call the "visible" handler instead - where you just update what's already created and show it. This prevents the Garbage Collector from going havoc. I followed up the code, tracking what interface/abstract class the DrawWindow belongs, and got into SCAN_MBW.cs. It is called inside a function called DrawWindowInternal, that it's passed as a parameter (so it's a handler itself) on the DrawGUI, that it is itself another handler that the Visible attribute uses to put on the current window's draw queue. Interesting enough, the SCAN_MBW originally relied on SCAN_MBE to be called on the event changes. Even better, there's a DrawWindowPre and DrawWindowPost hooks for the phase in and phase out event handlers for what I called "Visible state", but in this code they were "short circuited" into the same event handler as the DrawWindow in the present implementation. Pheeew. This was almost a full-blown Window Management toolkit! :-) Something I will look on again for sure. The problem I see on this is that the event driven support from SCAN_MBE is not being used anymore, and another subsystem were "hammered" on it, overruling the previous life cycle. This new lifecycle is the one recreating the world on every frame instead of reusing what was created in the previous state (PHP style!). So, it's not a surprise your GC is going nuts. :-) While far from ideal in the present implementation (from the code style point of view), the UbioWeld (I'm also mangling it on my own fork) plugin does the right thing on this. Ideally, each Window should be implemented in his own class (that would prevent some mess while debugging the thing), but the way how things are done (controlling states, and just updating what's already created on a OnGUI call) is there.

Well... A bug is only a bug until it's fixed.... Or documented and promoted to a feature. :-) There's no choice but to wait and see what happens. =D

Perhaps it's not a bug, but a visual way to tell what's "up" and what's "down" on the part? These markers are purely aesthetic - or at least, I didn't found absolutely any difference by using different markers on my parts. But what I would like is a way to tell where is +Y and -Y on the part. Sometimes, I ended up rotating the parts while stacking them up, and then when I attach something on these parts, that part became 180º rotated and I need to rotate it back. While adjusting the CoL, it's usual to reattach the wings on an adjacent part, and this rotate and rotate again thing can be annoying and error prone. Without visual cues about what's +Y and -Y (as the part you screenshoot), you cannot prevent such errors before they bitting you, and perhaps this is the way the Add'On author found to solve this.

From my times on Windows 3 programming, I learnt that using Modal Windows (what PopupDialog is) to do Modeless Windows job is rarely a good idea. But, granted, things may had changed. This is the time in which one need to call for numbers using Benchmarks. :-) Calling drawing functions, by itself, is not a problem necessarily. But this discussion is going to the same places as the Stacking versus Composite GUI debacle: it depends essentially on the environment you are running them and how you are running them. It's better to find some time to do that benchmarking I mentioned before further talking about, otherwise I would be just exchanging opinions.

Yes, but the argument I'm counter-arguing is that it's useless. My argument is that learning it can worth the pain on the long run. I agree that OnGui is somewhat esoteric (believe me, I worked with "worse" things that worked better), but IMGUI has it uses - mainly, by using just code to handle things instead of creating GameObjects (and all the clutter) just for simple widgets on the Editor screen. What, well... Helps performance.

I beg to differ. From my times on Orbiter, we use to use GDI directly to draw 2D (essential for HUD and MFDs). Then O2016 came, changing everything, and absolutely all the plugins that draw 2D became useless. O2016 provides now a 2D API, that is not that pretty, but it's guaranteed to work in future versions (local or remote). If anything changes badly, we will bash our heads on the wall only once (to update that 2D API), and then everything works again. I think that keeping on OnGui will prevent such problem, mainly due Unity itself.

It's not exactly related to Garbage Collector, but it also hurts as memory is consumed: if you are a helpless Mac user, since El Captain you are forced to tolerate this abomination called Memory Compression (zram for the mobile users). Do you remember Ram Doubler, QRAM and other "ram doublers" on the Windows 3 era? Same thing. Same crap. Compressing memory before swapping it to disk is a nice idea, since the lesser time you spend on I/O is far worths the extra time spent on compression - but as an alternative for swapping, it hurts gaming. Badly. Take this in consideration when gaming on Mac and before hunting down what can be a Unicorn on your mod.

Hi. I found an interesting bug on JSI Advanced Transparent Pods on KSP 1.4.1 for Mac, running on a Mac Mini Mid 2011 & MacOS Sierra. When the camera is at one specific altitude, the Kerbin rendering became flawed, with some faces not rendered at all (see the picture below). I tested it on a plain vanilla KSP 1.4.1 installation, all in the default settings, on a plain new save in sandbox mode. Absolutely nothing changed, besides the plugin and the test craft (all stock parts). The KSP.log from the testing session is here. The Player.log is here, and the craft "source" is here. There's some in situ testing you need me to do? I'm the one with the offending machine, and this kind of error would be detected sooner if this would happen in anything but a exotic hardware configuration. :-)

It just happened. I'm trying to figure out what mod is causing a glitch on the Kerbin rendering from space that, oddly, just happens at a certain distance - and it's the reason I didn't noticed it before. Since I want to make a video for a challenge, this glitch became a showstopper and then I'm hunting it down. So I decided to move all GameData to a backup folder, and copy back a few mods gradually each time to trim down the culprit. Easy, just a bit time consuming. But I forgot to backup my save, the game deleted everything that was using a mod (and *everything* was using a mod), and now I loose the vessel I was going to use on the recording (and some stuff more). =P I'm feeling pretty stupid by now. =D

This is *waaaay* interesting! Time to twist some rules on some challenges...

There's no free lunch. You gain something, you loose something. I used to play Orbiter until recently. There're fabulous work done there. But writing mods to it is far from being for the faint of heart. C++ is not that easy, it's hard to debug and "exceptions" just crash the whole shebang instead of being logged into a file. :-) For *real* space simulation, I don't think anything will surpass Orbiter for a long time. But to having fun, both writing mods and playing (with or without mods), I think that KSP is still the thing. They're not mutually exclusive, however. We can play both (if we manage to find the time, obviously!)

[snip] Anyway, the developer's exodus are not just off-topic, but also covered by a thing called NDA, and believe me - you are even more wrong about this than you think. There's not a single chance that anyone, anywhere, would be transparent about this.Not on this case, not on any other case. Non Disclosure Agreements have this name for a reason. :-)

Au contraire, this time is the exact opposite. They said what they think was going to happen ("1.4.3 next week"), something change or gone wrong, and then we have a situation created exactly by the transparency you say is the way to go. Sometimes we forgot that people do what people do, and not all the people are like "us". I'm pretty confident that such transparency would work with you as much as it would work with me - but it didn't worked for a lot of people, and know the guys have another fire to put out. The "sweet spot" of communication level is somewhere "lower" than this, if we take in account what's happening on this thread. But, granted, somewhat higher than the usual practice. I think you're mistaking transparency with communication skills. Low transparency is actively hiding information. Low communication skills is failing to show that information effectively. These are two different problems that happens to have the same final result - but being different problems, they need different solutions. "Use the right tool to do the job right" Nops. No new depot on steamdb.

Sausages, laws and software: too much transparency and it will affect your stomach. :-) The "level of transparency" is not that bad - you can find the information (or infer it) with proper research and perception - and this appears to be the problem. I think the problem is on the Communication level - and this can be happening even inside the Team itself, and the communication problems with the customers is more an effect than a cause.

I saw the light, I mean, read again some PMI essays. :-D Developing KSP is a *PROGRAM*, not a *PROJECT*. Any attempt to handle KSP as a Project will fail.

IMHO stock is what everybody gets by buying the game. The DLC is a paid add-on. An "official" add-on, but yet, something added to the game after being drafted from the shelf.

Google for it. What happened at that time leaved a lot of scars around here, and it's probable that the moderation would intervene to prevent a flame war.