[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[Autochton]

Oh ive already got the dual boot set up, just getting to grips with linux now. I've never used it before and its a bit of an investment of time to learn from the looks of it but it seems pretty interesting, appreciate the warning tho and the information

I'll point out that vendor graphics driver support is occasionally spotty, especially for new cards (old cards often have good support via open-source drivers). But I've become tremendously happy with playing KSP on Linux, and have no more trouble with it, I would estimate, than the next guy. I use Linux Mint 17 Qiana.

[Ryds]

Hi there,

I've a problem with Linux, glad to see there's a lot of mentions of it in this thread because I think it is to do with FAR. The game crashes on lift off, generally it's around the 10k to 20k altitude and will happen after about 3 or 4 reverts to the VAB or Hanger the next time I take off it'll crash around the point mentioned.

The reason I think it's FAR is that the last lines of the player.log is posted below. I'm trying to learn how to read the logs but I just can't tell for certain if it is FAR or if it is another mod.

Updating vessel voxel for Mars Orbiter

(Filename: /home/builduser/buildslave/unity/build/artifacts/LinuxStandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56)

If someone could please take a look at it and let me know what's up, I'd very much appreciate it. Thanks!

KSP.log:

http://mab.to/Xb71Vh5NM

Player.log:

http://mab.to/Es8fz7IVb

Gubbins:

KSP: 1.0.4 (Unix) - Unity: 4.6.4f1 - OS: Linux 3.13 Ubuntu 14.04 64bit, 8GB RAM

Filter Extensions - 2.4.1

USI Tools - 0.4.2

CapCom Mission Control On The Go - 1.0.1.2

Chatterer - 0.9.6.86

ChuteSafetyIndicator - 1.0.2

Community Resource Pack - 0.4.4

Contract Configurator - 1.7.3

CC-CP-SCANSat - 0.5.2.1

Contract Pack: Field Research - 1.1.1

Contract Pack: RemoteTech - 2.0

Contract Pack: Tourism Plus - 1.2

Contract Pack: Useful Space Stations - 1.0.2

DMagic Orbital Science - 1.0.8

Deadly Reentry - 7.2.2

Editor Extensions - 2.12

Ferram Aerospace Research - 0.15.5.1

Firespitter - 7.1.4

Interstellar Fuel Switch - 1.15

RasterPropMonitor - 0.22.2

Kerbal Attachment System - 0.5.4

Kerbal Inventory System - 1.2.2

KSP-AVC Plugin - 1.1.5

KW-Rocketry-Community-Fixes - 0.2

Kerbal Construction Time - 1.2.2

Kerbal Engineer Redux - 1.0.18

Kerbal Joint Reinforcement - 3.1.4

KerboKatzUtilities - 1.2.9

Infernal Robots - 0.21.3

ModularFlightIntegrator - 1.1.1

Docking Port Alignment Indicator - 6.2

Near Future Electrical - 0.5.3

Final Frontier - 0.8.6.1370

Civilian Population - 1.7.4

Outer Planets Mod - 1.8

PlanetShine - 0.2.3.1

Procedural Wings - 0.10

Procedural Parts - 1.1.7

QuickScroll - 1.3.1

QuickSearch - 1.1.3

QuickStart - 1.1.2

RCS Build Aid - 0.7.2

RCS Sounds - 4.3

RealChute - 1.3.2.3

RemoteTech - 1.6.7

SCANsat - 1.1.4.2

SafeChute - 1.7.1

ShipManifest - 4.4.1.1

StageRecovery - 1.5.7

TAC Fuel Balancer - 2.5.1.7

TextureReplacer - 2.4.8

Thermal Monitor - 1.2

TAC Life Support - 0.11.1.20

Trajectories - 1.4.3

Kerbal Alarm Clock - 3.4

TweakScale - 2.2.1

USI Exploration Pack - 0.4.1

Freight Transport Tech - 0.4.1

MKS - 0.31.6

Universal Storage - 1.1.0.7

Waypoint Manager - 2.4.2

Wider Contracts App - 1.2

[ferram4]

I don't see anything in there that would point to FAR being the cause, unless it happened to occur during a disintegration or many-debris-staging event combined with extremely high memory usage, which could lead to an out of memory error. Those are the only crashes that ever occur in KSP, so that means that the difficulty is in finding the mechanism for it...

Given the huge number of mods that you have, the memory leaks in the stock game, and the relatively low amount of memory that you have, it's quite likely that your game is attempting to allocate too much memory. You can try reducing the number of background processes to free up some memory to work with (assuming you're using 64-bit Linux) and reduce the number of texture-heavy mods that you use to free up memory, but other than that, there really isn't anything that you can do. There isn't much else I can do, I've already removed the most common causes of FAR introducing sudden OOM errors, so... I think you just have too many mods. Yeah, it can happen on Linux too.

[Ryds]

Ok , thanks for your quick and in-depth response Ferram4. It is a lot of mods true and if you can't see anything there then I'll accept that lowering the number of them may solve it.

Uff, got some thinking to do now regarding what parts are on which crafts that are already on missions! I've just managed to get a massive career mode CivPop base up and running on Minmus that was gonna be my launchpad to the solar system. I sense a frustrating couple of days ahead

Thanks again!

[ferram4]

FWIW, I am tweaking some stuff that might provide an improvement. No idea how much it will be though, because it's one of those things that requires evil bitwise operations to let me remove a bunch of memory, along with any bugs that might result from that, but if it works I should reduce memory usage to ~60% what it is currently. The current dev build (on the master branch) has that in there, so if you wanna try dancing with the devil and nitpick with him about exactly how much memory you can use, go ahead and try. No warranties on this one though.

[Ryds]

FWIW, I am tweaking some stuff that might provide an improvement. No idea how much it will be though, because it's one of those things that requires evil bitwise operations to let me remove a bunch of memory, along with any bugs that might result from that, but if it works I should reduce memory usage to ~60% what it is currently. The current dev build (on the master branch) has that in there, so if you wanna try dancing with the devil and nitpick with him about exactly how much memory you can use, go ahead and try. No warranties on this one though.

Haha! Thanks, I'll give it a go sure. Time to make a backup save

[damerell]

Given the huge number of mods that you have, the memory leaks in the stock game, and the relatively low amount of memory that you have, it's quite likely that your game is attempting to allocate too much memory. You can try reducing the number of background processes to free up some memory to work with (assuming you're using 64-bit Linux) and reduce the number of texture-heavy mods that you use to free up memory, but other than that, there really isn't anything that you can do.

The OP could add swap space. The address space itself on a 64-bit system is colossal, and if leaked memory ends up in swap it makes very little difference.

[Jovus]

I was having some trouble with re-entry using FAR and DRE where my craft would blow up high in the atmosphere (around 50-55km):

I've gone back and verified that this problem persists on a completely fresh install of KSP using just FAR v0.15.5.1 "Hayes" and DRE v7.2.2 on KSP v1.0.4 x86_64 for Linux. (More information on precise Linux setup can be supplied if necessary.) Please let me know if you need more information or if you think I should be posting in the FAR thread instead/as well. Reproduction steps: Download http://kerbalx.com/Jovus/Reentry-Testing-Craft. This craft is the craft used for reproduction. Get that craft into a 75km x 75km orbit. I prefer Hyperedit. Activate the engine to bring the craft down to a 75km x 25km orbit. Activate the decoupler. Keep the craft pointed retrograde through reentry. It's a bit unstable, so you'll need SAS. For best results, don't just use the 'hold retrograde' setting, as that will drain battery too quickly. To make the problem appear more rapidly, use physics acceleration, but this should be unnecessary. Player.log here

(The craft is a Mk1 pod with Science Jr underneath and a heatshield on the bottom.) After helpfully digging into it, Starwaster pointed out:

Edit: Ok, with FAR installed, occlusion starts to end at AoA 3 degrees. That shouldn't be taken as an absolute figure; it could be more or it could be less for various parts on the stack. Check your angle of attack during reentry. FAR has an option to display that. Click the FAR button then Flt Data. Look for Angle of Attack and Sideslip Angle. The further those are from 0, the more exposed your parts are going to be. I'm betting that's why you're seeing heating and it's probably by design as FAR is supposed to be a more realistic aerodynamic model. Believe it or not, in real life, you wouldn't see 100% occlusion on those parts either. Hot gasses would be slipping up the sides and scorching them. Even hitting the sides of the capsule, though heating would not be as severe because the shockwave expands and cools once it slips past the blunt end but even the sides have to be shielded to some extent. So frankly, you've got it pretty easy in stock as far as reentry heating goes.

...and I just wanted to check with you guys that that seems reasonable behaviour, since my experience of FAR/DRE is a bit dated. If so, I'll work on re-organizing my rockets, though I'm curious if there's any way other than oversized heatshields to return anything more than just a capsule. Thanks!

[Ryds]

The OP could add swap space. The address space itself on a 64-bit system is colossal, and if leaked memory ends up in swap it makes very little difference.

That sounds very interesting damerell. Just as I don't know too much about the workings of KSP, I also don't know too much about Linux, I only downloaded it to play KSP. Now I've read about increasing swap space from here https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/System_Administration_Guide/s1-swap-adding.html

It seems like a case of following steps to achieve which I'm fine with. But one thing I'd mention, as far as my memory is good back to 2 months ago, the crashing error seems to have started around the same time that I upgraded to Win10. Now in Linux when I try to access the files in the Windows partition, I get the error:

Unable to access “432 GB Volumeâ€Â

Error mounting /dev/sda3 at /media/jp/20824425824401B0: Command-line `mount -t "ntfs" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,dmask=0077,fmask=0177" "/dev/sda3" "/media/jp/20824425824401B0"' exited with non-zero exit status 14: Windows is hibernated, refused to mount.Failed to mount '/dev/sda3': Operation not permitted

The NTFS partition is in an unsafe state. Please resume and shutdown

Windows fully (no hibernation or fast restarting), or mount the volume

read-only with the 'ro' mount option.

Do you think that any swap space that might have been there before has been overwritten by the Windows upgrade? Windows and Linux seem to be working fine, KSP excepted. Again, I really do not know what I'm talking about so feel free to tell me that theory is nonsense!

[Gryphon]

Do you think that any swap space that might have been there before has been overwritten by the Windows upgrade? Windows and Linux seem to be working fine, KSP excepted. Again, I really do not know what I'm talking about so feel free to tell me that theory is nonsense!

I'm no guru, but I presume one question that others will ask is: is Windows actually in hibernation, or did you fully shut it down? (If you hibernated it, that might be why the mount process is complaining that Windows is in hibernation. If it's not, you should say that.)

Also, I suspect that the search for more complete Linux support is more likely to succeed in another thread. Or via the Googles. I got some intriguing results by searching for: Win 10 linux hibernation

[ferram4]

@Jovus: Well, I was able to reproduce the issue, which is very, very simple: DR is excessively punishing towards command pods if they have any bit exposed to the airflow, and FAR ends up exposing a little bit to the airflow through the one little piece of ladder on the side, but a lot more through the lip formed by not pushing it down closer to the part below it. Yeah. That ended up being enough to kill it when combined with the really narrow heat shield. You gave a way for hot plasma to get right up against the vehicle and then bad things happened.

[broomish01]

it actually turns out im having some serious issues getting the latest Nvidia drivers installed on linux. Following this:

tutorial however it does not seem to be working.

[Red Iron Crown]

This really isn't the thread for Linux issues. Perhaps start a thread in the Space Lounge or Support for that sort of thing.

[Jovus]

Gotcha! Thanks, Ferram; I'll take a look at changing my rocket designs.

[Guest]

Will FAR have better framerate with unity 5?

[damerell]

This really isn't the thread for Linux issues. Perhaps start a thread in the Space Lounge or Support for that sort of thing.

I have replied via PM to Ryds; I think the only FAR-pertinent point is that if you think you're running out of memory on Linux x64 it can always be fixed.

[Ryds]

This really isn't the thread for Linux issues. Perhaps start a thread in the Space Lounge or Support for that sort of thing.

Agreed, sorry to take it off track but thanks for the help that was given.

I have replied via PM to Ryds; I think the only FAR-pertinent point is that if you think you're running out of memory on Linux x64 it can always be fixed.

Thanks again Damerell. I'll have a read now.

[MatterBeam]

Hello, I have a few questions regarding FAR and supersonic airplanes in general:

-How useful are thin wings? I usually make mine from 8cm to 4 cm thickness. Is there any advantage other than weight?

-How important is area ruling in craft that travel at Mach 2 to 3, compared to the general streamlining (total front cross-section) of the craft?

-Is it possible to control maximal flap deflection angle through an action group?

-Does FAR, in combination with AJE, recognize a partially occluded air-intake?

Thank you for answering.

[tetryds]

I can answer that:

1-FAR does not account for wing thickness yet.

2-Way less important than you think it is, but it also helps to streamline the craft so it's not always a bad thing.

3-Not max, but you already have four deflection positions from retracted to max deflection.

4-Not gonna happen. At least not anytime soon, AFAIK.

[MatterBeam]

I can answer that:

1-FAR does not account for wing thickness yet.

2-Way less important than you think it is, but it also helps to streamline the craft so it's not always a bad thing.

3-Not max, but you already have four deflection positions from retracted to max deflection.

4-Not gonna happen. At least not anytime soon, AFAIK.

Thank you for the answers.

1-Testing showed that wing thickness has a significant effect on area ruling though...

2-Okay, thank you.

4-So I could translate an intake into the fuselage until only 10% of its original opening actually faces the airstream, and yet it manages to get maximal IntakeAir?

[blowfish]

1 - correct that it affects area ruling, but it has no effect on the lift/drag properties of the wing itself.

4 - neither FAR nor AJE calculate how much of the intake is exposed, so yes, you'll get the full area regardless

[Svm420]

Thank you for the answers.

1-Testing showed that wing thickness has a significant effect on area ruling though...

What he means is FAR isn't taking the thickness into account when generating lift for the airfoil. A 1m thick wing and a 1mm wing will both give the same lift. It will affect drag/ area rule so it does usually help that to thin the wing. But no mater what FAR has a predetermined airfoil shape it uses regardless of how thin/thick your wings are. All that is my understanding so if anyone with better knowledge feel free to correct me

[MatterBeam]

1 - correct that it affects area ruling, but it has no effect on the lift/drag properties of the wing itself.

4 - neither FAR nor AJE calculate how much of the intake is exposed, so yes, you'll get the full area regardless

Oh, okay. I assume only slanting affects the wing drag?

[blowfish]

Oh, okay. I assume only slanting affects the wing drag?

What do you mean by slanting?

[TheHengeProphet]

Oh, okay. I assume only slanting affects the wing drag?

Pretty sure "slanting" the wing in any direction is going to affect your drag.