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

[sashan]

The newest update breaks the VNG technologies mod. Parachutes on Kerbals no longer work. Any fix possible?

[tetryds]

I used the FAR mod and made a chart of the drag force. I am not sure if the drag is right; it increases after the speed of 300 m/s (?)

http://i.imgur.com/lMpGzAR.jpg?1

Yep, just like it should.

Check your critical Mach speed.

Also, which tools did you use to plot such data? That's cool.

An altitude plot would also be good together with that data.

Edited August 28, 2015 by tetryds

[ferram4]

@Kussris: Looks right, drag rises sharply at supersonic speeds, which is why most things stick to subsonic flow. The dropoff after implies that there's the confounder of decreasing air density though, so you'd get better data if you divided out by air density.

@sashan: Unfortunately, needs to be changed on the VNG side. If the parachutes aren't working, that implies that they're trying to work as a multiplier to the stock model, which is 0'd by FAR to let the voxel model do its thing; they would have to fix it by applying the drag force directly instead.

[cantab]

Ugh. Any pointers for fixing craft that seem to break FAR? In the SPH I get an IndexOutOfRangeException and a NullReferenceException when trying to use the static analysis or stability derivatives and no results there. In flight I don't seem to get any lift at all.

EDIT: Update. Reproduced in a clean 1.0.4 install with FAR 0.15.4.1 installed. .craft file and Player.log http://1drv.ms/1KgdUqa

By the way, loading it in Haack fixed this.

[DocMop]

I'm having some weird stuff going on with some parts. Mainly the 2.5m cargo bay from this mod:

http://forum.kerbalspaceprogram.com/threads/79542-1-0-4-SXT-Lack-s-Stock-Extension-New-props!-SXT-21-04AUG15-KSC-v3

I guess, pictures say more than words:

http://steamcommunity.com/profiles/76561197968773291/screenshot/621849045062868065

[ferram4]

That likely needs to be fixed on their end; probably what's happening is that the bay doesn't actually include colliders that close, completely / at all, and that screws up the voxelization. In that case, nothing I can do unless we're gonna bite the bullet and make voxelizing that a lot more expensive to use the mesh itself. I would much rather have the colliders fixed to keep it efficient, but I can't fix someone else's assets.

[TheHengeProphet]

I noticed that on occasion, the in-hangar FAR readout provides false information, but it's fixed upon reloading the craft. So, if anybody is looking at their data and thinking it wasn't what it used to be, reload the craft, and then look at the data.

It can also sometimes be fixed by raising and lowering your landing gear.

[Trolllception]

Not sure why my debug voxels are all crazy here. I am guessing this is why my cross section and pressure coefficients seem to be terrible. This is a brand new plane in 15.5

http://imgur.com/Ehb7SeO

Edit: Looks to be because of procedural parts and my 0 value ends. Increasing to > 0 fixed it.

Edited August 30, 2015 by Trolllception

[ferram4]

I've been using Pparts with 0-diameter ends with none of those problems, which indicates some other issue. In any case, if there is an issue, then likely it's something with how the mesh / collider is generated, because FAR is just reading off the mesh / collider. I can't fix that, it needs to be fixed on the Pparts end.

[BudgetHedgehog]

Ferram4, do you have any information on whether FAR will be enabled on 1.1 Win64 (assuming it exists) or stay disabled? By all accounts (the devs), it's performing admirably and U5 upgrade is apparently very stable, much moreso than previous Win64 builds, hacked or otherwise.

[ferram4]

Depends on whether my tests indicate that win64 is stable during experimentals. If it works, great. If it doesn't, and win64 still comes out despite remaining a mess, the lock will remain. Trust but verify. I'm hopeful, but I'm not going to back myself into a corner if everything falls through and it ends up being a situation where nothing has changed.

[BudgetHedgehog]

If it works, great. If it doesn't, and win64 still comes out despite remaining a mess, the lock will remain.

Fair enough, I completely understand. It'd be nice to use FAR and all my 16GB of RAM with an official, stable (and supported) Win64 build, here's hoping it's as good as Squad makes it out to be! Thanks for the info, much appreciated.

[Kussris]

@Kussris: Looks right, drag rises sharply at supersonic speeds, which is why most things stick to subsonic flow. The dropoff after implies that there's the confounder of decreasing air density though, so you'd get better data if you divided out by air density.

Thank you very much for the information!

[Drew Kerman]

Strange issue I narrowed down to FAR - I can't control my RCS jets once the voxel for my craft is updated. I suspect the craft voxel is updated immediately after the vessel loads because it has IR parts on it. Switching to the vessel, I can be holding down a key to thrust forward, see the jets come on and while still holding the key down the thrusters will stop firing and no longer respond at all once the log displays that the craft voxel has been updated. Stranger still is that I have other craft with the same IR parts and the same RCS ports attached to the same fuel tank and they work just fine - even when I see in the log the craft voxel has been updated. The craft with the issue looks like this:

I have three of these craft and they all have this problem unless I remove FAR and MFI. Here's my output log, I went straight to the craft, recreated the issue and Alt+F4'd out - search for "ShipManifestAddon.OnHideUI" as I pressed F2 before quitting to place a marker.

Not a huge issue because I can just remove FAR/MFI - it's not like I need them in space - but still puzzling. Maybe it thinks the RCS jets are stowed somehow? I should note this is a craft built back in I think 0.25 I've carried over into 0.90 and 1.0. This is one of the vessels VESSEL{} structure

[ferram4]

The voxel is updated immediately after the craft loads because it would really suck for the craft to enter an atmosphere and now need heating calculated, or for it to have parts that are covered in fairings that fire when they shouldn't. Nothing special about IR here.

Now, that said, FAR deliberately makes sure that engines, RCS jets, and a few other part types get priority in the voxel, so that they can't be borderline-exposed but then counted as stowed due to their voxels being overridden. So that points to the voxel being modelled as much larger than it should be and completely covering up the RCS jets there. Given the size of those jets relative to the rest of the vehicle, the problem is unlikely to be FAR itself; I suspect a part with a collider that is much larger than the visual mesh there creating the issue. Reproduce the issue with the fewest number of mod parts, and if it can't be narrowed down to one part being incredibly finicky, then I'll look at it. Until then, it's probably just an oversized collider from some other part.

[Drew Kerman]

The voxel is updated immediately after the craft loads because it would really suck for the craft to enter an atmosphere and now need heating calculated, or for it to have parts that are covered in fairings that fire when they shouldn't. Nothing special about IR here.

The voxel is actually updated twice during the craft load if you check the log, initially at the very beginning and then again when I guess IR and other stuff kick in. Other vessels without IR parts only have a single voxel update on load, so I was pointing a finger at IR for the second one.

Now, that said, FAR deliberately makes sure that engines, RCS jets, and a few other part types get priority in the voxel, so that they can't be borderline-exposed but then counted as stowed due to their voxels being overridden. So that points to the voxel being modelled as much larger than it should be and completely covering up the RCS jets there. Given the size of those jets relative to the rest of the vehicle, the problem is unlikely to be FAR itself; I suspect a part with a collider that is much larger than the visual mesh there creating the issue. Reproduce the issue with the fewest number of mod parts, and if it can't be narrowed down to one part being incredibly finicky, then I'll look at it. Until then, it's probably just an oversized collider from some other part.

Hrm, well I went and reconstructed the satellite in the VAB and couldn't recreate the problem on the launch pad:

The second voxel update hit and the jets kept firing. So I went back to my non-working sats and tried rotating the panels all the way around to see if at any point the RCS jets would fire. That didn't work. I suppose this could be chalked up to an old craft being brought forward into 1.0, since rebuilding it natively seems to have not caused any problems.

[ferram4]

But there is no difference between those vehicles. If the parts are the same, the meshes are the same, and the orientations of the parts are the same, then the voxels will be the same. FAR doesn't save any voxelization data, so there should be absolutely no difference between the newly-created and loaded-in-space version of the vehicle. Very strange; does one of the mods you're using save special mesh-based data for craft to load or something?

[Drew Kerman]

does one of the mods you're using save special mesh-based data for craft to load or something?

To my knowledge, no. I agree it's a strange issue. In this instance, I don't think I will be able to get to the bottom of it without a lot of work, and since I have the workaround of just removing FAR since these craft will never encounter atmosphere around Mun, I'm going to let it rest for now. If I come across another instance, I will let you know and hopefully the cause for that one will be more obvious.

Unless there's a way for me to check the status of the RCS thrusters? I couldn't find a way to see if the game considered them stowed or not

[soulsource]

Strange issue I narrowed down to FAR - I can't control my RCS jets once the voxel for my craft is updated. I suspect the craft voxel is updated immediately after the vessel loads because it has IR parts on it. Switching to the vessel, I can be holding down a key to thrust forward, see the jets come on and while still holding the key down the thrusters will stop firing and no longer respond at all once the log displays that the craft voxel has been updated. Stranger still is that I have other craft with the same IR parts and the same RCS ports attached to the same fuel tank and they work just fine - even when I see in the log the craft voxel has been updated. The craft with the issue looks like this:

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

I have three of these craft and they all have this problem unless I remove FAR and MFI. Here's my output log, I went straight to the craft, recreated the issue and Alt+F4'd out - search for "ShipManifestAddon.OnHideUI" as I pressed F2 before quitting to place a marker.

Not a huge issue because I can just remove FAR/MFI - it's not like I need them in space - but still puzzling. Maybe it thinks the RCS jets are stowed somehow? I should note this is a craft built back in I think 0.25 I've carried over into 0.90 and 1.0. This is one of the vessels VESSEL{} structure

Just out of curiosity, as I have similar issues that I couldn't reproduce in the VAB: Could you try your satellite with an older FAR version (Glauert, to be more precise, but make a backup of the save first, as Glauert still had overheating issues)? Maybe your issue is the same as mine... Not that this would help debugging it in any way, but it would at least kind of confirm my report.

[Drew Kerman]

...Could you try your satellite with an older FAR version...

Derp, that should have been the next thing I did after I narrowed the problem down to FAR.

So I have confirmed my RCS jets do indeed work under both Glauert and Goldstein after the craft loads. As soon as I dropped in Haack they failed to function again. I did notice that when I have my thruster keys depressed the altitude box drop down arrow turns red, signifying the thrust command is being executed (can't switch to Space Center) but nothing happens.

[cantab]

How does FAR handle the stock A.I.R.B.R.A.K.E.S? Is it simply done by the voxels when they're in their deployed position, or is there something special going on? I ask pursuant to discussion on how Trajectories handles (or doesn't handle) them.

[tetryds]

@cantab: at least for now, airbrakes behave like on stock.

This may change on the not so far future.

Edited September 2, 2015 by tetryds

[TheHengeProphet]

Knowing it's already bugged in a weird way, but I'll probe and see if I get an answer.

I get drastically different wave drag values when I load something than I do if I lower the landing gear and raise them again. The latter number is generally lower (almost exactly a difference of 0.2 m²), and I was wondering which number I should trust more: The number immediately after load, or the number from the update after landing gear actuation.

This difference is not just on that funky plane I sent you earlier, but it does seem to be involved with B9 Procedural wings.

[ferram4]

@The HengeProphet: Probably gonna be the latter one. Some weird things can happen starting stuff up.

@Gaiiden: Try the dev build on the master branch and see if that fixes your issue. I just fixed a rather critical voxelization error and I wanna see if that got it; if it did, I just need to do some testing and then a patch can be released to fix other bugs.

[sashan]

@sashan: Unfortunately, needs to be changed on the VNG side. If the parachutes aren't working, that implies that they're trying to work as a multiplier to the stock model, which is 0'd by FAR to let the voxel model do its thing; they would have to fix it by applying the drag force directly instead.

Is it possible to revert Kerbals to stock model, as a temporary fix?