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

[Van Disaster]

It's usually a bug - launch & revert quite often resets the CoL to what you'd expect it to be.

[taniwha]

Back (very briefly) to the DRE g-force argument. I've posted my explanation in the DRE thread.

That's all I will say on the matter here.

[TinfoilChef]

I need to uninstall FAR from one of my KSP installs. Am I correct in assuming that the only two steps involved are to remove FAR from the gamedata directory and then replace the stock parts (basically the 'squad' directory) with copies from an un-modified KSP install?

[AndreyATGB]

I need to uninstall FAR from one of my KSP installs. Am I correct in assuming that the only two steps involved are to remove FAR from the gamedata directory and then replace the stock parts (basically the 'squad' directory) with copies from an un-modified KSP install?

Why would you need to remove stock parts? All you need to do is remove FAR and module manager if you don't have other mods that need it.

[m4ti140]

So, a few pages ago I asked about pod lift, and since you told me it already works, today I tried to do some skip reentry, coming in from Mun.

I am playing with both FAR nad DR. I was using 1-2 pod with 2.5m heatshield from DR designed specifically for this capsule. To get a correct angle at reenrtry I shifted CoM of 1-2 pod in part.cfg, using CoM offset command. During reentry it should work more less like this:

where v is velocity vector and F is lift (or lift + drag bc I appearently suck at drawing, but you get the idea) vector. Insted it worked like this:

And I got pushed harder to the ground instead of getting lifted. Oddly enogugh, when I inverted attitude (pointed heatshield towards space)... I got positive lift, and literally pulled up, allowing me to perform a skip reentry.

This is exactly the oposite of how the capsule should behave during reentry. It appearently takes the plane, in which wings would be if one built an aircraft with 1-2 pod as root, as lift surface, instead of heatshield plane. As a result the vector of lift produced by pod during reentry is more less inverted - you get positive lift at negative AoA and vice versa.

[BigNose]

So, a few pages ago I asked about pod lift, and since you told me it already works, today I tried to do some skip reentry, coming in from Mun.

I am playing with both FAR nad DR. I was using 1-2 pod with 2.5m heatshield from DR designed specifically for this capsule. To get a correct angle at reenrtry I shifted CoM of 1-2 pod in part.cfg, using CoM offset command. During reentry it should work more less like this:

-snip-

where v is velocity vector and F is lift (or lift + drag bc I appearently suck at drawing, but you get the idea) vector. Insted it worked like this:

-snip-

And I got pushed harder to the ground instead of getting lifted. Oddly enogugh, when I inverted attitude (pointed heatshield towards space)... I got positive lift, and literally pulled up, allowing me to perform a skip reentry.

This is exactly the oposite of how the capsule should behave during reentry. It appearently takes the plane, in which wings would be if one built an aircraft with 1-2 pod as root, as lift surface, instead of heatshield plane. As a result the vector of lift produced by pod during reentry is more less inverted - you get positive lift at negative AoA and vice versa.

Nice catch, never used the capsules lift capabilites. Just tested it now, and I can confirm this odd behavior. Should be a quite easy fix for ferram4 though.

[NathanKell]

Not sure it'll make a difference in this regard, but are you using my fix for the heatshield?

[loknar]

I can't load KSP after updating the latest FAR.

The game is stuck while loading Squad/PodCockpitmodel

I tried overwriting FAR with the previous FAR I used, then load KSP again, still stuck.

Even deleting the while pod folder didn't produce any errors, just stuck.

I tried re-installing but it's like whatever I do nothing changes. And my backup of the KSP folder was not made before 21.1. I barely have time to play at all, fixing my installation is taking all my free time this weekend.

[ferram4]

@m4ti140: Noted. That problem will actually be a bit harder to fix in the current FAR code, since trying to add the "lift" effect from that blunt side of the capsule ends up being more difficult to do than you might think without causing the capsule to become unstable.

@loknar: That makes no sense; FAR hasn't touched the part.cfgs directly since before version 0.9.5, which was from before KSP 0.21.0. It never even touched the PodCockpit folder, since that is an internal space and FAR doesn't mess with that at all.

You'll probably just have to repair your KSP install or reinstall it wholesale to fix it. Make sure that you're using the latest version of KSP and FAR, and that you're not placing KSP somewhere where it will have permissions problems. Other than that, I can't help you; the last time FAR caused this error was when it still manually changed part.cfg files and it hasn't done that in several versions.

[paju1986]

There are an incompability issue with FAR and remotetech2 because FAR doesn't inicialize without a commandpod but since remotetech2 list all unmaned commandpods like SPUs FAR doesn't recongnize them and doesn't initialize...

I wish this can be solved, i really would love to have some unmanned SSTO spacecrafts with remotetech

Regards.

[loknar]

Hey Ferram,

I just made another fresh install and my old save.The game loaded fine.

Then closed the game and installed latest FAR and Chatterer: No files overwritten, only added files.

loading the game, i get stuck on Squad/Spaces/PodCockpit/model

Edit; test details

Test 1:

a) fresh install 21.1 - startup OK - startup 2nd time, OK (to be safe)

copying FAR 0.9.6.2 - startup stuck on Squad/Spaces/PodCockpit/model

--waited 10 minutes-- KSP is responding, just not apparently progressing, except for regular silly progress cues, with 9-22% cpu activity

c) Alt-f4 to close ksp, log entries suggest warnings and errors, example:

._ModuleManager.dll:

System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid.

at Mono.Cecil.PE.ImageReader.ReadImage () [0x00000] in <filename unknown>:0

at Mono.Cecil.PE.ImageReader.ReadImageFrom (System.IO.Stream stream) [0x00000] in <filename unknown>:0

at Mono.Cecil.ModuleDefinition.ReadModule (System.IO.Stream stream, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0

at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <filename unknown>:0

at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName) [0x00000] in <filename unknown>:0

at AssemblyLoader.ScanForBadTypeRefs (System.String file) [0x00000] in <filename unknown>:0

at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0

._FerramAerospaceResearch.cfg' contains no data.

._FerramAerospaceResearch.dll

(failed to load assembly)

the real files does not start with "._" obviously. But that seems normal and the root cause may be the modulemanager

But something is wrong with my pc. or something...

Rolling back to older versions of FAR, by overwriting the files, down to 0.9.5.5 which was the previous version I was using, does not heal my installation.

I'm out of time now - I will try a fresh install + FAR0.9.5.5 instead of downgrading next

Edited September 8, 2013 by loknar

[Van Disaster]

Two interesting notes:

* Running static simulations appears to reset the CoL marker ( presumably to where it's meant to be )

* The canard design I just flew to orbit apparently should have spent the entire time backflipping dynamically unstable aircraft seem doable.

[a.g.]

The "._" files sound very much like the kind of junk Mac OS puts in zip files in a supposedly hidden subdirectory (which is obviously very visible on every other OS). If they somehow actually get copied into the game directory, they might easily confuse the game.

[paju1986]

I resolved the bug changing the line 166 of FARGlobalControlObjet.cs by this

if (p.Modules.Contains("ModuleCommand") || p.Modules.Contains("ModuleSPU") && !p.Modules.Contains("FARControlSys"))

now it looks for modulecommand or moduleSPu to be present on the vessel making it compatible with RemoteTech2

Can you add this to your code ferram? thanks you.

Regards.

[KerbMav]

Ran every simulation, reloaded x times ... phantom lift in a queer direction and no visible cause ...

http://imgur.com/a/1HFcr#3

[ferram4]

@loknar: Make sure that ModuleManager is in the right directory and that you don't have any extra copies of the dll floating around in your GameData folder and its subfolders. Make all your hidden folders visible and make sure that nothing is floating around in there that shouldn't be their (I have no idea why that would happen, but it's a possibility).

@paju1986: I'll add that in if another revision is necessary, but I make no guarantees about that happening soon.

@KerbMav: It's a bug; it should have no affect on the behavior of your vehicle.

[KerbMav]

This is after taking measures to remove the buggy display of the CoL - which still works (save/reload) - the craft behaves as the CoL predicts in the VAB, it rolls to the right instantly after take off.

I fear I will discover either something really strange - or something completely stupid on my end ...

[amo28]

Long time listener, first time caller.

Wanted to find out if anyone else has noticed any odd issues with re-entry on the new 9.6.2 release.

Since updating to this version, everytime a plane re-enters the atmosphere, no matter what my entry angle is, drag throws the plane into a head to tails pitch frenzy. I tested it five different times with a quicksave last night. Pushed all my fuel to the front, to the back, balanced, dumped out a bunch, it didn't seem to matter what my CoM was.

I watched it on Flight Engineer's Surface tool. The plane keeps perfect attitude until about 69-70km. Then as soon as the atmo and drag data starts to populate in Flight Engineer at ~69km, wham -- doing backflips.

This has happened on two different SSTOs since the update. I can upload pics tonight, but just wanted to see if anyone had run into something similar, or had any suggestions.

Thanks!

[Blatter]

Control Axis: Manually set control axis for control surfaces, and make the rudder act separately from the ailerons. Alternatively, make the ailerons actuate on yaw inputs and make the rudder respond to pitch inputs!

Does this mean I can have different joystick controls for spaceplanes and rockets? It's always awkward to have to go back and swap yaw and roll controls in setting every time I want to fly something different.

[ferram4]

@KerbMav: Try getting rid of all of a specific wing type (like, say, the delta wing part, or the standard control surface) and see if that changes things. Also check the vertical tails to make sure they're exactly straight, since that has been a source of that bug.

@amo28: The fuel burned has pushed the CoM behind the CoL; both of your spaceplanes have become unstable due to CoM movement caused by the large amount of fuel being burned. You will need to redesign them in order to make them stable.

@Blatter: Not supported, sadly. I don't believe it is possible for me to change that.

[softweir]

@KerbMav: No possibility you have an inverted command pod, mechjeb or reaction wheel unit anywhere? I managed a spectacular recreation of the recent Proton rocket failure by having an inverted inline reaction-wheel unit in the stack, managed the same by putting a command pod upside down and deciding to look out through its window instead of sticking with the main command pod, and MechJeb can do wild tricks if one of its units is misplaced and has been the subject of a Control from Here input.

[loknar]

Long time listener, first time caller.

Wanted to find out if anyone else has noticed any odd issues with re-entry on the new 9.6.2 release.

Since updating to this version, everytime a plane re-enters the atmosphere, no matter what my entry angle is, drag throws the plane into a head to tails pitch frenzy. I tested it five different times with a quicksave last night. Pushed all my fuel to the front, to the back, balanced, dumped out a bunch, it didn't seem to matter what my CoM was.

I watched it on Flight Engineer's Surface tool. The plane keeps perfect attitude until about 69-70km. Then as soon as the atmo and drag data starts to populate in Flight Engineer at ~69km, wham -- doing backflips.

This has happened on two different SSTOs since the update. I can upload pics tonight, but just wanted to see if anyone had run into something similar, or had any suggestions.

Thanks!

I know what you're talking about. When you're >70km you exit the atmosphere and your control surfaces can't compensate for uneven thrust force. Make sure the CoG and CoT are aligned. Only tiny shifts will have huge impact at high thrust. Building a plane with non symmetric parts and wings, it is almost impossible to be perfectly aligned so I fixed this by using a rocket with gimbal (many don't). I use a rocket at the rear while air breathing turbines are on the wings.

Ferram said your fuel distribution may be causing unbalance. That's another challenge but to a lesser extent in my case because I built a rather big plane.

Does that help? Maybe post screenshots (F1)?

[Van Disaster]

I've noticed some odd tumbling on re-entry today also. I spent today doing some aerocapture runs on Jool and Laythe & ended up needing to leave RCS on ( given FAR was reading out Mach 216 on Jool that's not entirely unwarranted! ) and lost control high up over Laythe anyway, a few times, thankfully high enough to get it back again. Each time it suddenly pitched down for no obvious reason, in air that should probably not give that amount of control authority.

Going to test a few different designs over Kerbin tomorrow, I think. Hopefully it's just an issue with that plane with that fuel load, although I did move some fuel around to change things between runs.

[loknar]

aerodynamics in thin atmosphere may seem strange. I think it may be normal to loose control except with high thrust (with vectoring) and a very good design. I think in re-entry, the ship is under drag instead of thrusting forward so that throws off the normal flight characteristics.

A craft stable at sea-level is very different from a craft stable during re-entry. Correct me if I'm wrong.

Example: Try putting any jet plane at 40km altitude.

Edited September 10, 2013 by loknar

[KerbMav]

@KerbMav: Try getting rid of all of a specific wing type (like, say, the delta wing part, or the standard control surface) and see if that changes things. Also check the vertical tails to make sure they're exactly straight, since that has been a source of that bug.

Took off almost everything wingy - nothing. But: When I took off and reattached the small wings with the jet engines the COL was as centered as never before ... Butbut: The plane still rolls to the right.

@KerbMav: No possibility you have an inverted command pod, mechjeb or reaction wheel unit anywhere? I managed a spectacular recreation of the recent Proton rocket failure by having an inverted inline reaction-wheel unit in the stack, managed the same by putting a command pod upside down and deciding to look out through its window instead of sticking with the main command pod, and MechJeb can do wild tricks if one of its units is misplaced and has been the subject of a Control from Here input.

Navball looks OK. There is the cockpit, a small "autopilot" probe core somewhere attached in the original orientation the VAB offered me and one big "SAS" wheel - all three being there since I started building this monster. But since the other fiasco ... I will rip them off and built in new ones.

And: Since when does the location of reaction wheels matter? :shock:

What is getting to me is the wild way these problems turn up - first the thing wouldnt take off at all. Then it was unstable until a certain speed/height and flew straight up to 10k to then get out of control again. While trying to fix this the CoL drama started bringing with it the rolling after take off - which seemingly had nothing to do with the shifted CoL at all as it persists even after the CoL is straight!

And if that wasnt enough, before the last trial yesterday it split in two between the bay and the batterie! Which brings me to the conclusion, that there is a big problem with the SpaceJunk Cargo Bay and I should replace it with something else for testing.

But while I am here: Does FAR only affect Kerbin or does it change Eve (and Laythe) too?

Edited September 10, 2013 by KerbMav