steve_v

Short answer: If they're NiCds, use a series resistor & basic ohms law. Longer answer: If they're NiCd or NiMH batteries, you don't really need to worry about the voltage, so long as it's greater than the charged voltage of the battteries. What matters is charge *current*, and not over-charging the cells. Ensure you stay below the maximum charge rate specification for the cells you are using, generally specified as a fraction of cell capacity in mAh. To charge NiCd & NiMH cells properly, you really need a delta-peak (voltage) or temperature sensor charging controller to detect when they're 'done'. Otherwise 'bad things' can happen, in the worst case - explosions, I kid you not. If they're NiCd cells (NOT NiMH) you can be really cheap, and just use a super low 'trickle' charge rate. Here's a cheat sheet I found on the 'net: looks about right to me. Lead-acid is easier, since cell voltage is fairly linear with charge state. All you really need is a constant voltage approx 1.5v higher than the nominal battery voltage, a reverse polarity diode and a charge rate within spec. I'm not sure what you're using this for, or whether weight is an issue, but using a 6v SLA battery will probably make life somewhat easier. Store bought solar car battery 'trickle' chargers really are as simple as a panel, a diode and a pair of alligator clips I used to charge 7.2v NiCd battery packs from a 12v auto battery - ammeter and a length of toaster element in series to limit the current to maximum charge rate spec. Full charge detection by holding hand on battery pack Not overly good for them, but it works.

You *could* use the debug menu to insta-complete the contracts, if it's not too cheaty for you. I had the same dilemma, ended up just sucking it up and starting over. Took it as an an opportunity to try a new mod mix too.

Agreed, something like: Basic flight suit (Big EVA warning like what you get trying to EVA in atmo) -> EVA suit (with safety tether) -> EVA mobility pack. I've introduced a few people to the game, and I keep hearing 'Wow, Kerbals have thruster packs? I didn't realise and just let him float away' Making it part of the tech tree would cure this too.

I've heard a few nice success stories re. BTRFS from the professional realm, the only thing that's really keeping me from using in a production environment it is that IIRC it still lacks RAID5/6-like functionality. Hence the liking for ZFS, despite the licensing concerns.

In the first instance, I'd try a clean install. Many parts have changed with this release. The +9,8% probably has something to do with multipliers from the new 'strategies' system. Is this an existing save? I've actually never had much luck with the patcher, usually zip up the previous version and download fresh. The Firespitter *plugin* works, if you grab the latest version. Dunno about the parts though.

Yeah, even the x64 build has been known to crash at the 32bit line, ~3.2GB. So although having 32GB RAM is nice, it won't help until Windows x64 KSP is more stable.

The whole redneck repurposed barn thing really 'aint doing much for me. While starting out small and simple makes sense, I don't really see the need to make it look so old and decrepit. I mean, 'cmon, these little guys have pretty up to date space suits and yet operate out of some abandoned farm? Low budget /= 'old car bodies and rusty scrap'. This. Once again, yeah.

Correct

You appear to be running the open source driver, which is now the recommended option. That said, have you tried AMDs proprietary 'catalyst' drivers? Last I checked they were buggy as hell, but still outperformed the Xorg / Gallium driver. I don't have an AMD card though, so will be of limited help. Note that this may not be an option if you've got Xorg >1.12, thanks AMD. @brian6712, I have one, it works fine without any special drivers. Debain Sid x86_64.

Ya know, that looks just like an IRQ conflict from the bad old days. It's a long shot, but have you tried messing with APIC / IRQ settings in BIOS?

The GNU/Linux build still loads / runs in the background, at least for me. I'm eating toast & posting this while the game loads I assume it's not supposed to, but this kind of breakage I like.

Ja, 'tis just getting a bit quieter now that 0.25 has been out for a while

I never really got the pint of exFAT TBH, I use ext2 or FAT32 for small disks, where the overhead of say, NTFS is a significant chunk of the capacity. NTFS for everything >16GB that neads to be readable by Windoze My larger storage arrays are all ZFS now. For anything else: ext4. Reiserfs can be a good choice for certain workloads, if you don't mind that the guy who wrote it is a bit of a creep. The only reason I'd use a non-journalled filesystem is, as above, on really small disks. Even then the potential for corruption if it gets pulled in the middle of a write makes me a bit leery, especially given my not so 'flash' experience with cheap USB disks. I would suggest ext2, but you'll need to install a driver... Filesystems are fun, I feel kinda sorry for those stuck with only 3 to choose from

I doubt it. I alt-tab out whenever I feel like it, with no ill effects whatsoever. (GNU/Linux x86_64) Even fancy window switching doesn't upset it: I'm pretty sure this 'don't alt-tab' mantra I keep hearing is a Windows thing... I don't know what window manager you're using though, so YMMV. TimeControl has an FPS counter, if that's what you're after. Many other handy things too. That said, I may have to have a play with glxosd, been looking for something like that for a while. EDIT: Yup, fonts are screwey for me too. (compiled from GIT, as not packaged for Debian) Been mucking about with this for a while now, got me stumped. Everything else I can find works fine with glxosd.

I too would be most interested in finding out what is causing this. I'll post here since I suspect that it's the same issue that's been bugging me for a while. I usualy play in GNU/Linux, but fired up a Windows install to check, it's there too. I'm getting a small 'hitch' or pause on a single frame with an otherwise good framerate (even at 120+FPS), most easily seen when rotating or panning the camera in editor or flight scene. With higher part counts in flight also causes the mission clock to flicker yellow. In flight, this appears to happen even when on rails / warp, though somewhat harder to spot. Logs are clean. AFAICT, it's happening all the time, higher part counts (or lower overall perfomance) simply make it more obvious. My stopwatch says every ~5 seconds, every second 'pause' (i.e. 10s) is slightly more noticeabe / longer. I'm not seeing a 1 second pause, more like 0.25s. Still enough to be really annoying. Stock or modded, 0.25 and 0.24.2, 32 and 64 bit. Plugin based mods exacerbate the problem, MechJeb being the biggest offender. Looking over the CPU-Performance-Database thread it would seem this is a common problem. Consensus points to GC. Any Idea what, if anything, can be done about it? I have tried to get some profiling going, but currently having issues building a working mono from unitys git repo (and finding time to muck with it). My complete lack of mono / C# knowledge is probably not helping, and if it's a unity issue this may not reveal anything anyway. Anyone else care to try?

Yes and no, while Unity is technically multi-threaded, the physics engine (where KSP does most of it's CPU intensive calculations) is not thread safe. Ergo, the bulk of the work is still limited to one core. This is as it has been, and will be unless major changes take place on the Unity3D side of things.

Generally not in one piece... Water is Evil, and EVA parachutes have saved many test pilots. There's something seriously fishy about Kerbins water, it seems unreasonably hard, not to mention devoid of fish IIRC firespitter has floatplane landing gear.

A small 'cosmetic' issue to report: Seems I'm missing a file: IsolatedStorageException: Could not find file "/home/steve/KSP_linux-0250-FAR/GameData/HaystackContinued/icons/button_vessel_spaceobject.png". Sure enough, no icon of that name in downloaded archive. Otherwise working fine

Kubuntu/KDE will run sweeet on that, so should KSP Been a long time KDE fan (since 1.0), shouldn't be a problem unless you're really short on RAM. IME, KDE is actually less resource hungry than the current Gnome-shell or Unity desktop. I run KSP in KDE with full desktop compositing glitz on, and regularly alt-tab out to do other stuff. No discernable performance hit, and your rig is faster than mine...

I certainly haven't noticed any observable speed difference between the Debian based distros, if you ignore the overgrown desktop cruft. The biggest issue with Debian stable is, IMHO, the somewhat outdated glibc - however this can be worked around, at your own risk.The forums.debian.net community will probably bite you if you install foreign software, muck with sources.list (without knowing what you're doing) or *mention* Ubuntu... I started out with zipslack 3.5 - on a 486 Slackware is actually a really good distro, and fairly up to date too. Provided you like things done the old school way, with minimal automation. You will however, need to learn Shell and get used to compiling things yourself I haven't touched anything Red Hat based since the GCC 2.96 / RH7 debacle, 'nuff said. For anyone wanting an _educational_ GNU/Linux project, I heartily recommend linuxfromscratch - not really a usable desktop distro and about the steepest learning curve out there, but you can make it into pretty much anything you want. Once you pick a distro 'family' eg. Debian based, Red Hat based, Arch based etc. it's pretty easy to get too used to the distro 'isms' and loose sight of the generic inner workings common to all GNU/Linux systems. Linuxfromscratch or Slackware will cure this - if you're willing to get your hands dirty

Firstly, do you have working OpenGL? output of: glxinfo | grep 'direct\ rendering\| renderer \|OpenGL\ vendor\ string'

Shamelessly nicking your graphic Camacha 'cause it's the truth.

IIRC, it's being set because the use of ',' as opposed to '.' as a decimal seperator in certain non-english locales causes some truly wierd behaviour in KSP - including silent save file corruption. As such, LC_NUMERIC would probably suffice no?

Because, for the billionth time *people do not listen*. It has been tried before. They do not listen when mod authors say "Do not report WinX64 bugs here" They do not listen when mod authors say "Re-enable at own risk, warranty void" If it's 'confusing a pile of people', it's because they *do not listen*, and do not read the OP before downloading. Is it so much to ask that people RTFM before complaining? This is not a case of 'disliking' x64, it's a case of getting fed up with dealing with irrelevant bugs outside the authors control and a constant stream of people who apparently cannot read.

Me wants bonus points - does it count if assembly is the *only* programming I've done for PC?