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

[ferram4]

@run1235: There was a fix for an issue like that in the current update. However, if you're using CKAN, you're not eligible for support here; there is a CKAN-specific thread linked in the OP for CKAN users to help isolate CKAN-specific issues.

[Ser]

ferram4, As I remember, in the times of Fanno or Ferri it was impossible to go straight up to 100km, then drop straight down and survive because chutes were unable to reduce vessel's speed until you hit the ground in that case. Going suborbital you had to necessarily choose a shallow trajectory. Reentries were kinda nightmare: if you chose too shallow reentry you burned, if it was too steep you hit the ground at 400 m/s. Now it feels like viscosity of the air has got higher: it's not a problem to drop your speed to 200 m/s in atmosphere even without using any chutes, just let the vessel fall down. Things have got too easy. Is that right?

[tetryds]

@Ser: you just get a lot of transonic drag that was not being modeled that well before.

Blunt bodies behave better than ever.

[Ser]

tetryds, No doubt in that, aerodynamic model is wonderful. But are the things realistic now? From the point of final result, not the way they are modeled.

[sashan]

Not possible. There were no changes to the code that calculate the main axis between 0.15.4 and 0.15.4.1. I see that the FAR icon isn't showing up for you; did you install this using CKAN, or make any error in a manual install?

There is an icon, one of those white ones. Menus shows up when I press it. FAR works just fine, aside from that display bug. The plane flies fine too. It's active texture management screwing up icons, I'm used to it.

It installed manually. I am a little bit of modder myself, so I don't screw up such easy things.

I didn't update it before that bug happened. I did it now, will try it out in the evening.

How is water handled? I assume that similarily to air but with different rho and mu? Cause I sometimes ditch planes with better buyoancy installed, and they are fine from the point of view of collision tolerances, but break up due to aerodynamic stresses.

Edited July 30, 2015 by sashan

[Amedee]

I'm just letting you know that I started again from scratch. Deleted my entire KSP directory, all saves, all crafts, all mods. Download KSP 1.0.4 from Steam. I am now reinstalling all mods, one by one, in a paranoid way, putting every little change as a separate git commit, and checking both log files (ksp.log + player.log) for anything suspicious before I continue to the next mod. Current rate is about 1 mod per day (this includes reporting any errors I find and following them up), so I calculate that around April 2016 I will actually be able to play the way I want.

Installed so far:

[TABLE]

[TR]

[TD]ModuleManager[/TD]

[TD]2.6.6[/TD]

[/TR]

[TR]

[TD]Community Tech Tree[/TD]

[TD]2.1[/TD]

[/TR]

[TR]

[TD]Stock Bug Fix Modules[/TD]

[TD]1.0.4b.1[/TD]

[/TR]

[TR]

[TD]KSP-AVC[/TD]

[TD]1.1.5[/TD]

[/TR]

[TR]

[TD]Ferram Aerospace Research[/TD]

[TD]0.15.4.1_Goldstein[/TD]

[/TR]

[/TABLE]

I saw this in Player.log:

NullReferenceException
  at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject ()
  at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 
  at ApplicationLauncher.ScaleModList () [0x00000] in <filename unknown>:0 
  at ApplicationLauncher.RemoveModApplication (.ApplicationLauncherButton button) [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARDebugAndSettings.OnDestroy () [0x00000] in <filename unknown>:0

And this in KSP.log:

[LOG 12:32:18.328] MFIManager Start Post RemoveModuleOfType. Current modules coVesselModule : 
  ModularFI.ModularFlightIntegrator active=True order=0
  FerramAerospaceResearch.FARAeroComponents.FARVesselAero active=True order=0
  FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI active=True order=0

[EXC 12:32:18.333] NullReferenceException: Object reference not set to an instance of an object
    FerramAerospaceResearch.RealChuteLite.ChuteCalculator.GetApparentDiameter (.DragCube cube)
    FerramAerospaceResearch.RealChuteLite.ChuteCalculator.Start ()

(...)
[EXC 12:54:12.381] NullReferenceException
    UnityEngine.Component.get_gameObject ()
    ApplicationLauncher.ScaleModList ()
    ApplicationLauncher.RemoveModApplication (.ApplicationLauncherButton button)
    FerramAerospaceResearch.FARDebugAndSettings.OnDestroy ()

Dropbox link to KSP.log, Player.log, .craft file: https://www.dropbox.com/sh/ueufcsaou21kkvy/AACyygfjum0_zZyobNQ_u_iya?dl=0

I did not notice anything abnormal during gameplay, but because I am paranoid, I am suspicious of any Exception and I will not have confidence before my logs are 100 Exception free.

Question

Would the FerramAerospaceResearch.RealChuteLite Exception be solved if I installed the actual RealChute? I am guessing that FAR's RealChuteLite would be disabled if RealChute is detected? Or am I talking nonsense?

Answer to my own Question

Installing Realchute 1.3.2.3 solves the FerramAerospaceResearch.RealChuteLite Exception.

However, now I get another FAR Exception at the end of Player.log, preceded by a RealChute Exception (which I will report in the RealChute thread):

NullReferenceException
  at (wrapper managed-to-native) UnityEngine.Component:InternalGetGameObject ()
  at UnityEngine.Component.get_gameObject () [0x00000] in <filename unknown>:0 
  at ApplicationLauncher.ScaleModList () [0x00000] in <filename unknown>:0 
  at ApplicationLauncher.RemoveModApplication (.ApplicationLauncherButton button) [0x00000] in <filename unknown>:0 
  at RealChute.RCToolbarManager.RemoveButton () [0x00000] in <filename unknown>:0 
  at EventVoid.Fire () [0x00000] in <filename unknown>:0 
  at ApplicationLauncher.OnDestroy () [0x00000] in <filename unknown>:0 

(Filename:  Line: 4294967295)

NullReferenceException: Object reference not set to an instance of an object
  at Versioning.get_version_minor () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.CompatibilityChecker.IsCompatible () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.CompatibilityChecker.IsAllCompatible () [0x00000] in <filename unknown>:0 
  at FerramAerospaceResearch.FARDebugAndSettings.OnDestroy () [0x00000] in <filename unknown>:0 

(Filename:  Line: 4294967295)

This is at the very end of the file, probably when I close the game.

Current mods:

[TABLE]

[TR]

[TD]Name[/TD]

[TD]Version[/TD]

[/TR]

[TR]

[TD]ModuleManager[/TD]

[TD]2.6.6[/TD]

[/TR]

[TR]

[TD]Community Tech Tree[/TD]

[TD]2.1[/TD]

[/TR]

[TR]

[TD]Stock Bug Fix Modules[/TD]

[TD]1.0.4b.1[/TD]

[/TR]

[TR]

[TD]KSP-AVC[/TD]

[TD]1.1.5[/TD]

[/TR]

[TR]

[TD]Ferram Aerospace Research[/TD]

[TD]0.15.4.1_Goldstein[/TD]

[/TR]

[TR]

[TD]RealChute[/TD]

[TD]1.3.2.3[/TD]

[/TR]

[/TABLE]

Edited July 30, 2015 by Amedee
Add a question

[damerell]

tetryds, No doubt in that, aerodynamic model is wonderful. But are the things realistic now? From the point of final result, not the way they are modeled.

In a DRE world that sort of re-entry doesn't work because the very high Gs of deceleration kill the crew, as they should. I'm guessing you don't have DRE installed?

[cantab]

ferram4, As I remember, in the times of Fanno or Ferri it was impossible to go straight up to 100km, then drop straight down and survive because chutes were unable to reduce vessel's speed until you hit the ground in that case. Going suborbital you had to necessarily choose a shallow trajectory. Reentries were kinda nightmare: if you chose too shallow reentry you burned, if it was too steep you hit the ground at 400 m/s. Now it feels like viscosity of the air has got higher: it's not a problem to drop your speed to 200 m/s in atmosphere even without using any chutes, just let the vessel fall down. Things have got too easy. Is that right?

Here's a discussion of the Apollo entry

http://space.stackexchange.com/questions/2661/what-was-apollo-11s-reentry-speed-at-parachute-deployment

This indicates that drogue chute deployment was at around 7 km up at a speed of merely 100 m/s or so. Obviously these things depend on spacecraft design, and of course Apollo never did a straight-down entry, but this suggests that if anything FAR is still not applying quite enough drag to a blunt object

[Ser]

Amedee, have you ModularFlightIntegrator of version 1.1.1 installed? Also I have some weird issues with StockBugFixes.

In a DRE world that sort of re-entry doesn't work because the very high Gs of deceleration kill the crew, as they should. I'm guessing you don't have DRE installed?

I have it installed. More of that I set Convection parameter to 40x for the reentry had some sense, not just a walk in the park. But I'm not speaking about orbital reentry with 2900 m/s at 100 km Apo, but just the simple up-down flight, with 0 m/s at 100 km Apo. And everything works fine with G's barely higher than 2x.

Here's a discussion of the Apollo entry

http://space.stackexchange.com/questions/2661/what-was-apollo-11s-reentry-speed-at-parachute-deployment

This indicates that drogue chute deployment was at around 7 km up at a speed of merely 100 m/s or so. Obviously these things depend on spacecraft design, and of course Apollo never did a straight-down entry, but this suggests that if anything FAR is still not applying quite enough drag to a blunt object

So do you mean that drag should be even greater?

P.S. Christ! I knew that the latest chute model in KSP is inadequate but I never thought that it is THAT bad, as mains open normally at 300, 500, 1000 m/s.

Edited July 30, 2015 by Ser

[Amedee]

Amedee, have you ModularFlightIntegrator of version 1.1.1 installed?

I have the ModularFlightIntegrator that came with FAR. According to it's .version file, it is 1.1.1, which is the most recent version AFAICT.

Why?

Also I have some weird issues with StockBugFixes.

If I don't have StockBugFixes installed, I have a lot more Exceptions. Now I only have one Exception left that is related to StockBugFixes, and that's in ClawKSP.MGNFix. The StockBugFixes dev is already aware of the issue and is working on it. I do not have any "weird" issues with StockBugFixes. I suggest you report any issues over there in the relevant thread, it's not related to FAR.

[Ser]

Amedee, just wanted to help as your exceptions look familiar for me. But ok, if you don't want that, I'll stay away.

[includao]

I have seen that FAR copies ModuleParachute to transform it into RealChute. Does editing the dragModifier DEPLOYED cube and the fullyDeployedDrag allows me to create a super sized parachute that works under the FAR model? I followed http://forum.kerbalspaceprogram.com/threads/120691-cfg-modding-parachutes to try to make my custom parachutes but it doesn't seem to work properly (I've deleted PartsDatabase.cfg).

Edited July 30, 2015 by includao

[ferram4]

@Ser: Pods smacking into the ground at 400 m/s was never a realistic thing and points instead to an error calculating drag.

@Amedee: You need to provide actual reproduction steps. The AppLauncher exception is something I've never seen.

The RealChuteLite exception is known, but that's stupid_chris's territory. The ComaptibilityChecker exception is known, but harmless.

@cantab: That would be a good comparison... if the stock pods were not overly dense for their size. Note that the 3-man pod weighs as much as the Apollo capsule, while only being 2.5m diameter rather than the 4m diameter of Apollo. That will lead to the forces being 0.391 times that of real life, resulting in a terminal velocity of 1.6 times the real life equivalent. Currently, things seem to be correct.

@includao: Maybe? That's stupid_chris's code, no idea what happens in there.

[soulsource]

Hi! I've got an issue with the latest release (Goldstein). Parts are incorrectly labelled as stowed on my munar orbital station. This issue is not present with the previous release (Glauert).

I've tried to bisect, but I was too lazy to recompile, so I just copied the .dll files from the git repo. Anyhow, the first bad commit seems to be:

commit f47eb0360d6fa05d02c10a127ae7e08fa403f445

Author: ferram4 <snip>

Date: Sun Jul 26 17:04:27 2015 -0400

messing with voxelization a bit

Edit: If it helps, the player.log with Goldstein:

Part 1

Part 2

Part 3

Part 4

Part 5

Edited July 30, 2015 by soulsource
Redacted email address, this forum is indexed.

[Amedee]

@Amedee: You need to provide actual reproduction steps. The AppLauncher exception is something I've never seen.

You do not have to worry about the AppLauncher exception (not for me anyway), because it does not occur when RealChute is installed.

The RealChuteLite exception is known, but that's stupid_chris's territory.

I know that, and I will report it in the RealChute topic. Don't worry about it. I just mentioned it to give context.

The CompatibilityChecker exception is known, but harmless.

Any exception still freaks me out, because I cannot know if it is harmless. But OK, if you say so. Will it be fixed some day?

[gilflo]

Thank you Ferram for the update, but as you said temp bug still there .

It looks like if you have more than one vehicle, for example a cargo with a satellite inside or with a small jet on roof, the bug is more active (more parts i suppose) and needs to be fix by mean of Conduction factor.

But what is surprising is that it seems there is no rules. By decreasing conduction factor, temp on ground can decrease to 288 but can also increase to 500 or 900, it looks like trying decreasing values gives erratics jumps towards lower or higher temp!

[ferram4]

@soulsource: I need full reproduction steps; there were no changes in that commit that would affect anything being "stowed" and many of those changes were superseded by the next commit.

And please don't link your log like that, it's a pain to try and go through. Use dropbox or another file hosting site without such a tiny limit.

@Amedee: Well, if the AppLauncher exception occurs, and I have no data about it, I have to worry. You're the only one who's had that occur, so yes, I have to worry about it.

No idea if there is a way to fix the CompatibilityChecker exception. It's throwing from a static class when the scene is ending; I don't know if there's a way to even detect what's going on there besides a try{ ... } catch{ //Do nothing } block.

@gilflo: And that's why I'm more annoyed with people blaming it on FAR than anything else. It's not like I have any means to fix a bug created by Squad that they're not willing to hotfix.

[Nansuchao]

I found another solution to the heating bug. First, use Ignore Max Temp from the Cheat menu, if you know that your ship has this problem. Then, if you have KER to check the temperatures, you'll see that they can reach very high level on TimeWarp. In real time instead, they tend to slowly return normal. When the temp begin to decrease, use TimeWarp (no more that 50X) to speed the cooling process, then save. After a certain amount of time, those part will begin to overheat again, but you can quickload and avoid much trouble. The sad side is that in this way, you need to avoid the use of TimeWarp, except from KSC.

[gilflo]

@gilflo: And that's why I'm more annoyed with people blaming it on FAR than anything else. It's not like I have any means to fix a bug created by Squad that they're not willing to hotfix.

But is there really a heat bug when using KSP without FAR?. As far as i tried without FAR, i did not see the same kind of bug, aircraft stationnary on ground and heating up to explosion. I had some heating problem during climb but it could be du to a bad choice of speed and path....so that's may be why they don't consider any heat bug and won't fix it!

[blowfish]

But is there really a heat bug when using KSP without FAR?. As far as i tried without FAR, i did not see the same kind of bug, aircraft stationnary on ground and heating up to explosion. I had some heating problem during climb but it could be du to a bad choice of speed and path....so that's may be why they don't consider any heat bug and won't fix it!

The reports I've seen suggest that it exists in stock, but that FAR makes it worse.

[Ser]

ferram4, with Goldstein I have the drag halo around vessel's surfaces appear too early, at approx. 80 m/s. And it's FAR that causes it somehow because removing FAR fixes it. I think it shouldn't appear at that speed but if that's intended is there a way to get rid of it as it is unrealistic and impedes the view too much?

Edited July 31, 2015 by Ser

[steve_v]

But is there really a heat bug when using KSP without FAR?.

Well I've certainly been able to reproduce it in stock, though FAR does exacerbate it, for reasons explained previously.

[soulsource]

I've been trying to find an easy way to reproduce the issue with parts being marked as stowed for hours now, but didn't manage to. It only appears on my munar station, and there also only when switching to the vessel. When I undock one of the station parts - the fuel depot, and dock it again, the issue is gone, until I switch to another vessel or KSC and back. Similar when I undock two of the other station parts and redock them again...

I've even built a (nearly - of course I had to remove the fairings that would have otherwise blocked the docking port of the fuel section) perfect replica of the munar station (from the saved station parts) and put it on the launch pad. It doesn't have any issues...

Nevertheless, there's one thing I've done on the munar station, and that was that I mounted a few additional solar panels using KIS. Maybe that's the cause of the issue. Only funny that it doesn't surface with the older FAR build...

So, I have two hypotheses: Either it's some issue with KIS-mounted parts, or it has something to do with using stock fairings to manually "shield" docking ports...

I have uploaded my save, just in case you want to look at the affected craft - Munstation Core, which requires FAR and RealChute, and which is unable to transmit any science since the antennas are marked as stowed, but as I'm not able to give you a better way to investigate the issue, I'd say, let's ignore it for now, until someone manages to find an easy way to reproduce, or even investigate it.

Edited July 31, 2015 by soulsource

[Tarheel1999]

If it's not reproducible, it's hard to test for and fix.

[soulsource]

I know, that's why I suggest to ignore it for now. Reproduction of the issue itself is easy, as it happens every time with the munar station in the linked save file. One just needs to try to transmit science from it. The antenna won't deploy. It's nevertheless pretty hard to build a craft in the VAB that shows the same behaviour...