steve_v

I'll vote "don't care", since the models are spiffy. I'd be more excited if it was going to a multi-part assembly (intake | compressor/turbine | nozzle) - this would solve the mass offset issue (put most of the mass in the centre part) without having a hidden/clipped non-functional model, and would allow more realistic designs without nerfing VTOLs. Since the new bits are going to be hidden inside another (probably fuel tank) part, it does nothing for realism except penalising weird engine placement. It's purely aesthetic, but only when you don't want it.... if you're using it right you never even see it. What exactly is the point of this change again? Making the mass offset slightly less confusing? - why not fix it properly, and make jet engines work like actual jet engines? If they do get the turbine extension bit as described, please make it switchable so it doesn't bugger up ~80% of stock VTOL designs. If Squad ever gets around to sorting out performance, perhaps we can stop worrying so hard about part count... wouldn't that be nice.

CKAN is still buggering up my desktop (KDE) service registry: kbuildsycoca4(6188)/kdecore (services) KServicePrivate::init: The desktop entry file "/home/steve/.local/share/applications/ckan-handler.desktop" has Type= " Application" instead of "Application" or "Service" kbuildsycoca4(6188) KBuildServiceFactory::createEntry: Invalid Service : "/home/steve/.local/share/applications/ckan-handler.desktop" Deleting this file returns normal operation, but subsequent launches of ckan put it right back. This is interfering with normal operation of my DE (changes to default application / mimetype registry do not stick). No notification or "install handler Yes/No" dialog is presented, or ever has been to my knowledge. I do not see any way do disable this behaviour, in either the CLI or the GUI. How do I prevent CKAN from lousing up my desktop every time I start it? For reference, the freedesktop standard. The file ckan generates is incorrect, note the lack of whitespace between 'key=value' pairs in the official spec. Here's a .desktop file that works: [Desktop Entry] Encoding=UTF-8 Value=1.0 Type=Application Name=Pillars of Eternity GenericName=Pillars of Eternity Comment=Pillars of Eternity Icon=/home/steve/Games/Pillars of Eternity/support/icon.png Exec="/home/steve/Games/Pillars of Eternity/start.sh" "" Categories=Game; Path=/home/steve/Games/Pillars of Eternity And here's what ckan is generating: [Desktop Entry] Version = 1.0 Type = Application Exec = mono /home/steve/Games/KSP_linux-1004/ckan.exe gui %u Icon = ckan StartupNotify = true Terminal = false Categories = Utility MimeType = x-scheme-handler/ckan Name = CKAN Launcher Comment = Launch CKAN As you can see, it's full of 'key = value'. This breaks the KDE mime configuration parser and resets all file associations to defaults. I'll just leave this here and hope someone spots it, as I got no feedback whatsoever the last time I attempted to call attention to this irritating bug.

I have the Fractal Define R3 (the R4 is a minor upgrade, almost identical) It's a pretty nice case. I bought mine for the 8 3.5" internal bays, but it's also very quiet (even with dual Xeons in it, though I did have to fabricate brackets for socket 771)

I.e. Norton being stupid. This is nothing new, and hardly the fault of CKAN. I guarantee that there's plenty of other files on my machine Norton has never heard of, does that make them "BAD" too? True, but so would a non-stupid AV, since it's the AV causing the issue.

The '/usr/local/bin/mono: command not found' did tend to suggest that either mono was not installed, or it wasn't in /usr/local/bin. It certainly isn't in /usr/local on Debian... but I guess Ubuntu will be Ubuntu. - - - Updated - - - Argh, again too slow I am, nevermind.

Don't use sudo to launch ckan, that grants root privs and is a massive system security fubar. Fix the permissions instead. - In fact, don't use sudo / root unless you absolutely have to, for system administration tasks. I doubt that has anything to do with your problem though, as 'command not found' means exactly what it says. Is mono installed? Why are you specifying /usr/local/bin? is mono installed there? Installing mono should be as simple as 'apt-get install mono-complete', or whatever the mono virtual package is called in Mint. I doubt it installs to /usr/local, more likely the standard /usr prefix, and if so it'll be in your $PATH and can be called with 'mono ckan.exe' in the directory containing ckan. To execute a binary that is not in your $PATH (e.g. ckan.exe) you need to provide path - so the command line would be: 'me ~/Desktop $ ./ckan.exe' if ckan.exe is in the current working directory. This is functionally equivalent to 'mono ckan.exe', the file magic will work out that ckan.exe should be launched with mono. That won't help you if you don't have mono installed, see above. And yes, KSP is pretty awesome

CKAN is repeatedly buggering up my desktop (KDE) service registry: kbuildsycoca4(6188)/kdecore (services) KServicePrivate::init: The desktop entry file "/home/steve/.local/share/applications/ckan-handler.desktop" has Type= " Application" instead of "Application" or "Service" kbuildsycoca4(6188) KBuildServiceFactory::createEntry: Invalid Service : "/home/steve/.local/share/applications/ckan-handler.desktop" Deleting this file returns normal operation, but subsequent launches of ckan put it right back. This is interfering with normal operation of my DE (changes to default application / mimetype registry do not stick). No notification or "install handler Yes/No" dialog is presented, or ever has been to my knowledge. I do not see any way do disable this behaviour, in either the CLI or the GUI. How do I prevent CKAN from lousing up my desktop every time I start it? CKAN version v1.14.3-0-g652be65, updated via self updater.

Ahh, that... it's may be this known issue, no real solution for this one. Or it may be related to mouse polling rate, for which an answer may be found here. Yup, for some reason the 64 and 32 bit Nvidia libraries cannot be installed simultaneously on Ubuntu (not sure what gives, again no Ubuntu here) so the 32bit parts of steam fall back to mesa indirect rendering. It shouldn't affect the game itself though (assuming you have steam set to launch the 64bit KSP binary). The link mentioned in the error message offers some explanation. Methinks somebody needs to light a fire under Valve about a true 64bit steam client. - - - Updated - - - There are updated drivers here which *might* fix this. This may also be an issue with the steam runtime, though I thought that was fixed... does starting steam with 'STEAM_RUNTIME=0 steam' make that message go away? Otherwise, more help may be forthcoming on the Ubuntu forums / google...

'aptitude search ~invidia' I don't have a *buntu install to check on, but on Debian (upon which *buntu is based) the relevant bits are: i A libgl1-nvidia-glx - NVIDIA binary OpenGL libraries i A libgl1-nvidia-glx:i386 - NVIDIA binary OpenGL libraries obviously enough, the 'i386' package is the 32bit version of the driver library. I don't actually use steam either, if you already have KSP installed, can you start the KSP.x86_64 binary directly, without steam? Such things usually reside in '~/.steam/steam/SteamApps/common/<name of game>' - - - Updated - - - Hold that thought, I have an Xubuntu 14.04 VM around here somewhere... BBS. - - - Updated - - - Ok, try 'apt-get install libgl1-mesa-dri:i386 libgl1-mesa-glx:i386' How did you install steam? 'apt-get install steam' *should* pull those in automatically.

No such thing, 355.11 is an Nvidia proprietary driver version number and is most certainly not open source. AFAICT, it's also not a version packaged for Ubuntu, which leads to the all-important question...Where did you get it from? If you downloaded the .run file direct from Nvidia, don't. Use the package manager. The errors from steam indicate that it cannot find the driver, and attempted to fall back to software, 99% probable that this is because the driver is not correctly installed. 99% of the time that's because someone installed it wrong. Again, how did you install? The package manager will swap out (and blacklist) Nouveau automatically. I have no idea what Nvidias installer does, but it probably does it wrong.Check the output of: glxinfo | egrep 'direct | vendor'You should get something like: direct rendering: Yes server glx vendor string: NVIDIA Corporation client glx vendor string: NVIDIA Corporation OpenGL vendor string: NVIDIA CorporationAnything else and you have not installed the driver correctly. Assuming you have aptitude installed (apt-get install aptitude), what does: 'aptitude search ~invidia' output? For further troubleshooting: Check basic opengl functionality with eg. the 'glxgears' demo. Inspect (and post) output of 'dmesg', 'glxinfo' and the contents of '/var/log/Xorg.0.log' to see what's going wrong. Installing the Nvidia driver on Debian is as simple as 'apt-get install nvidia-driver nvidia-settings'. Ubuntu is just as easy, it even has a lazy clicky-thing. Did you read the instructions? Using the installer from Nvidias site or any other random location usually just breaks everything. If you say so, works fine for me.

Probably this bug. Community fix here.

If the unfinished mess that is Stardrive 1 is anything to go by, I doubt it. Extremely disappointed with the way that game turned out, the website still boasts promised features never implemented, and it appears that no attempt whatsoever was made to finish the story. Abandoned to the winds (and mods) as far as I can tell, I gave up on it ever being fixed some time ago. A real shame too, it had much promise. Felt very much screwed over, as I bought this before release only to see it abandoned in favour of v.2. Will not buy anything from this dev again. As for the MOO remake... Keen, but not getting hopes up yet.

Maybe, but not because of clock-speed alone - the i5 has better single-threaded performance, and this is all that matters for KSP at present. Again, maybe. Multithreading is supposedly improved, as is physics performance in general. But physics will most likely still be on a single core (per craft?). We'll have to wait and see, but I'm not overly optimistic.

Is this on Windows? (assuming yes as you compare to DirectX) I don't see a significant performance hit with 8xMSAA vs. no AA on Linux (GTX680). I have heard that Unity is slower in OpenGL, though again I have no frame of reference.

You may be right, this depends on the game engine. I would however need to install Windows to have a valid frame of reference for engine vs. driver AA comparison. This is something I really cannot be arsed doing right now (though maybe later, probably when Fallout 4 drops ) Driver AA is quite acceptable to me at this stage. All the same, in-game AA support with OpenGL would be nice, on any platform but Windows OpenGL is the only option. Hopefully this is fixed in U5. - - - Updated - - - I can certainly tell the difference between 4x and 8x MSAA (27" LCD @1080p), but it's a matter of taste and the improvement may not be worth the framerate/VRAM hit in some cases. Nvidia on Linux also offers SSAA & CSAA, or various combinations of, but although they work I have done no real image quality comparisons.

Driver AA works as expected, at least up to 8xMSAA. I haven't tried anything higher as this looks fine. I too cannot stand jaggies. If performance is an issue FXAA works too, though it's not as effective. Worth noting that if AA is forced in the driver AF must be too, otherwise things look... interesting.

So in the context of KSP with OpenGL on GNU/Linux: OpenGL works just fine, driver AA causes no problems.

Old, old bug. No fix besides quicksave -> exit game -> restart game -> load save. Sorry I can't be more helpfull, 'tis something that has been bugging me for a long time too.

What, lack of AA in the game engine is "OpenGL is less visually capable"? how is Unitys brokenness the fault of OpenGL? As for driver forced AA, again - data please. I've been using it for a long time, on both GNU/Linux and Windows - some game engines have a problem with it, some pretty much require it for decent AA. It's not like it's going to eat your cat for trying.

Always has been, it's just a shame that what was once the standard (and only) option is now a stupidly expensive enthusiast/gamer item.

I'm too lazy to load up your craft, but by the name I'm guessing Looking through the craft file, it has a claw on it... There are some long-standing (since it was introduced) issues with that part, including "stuck orbits" and exploding on timewarp. There are partial fixes in Claws Stock Bugfix Modules, might be worth a shot.

1: Better performance. 2: Fewer bugs. 3: Better memory management / on-demand texture loading. 4: Non-stupid contract / science system / meaningful career progression. 5: See #1

If you have an Nvidia card, forcing AA in nvidia-settings works just fine, can't comment on AMD though. I call BS, please provide data to back up that claim.- - - Updated - - - ~45. None at all. No - what's the error? almost all mods should be platform agnostic, there are very few exceptions and I doubt that is one of them as it packs no native code AFAIK. - - - Updated - - - I also run KAS, and have no such problem, so it's not Linux specific - sounds like installation issues to me.- - - Updated - - - FWIW, Linux is no silver bullet for running an insane number of mods, there's still a limit somewhere in unitys code - but you probably won't encounter it until you hit ~8GB.

There is absolutely no reason to do collision physics, or anything beyond relatively basic orbital calculations if the orbital path will not intersect any other objects. Why would there be?No thrust & no external forces besides gravity == no strange orbital perturbations. If this is happening on rails, it's pain mathematical error. If it's happening off-rails, it's still mathematical error, with more variables involved. Or we could just blame Unity some more.

Ooh, shiny This ought to to be extremely useful. - - - Updated - - - On second thoughts (and a little testing) it looks like this may need some work for 1.0.4 - either that or I'm not using it correctly. I can open a save, but I see only PARAMETERS and a bunch of SCENARIO subtrees, no flightstate / roster etc. Opening a saved craft file works as expected though. What am I missing here? (and what does the 'debug' option do? I see no change with it checked)