steve_v

Well, to be fair, *nix had a CLI before DOS was around (early 1970s)... hence the reference to typewriters in the 'TTY' wikipedia link. So while Linux indeed 'inherited' it, it wasn't from DOS. Cool trick, one I did not know about. I tend to use 'pastebinit', but yours works wherever there is netcat.

This is not a chipset, try 'lspci' to get the exact model and ask Google about the state of support. IME, all SiS GPUs are rubbish and support is somewhat flaky, but you might get lucky. The GUI interface is your/your distros choice of Desktop Environment (Unity/Gnome/KDE etc.) running on top of the X window system, which in turn runs on GNU/Linux. When I say 'X' that's what I'm referring to. CLI = Command Line Interface / console / terminal / VT / TTY. Switch to/between them with Ctrl-Alt-F1 through F12, how many are enabled depends on the distro. X will be running in one of these TTYs, usually #7 or 8. A CLI is also what you get when you louse up X configuration , and it's the best place to be when debugging the GUI Short version: corruption only in the GUI, CLI ok? If so, then the problem is the sis driver shipped with X, and you have a functional CLI to fix it from. Unlike Windows where drivers are provided by the hardware manufacturer, all Linux drivers are included in the kernel (all open-source drivers anyway, a few exceptions exist) Ergo, the livecd/usb has drivers included. Comes with X, on Debian derivatives it's in the 'xserver-xorg-video-vesa' package, and usually installed by default. You will have to enable it in /etc/X11/xorg.conf though, something like: Section "Device" Identifier "Name" Driver "vesa" EndSection Note this is from memory, see 'man xorg.conf' for the full manual or search the web for examples. Many modern distros don't have this file at all, relying on autodetection - a somewhat sane template (in which you would just need to change the "Driver" line) can be generated by running 'xorg -configure' from the CLI. Looks like the sis driver was removed from Debian some time ago for being horribly broken and unmaintained. It appears that Arch is still shipping it in some form though. Post xorg logs so I can see what driver you're actually running - it might be falling back to VESA already. As long as it's not something properly obscure, this may be easier than fighting the old buggy SiS driver... bung it in and check 'lspci' output to find out what it is. Cool, it's not a fatal error anyway, probably trying to set some features the disk or hba doesn't support. Should be safe to ignore. ---- If you upload/pastebin the Xorg log and lspci output then there'll be less guessing.

This effect is not unknown in other fields of endeavour, though the name varies.

Yeah, hardware specs needed - particularly GPU. My guess is this machine includes an ancient and slightly unusual graphics adapter. I assume the graphical corruption only occurs in X, not at the CLI? Up the contents of /var/log/Xorg.0.log and the output of 'lspci' so we can see what hardware you have and what driver it's loading. IIRC, there are issues with the current driver (or lack thereof) for older SiS video - the mention of sis630_smbus makes me suspect SiS motherboard chipset, so perhaps SiS video too? All those distros likely use the same X release, so the same GPU driver with the same problems. It may be worth trying the generic VESA driver, you won't get any acceleration but it should work with anything. OTOH, if it'll take a cheap AGP/PCI graphics card (and you have a junk-box containing such items), this could be an excuse for installing something better. The sis630_smbus not detected warning isn't a problem AFAICT, blacklist the driver if the message bothers you. The ata SET_FEATURES error is probably due to the (I assume) use of a PATA to SATA adapter... is this drive otherwise working?

Um, no. The current (4.5) spec was released in August 2014, and until everyone switches to Vulkan, OpenGL will continue to be the standard (and only) graphics API on any non-microsoft operating system. Every GPU in existence (if manufactured after ~1998) is supposed to support it. That said, Unity3d + OpenGL on Windows is unofficial/unsupported, so YMMV.

Well, going by posts elsewhere on this forum, some consider ~20FPS "great" performance. Excuse my ignorance (or the fragmentary information from Squad), but has stable Win64 actually been confirmed for 1.1? What about on OSX?

No, I'm complaining about the performance of the current release, and asking how much improvement 1.1 will bring. An announcement along the lines of "1.1 coming soonTM, with X% better performance <insert pretty benchmark graphs here>" is going to perk up my ears far more than any variation of "we're adding cool new feature/part Y <promo pics here>" Particularly as mods already add much the same (or better) content.

True, but an OCd part or one from a different manufacturer is not identical hardware. Again: this is why detailed hardware specifications accompany any real benchmark. Given that KSPs performance issues are almost entirely CPU performance issues, and overclocking is an obvious, easily eliminated skew, there's no real reason not to produce a controlled benchmark. CPUs of the same make-and-model, at the same clock, with the same microcode will perform close enough for our purposes. All you have to say is: We tested on <detailed hardware/software spec> at <settings>, and include the error margin from multiple runs. It won't be exact across different manufacturers, and possibly even firmware/microcode revisions... but if you specify these in the test environment there's no confusion and no false expectations. It's really not that hard, there are many websites devoted to such testing, and by-and-large results do correlate. I don't expect Squad to use remotely the same hardware that I have or spend time testing on 50 different configurations, so I'll never anticipate exactly the same numbers. It'd still provide a useful delta, and even a not-directly-comparable benchmark is better than no data at all - especially if the 1.1 improvement is as large as some are speculating. Erm, really? I've yet to see anyone OC a HDD... source? --- Since we're so fond of sample-size-of-one evidence here, I'll add some more: A couple of years ago, I benchmarked DooM3 on two systems I was building from spare bits. Both had Q6600s and 8800GTs - different OEMs for both motherboard and GPU (same clock though)... I got an average of 2 FPS difference - this is well within the error margin of repeated tests on the same machine.

If the FAR analysis windows are blank, this sounds a little suspicious. But as the saying goes: Pics (and logs) or it didn't happen. Unless you can show clear evidence of a bug, reproduce it with a minimal mod setup and include all the relevant info, everyone is going to assume design issues and direct you to the craft repo thread. Claiming "bug" or "not intended behaviour" without the info needed to diagnose just wastes time. Listen to tetryds & kcs123, much knowledge they have .

So identical hardware isn't identical... Horses***. This is the kind of excuse I regularly hear from those who have no idea how the things work. Computers are not magical, they perform to well understood metrics, traceable right back to the underlying physics. Yes, there's a lot of variation in PC configurations, but the same code executing on the same hardware will perform near enough to exactly the same. Otherwise any benchmark would be worthless. All one needs to do to avoid this confusion is release the specs of the test system, it's a critical requirement of any useful benchmark. Then don't present anecdotes as evidence. Hint: FO4 has lots of knobs, and can be configured to run reasonably well on hardware well below spec. KSP has none that have any worthwhile effect on the obvious CPU bottleneck. LOL. surely you've been around here long enough to know better than that. I's been getting steadily worse for some time.

It feels like I've been watching this exact scenario playing out with each new release - more and more CPU intensive features added atop an engine that clearly cannot handle even the base game at reasonable performance levels. Adding mods to this "extremely moddable" game only compounds the issue. In this day-and-age I expect release-quality games to have release-quality performance. Every other game I have runs just great, including shiny new titles like FO4 - I get consistent v-sync 60FPS on at least "high" settings. I'll take a graphical fidelity hit or turn off features to achieve smooth FPS if I have to, I'll even buy new hardware if that's what it takes. My problem with KSP is that there is exactly nothing the player can do to improve performance of the lousy physics engine - the game chugs along at miserable FPS while my GPU twiddles it's thumbs and 3/4 of my CPU goes idle. I am well aware of the reasons for this, but after several years hearing them I am through listening to the lame "unity limitation" excuses. Someone brings up the well-known stutter, and the response we get is "better things to do" / "new features = more meaningful improvement". I don't care if it pushes back the release or puts new features on the back-burner, Fix. Performance. Seems the powers that be are keeping very quiet on what kind of performance improvement we can expect from 1.1, and details on how effectively the new PhysX is multithreaded are hard to come by. This does not inspire optimism. How about some benchmarks to show off the improvements? It'd go a long way towards allaying my concerns. Surely someone has done such testing internally before making the vague "better performance" claims I have encountered, show me the numbers so I can stop complaining.

Interesting, has this changed recently? I'm not sure about the current state of affairs, but in previous versions this was not entirely true... I certainly abused these contracts a bit - build a new vessel (meeting "new", "power", "docking port" etc. criteria, then dock to existing station to get the "crew capacity" bit. Worked at some point (most of my "stations" were actually spaceplanes ), but I dunno if it still does.

There's an FPS graph in the debug (mod+F12) toolbar. For the rest, I agree with your observations, but I don't know the code well enough to explain why.

FWIW, the FAR craft repository may also offer some design inspiration. As for mods, I'd be vaguely suspicious of fuel wings - mainly because it messes with wings (and I've never used it ) The others you mention: no conflicts that I know of, working fine here. I'm inclined to agree with Streetwind in that it's probably a gear placement issue, but pics of the craft in question would help.

Yeah, this. Particularly when attached to that tail-connector part, they'll have a slight toe-out. Wheels in KSP (currently) don't really behave much like wheels... even a slight out-of-true causes very strange things to happen. You may have better results attaching the rear gears to the straight fuselage, then offsetting them back to where they need to be.

Delete the both ckan.exe and the 'CKAN' directory.

Indeed, too often I find myself greping the the part .cfgs just to figure out where a particular item is in the tech tree.

Good call on dropping the stock RT thing, suggest you focus on performance and bugfixes instead. No new features == no worries... so long as we do get 64bit for Windows and performance back up to pre-1.0 levels - at the very least. Honestly, I have zero interest in any Shiny New S*** until the pervasive performance issues are sorted. I've been waiting literally years for respectable performance, bring on 1.1... the release where the game starts to perform like a professional product rather than a tech-demo, and the "engine" bugs we all know and hate actually get fixed... Or not. If we still get GC stutter and single-digit framerates after 1.1 I will most likely be ditching this game for good.

Nothing, as far as I am aware. Define "fancy". FAR makes craft that look like aircraft fly like aircraft... If yours doesn't look remotely like a plane it probably won't fly very well. Dunno, you didn't mention which other mods you are running. Sounds to me like a: you have too little lift, or b: some other mod is messing with FAR. For the former: Pics. For the latter: full mod list, repro steps and logs. If you're willing to produce a proper bug report, you might try posting it over in the FAR thread. Ferram4 is pretty quick in squashing actual bugs, but you will have to provide sufficient information.

Very nice ... but the ability to dock back to the winged section for re-entry is kinda the point, If I can't land the whole shebang back on the runway in one piece I'll just use a rocket.

Fair enough, If you don't enjoy piloting you probably won't enjoy spaceplanes - I'm not aware of a mod that'll fly them for you. (MJ can land them, but that removes half the challenge IMO - my landings are a bit hit-and-miss) There's certainly engineering involved though, I can slap a working rocket together in ten minutes or so, but designing an SSTO spaceplane takes rather longer. I enjoy the design challenge almost as much as the flight. Well... yeah. What you get for all the hassle is dirt-cheap flights to LKO. Anything that goes further is usually carried as payload, with the lifter left in LKO... much like a rocket. That said, I'm trying to figure out a way to get both... A spaceplane with a re-dockable cockpit/long range module is my current concept, but it's proving an interesting engineering challenge.

Troll-bait much? I fly spaceplanes whenever it's feasible to do so - for fun. I've never "shown off" a single design. Sure, everything you can do with a spaceplane you can do with a conventional rocket... but flying rockets is boring. A typical rocket+pod crew transfer goes like: launch, turn a bit, stage a few times, wait. Retroburn, decouple pod, wait, parachutes, wait. IMO this just can't compare to the satisfaction of hand-flying a spaceplane to orbit, pulling hairy manoeuvres in upper atmo to avoid exploding on re-entry, then nailing a perfect landing back on the runway. No hardware sacrificed, no space-junk created, much feeling of accomplishment. This game gives you an alternate solar-system where SSTO spaceplanes are actually possible, why not enjoy it? I haven't even unlocked rapiers in my current career save, and my space program is already ~70% spaceplane powered.

If you have V-sync off, that's exactly what it will do - the GPU will render as fast as it can (up to the FPS limit) regardless of your monitor refresh rate. It's not a problem and nothing bad will come of it (except possibly some image tearing), though rendering frames faster than they can be displayed is a little wasteful. Setting the framerate limiter won't fix tearing, but it will prevent the GPU doing pointless work that the monitor can't display. V-sync is more of an image-quality thing really - if your GPU is rendering frames out of sync with the refresh rate of the monitor you will likely see a bit of tearing. Monitors draw an image line-by-line, top to bottom - without V-sync a new frame may be sent to the monitor before it has finished drawing the last, and this can produce ugly horizontal breaks in the image where the screen effectively shows part of two different frames. V-sync instructs the GPU to only push a new frame to the monitor during vertical blank - the period where the monitor blanks out the current frame before starting on the next. It eliminates tearing, but it may introduce a slight performance decrease by making the GPU wait on the monitor. Most GPU drivers offset this using (double/triple)buffering or "pre-rendered frames" drawn to a memory buffer until the display is ready for them.

Your monitor refresh rate has nothing to do with the framerate limit in KSP, unless you have V-sync on. If your monitor can only do 60Hz, so be it, it doesn't stop the GPU from refreshing faster than this - you just won't see it. If you have V-sync (sync to v-blank) on then the GPU will render at the monitor refresh rate, and the framerate limiter won't do anything unless set below that. The default cap is there to stop your GPU running away rendering simple stuff at silly FPS. or to smooth out framerate spikes. 120FPS is a reasonable default because some have 120Hz monitors, and you usually don't want it set below your refresh rate. No, it's a limit, not a target. The only thing it "tells our computers to do" (eh whut?) is not render faster than what you set here. If you want to synchronise to your refresh rate (and eliminate tearing) use the tool for the job - V-sync. If you want to limit FPS without using V-sync (it comes with a small performance hit), then use the FPS limiter. The wiki is not only helpful, it's entirely correct. What more is there to say? "Sets the max FPS" is precisely what it does.

Spaceplanes for crew rotation, small satellites and those low-margin contracts where 100% recovery on the runway makes them worthwhile. Rockets are reserved for bulky / heavy things that don't fit in my spaceplanes. I've been playing this long enough that rockets are somewhat... easy now. Spaceplanes are more of a challenge == more fun.