Lisias

Nuff said.... =P

I downloaded the last version form github, and got this too. 45 minutes before I just quit and decided to go without it until I have time to tweak =P with it. I'm using 1.4.1 MacOS. My log file, at the time I quit the loading, was *HUGE*. Really huge. I will reinstall it on my KSP before going to bed and let the thing run all night long and see what we get. /me 2. And I'm guessing this is the reason it's taking so long to load. Exceptions make heavy use of the stack, that need to be cleaned before the program goes one after handling the exception. In time, I'm using Module Manager 3.0.6 (latest from Sarbian's github). Is anyone with problems using a previous version? (a shoot in the dark, but... I would prefer not leaving the machine running all night!)

Anyone had tried using both original KerbinSide and the Remastered? I have some (internal) custom missions using the facilities from the original, and I would like to keep using them.

Bleh. I was hunting down a bug on KSP, messed up the GameData mods and allowed KSP to delete the crafts without realizing that I didn't made a backup (not to mention debugging the thingy on my "production" KSP, not the testing one). (mea stultitia, mea maxima stultitia...) Since 1.4.3 is now on the wild, i will see how it works and after upgrading everything here (or not), I'll rebuild the contraptions I did for this challenge and then publish them here. :-)

There's a one more little catch. prefixed and postfixed "++' and '--' has different colateral effects, and depending on what you are doing, it's better to use one or another. The postfix (i++) creates a temporary copy of the data (as it returns the previous value before incrementing). The prefix (++i) returns the data itself, as the previous value is irrelevant and there's no need to preserve it for using later. This is specially relevant when your objects overloads the "++" (assuming you follow the standard to the letter). So, [ for( int i = list.Count; i >= 0; --i) ] is even better.

If we are still talking about 1.4.2, it works on MacOS Sierra 10.12.6 perfectly. Oh, dear... This is not going to end well for me... =/

Too late. =P In some place on the Wiki (and I failed to find it in the short timeframe I have to see this forum now), there's an article explaining how to edit crafts and there is written that "you never have to drag something" - it's always a click to select, move, and another click to place. (I would love a drag feature, lots of acidental moves would be prevented....). This is due the buggy Unity API for User Interface. =P

The MacOS version of KSP is flawless. My machine hangs and restart before KSP have a chance of doing something buggy. I miss the times when MacOS updates were paid. They had to convince us to buy the thing, so the thing must works. Now? They shove new, terribly bugged new versions down our throats and nobody can do something about - except going for Linux or Windows instead. Listening, I mean, reading us.

Well.... I'm "trying" to do something similar using the corridor. Some extra "struts" are needed, however. :-)

I did. This kind of development is not viable anymore where I live (everything gone to Mexico, god damned local government), so I moved on. About KSP being not life critical, well.. It is for Squad. It's how they make their living. And besides nobody (except by Jebediah, but he's used to it) being killed by the bugs, people reacts somewhat as it does it - and customer's perception (and expectations) talk louder than facts on the Game industry! When people are being paid for using a Software (or take it for 'free'), the expectations and perceptions are somewhat... relaxed. But when people pay for the product (even by a few pennies), things change. And change a lot. I did a lot of Android development when I quit that business I mentioned. And it's one of the reasons for In-game advertising being somewhat a problem nowadays on Android - people that pays 1 or 2 bucks for the game are usually very vocal on the Store's Evaluation, while people that gets the game "for free" are a lot more... tolerating. (and I didn't even touched the personal time invested on the gaming, that it's something that people usually values even more than the money spent on the license) This is not web development. All you learnt about that business model doesn't works exactly as you is used to. People don't need to die to you be put out of business...

Please don't. People need to vent, and it's better to have them venting on one single place, where you can watch and manage the situation easier, than scattered over the forum. I understand that this can be annoying for some people, but my solution for this is simple: don't read this thread if you don't want to see what's on this thread. As a side note, I would only publish a launching date when the artifact to be launched is 100% ready for launching. Or just publish an announce with the launching and that's it. The vast majority of the KSP users are not software developers, and they don't cope well when something wrong happens and you can't fulfill a promise (what's essentially what a launching announce is: a promise).

Bug tracking is nice to control what's being done, and to find explanations/causes/whatever about what happened once it happened. But I would not rely on it for foreseeing the future. It can be done sometimes, but in the general it causes more trouble than anything. Another possible explanation is that someone finally found time to work on it. Another good one is that the guy that was handling it got sick and just came back (or vacancy, or whatever). Or the guy had already solved it, was reallocated to something urgent, and just came back to update what he did sometime ago. Or you are right and the thing is being prep for shipping. But please note that without inside information, your guess is so good as the others of mine. :-)

20 years of software development here. I did realtime programming for embedded devices for autos. If I ever made a huge little mistake as typing the decimal point in the wrong place, I could had killed someone. A friend of mine gone working for medical appliances. One of his colleagues made a little mistake on the FSM that handled the temperature of a incubator for premature babies, and a baby died. Welcome to the desert of the real. #matrixFeelings Your time on web development had given you a somewhat distorted view from the reality. You should not use a development model where the end user has everything for "free" (and the cash cow is fed by third parties) on a business model where the end user effectively *pays* for the software. Last time someone tried this stunt, we got Windows 95. =D (and God knows that was only the infinite deep pockets of Microsoft that saved their sorry backs - things just became really stable on Win98se, by the way - a little before they did it again with WinME! =D) On the other hand, perhaps I was too hasty on my last post, and that years on mission critical development gave me a harsher than needed view of the reality. My apologies - I will try to control my anxiety and avoid to answer things without reading it *twice* in the future.

EXACT. This is essentially KSP 2.0 now. Perhaps this is the strategic error they did: they handled what should be a major release as it was a mere minor one!

"Good customers complain. Bad customers just go away." :-) We can disagree in how we express our expectations and affections, but believe-me - we have an agreement on the expectations and affections.

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