sal_vager

It might be the VM, I never managed to get KSP to work in a VM due to the graphics drivers simply not being good enough, though things may have improved. If you're not seeing the ground loading around the KSC that'll be anti-aliasing, usually it needs turning off, but I leave mine on as it works on Nvidia and PPFX doesn't work if it detects that AA is off in the settings.cfg chmod is a Linux command to set the ownership of a folder or file, and also set whether the file is executable, a script like yours will not be executable by default, you can find more info here. "chmod 777 yourscriptname" in a terminal would make the file readable, writable and runnable by everyone. You can also right click the file, click properties and then the permissions tab, then click to make the file executable in most desktop environments. No idea on the crash though, if anything only KSP should crash, though again as it's doing something graphics related it could be the graphics driver, maybe it says what's going on in your VM's log.

I'm no expert with scripts, but I pasted your script in a new file on Ubuntu, edited the path, made it executable and clicked it... It works!.....mostly. I think the line disabling anti-aliasing breaks the settings.cfg, the in-game graphics tab was blank even after a restart without using the script, I deleted my settings.cfg to fix it. The default for anti-aliasing is "ANTI_ALIASING = 2" and turning it off would be "ANTI_ALIASING = 0", I guess the game does not check for the string "False" and convert it to an integer, I should have just tried editing the file to fix it instead. Editing your script again to "ANTI_ALIASING = 0" worked fine, with no settings screen corruption and AA was off. As to why your script won't start, don't forget chmod Edit: As for making KSP run with anti-aliasing, the only method I know is to force FSAA at the graphics driver level, I do this on a per application basis using Nvidia Settings, as can be seen here.

That's fantastic SuperFastJellyfish, now everyone can read it. Also, if anyone is having trouble with off-topic posters don't forget you can put people on your ignore list in your account settings.

Might be a novel form of thermal radiation thruster, though I have read that pure radiation thrusters are really feeble, but as thrust did change with Q factor it's hard to rule out the need for the magnetron.

Perhaps it's best you give pointers on how to make a small single stage space plane (SSSP), so Sharkman Briton can learn from that, and he can progress to a 100 ton payload monster as his skills improve over time.

The news articles are definitely a poor source for any real information on this, remember they largely cater to the mass market readers, as far as I can find there simply is no adequate explanation at this time.

From what I read, they found a thrust of about 20 micro newtons, not pico newtons as some have reported, they also found true reversal of thrust after they ruled out the magnetic damper by swapping it for oil damping and heat by using a ton of glass wool insulation, all this was in a vacuum. Thrust was in-line with Shawers calculations, though their drive, and they built their own for these tests, was only 700watt (household microwave oven magnetron), but they had the most accurate testing rig possible (apparently in the world). Their Q factor was low due to a fudge up with the epoxy sealing the small end, and Q went down during testing due to oxidization of the internal surfaces (testing started in air, moved to a chamber later). The test device was essentially hollow with a commercial wave guide bolted to it, then the magnetron. The one thing that was brought up at the end of testing was possible magnetism from the power feed lines, which ran to liquid cups to prevent any movement of the lines transferring force, but the lines themselves were just bunched together to reduce electromagnetism, not wound together, so there may have still been some. The thrust seems to be linked to the temperature of the device, as thrust was measured in most cases while it was still warm, it only actually reached 35°C though, with most of the heat in the magnetron. They did mention that if they shut off power early the thrust would instantly stop, but if allowed to "charge up" (that's the term in the paper) it kept running after power was removed. No explanation is given as to the cause of the thrust, nor was the test even looking to verify the device, the only intention of the testing was to find overlooked possibilities which they were unable to do.

Guys, I'll be rolling this into the main EMdrive thread. Also, Tajmar was only trying to rule out outside causes and mistakes in testing, he didn't try to validate the drive itself, though if you can get access to the full paper you'll find he did find thrust and couldn't find a cause, but it's paywalled or I'd post my copy.

Whoops, my mistake, threads de-merged, there's two different issues here.

I recommend that anyone unhappy with this feature votes for the feedback issue on the bug tracker. But as Claw explains this is intentional, and jet engines including the Rapier will draw from all tanks on a stage by stage basis, starting with the lowest stage, just as RCS thrusters will. As can be seen here, the fuel flow with a jet matches the drain seen with RCS and monoprop, with the last stage in the construction "tree" being the first stage that fuel is drawn from. Any tanks lower in the tree, such as droptanks or cargo, will be drawn from first, and the only way to prevent this is to use the right click context menu to disable fuel flow from tanks that are intended as payload. Please note that if fuel is draining from upper tanks through decoplers first then either something has gone wrong with the build and KSP does not realize there's a decoupler in the way, KSP has found a path due to other parts or the top of the craft was added to a common booster stage (or it's the fuel Kraken). I still think fuel flow should be controllable via action group instead.

With the move to Unity 5 for 1.1, Squad will be dedicating most of their time just to getting everything working, this does mean new wheels which will fix the bugs with the existing wheels, and a new UI which has increasingly been identified as the cause by members of our community of the memory errors and game lag, not to mention any number of little internal improvements that the Unity 5 engine brings over Unity 4, but we'll have to wait and see, most bugs that are addressed are listed in the change log for each release, and the readme file, rather than in some official announcement. Also, the relay mechanic is being developed by RoverDude, this is separate to the work on the port to Unity 5 by the Squad developers, so rather than expanding verses quality, we're getting a bit of both. That's not to say Unity 5 won't have new issues of its own, but we'll have to wait and see how it turns out, though as the core developers are concentrating on the issues that moving to Unity 5 entails, they are also spending more time on this iteration to see what's really going on with the bugs they couldn't address before, such as the 64bit career bugs. 1.1 will be better, not perfect, there will be a few rough spots as converting all that code to use the new engine features, stop using the deprecated commands, and still work and be playable at the end of the day is no small feat, some Unity customers have managed it and others are sticking with Unity 4 due to the difficulties, and Squads biggest issues so far have been the wheels which needed to be completely replaced, and the UI, which had to be replaced because Unity 5 completely changed how UI's are handled. The rest is near never ending tinkering to get things the way they should be, but that takes time, all we can do is be patient and see how things develop

I think this thread has about reached its end, the vast majority of players asked for (1) lower LV-N heat production so they could carry on using nuclear engine clusters for all their craft, from SSTO space planes to Gilly landers, without them exploding due to heat after being run continuously for several minutes at 100% output. And (2), for radiators to manage the heat produced by the above. Well Squad listened, players got what they asked for I guess if you cluster enough of them and are prepared to carry enough fuel for a half hour burn you can continue to enjoy the heat production mechanic, but for now this thread has started to go off-topic and into the realm of personal attacks. Closing!

It's rare but it's there, I'm not sure if it really counts as an easter egg though, as usually easter eggs reference something outside the game, like the face of Carl Sagan on Tylo (since removed).

Moved to modded support, it really shouldn't be doing that though, as well as the F3 report you might want to check out your output_log in KSPData, it'll have a lot more info.

Fog has been used in 3D games for a very long time to reduce the load on the CPU and GPU, as you can hide stuff in the fog and then you don't have to draw it at all.

This is pretty old, over 6 months in fact, I'd hope that Maolagin would have figured it out by now, usually this is an anti-aliasing issue with the proprietary AMD driver but I bet it'd effect the older Nvidia cards as well. Now it's interesting that you fixed your issue by using the 64bit binary, you likely don't have the 32bit mesa libraries installed, but I'm glad you found a fix Setting as solved as it should be by now, and closing as it's old old old.

It might be an issue with the save you're using as well, I recommend testing a new save to see if the issue persists, and uploading your current save to dropbox, as one of us might be able to fix it.

I think you're just really short on intakes, those engines like a lot of air so consider adding more intakes

Oh if only I'd seen this sooner, most games have their binary set as not executable in the zip, so Ubuntu and most other distros won't know what to do with it... KSP performance on Linux is as varied as there are Linux distros, but you'll get the best performance and stability with an Nvidia graphics card, though I'd not recommend the latest and greatest, as Linux driver support usually lags behind, so something from the middle of the range to upper middle is best. AMD should get better, if they embrace open source drivers fully which I think they will do, and even Intel is okay, but if you're getting an Intel card, go for a good one, they aren't as powerful as an AMD or an Nvidia, but their open driver is great. Also, marking as solved as the original question was solved.

Hi Mongoose, thanks for looking into this, you may be interested in knowing that the whole UI is being remade in Unity 5, also there is a public bug tracker [here] which is a better place to put issues such as this one. Hopefully the new UI will fix these alpha issues, if not then your fix may help. Thanks

Looks good carneyvich, it doesn't really count as a challenge though, please see the challenge guidelines. Moving to Fanworks, it'd be nice to see what people make.

How so Kerbonautics ?

Welcome to the KSP forums Mango2015 The LV-N is still the workhorse of choice for large craft and orbital operations, it's just no real use as a lander engine anywhere there's an atmosphere now, also as it runs on straight liquid fuel you can ditch that oxidizer or use the aircraft LF tanks, that will give you the long legs you're used to from the nuclear engine. It's definitely a good choice for the trip to Duna

Hi notasnark, your log file is full of these. NullReferenceException: Object reference not set to an instance of an object at FlightIntegrator.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at Vessel.recurseCoMs (.Part part) [0x00000] in <filename unknown>:0 at Vessel.findWorldCenterOfMass () [0x00000] in <filename unknown>:0 at Vessel.CalculatePhysicsStats () [0x00000] in <filename unknown>:0 at Vessel.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) As you're using Steam, I recommend you try validating the game cache before anything else. I also suggest you try starting KSP with the KSP.x86 and KSP.x86_64 files in the game folder, instead of using Steam in case Steam is overriding your keystrokes.

Please try the solution provided in this post, let us know if it works for you.