steve_v

Caps is considered shouting, no? And yes, I do see this issue, so I am playing mostly-stock until 1.2.1 is out. Options at the moment are to exercise restraint with part mods, or put up with the UI issues.

You could 'suck it and see', but if you want to get more technical on your RC filter design, I find this lazy tool most useful.

AFAIK It was not noticed during pre-release, likely because few large part packs were available at that time. Fixed in 1.2.1. Chill. Shouting about it won't speed up the release.

If you need .NET 3.5 target (and you probably do), you could install a mono 3.x snapshot with a source like: deb http://download.mono-project.com/repo/debian wheezy/snapshots 3.12/main deb http://download.mono-project.com/repo/debian 312-security main Seems to work for me, I just built FAR with it... mono-reference-assemblies-3.5 doesn't exist in the mono-project repo, where'd you get it? if it's a stock Ubuntu package I doubt it'll work properly with the (newer) mono-project packages. Note I run Debian, not Ubuntu... but they do say those packages are for Ubuntu too. Remove any distro packages first to avoid conflicts.

Assuming zero is zero on both sides, and the scale is linear, all you need is a resistor - in series for voltage to current, parallel for current to voltage. You only really need a converter/loop driver board if using a non 0-x scale, e.g. 4-20mA.

There are still issues (The part-count UI flicker is pretty annoying, the garbage-collection issue is not fixed, wheels are only semi-fixed, and it still crashes my WM in windowed mode), but I've encountered no seriously game-breaking problems like CTDs or randomly exploding craft... so far anyway. So my pitchfork is still racked... at least as regards the PC version. Consoles is another matter entirely, but they're still running the old "Hair on fire" version, plus extra special FTE bugs. Personally, I put it down to this^. Perhaps perversely, I was not at all pleased when the release date was announced. I thought "here we go again, all the remaining bugs will remain unfixed". But this release is not so bad, and this hat is sort of tasty.

I don't even own a console and I think this situation is totally unacceptable. I had the misfortune to try (to help someone with) the PS4 version in person, and yes, it's bad. Unplayable after the first few flights bad. Not good SQUAD, even if it's not really your fault (but who hired FTE?) it's still your logo on the loading screen and your rep on the line. In the interests of keeping your recent console customers, I too think a full refund or a free PC copy is in order... and I sure hope someone is lighting a large fire under FTE for this debacle. At the very least, post some indication as to when (if?) PS4 & XBox are getting a (working) patch, it's really starting to look like nobody at @SQUAD gives a fat rats behind about this situation (so long as they made some $$). Next plan: quick cash grab from unsuspecting Wii owners... I do hope this is not the case, but so far it's looking like it.

First, check for log exceptions/spam, then install memgraph and have a look at a: whether your pauses line up with the garbage collection runs, and b: just how huch heap is being allocated ("last" value). Performance tab is next to useless, AFAICT.

What about launching KSP in its own Xserver? Should dodge multi-head/fullscreen issues, and/or let you run a WM that can deal with Unitys misbehaviour without crashing. Note that, IME anyway, launching KSP without a WM (as suggested on Arch wiki) will likely result in no mouse focus... install some other window manager to use here.

Bug #11382?

IIRC, you could also ctrl-click to select multiple items in the staging stack to move... this also appears to be broken. Time to file a bug report...

Again, our construction methods differ - I use both V-snap and H-snap all the time... When I want something centred, I mean centred, not whatever the closest offset gizmo step is .

Yeah, this has changed, used to be my preferred asparagus & staged booster construction method. It's not just decouplers either - since 1.2 I can't split any staging stack, and it's pretty annoying TBH. Also running GNU/Linux, FWIW. And then (assuming no EditorExtensions) spend ages trying to get all the pairs aligned vertically. Very clunky.

A dev build that runs on 1.2 already is.

Yeah, it's broken for me too (Mozilla/5.0 (X11; Linux x86_64; rv:45.0)). Nobody I'd suggest pinging is online ATM (probably midnight in Mexico or somesuch), you guys have already submitted this via the kerbalspaceprogram.com bug report form, right?

That means I have to sign up for (and figure out how to use) that newfangled github thing, right? Consider this a solid "when I get around to doing that, and the other things".

In case it's of interest to anyone, here's a quick & dirty bash-completion function for pyKAN. Trivial, but it makes my life easier anyway. #!/bin/bash _pyKANComOpt() { local cur prev words cword _init_completion || return opts="-h --kspdir --debug --key --value \ --repo --allsettings --allmods --search \ --allversions --installed --upgradeable \ --module --version --reccomends --suggests" cmds="install addkspdir listkspdirs show_settings \ show delkspdir list_repos default_ksp \ add_repo del_repo update upgrade \ uninstall change_setting list_modules" case $prev in --module) COMPREPLY=( $(compgen -W "$(./pyKAN list_modules | cut -d' ' -f1)" $cur) ) return 0 ;; --kspdir) _filedir return 0 ;; --suggests|--reccomends) COMPREPLY=( $(compgen -W "ask yes no" -- $cur) ) return 0 ;; esac case $cur in -*) COMPREPLY=( $(compgen -W "${opts}" -- $cur) ) return 0 ;; *) COMPREPLY=( $(compgen -W "${cmds} ${opts}" $cur) ) return 0 ;; esac return 0 } && complete -F _pyKANComOpt -o filenames pyKAN Needs bash-completion, and bash, obviously. On the whole packaging for the masses thing... I kinda like it the way it is TBH, and I much prefer loose python scripts to a .NET binary blob. The error messages re. missing deps are pretty obvious, took me all of 5 seconds to install them. Really not sure what the big deal is here? Again, much thanks for a CKAN client that doesn't constantly get in my way...

Even if you clean out GameData, there are many mods that add persistent data to the save and many more that change or add modules to stock parts - these 'tainted' parts remain on any craft in the save. So I'd say "stock" == clean GameData + fresh save file. Doesn't mean saves from modded games are completely useless, but you'll almost certinly be asked to repro any issues in a new save. Testing with a clean save in a clean environment is kinda step one for bug reporting anyway.

Nothing in that log I would expect to stop the game loading, but LaserDist isn't working (probable reference to KSPUtil, which no longer exists): ADDON BINDER: Cannot resolve assembly: KSPUtil, Culture=neutral, PublicKeyToken=null ... AssemblyLoader: Exception loading 'LaserDist': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. And the last thing loaded is a flag from KW Rocketry: Load(Texture): KWRocketry/Flags/KWFlag02 I'd start by removing those two mods, but since there's no smoking gun in the log, the general procedure for this kind of thing is to make a copy of the game and add/remove mods from it until you can isolate the culprit. Ckan makes it far too easy to install 30+ mods all at once... then you have to go back through them one at a time to figure out which one broke the game.

Wow, didn't expect this to be such a popular bug. RL interfered with my planned testing, but I've been well and truly ninjad anyway so I'll leave it alone. Here's hoping Roverdude can come up with something, since he seems to have taken an interest...

But I got distracted going through my old windows games... which developed into going through my older DOS games... then patching dosbox to support openglide... and patching openglide to support Carmageddon. Which is what I am playing right now. Grim Dawn will keep for later.

Wine = Win

Have one, but it's probably broken as usual, been literally years since I booted the thing. Also have too much stuff always running / most of my files on NFS server / old and deep-seated loathing for Windows. More importantly have "no Linux port == no purchase" rule. Might not-buy it and see if it runs in wine though.

Sigh, another awesome-looking game with no GNU/Linux support. Oh well.

On the topic of performance... I was hoping to load this up in 1.2, but it absolutely murders my framerate. Even without Scatterer & DisantObject (StockVisualEnhancements and EnvironmentalVisualEnhancements directories only, LowRes). I go from 60+FPS (EVE) -> ~28FPS (SVE). It's not throwing any exceptions either, though I can drop logs if you wish. Whatcha doing that standard EVE doesn't? Debian GNU/Linux 8.6, GTX680 (Nvidia 352.79), I7-3820, 32GB. Do I need a Cray to run this thing or what?