steve_v

Can't say I've ever seen that, but then I don't recognise the part you are attaching them to... Does this happen with all parent parts, or only some (possibly mod) parts?

As will actually knowing what you're doing, and checking compatibility first. Back on topic: Some mods introduce bugs, but IME they are fixed far more quickly than bugs in the stock game, of which there are plenty. Some mods even exist solely to fix stock bugs. When I play, it's with 40+ mods. When I don't play, it's because of stock bugs.

Try disabling AA (use GPU driver AA) & "Edge Highlighting (PPFX)" in settings. - - - Updated - - - It's a known bug, here's the bug report.

RAM is a moot point, it's got 32MB now. 'Tis the L2 cache I'm asking after. If by RAM you mean cache SRAM, I'd tend to agree. Time to break out the IC extractor. Also, posted from Mozilla 1.6 on machine in question. Looks like the current Firefox needs a tad more than 32MB Hmm, Mozilla + SSL crashes the OS (trap!)... further investigation pending.

So the question then becomes: Faster memory access for small tasks, slow access for large tasks. VS. Slightly slower memory access for all tasks. If it were pure DOS, I'd not need the extra RAM in the first place. But with OS overhead, I'm thinking the larger cache will be a benefit, as even if slightly slower it's still much faster than system RAM. Opinions is all I'm after, what would you pick here?

Err, really? That's a non-answer if ever I heard one. What I want to do is add another 16MB of RAM, and if possible improve cache performance. I have read/heard that 128kb is about right for 16MB, but will likely cause excessive cache misses when accessing RAM >16MB and a corresponding performance drop off. Correct? What I would like to know is: Will the benefit of a larger L2 cache outweigh the slower access time (20ns) for typical (OS/2) workloads, or DOS games (DooM etc.) within OS/2 (which will probably be hitting 16MB+). I'd just "suck it and see" but those chips are a pain to install/remove without damaging them.

It's the x64 build of the Unity3d engine that has issues... Serious issues on Windows, not so much on GNU/Linux. In either case, a 64bit OS is all good.

The dilemma: L2 cache: 128kb of 15ns cache SRAM, or 256kb of 20ns cache SRAM? 128kb is stock for 16MB RAM, but I'm looking to add another 16MB... how much difference will another 128kb of L2 cache make, and will I be better off with more but slower, or less and faster? Alternatively, anyone know where to get a full set of (9x=256kb) 256b 15ns cache chips? System specs: Model: IBM 330-100DX4 (6571-W5W) Chipset: OPTi CPU: Intel 80486DX4-100 RAM: 16MB 70ns FP. HDD: Seagate 545MB 4200RPM GPU: Cirrus Logic GD-5430, 1MB VRAM. Audio: Creative Soundblaster 16 Value (ct2950) Ethernet: 3Com Etherlink III (3c509b-tpo) OS: OS/2 Warp 3 connect. Not exactly a KSP-worthy machine, but I'm taking that "All Questions Acceptable" literally here.

Yeah, first thing I miss when booting Windoze... It's included functionality (as well as a radial map view, like Scanner) in KDE/Konqueror

While disabling heat damage will prevent exploding, the temps will also stop solar panels from working... This bug needs fixed ASAP. You shouldn't need to "design around" something that is clearly a bug. Drop conduction factor and raise radiation factor, then wait. Or edit the save to reasonable temps first, if it's going to take too long. On GNU/Linux, sed is your friend.

Linux version only runs on Linux There is a way to run 64bit on Windows, but it's an unofficial "community hack". You will most likely run into bugs and mod incompatibilities, so YMMV.

Could not allocate memory: System out of memory!... d3d: failed to create 2D texture id=2029 w=8192 h=4096 mips=14 d3dfmt=21 [out of memory] Crash!!! Pretty self-explanatory. 32bit KSP can only use ~3.5GB of memory (32bit address space limit) You have too many memory hungry mods (probably textures). Use ActiveTextureManagement, force OpenGL, loose some mods, or switch to GNU/Linux where there is stable 64bit KSP. I'd start with KerbalGalaxy, as it probably has the biggest textures.

Meh. As I understand it, U5 implements PhysX 3.3... which supports GPU acceleration for Nvidia cards on Windows. But it's only used for cloth simulation, which is no good to us anyway. Performance across the board should improve, but it looks like it's still unable to utilise more than one thread for a group of connected rigidbodies... which means one thread per craft. Which means performance will still suck, but maybe not quite so hard. There are cross-platform GPU accelerated physics engines available (bullet springs to mind) but someone appears to be intent on using only stock Unity functionality. Personally, I'm not expecting any huge performance boost. But we shall see.

Better idea: use second GPU as dedicated PhysX processor. Oh, wait, KSP can't use GPU accelerated PhysX. What a shame. I guess we're stuck with lousy performance and that second GPU will just sit there twiddling its thumbs while your CPU melts. KSP, please utilise available hardware properly. I am tired of awful performance on high-end machines.

Uh, yeah. There's no reason to run a 32bit OS on even remotely modern hardware. Step1: Install 64bit GNU/Linux (or switch up your current distro if you know what you're doing ) Step2: Switch to 64bit KSP Step3: Add moar mods

Probably, but mostly because fewer features

Yeah, unless you use FAR... in which case nosecone and intake drag actually makes sense.

No, provided you have enough IntakeAir to run your engines. One intake per engine should be enough, but it's a balancing act between thrust, intake air, velocity and drag. More intakes won't necessarily equate to more thrust at altitude unless intake air is the limiting factor - air breathing engines loose thrust as air density decreases anyway, and more intakes won't change this. They'll just add more drag, and more drag = less speed = less thrust (thrust is a function of air density and velocity for KSPs jets). The part description for the engine should give you an idea of where thrust peaks with regard to velocity. Once you get far enough beyond peak thrust velocity (or altitude) that you stop accelerating, it's time to think about switching to rockets - at this point intakes become dead weight anyway. Working out exactly where that point is for a particular craft is a matter of trial and error. Air intakes also work better as velocity increases, so reducing drag for moar speed is often better than adding more intakes. What you want is just enough intake area to prevent your airbreathers from flaming out before you're finished with them.

Or, ya know, a real multi threaded GPU accelerated (OpenCL/CUDA) physics engine. Which is what the game has needed since day 1. Doing complex rigid-body physics in a 32bit, single threaded, CPU only engine is ridiculous - the processing requirements increase pretty much exponentially with body(part) count. Get a faster CPU? Nope, they don't exist in consumer grade hardware. Welding would be nice, but it removes one of the key features of the game - the part interactions. Heat transfer, impact destruction, joint failure etc. would all have to go. I get that it's a Unity issue, but it's crippling the game. Something. Must. Be. Done. There's no point in an "unlimited part count" unlockable if the physics engine can't handle it. As it is, the game becomes unplayable at part counts that are effectively encouraged by the progression system. - - - Updated - - - And don't get me started on the excessive memory consumption and brain-dead "put everything in RAM at startup" asset loader...

Last I heard, it was USI OKS/MKS adding the default internal (which has crew seats) to probe cores that triggered this. Not sure if it's fixed yet so it might be worth a look over the appropriate mod thread. - - - Updated - - - Here it is, there's both a MM patch and a pull request in that thread. I'm not using UKS myself though, so YMMV. If it's not that (and you have a version of UKS with that patch) then it's time to go mod-bug hunting...

How long is a piece of string? That's a nice build, and quality components too. It's actually pretty close to what I'd pick if I was building a new box, though I'd add an SSD for the OS, and maybe go for less fancy RAM. As for how well it'll run KSP... nothing will run KSP "well", but you should be ok with that CPU, it's all that really matters for this game.

Because the test craft part count decreases due to staging.

Attempted to play KSP, spent hours trying to work around bugs. Innumerable quickloads and exploding ships later gave up. Tried to play KSP again with a new save, got ....ed off with the abysmal performance and stuttering. Gave up again and deleted my install in a fit of rage. The increasingly poor performance since the latest patches (go look at the "cpu performance database" thread for details) plus the stuttering, thermal instability, infinite ragdolling, claw kraken, cargo bay bugs + all the other bugs = unplayable game. Sorry, but you did ask. - - - Updated - - - Observe (not my image). I give up, this is pure BS. So no I didn't do anything in KSP at all today, except to decide it's too broken to play any more.

Well, I haven't used it myself... But I've watched 3 other people (so far, counting) get really angry with it. So I guess that counts as "experience"?

The first step is probably still going to be getting the device node(dev/sd[x]), you'll need it to surface scan (badblocks) run self-tests (smartctl) and possibly fix or re-create the partition table... Or remove proprietary garbage-ware such as U3. Any of these issues can cause a drive to appear as a cdrom. And yes, physical defects can too, though it is uncommon. If this has ever had a hybrid-iso install image (e.g. debian) written to it, that'll do it too. Nuking it with Destroyer of Disks + creating a new partition table should fix. I'd be surprised if Gparted didn't pick up on most of these though. - - - Updated - - - Ahh yes, do check the usb-disk emulation mode and usb-legacy settings in BIOS too.