steve_v

I'm having issues with parachutes during reentry too, FWIW. DRE (current), FAR (current git) nothing else that interferes with physics AFAIK. Skintemp reaches ~1500 and causes destruction long before deployment altitude. The pod itself is at reasonable temperatures, and has plenty of ablator remaining at this point. I can re-enter the pod intact fairly easily, but can't seem to find a placement that keeps the 'chutes cool, even with deliberate aerodynamic shielding. If the 'chutes are on the outside of the craft they explode, usually at 20-30KM. I've tried several entry angles (from ~100KM equatorial) ranging from 55KM down to -50KM pe with very limited success. I don't think it's a design issue as it's just a mk.1 pod with a realchute cone on the top stack node. It may be just my piloting, and I realize much has changed, but it sure wasn't this deadly in 0.90... Is something up or am I just being a wuss? --edit-- Nevermind. All working as expected now, having re-installed DRE & FAR, and culled some old local MM stuff. As you were.

Log file @ '~/.config/unity3d/Player.log', where '~' denotes the users home directory, and '.config' is a hidden folder therein. Use the whole path in a terminal - e.g. 'pastebinit -i ~/.config/unity3d/Player.log', or search for the 'show hidden files' option in your filemanager of choice. Leading '.' in the filename = hidden file. I make a symbolic link from my KSP directory for convenience, the default location is a pain.

FWIW, it's only the KW 'aero' parts directory, specifically the nosecones, that triggers this. I don't see anything particularly special about those parts though... Thanks for sorting out the 'deadly launch' issue Starwaster, 'twas a mite inconvenient, though technically not your fault

This pack contains a mk.2 drone nose. And here is a fueled mk.2 nose.

Likewise. I install it, encounter some variant of this bug, and un-install it again. I've reported it more than once too... and it's still there Cycle repeated every KSP release since .19. I'd love to actually play with this mod, but that bug is a showstopper for me.

I can't see any relevant MM patches in the archive anymore, so... probably? Turbojets are pretty lethal now, especially at low altitudes... the engine curves do feel a bit off to me, FWIW. Then again, more power was needed for the Mk.3 parts... So maybe it's a good thing. Definitely going faster than before, might try for Mach 5 before lighting the rockets next run. * Still needs work, flies like a brick subsonic I also note that the (rapier)engines don't flame out until ~33% Air Req Met - This intended behaviour?

Workaround not working here. May be worth noting that it's not the whole down position shape of the gear that's not updating, looks like just the bay door to me - either that or there's something invisible under the gear...

I'm having issues with the control surfaces / latest release. 1.1: 1.1.1: If I replace the elevons in the SPH I get both sides as on the left wing, but on launch they revert to the default sizes as on the right. Texture switching appears to be broken too.

IIRC, I escaped as quickly and quietly as possible... to organize *supplies* for the unsanctioned after function festivities. Others handled the misdirection of authority 'twas a good night, after the excruciatingly boring "main" event was out of the way Not that I'm encouraging such shenanigans, of course. Finding a 'date' was prearranged among a group of friends to get everyone a ticket, and generally dissolved as soon as we got through the door. Pro tip: For a truly priceless reaction, turn up with greasy coveralls over the formal wear... (and go with someone who can take a joke). I never really took this kind of thing seriously, always felt a bit too contrived to me.

Please, if you do this at least leave the source up - I can work a compiler (entry barrier anyone?)

Just stopped by to say thanks for keeping FAR alive, ferram4. The new stock aero is better than it was, but it's nowhere near as sweet as FAR. The current voxelAeroPort git build is working rather well here and once more, things are flying as they should Waiting patiently for a release... and tracking git closely to see what's in the works

Exactly, and I for one don't like where this is heading. I'm not trying for an OS holy war either, so here's my privacy angle: Computing privacy is inextricably linked to software freedom. GNU/Linux (or BSD) is better than Windows (or MacOS for that matter) because free software respects your freedom. That includes the freedom to not be spied upon or advertised at. GNU/Linux is just the current poster-child for the free software philosophy. My main beef with Microsoft, among others, is that it's part of the buisiness model to keep consumers from understanding the gadgets they buy, or modifying them to work as they actually want them to work. If you could fix the bugs yourself, why would you fork-out for the upgrade? Why must we all buy new gadgets every year, simply because we can't replace the parts that wear out or improve the code to do new things? If you bought the hardware you should be free to do whatever you want with it, without a by-your-leave from MS or anyone else, and without telling them where you buy your bog-roll. It's insidious - big technology companies are training a generation of people who have no idea how the devices they rely on actually work, and filling our homes with machines that work for the manufacturer more than they work for us. Information is power, every time you are forced to give away your information you are effectively paying to use your own equipment. Windows 10 sure ain't free if you pay in information, GNU/Linux is free because people want to be free, and enough of those people can code Free sharing of designs and code fosters innovation, and it's how this whole IT revolution got started in the first place. Far too many devices already come with remote-brick backdoors, restrictive DRM or built-in spyware. Microsoft has been doing it for years - only now they're telling you about it Even Ubuntu tried it, sort of - but it's open-source so the code got pulled by everyone who didn't like the idea. The rub is that you can't do that with a closed OS. Microsoft spying in a tech preview is small fry, and it's nothing new. But do you trust them to take that keylogger out for the release? How will you know if you can't see the code? Proprietary code everywhere means you will be assimilated. It means you must conform. I'm pretty sure this is not a good thing. It's the thin end of the wedge. The way is FOSS/GNU, and many hands make light work. Also several complete operating systems The work has already begun. If you have the skills, feel free to pitch in Been there, done that, bought the t-shirt. Edit: Yup, I thought as much. My local pizza delivery is trying to canvas fingerprint my browser. The internet is broken.

Ahh, but is it actually providing any benefit? anyone happen to know what's in those mystery patches? I've been running the release versions since forever, doesn't feel like I'm missing anything... but who's to say, I can't find any patch notes etc.

The closest I can see in the Linux Nvidia driver is "allow flipping", which makes no difference here

I wasn't aware of any incremental patches... correct me if I'm wrong. What does that '.705' actually add/fix?

Yeah, this ^. Windows has a serious case of 'clay feet'. This, combined with the ever expanding raft of extraneous 'features' layered on top, tends to make debugging anything on Windows a complete bear. The number of times I've wished for some good ol' console debugging output and instead got a (frozen) flashy animation or a cryptic 'error code'... Grrr. Microsoft's policy seems to be: Users are stupid. They won't notice or care about bugs, won't need to do anything too complicated... Just hide everything behind some shiny graphics, give them a few new toys and let the marketing department convince them that it's more productive. - What does windows 8 do that windows 2000 didn't, besides look nicer? Old, old bugs go un-fixed, consumer feedback goes unread, programmers and game developers wishlists are ignored. With each new release, new bugs are layered atop the old. If the users don't like the way the system works it's: "this is better/progress/the way things are, just learn how to use it". I expect my systems to adapt to me, not the other way around - perhaps I'm not a 'typical' user, whatever that is. I cringe every time I hear things like "Just re-boot it, it'll fix itself", "It probably crashed, just restart it" or "Windows needs to be re-installed when it gets slow..." Microsoft has everyone trained so well, most users simply accept that computers stop working from time to time; no explanation required. If one of my machines crashes, I expect to know why, and in great detail. I also expect to be able to fix it. Same goes for my car, fridge, home electrical system etc. I cringe more every time a (usually new) FOSS/GNU/Linux user says something like: "It broke/I broke it, so just re-install" - Don'tcha know you can actually fix that? I use FOSS everywhere I can. I can sometimes even make bugs get fixed, either by fixing them myself or by drawing them to the attention of developers who actually listen to the users - 'cause the developers are the users I find this far more satisfying than submitting reports to the "Microsoft Error Report" black-hole - at least I know I'm being heard, if not always taken seriously As for the whole privacy thing, I moved all my personal/sync data onto my own 'not-a-bloody-cloud' server (in my house) years ago. Facebook is just for OTR encrypted XMPP chat and my browser runs several anti tracking/data-mining plugins. I have also ripped out and rebuilt or replaced the OS on every computing device I own, so I'm reasonably confident nobody's mining my data or keylogging me. Windows 10 can be invasive or not, I won't be using it either way. It's not paranoia, I really have nothing to hide... I just loathe targeted advertising... And I like to learn how my gear works, in great detail, usually by dismantling it.

For orbital deliveries via spaceplane: dawn or just after is preferred, so as to have good light for both takeoff and landing - landing in the dark is... hard For new rockets anytime there's light is a bonus, so I can see what's going on, but for tried and trusted designs I really don't care.

Seems the Linux driver has no such option, and since I nuked my Windows install some time ago I can't exactly try this myself... Anyone else have positive results with this setting on Windows? - Not that I don't believe ya , but I'm not going to install Winblows just to try this out.

The full game (i.e. ksp-linux-0-90-0.zip) from the store. I have never seen any real use for the patcher, or the launcher for that matter. EDIT: The patcher appears to work fine for me, but it's a binary with no debugging symbols or source, so good luck figuring out where it's segfaulting... What packages did you install? On Debian/*Ubuntu the package 'ttf-mscorefonts-installer' from non-free/multiverse should pull all the fonts you need. The OP indicates only arial & arialbd are actually needed: make sure the system can see them with e.g. "fc-list | egrep -i 'arial.ttf|arialbd.ttf'" OTOH, mods 'n stuff may well need other MS fonts, so better off just installing the lot: Debian based systems: 'apt-get install ttf-mscorefonts-installer' Arch based systems: check the wiki.

If you run out of RAM / swap, the kernel will invoke the OOM killer. That code's pretty well sorted now, and it even makes a reasonable guess as to what to kill to free some RAM. IME running out of RAM just results in a horribly slow system for a few seconds, followed by the offending process vanishing I'ts a valid point though, how much system RAM do you have? FWIW, I have no swap space at all & it's never caused any lockups for me - even when I broke unitys' GC and KSP leaked to 10+GB...

Mkay, It's probably not all that helpfull (other ideas for isolating this appreciated) but AFAICT it's not my system. I have jumped through plenty of hoops with absolutely no improvement. CPU 'affinity' (via taskset / schedtool): no effect, regardless of core(s) selected. Process priority: minimal to no effect, even at 'realtime' priority. Background processes: no effect, even in a minimal environment with just enough to start a bare X session for KSP, no other services running. CPU scheduler: no effect, tested with BF, CFS, RR, FIFO. I/O scheduler: no effect, tested with BF, CFQ, NOOP, Deadline. HT/CStates/Speedstep: no effect. GPU scaling: no effect (GPU not heavily loaded anyway) even with GPU locked to max freq. Background I/O: no effect, issue persists even with entire KSP install loaded into a RAMdisk & nothing else running. <- Installed more RAM just to try this! GPU (nvidia-settings) configuration: I can't find anything that makes a lick of difference, expected as my GPU isn't working hard anyway. Mucked with Vsync, AA/AF, GL_YIELD Thread optimisation etc. It's the cause of most of my 'wrong part clicked' frustration in the VAB/SPH, and yeah, in flight this is obnoxious indeed. Anything else I can try here? Some built in performance / profiling tools would be more than a little handy, I'm not adverse to getting my hands dirty but there's just no way to see what's actually going on. I'm at a loss as to where to go next. I have tried recompiling mono to enable profiling, but it seems this only works with plugins - whatever is going on it's in KSP / Unity code and I can't see it.

Main reason I don't run 'buntu. Haven't tried Mint in ages, I tend to stick with mainline Debian these days and only install the bits I want, it's amazing how much fat one can trim off KDE

Ja, but there's no 64bit unity for OSX, therefore 64bit OSX is irrelevant for KSP. The elephant in the room is still the 32bit address space limit, since all textures are loaded into system RAM before VRAM even comes into the equation. As long as you have sufficient VRAM for the textures actually used in the most complex scene, plus some for shaders / AA etc. it'll run (but perfomance will suffer for all the texture swapping). I'm not sure what the true minimum is for KSP, but I'd be surprised if it's >128MB. Of course if you have a machine that can run OSX, it can also run GNU/Linux, so there's no real need for a separate box

Game: usually 40+mods, <5 crashes in the last 2 years. Pilot error / design flaw (counting pre-explosion reverts) ~1/8 launches. Poll: No idea, "master" is not an accolade I'd bestow upon myself, it's earned from others

What, some people don't like to dismantle and rebuild everything they own? I'm shocked. I'll admit I do take a perverse joy in making IT hardware do exactly what it wasn't designed to do