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

[Hektos]

@Hektos: If no reproduction steps, no ability to address the issue. That's the way it works.[...]

Thanks for the help

[ferram4]

Ummm... what? But nothing changes physics-wise between flight view and map view at all; are you sure that it's not a coincidence or that something else isn't interfering? And I still need reproduction steps that include the minimum rocket needed to recreate it, since I haven't seen anything happen when switching to map view myself.

Full logs would be helpful, maybe. I dunno, this is just too weird to actually be caused by switching to the map.

[Hektos]

Ummm... what? But nothing changes physics-wise between flight view and map view at all; are you sure that it's not a coincidence or that something else isn't interfering? And I still need reproduction steps that include the minimum rocket needed to recreate it, since I haven't seen anything happen when switching to map view myself.

Full logs would be helpful, maybe. I dunno, this is just too weird to actually be caused by switching to the map.

Sorry I should have been more specific on my last post. Upon trying to recreate the conditions per your request, the NaN errors no longer happened. Rocket took off fine and map view didn't crash the game *shrug*

So in essence you "fixed" the problem for me, hence the thanks

A little more thought on the matter has lead me to have a sneaking suspicion it has to do with the trajectories mod though (it only shows in map view) and not having one of the buildings upgraded. I shall report back if I run across any more relevant information regarding the issue.

[Commissar]

Sorry I should have been more specific on my last post. Upon trying to recreate the conditions per your request, the NaN errors no longer happened. Rocket took off fine and map view didn't crash the game *shrug*

So in essence you "fixed" the problem for me, hence the thanks

A little more thought on the matter has lead me to have a sneaking suspicion it has to do with the trajectories mod though (it only shows in map view) and not having one of the buildings upgraded. I shall report back if I run across any more relevant information regarding the issue.

unless it's a "quantum" bug, where looking for the bug changes the bug

[Hektos]

Sorry I should have been more specific on my last post. Upon trying to recreate the conditions per your request, the NaN errors no longer happened. Rocket took off fine and map view didn't crash the game *shrug*

So in essence you "fixed" the problem for me, hence the thanks

A little more thought on the matter has lead me to have a sneaking suspicion it has to do with the trajectories mod though (it only shows in map view) and not having one of the buildings upgraded. I shall report back if I run across any more relevant information regarding the issue.

unless it's a "quantum" bug, where looking for the bug changes the bug

Whelp I spoke too soon. NaN lockup is easily reproduceable. However I am now 99% certain it is something to do with the trajectories mod.

Steps to reproduce:

1) Create any rocket with 4 R8 Winglets (My test rocket, all stock parts stock)

2) Go into map view

3) Launch the rocket

4) Activate trajectories

5) Lock up your game with NaN errors

I removed trajectories and was unable to reproduce this lock-up. However if you're at all still interested in tackling this problem, here is my output_log.

[ferram4]

We are quite fortunate that KSp mods are generally devoid of multithreading, so Schrodingbugs don't show up that often.

However, if there are NaNs appearing only with trajectories, my first guess would be that trajectories is doing something funny. You can try out the dev build of FAR (dll in the github repo, not the release itself) if you want to see if it makes a difference.

[Hektos]

We are quite fortunate that KSp mods are generally devoid of multithreading, so Schrodingbugs don't show up that often.

However, if there are NaNs appearing only with trajectories, my first guess would be that trajectories is doing something funny. You can try out the dev build of FAR (dll in the github repo, not the release itself) if you want to see if it makes a difference.

No dice, but thank you for trying good sir. I'll admit I have not done extensive testing on this (I would like to actually play the game ) so it may just be this specific situation.

I'll just drop trajectories for now as I can live without that for the time being.

[Redgum]

Certainly improves the way aircraft flew in base KSP. That much is certain.

However, I'm seeing some VERY incorrect physics at play now when rockets are in near space. One acted like a pendulum tonight. Amusing, but wrong. My Kerbalnaut screamed for a full 7 minutes and 18 seconds before he impacted kerba-firma. Someone at mission control could be heard a second after the firey impact saying, "he took a long ride on a short int."

This is what happens when 32 bit code tries to calculate 64-bit calculus problems.

*sigh*

[eddiew]

Hi Ferram,

Probably said it before, but great mod - really can't enjoy KSP without it

That said, pretty sure I've got a bug report for you! Putting an octagonal or cubic octagonal strut inside a fairing or cargo bay, reliably prevents the in-flight FAR window from opening, and the vessel will act very draggy. Not sure whether this is due to unshielded components (in the bugged bay/fairing) or whether it's reverted to a stock drag model. Either way, rockets that can launch without an octagonal strut often can't launch with one.

Happens to me consistently and reproducibly in FAR versions 0.14.5.1 and 0.14.6. Debug log contains...

[Exception]: ArgumentNullException: Argument cannot be null.

Parameter name: key

...and every FAR-button click on a bugged vessel produces another line of...

[Log]: [Orbit Targeter]: Target is null

Happily, scaling a regular modular girder down to a similar size causes no such error, so there's a viable workaround

Thanks!

[DaMichel]

It's me again ;-> I have another issue with the current dev version. For some reason none of the intake parts get FAR modules attached to them as evident by FARs editor debug gui. Not sure what is wrong. My stuff seems up to date and i didn't see any errors. Can someone confirm the issue?

@Redgum: Sounds like your upper stage was aerodynamically unstable. Anyway, in such cases more info is needed.

[ferram4]

@Redgum: If your rocket is acting like a pendulum, I'd suggest cutting its connection to the ground. If that's not the problem, you need to describe it more clearly.

@eddiew: I need a full copy of the output_log.txt, since I haven't seen any issues with physicsless parts in cargo bays.

@DaMichel: Update all your FARPartClassification files and get rid of the custom one, intake handling has moved back into code, not MM.

[Behemoth1702]

ferram4,

any thoughts about that donation possibility for mod users to support you?

Also - is it cool to use the most recent dev build dll from gitHub? I really like how you "fixed" the drag behind air intakes issue and would like to use that.

Also - in FAR Settings there is a "use splines for supersonic math" - where can I read up on this? Is this good for performance? What does it do?

Thanks!

[eddiew]

@eddiew: I need a full copy of the output_log.txt, since I haven't seen any issues with physicsless parts in cargo bays.

Well, lol, problem resolved! I checked that log right after it had had the error, and down at the bottom...

Parameter name: key

at System.Collections.Generic.Dictionary`2[PartJoint,KerbalJointReinforcement.KJRMultiJointManager+TwoConfigJointTuple].TryGetValue (.PartJoint key, KerbalJointReinforcement.TwoConfigJointTuple& value) [0x00000] in <filename unknown>:0

at KerbalJointReinforcement.KJRMultiJointManager.RegisterMultiJoint (.PartJoint partJoint, UnityEngine.ConfigurableJoint multiJoint) [0x00000] in <filename unknown>:0

...etc.

...which is KJR, not FAR, and ohgahdimnotrunningthelatestkjr... Updated KJR from 3.0 to 3.0.1. Problem went away. Apologies for the misreport, and thanks for the multiple quality mods

[DaMichel]

@DaMichel: Update all your FARPartClassification files and get rid of the custom one, intake handling has moved back into code, not MM.

Thanks i have to remember that. I thought Git would take care of this but i was wrong.

[Hyomoto]

Just wanted to pop in to say thank you. 14.6 has been the best version yet, flying has been an absolute delight.

[camlost]

@ferram4, Seems like bac9's new procedural wing is till having problems in wing interaction. Trailing edge flaps behind a proc wing stalls early.

[Wanderfound]

Slashy made a ramjet for stock: http://forum.kerbalspaceprogram.com/threads/106156-I-made-a-ramjet%21

Now that FAR's skin drag has turbos struggling to get much past Mach 4, there's not really a need for further nerfing in FAR. But there is a gap for a low hypersonic jet that doesn't work at low speeds...

Anyone feel like hacking together a FAR ram/scram jobbie?

[Northstar1989]

@Ferram4

So, I guess my praise/flattery/attempt to get you to approach Squad about helping overhaul aerodynamics (if you haven't already) went completely unnoticed?

I really hope you'll give it a try. KSP could really use great work like yours in the stock game. Keep in mind they'll probably be willing to pay you for your work (as I understand it, this is what they've done with other modders like PorkJet). Probably not a ton, mind you (Squad's not exactly loaded), but every little bit helps, right?

Regards,

Northstar

[ferram4]

@camlost: Define "early." If it stays unstalled until it's above 25 degrees of deflection from the airstream, it's not early.

@Wanderfound: If you're gonna do that, nerf the turbojet even more. There's no reason for it to go past Mach 3 if you're gonna produce something else that can do better.

@Northstar1989: I offered it to them (through Ted) on IRC twice; once quite some time ago, and again shortly after they announced they were overhauling aero. I have heard nothing from them. Come to your own conclusions from that.

[mecki]

Thank you for this awesome mod, it makes KSP so much more enjoyable for me!

Edited January 5, 2015 by mecki

[camlost]

@camlost: Define "early." If it stays unstalled until it's above 25 degrees of deflection from the airstream, it's not early.

Minor stall at 10-15 degrees regardless of the AR of the wing before it.

[cantab]

Regarding ram/scramjets, I think in the stock system a ramjet would be interesting. I'd say give next to no thrust below about Mach 0.5 and be a fuel-guzzler at subsonic speeds, and rise to ideal performance at maybe Mach 5-6. While "better" than the turbojets in some respects, no low-speed thrust would make it harder to use; you'll need to take off using your rockets which means you need bigger rockets, or another jet which becomes deadweight later on.

As for a scramjet, well in the stock system orbital speed is around Mach 6-7 so there's not a lot of "room" for various jet engines. In an enlarged system though there's a lot more place for a scramjet operating into double-digit Machs.

[kmacku]

So, I'm having a recurring problem, and I think it's leading to difficulty in flying, or at least it's hampering my ability to design spaceplanes. I have the basics down at least: CoL, CoM and where they should be in relation to one another, how to check where that balance shifts as fuel burns, so on. Literally everything I design faces a few red (incorrect) numbers, and they're usually if not always the same culprits.

It's usually (if not always):

Mw (is positive, should be negative)

Yß (is positive, should be negative)

Lß (is positive, should be negative)

Lß is the big one; it's red on every one of my designs, but there are a few others that pop up in that Lateral Derivatives zone, and I just have zero concept of how to get them "righted".

This was with an entirely symmetrical spaceplane of really simple design, before I've added any science modules, ladders, gear, accessories, snacks, etc. to it. I usually run my tests at 10km and Mach 1, but I jump around with different altitudes and speeds to see if things change, but they pretty much remain constant.

Any help would do!

[bukschr]

Hello, I recently installed FAR and I didn't originally know there was even supposed to be a gui in the editor. I read through some pages and haven't been able to get the gui to display. I reinstalled FAR and also deleted the config. I'm not sure how to post the log without copying and pasting it. I use a few mods: 000_Toolbar, ATM, Community Resource Pack, FAR, KAS, Kerbal Engineer, KWRocketry, Docking gui, Open Resource System, ORSResourcePack, Procedural Fairings, Tech Manager, Trigger Tech, TweakScale, and WarpPlugin.

[ferram4]

@camlost: For the control surface itself? Meaning, the wing is at 0 AoA, the control surface deflects to 15 AoA, and it's stalling? If that's the case, it's an issue of the wings not having their colliders set up early enough; ultimately, nothing I can do.

@kmacku: Mw wrong means that it's pitch unstable; for your test case, the CoL is in front of the CoM.

Yß wrong means that it's yaw unstable; you require more vertical tail.

Lß wrong means it's roll unstable; attach the wing higher up / add more backward sweep / add additional dihedral.

Also, testing at Mach 1 is a terrible idea. Most planes behave terribly at Mach 1 and you never spend much time there. Check above an below it, but right near it is a regime you'll not spend much time in.

@bukschr: Either improper install, in which case the game should have yelled at you, or you're on the win64 build of KSP, which is not supported (and which FAR disables itself on) due to the build's many inherent bugs and instabilities. If you are using the win64 build, then either switch to win32, Linux64, or decide not to use FAR.