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

[Svm420]

Hey ferram How can I add the animation for lights turning on and off to the animation orvide fle from the latest dev branch. Is this correct? Thanks!

FARAnimOverride
{
	moduleName = FSanimateThrottle
	animNameField = animationName
	moduleName = ModuleLight
	animNameField = animationName
}

[ferram4]

@Gaiiden: Ack, lots of part mods.

@Gaiiden & Svm420: Instead of working on a specific craft, get me reproduction steps to reproduce the issue with no other mods / as few mods as possible on the vehicle. It points to something breaking in either the save or load code for some module if it's corrupting craft files, but I have no idea what could be causing that.

@Svm420: I think that should work fine for the lights.

@Shurikeeen: It looks like there is a collider on the vehicle that isn't oriented right for some reason. This requires going into the asset itself and setting everything up correctly. If that's not it, no idea, there's nothing i can do for broken assets.

[blowfish]

Hey ferram How can I add the animation for lights turning on and off to the animation orvide fle from the latest dev branch. Is this correct? Thanks!

FARAnimOverride
{
	moduleName = FSanimateThrottle
	animNameField = animationName
	moduleName = ModuleLight
	animNameField = animationName
}

They need to be in separate FARAnimOverride nodes.

[Svm420]

They need to be in separate FARAnimOverride nodes.

Thanks I wondered. Maybe add a example commented out? or just another blank node to indicate such? Either way thank you both for make that happen and very quickly I might add

[Drew Kerman]

Ack, lots of part mods.

Hah! A small fraction, really

Instead of working on a specific craft, get me reproduction steps to reproduce the issue with no other mods / as few mods as possible on the vehicle. It points to something breaking in either the save or load code for some module if it's corrupting craft files, but I have no idea what could be causing that.

Well, it seems for me at least the problem mostly stems from this issue somehow. I went back to 0.90, loaded the craft file in the VAB and re-rooted so the RCS tank was no longer the root, then I copied the .craft file over to my 1.0.4 install and it loaded up in the VAB with no errors related to FAR. Ferram if you feel this issue could have farther-reaching consequences I'll continue to look into it further, otherwise for me it seems solved - I no longer create craft with that tank as a root part.

[Basilicofresco]

Hi! I'm experiencing overheating problems for no reason with a space station orbiting Minmus. Apparently the skin temp of some solar panels keep rising and therefore several parts are glowing red. Just to be sure, I installed additional large radiators but they did not help. Disinstalling FAReverything comes back nomal... is there anything else I can do in order to solve or avoid the problem?

KSP 1.0.4

FAR 0.15.4.1

TAC Life Support 0.11.1.20

KerbalEngineer 1.0.18.0

SCANsat-v14.1 (you don't need it to load the minmus space station)

It's is a career game started from zero from the version 1.02.

Here is the quicksave, let me know if you need additional details.

http://drive.google.com/file/d/0B6xCI60sZ39TNUFsTDZvR180azg/view?usp=sharing

Thanks in advance!

[Svm420]

Hah! A small fraction, really

Well, it seems for me at least the problem mostly stems from this issue somehow. I went back to 0.90, loaded the craft file in the VAB and re-rooted so the RCS tank was no longer the root, then I copied the .craft file over to my 1.0.4 install and it loaded up in the VAB with no errors related to FAR. Ferram if you feel this issue could have farther-reaching consequences I'll continue to look into it further, otherwise for me it seems solved - I no longer create craft with that tank as a root part.

I don't think telling him that you found a way to avoid it helps him. He wants 100% reliable reproduction steps so he can do it on his computer and fix it if he can. I would say that that issue is not the cause as I had the same thing happen to me as you did and I did not scale the root part.

[ferram4]

I somewhat doubt that that is the actual cause. I can see it messing up the resulting voxel, but it wouldn't cause anything to throw.

Workarounds are great, yeah, but they don't fix the bug you reported. If we all go along with this, I'll just get someone else coming in here with the same issue down the road (maybe you again) and we'll get to do this whole song and dance again.

Unless the bug can be traced to another mod, to the stock game alone, or to an older version of FAR that has been superseded by a development version, the issue isn't fixed; currently this is one of two remaining things that are holding up a new release, and since it seems to be a "break crafts completely on loading when there's no reason for it" kind of issue, it's kind of important to fix it.

[Shurikeeen]

@Shurikeeen: It looks like there is a collider on the vehicle that isn't oriented right for some reason. This requires going into the asset itself and setting everything up correctly. If that's not it, no idea, there's nothing i can do for broken assets.

Yeah, a collider sifted during the Unity export apparently

[Gryphon]

Yeah, a collider sifted during the Unity export apparently

http://i.imgur.com/w7veolP.png

Well, then it looks like it was voxelizing correctly!

[HoneyFox]

Ferram, I have a couple of very bizarre things to report, and I *think* they can be reproduced if you use the same parts I am. Latest GitHub version of FAR.

If using QuizTech in-line 1.25m VTOL engines on a craft, certain lifting surfaces won't have any lift.

Secondly, when they're not producing lift (maybe when they are, too), BahaSP VectorJets, at least, will read as producing thrust but won't actually produce any if there is one of these dead lifting surfaces in its path. Check this out - picture illustrates both phenomena, bizarre craft for testing purposes. The two similar white cylinders on either side are the QuizTech engines, and the jets are the Baha VectorJets.

Note the wings producing lift, but the horizontal stabilizers aren't - same AoA and everything. There isn't even a nub of a lift/drag indicator like there is on stationary parts normally.

https://dl.dropboxusercontent.com/u/59567837/noTailLift.png

I remember that I've seen some code logic which will ignore the ctrl surface if: 1. it's behind some other thing (perhaps by raycast or by voxel checking? i don't remember that clearly) and 2. its deflection angle is not big enough.

[AccidentalDisassembly]

I remember that I've seen some code logic which will ignore the ctrl surface if: 1. it's behind some other thing (perhaps by raycast or by voxel checking? i don't remember that clearly) and 2. its deflection angle is not big enough.

I found out that the problem was caused by the presence of FARBasicDragModel (or whatever it was) definitions in the part file, which were not being removed because the MM patch to remove them lacked necessary curly braces {}. At least that's what I think caused the problem.

[ferram4]

Except that would have no affect on a control surface since none of them ever had FARBasicDragModel attached to any of them, and so could have no affect on control surface behavior. I believe that the issue was traced to a main axis determination issue that should be resolved now.

[Drew Kerman]

I somewhat doubt that that is the actual cause. I can see it messing up the resulting voxel, but it wouldn't cause anything to throw

Okay, I investigated further and turns out it's due to my own ineptitude. See for yourself - Line 12598 in the .craft file I included in my output_log archive has an empty Link property. It seems when I manually edited out the launch clamp part attached to the engine at the bottom (game wasn't running when I decided I didn't want the clamp included in the save file and I was too lazy to run it just for this) I properly deleted the entire bottom node attachment but only deleted the part reference from the Link and not the whole line itself.

Reproduction steps (tested on stock parts, with only Squad, FAR, MFI and MM mods installed):

- Create a new craft

- start with any root part

- node-attach a second part beneath the root part

- node-attach a third part beneath the second part

- Save the file

- exit the game

- open the file in a text editor

- delete the entire PART{} for the third part

- in the second PART{}, delete the line attN = bottom,[partname_####]

- above that, removed the [partname_####] reference from the link property but leave it as "link = "

- save the craft file

- restart the game, go into the VAB and load the craft - NRE spam ensues

I don't seem to get a framerate hit, probably because this test case has 3 parts vs 75

Edited August 18, 2015 by Gaiiden

[HoneyFox]

Hi ferram. I've been working on a modified version of FAR which allows player to attach lua scripts (which can be reloaded at runtime so it will be easier to debug) to any control surface so that certain control surfaces can be controlled via cuztomized logic if needed. I know that this might be overcomplicating things a bit but I just want to inform you of it.

[ferram4]

@Gaiiden: Uhhhh... in this case, this is basically a case of a broken craft file, not a mod bug. I suspect plenty of things will be broken in that case, not just FAR-related. Particularly anything that relies on the game being able to figure out the root part of a craft in the editor.

Okay, I was seriously concerned that it was a nasty rare bug that I introduced somewhere. Okay, this is much better.

@HoneyFox: There is no such thing as overcomplication.

[Drew Kerman]

@Gaiiden: Okay, I was seriously concerned that it was a nasty rare bug that I introduced somewhere. Okay, this is much better.

Yea, sorry about that. I also didn't mean to make it sound like it was something I expected you to fix, just wanted to make it clear this was in fact the actual cause since I was wrong originally. Also hopefully it clues in Svm420 somehow? Not sure now how our issues are closely related

[Basilicofresco]

Hi! I'm experiencing overheating problems for no reason with a space station orbiting Minmus. Apparently the skin temp of some solar panels keep rising and therefore several parts are glowing red. Just to be sure, I installed additional large radiators but they did not help. Disinstalling FAReverything comes back nomal... is there anything else I can do in order to solve or avoid the problem?

KSP 1.0.4

FAR 0.15.4.1

TAC Life Support 0.11.1.20

KerbalEngineer 1.0.18.0

SCANsat-v14.1 (you don't need it to load the minmus space station)

It's is a career game started from zero from the version 1.02.

Here is the quicksave, let me know if you need additional details.

http://drive.google.com/file/d/0B6xCI60sZ39TNUFsTDZvR180azg/view?usp=sharing

Thanks in advance!

Is it a known problem?

[cantab]

Is it a known problem?

Known bug, Ferram says it's not is fault and there's nothing he can do about it. A partial workaround is to turn on the "Ignore Max Temperature" cheat, but you still experience other consequences of overheating - solars stop working, ablator disappears, and your ship glows white hot ruining your screenshots.

[DaMichel]

Also try lowering the conduction factor (ALT-F12 -> physics -> thermal). It might be enough to keep temperatures normal.

[Xgkkp]

Few minor questions on the stability simulations.

• I assume that the third lateral box is supposed to say "Init r"??
  
• What is the blue line, phi, on this chart? (And theta on the longitudinal sim) I can't find mention of it on the Terms and Symbols nor stability notes pages.
  
• FAR used to have a popup over the chart values (certainly on the main lift/drag page) that was useful as a reminder of what the variables were. Was there a reason this went away? It was useful.
  
• This page colours Yp red if positive, however the main page doesn't. Less a question, more an observation - I imagine a minor bug?
  

[Gryphon]

Is it a known problem?

The stock heating calculations do poorly with some small parts, getting inaccurate results that lead to runaway heating. FAR makes this problem more obvious because it calculates the size of parts more accurately than stock.

What's interesting to me is that Starwaster's Deadly Reentry encountered a similar issue, also caused by extremely small parts (smaller than stock is having an issue with, IIRC). He worked around it by setting a minimum allowable thermal mass.

You probably want to read the thread discussing the problem and ways to work around it.

[ferram4]

@Basilicofresco: As I've said many times, I can't fix stock bugs. Complain to Squad, convince them to rush out KSP 1.0.5 rather than waiting for 1.1 and causing other bugs in the engine update.

@Xgkkp: 1. Yes, fixed that.

2. phi is roll angle, theta is pitch angle. Standard symbols in aerodynamic simulation in any textbook.

3. Got removed temporarily because it was getting out of date with the FAR version, the help button cluttered the UI, and no one ever reads them anyway.

4. Also fixed.

[Cairol]

When trying out 1.15.4.1 I encountered the problem that my nuclear rocket motors make attached fuel tanks overheat on the launchpad until they explode.

Even when putting radiators on the attached tanks, the tanks get hot and explode eventually.

No part clipping involved.

Without FAR installed, no problem.

I know that FAR is not the cause of this spontaneous overheat problem.

But it obviously still exaggerates the stock bug.

So I sadly have to uninstall FAR again until the stock bug is fixed or the exaggeration of the effect by FAR.

[Gryphon]

I know that FAR is not the cause of this spontaneous overheat problem.

But it obviously still exaggerates the stock bug.

So I sadly have to uninstall FAR again until the stock bug is fixed or the exaggeration of the effect by FAR.

As I noted above, various workarounds have been proposed.