Lisias

He's talking about this. When this happened to me, it took so much time to detect that I got sympathized with the fellow Kerbal and made this image to make it clear. :-) Essentially, my elevons became airbrakes! :-D On the bright side, when having a odd number of surfaces on my wings, I usually make two of them as airbrakes (attaching the deploy to the brake action, and reversing the deploy of one of them) and save two parts (symmetrical airbrakes) on my designs. I had to learn something from this stunt! ;-) In time, @Val, since the CoM usually moves as the fuel is consumed, would be more appropriate to make the elevons shift functions based on the CoL? This would make things a bit more realistic - and logical, as the rotation pivot is the CoL...

1.4.3 is a bit more memory hungry. I don't know exactly what was changed, but I have the feeling that they trimmed somehow the Garbage Collector to be less intrusive (by being less active). This, and the nasty habit from Unity of never giving memory back to the system, can be a hindrance to gameplay on smaller memory systems.

What's the difference between merging an craft into the current editing one, or merging a subassembly? There's some difference on the internal data structures if I choose one or another?

Don't make it as a vessel, make it an "asteroid" or even a "planet" :-)

Building a full scaled Rama will be a hell of a challenge, even scaling it down to Kerbals! o.O

Check if the airplane's root part is not rotated 180°... It's a wild guess, but it's the only thing that came to my mind.

You probably removed a dependency. Did you had installed the "ComunityResourcePack"? IIRC, LqdHydrogen is defined there.

Him. :-)

I have a feature request. I usually play KSP on a window - or I'm editing some post on the forum, or some code no MonoDevelop, or just messing around while something loads (usually a webradio). And I found some widgets from the U.I. somewhat bigger than it should. How about using the U.I. size slide value from the KSP Settings to resize the buttons? This is doable with IMGUI? (I know this is not a full blown GUI api). In the following screen shot, the top left buttons and the bottom right buttons ideally should be in the same size (and the whole shebang resizable by Settings/"UI Scale" or perhaps Settings/"Apps Scale"). I'm loosing some useful space on the right panel. The Description Edit Dialog sometimes wraps below the window, and I can't hit the OK or the Cancel button unless I delete some lines. A way to drag the thing around (as we can do with long KSP-AVC reports at startup) would also be of great help. To be honest, this "issue" is far more annoying to me than the previous...

I have to remember that at least some projects effectively use the issue tracking! EDIT: I passed through the issues, and this appears to be related but exactly equal. On "my" issue, the vessel falls as a rock. They are not being gently placed on the ground, they are on free fall being accelerated by G.

It also helps if the landing gears are exactly where the CoL (the blue thingy) is (or a bit further to the back) When the gears are in front of the CoL, it's a slightly harder to raise the craft's nose, so you need a bit more speed to compensate the drag imposed by the control surfaces. With the gears at (or slightly) behind the CoL, the nose raises easier as you get lift, so the surfaces work a little less, cause a bit less drag, and you take off with a bit less speed.

Not with the framerate I'm getting from this expensive potato computer I call a Mac. =P

Brainstorming mode on. :-) In order to accomplish that, we need inertia and friction being accounted on each kerbal "on the wild", and not only on the focused (being controlled) one. We would need, also, a better dragging model - so kerbals inside a hull would not be thrown into the vessel's tail even when the vessel's acceleration is zero. Videos and some personal tests suggest that these requirements can not be fulfilled by the present engine. So... We will need to try that "on the Kerbal way": brute force. :-) One (possible?) solution would be a Part that, once attached to a vessel, would keep track of all Kerbals on the vessel and, once any of them does "EVA", would check them if they are inside a "walking zone" (distance from the nearest part? inside the collision meshes?), and automatically apply to them the same attitude and position changes that the vessel suffers. A focused Kerbal would have to apply his own changes on top of the automatic ones. This essentially would simulate a Local Frame of Reference for each Kerbal (being that frame the vessel itself). Long shot, wild guess - I don't know enough to tell if that thing is viable or not.

Well... I have good news and bad news. =/ The good news is that in the above link, there's a UNOFFICIAL pre-release of the last available AirPark version compiled for KSP 1.4.1 (and tested on it). And it works. The bad news is that there's a small glitch on it that renders the thing unusable. When switching vessels (or EVA), the thing auto-unparks and even by going back you can't do nothing as the part still thinks she's parked and don't allow you to park it again. I uploaded this unofficial pre-release in the case that anyone wants to test it with me in order to pursue a fix. What leads me to question @gomker about his/her plans for the plugin - do you still plan to maintain it? If yes, assuming I manage to fix it, do you want me to open an issue on your repo and later apply a pull request?

Restarting the computer to fix things was plain unthinkable on Mavericks time and before. Apple had gone through the tubes. Epically. Would Bill Gates be Apple's CEO, and the transition to the Microsoft Way would be complete.

Well, I got a bit jealous =P of the @simast idea and decided to try my own version of that interesting Bi-Coupler based plane. :-) First things first, I did a "reverse engineering" =P of the thing. But I had some difficulties on building a stable craft with the parts I'm using (J85 is underpowered with AJE installed, more powerful engines are heavier and I didn't wanted to add more engines to this little hull; control surfaces not matching the CoM for correct functionality; CoM and CoL far from optimal aligment, etc), and when I finally got something in the air that could land and fly again, I realized that I ended making... The Bat. :-) https://kerbalx.com/Lisias/Bat-Mk1 WARNING: This thing doesn't recovers from flat spins!

I once put a tape on the mouse's optical window from a colleague. That would be funny, except that my boss had bought a identical mouse, he sits on the side of the intended victim and I don't have to explain why I paid for my boss' beer for a month. =P

so, you will not throw gas into the fire by talking about indicated airspeed and true airspeed? :-) I once saw on the news about an unfortunate (and somewhat dumb) ultralight aeroplane pilot flying "backwards" while trying to come back to land from flying over the seas. At the of the day, the sea is warmer than ground, and then winds blow from land to sea. If you have a underpowered vessel (and most ultralights do), you can end up without enough power to overcome the wind and being pushed back to the seas. While flying. IIRC the lucky <piiiiii> had take off with full tanks (what's not much on these aircrafts) and barely managed to land on the shores. If memory serves, he climbed the most he could in circles, then gone for the beach nosediving.

Lobo? It's you?

If you have to use parachutes, you would not be able to takeoff anyway...

Another issue for "hints while strutting" series: do not strut into the flight deck! It can't take the load without being strutted itself into something else, what is a problem due the way it snaps into its place. :-) Seriously. Save yourselves some pain while strutting. This kind of thing is harsh to detect. =P

I'm writing some quick&dirty tricks for building blimps, but some issues on my rig and KSP made me spend some days debugging. Now the issues are solved, and I'm "back to business". I opened Paintbrush to edit the screenshots, and then KSP crashed again under my nose! It took me some serious minutes clicking on the report button until I realize that I was trying to click on a Crash Report SCREENSHOT, that I had edited on Paintbrush yesterday and was auto-opened. =P #sigh Well, back to business after a break for some coffee.

I stumped on something that it's an issue, but not necessarily a bug - at least, not a fixable bug - so it would be a feature in disguise. :-) There're some moments that by switching modes (default key '5'), you loose the ability to move the camera in both modes (stock and WASD). The camera became stuck, and the only thing that works is looking around. It appears to happen when you switch modes while moving a part (or an AES strut connector). The solution, once this happens, is to save the craft, exit to KSC and then go back and reload the craft. Just hitting "New Craft" is not enough, you must exit the Editor and come back. This "feature" =P works both in SPH and VAB.

Being one of them taking the risk of seeing the subcontractor selling similar parts (as the very same would be probably forbidden by contract), cheaper (as he's fighting for incoming) for your adversaries, allowing them to better compete with you and eroding your chances of retaking the market in the next period when things get better. You can't have the pie and eat it too. In order to mitigate some risks, you need to take others: "Choose your poison" - literally.

This one is interesting. Appears to exist a memory leak somewhere on Unity that consistently crashes my machine if I leave KSP running by it's own by the night. Reproducing this is easy: turn off your computer energy saving (so it doesn't sleep before the crash), fire up KSP and leave the machine alone by the night. I didn't measured the time it needs to crash, but it's less than 7 hours. ;-) The interesting part is that, by all means, the crash report is essentially the same as when you overrun your VRAM. It's essentially equal, except by the physical addresses of the routines and process specifics data. So, I'm guessing the memory leak is on the VRAM memory management. Since the crash report is virtually identical to the previous, I'm quoting a snip from the Player.log from Unity: Native stacktrace: 0 libsystem_kernel.dylib 0x00007fffc5640d42 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fffc55a6420 abort + 129 2 libGPUSupport.dylib 0x00007fffbd9c4c05 gpusKillClient + 83 3 AppleIntelHD3000GraphicsGLDriver 0x000000010e002e0e _ZN13GhalInterface16getCommandBufferEPPhS1_PjS2_ + 158 4 AppleIntelHD3000GraphicsGLDriver 0x000000010e01eeb1 _ZN6GHAL3D24CPrivateCommandTransport18FlushCommandBufferENS_10FLUSH_TYPEEh + 273 5 AppleIntelHD3000GraphicsGLDriver 0x000000010e01ec52 g575SubmitPacketsToken + 69 6 AppleIntelHD3000GraphicsGLDriver 0x000000010e2703ea glrBindContextDrawFramebuffer + 2369 7 libGPUSupport.dylib 0x00007fffbd9c7a3f gldUpdateDrawFramebuffer + 117 8 GLEngine 0x00007fffb4c05e02 gleUpdateDrawFramebufferState + 560 9 GLEngine 0x00007fffb4b164cb glSwap_Exec + 59 10 OpenGL 0x00007fffb4af8126 CGLFlushDrawable + 66 11 gameoverlayrenderer.dylib 0x0000000101f4e702 _Z21SteamCGLFlushDrawableP17_CGLContextObject + 33 12 KSP 0x0000000100f4737a _Z16PresentContextGL12ObjectHandleI19GraphicsContext_TagPvE + 90 13 KSP 0x0000000100f62edf _ZN13GfxDeviceGLES12PresentFrameEv + 111 14 KSP 0x00000001006b8282 _ZN15GfxDeviceWorker10RunCommandER20ThreadedStreamBuffer + 36242 15 KSP 0x0000000100d9fccc GfxDeviceWorkerAutoreleasePoolProxy + 60 16 KSP 0x00000001006b8fa4 _ZN15GfxDeviceWorker3RunEv + 116 17 KSP 0x00000001006af44c _ZN15GfxDeviceWorker18RunGfxDeviceWorkerEPv + 60 18 KSP 0x0000000100bee2ba _ZN6Thread16RunThreadWrapperEPv + 90 19 libsystem_pthread.dylib 0x00007fffc572b93b _pthread_body + 180 20 libsystem_pthread.dylib 0x00007fffc572b887 _pthread_body + 0 21 libsystem_pthread.dylib 0x00007fffc572b08d thread_start + 13 Debug info from gdb: ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= pid 61509 != 57908, skipping destruction (fork without exec?) But I don't claim any significance (yet), as I dumbly didn't saved the Player.log from the VRAM crashings. I will revisit this next time it happens.