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

[TommyC81]

Hey ferram4,

just registered to say thanks for the work you've done! 10$ sent your way as token of appreciation.

[Lakel]

That thing that a reinstall fixed? its back. this time no b9 pwings part, just an abundance of firespitter struts and float parts.

Craft is disassembling itself around 11m/s, no crazy noseup, some fun stability derivatives. Using latest github version as of this post. Graph was showign up to 1035 with 15.1, dropped to number shown with the github version

To be clear, this was not supposed to fly, just be a boat.

https://www.dropbox.com/s/8oddiheeym7dreq/output_log.txt?dl=0 https://www.dropbox.com/s/m9r6sdqf5tq5d2r/BoatBoat.craft?dl=0

Has hit a few designs I've been messing with, not sure if its caused by mods or not, i know BDarmory weaponry on wings has triggered it, weaponry in cargobays does not, open or closed. Craft go back to "normal" figures soon as removed. Everytime i see the crazy graphs, the result in simulation is the same, start moving and the craft is destroyed by aero-failures at no more than 15m/s. I do know for sure, it has hit craft with just the B9 Pwings and nothing else

Edited May 16, 2015 by Lakel

[ymir9]

Drogue chutes don't seem to work with the new RealChuteLite implementation.

Is there some way to disable realchute and revert to the stock chute system?

[Crzyrndm]

Drogue chutes don't seem to work with the new RealChuteLite implementation.

Is there some way to disable realchute and revert to the stock chute system?

The whole reason for RCLite was that the stock chute system will/can not work with how this version of FAR does things. You may want to be more specific about how/why "drogue chutes don't seem to be working" because they do their job of correctly orienting my pod here (a drogue so it won't ever have much impact on the descent speed.)

Edited May 16, 2015 by Crzyrndm

[kcs123]

That thing that a reinstall fixed? its back. this time no b9 pwings part, just an abundance of firespitter struts and float parts.

Craft is disassembling itself around 11m/s, no crazy noseup, some fun stability derivatives. Using latest github version as of this post. Graph was showign up to 1035 with 15.1, dropped to number shown with the github version

To be clear, this was not supposed to fly, just be a boat.

https://www.dropbox.com/s/8oddiheeym7dreq/output_log.txt?dl=0 https://www.dropbox.com/s/m9r6sdqf5tq5d2r/BoatBoat.craft?dl=0

Has hit a few designs I've been messing with, not sure if its caused by mods or not, i know BDarmory weaponry on wings has triggered it, weaponry in cargobays does not, open or closed. Craft go back to "normal" figures soon as removed. Everytime i see the crazy graphs, the result in simulation is the same, start moving and the craft is destroyed by aero-failures at no more than 15m/s. I do know for sure, it has hit craft with just the B9 Pwings and nothing else

http://i.imgur.com/mIVF1tu.jpg

I don't see any bug there. Your pitching torque is too high compared to lift and drag, also due to such high pitch torque, craft part meshes colide with ground/water too hard, that could be reason for craft being destroyed.

[ymir9]

The whole reason for RCLite was that the stock chute system will/can not work with how this version of FAR does things. You may want to be more specific about how/why "drogue chutes don't seem to be working" because they do their job of correctly orienting my pod here (a drogue so it won't ever have much impact on the descent speed.)

Thanks for your reply.

From my testing it seems that drogue chutes are treated like normal parachutes and have the same levels of drag and temperature tolerances.

Also in all chutes, realchute seems to ignore what deployment settings I use in the right-click context menu.

[oobayly]

I just install Ferram as I wanted to use the trajectories mod. I found that my parachutes were deploying way too early - effectively ignoring whatever pressure I selected. Doing some "real science" I sent up a test vehicle, set the deployment pressure to 0.5 (which should have been about 3,500m) and deployed the chute in space. I found that it deployed at about 26,000m - or a pressure ratio of 0.005.

I hadn't realised that FAR was now using RealChutes, and I found in the release notes that the chutes were deploying at the kPa value, not the pressure ratio:

May 2nd 2014

v1.3.2.3

-Updated flags to DDS files, thanks to sumghai again

-Slight bugfix to parachute heating, they now heat, much, much, MUCH faster, as they should.

-Fixed a bug with minimum deployment pressure being in kPa, allowing deployment way too early

I don't however understand how this hadn't been caught yet - I can't be the only one who deploys his chutes early and relies upon the pressure deployment.

[DuxDucisHodiernus]

@DuxDucisHodiernus: The exception is already for all surfaces, the problem is that I think the surface is being voxelized before the fuselage, and so when the fuselage comes along it overwrites the surface. Sometimes. Normally the exact balance of where things go isn't so important as long as everything is accounted for, except in this particular case, it seems.

All it actually requires if the surface is flat along the vehicle is that it deflects a certain amount. It's just realizing that it's flat on the vehicle.

So um, can/will it be fixed? Also it's kinda strange that it starts working sometimes after moving the gear up and turning the airbrakes on and off again. Not super reliably, but it does work at least sometimes.

[Gatos]

Ok so I'm not sure if anybody has mentioned it, but I'm having a lot of performance hit in the VAB and SPH after installing the Fanno update.

This is due to FAR constantly trying to update the Voxel thing:

Those spikes makes it very jerky and now it averages 60fps, with lag spikes dipping at 20 every half second. it used to run at a smooth 100+ in the VAB.

Edit: It seems that it's only some parts that are causing this bug, the parts don't need to be added to the ship, just selecting them causes FAR to constantly update the vexel thing.

I'll try to remove all the other mods.

Edited May 16, 2015 by Gatos
Description

[zengei]

ferram, FYI the mod website listed on Kerbal Stuff is wrong, it's: http://kerbalspaceprogram.com/forum/showthread.php/20451 when it should be http://forum.kerbalspaceprogram.com/threads/20451

[Gatos]

Ok I found the mod that was crashing with FAR.

It was the toadicius.dll from toadicius tools used by the tweakable everything mod.

[BudgetHedgehog]

Ok I found the mod that was crashing with FAR.

It was the toadicius.dll from toadicius tools used by the tweakable everything mod.

It's actually a stock bug with tweakbles that TweakableEverything exposes. Toadicus posted about it earlier in the thread.

[ferram4]

And it's the same thing that was plaguing FAR's right-click-wings-causes lag bug. And likely the same thing that cause(s/d) pFairing's right-click-lag bug.

@Lakel: I'll take a look at it, but seeing as you're the only one suffering this bug right now, can you try and narrow it down to the simplest, barest craft possible that causes the issue, and also post pictures of the transonic cross-section graphs resulting from it? This sounds like the main axis is screwing up, or the voxelization is working with something gigantic, but I need the simplest test case possible to be sure.

@DuxDucisHodiernus: As I already said, I have some ideas for how to fix it, I just have to see how they play out. Shouldn't be too difficult to do though.

@zengei: Thanks, I'll fix that.

[Volt]

Is it possible that FAR could be causing a slow memory leak with its voxel updates? I'm getting very frequent debug messages about said updates and watching in dismay as my meagre 300mb of free unallocated memory is being eeked away by I-don't-know-what. And my FPS is decreasing in kind. After pretty much every long spaceplane flight, I have to restart my game.

Edit: Wrote this post while making my third attempt at reaching the Pyramids without a crash. Memory left hit 200 and the game froze, then crashed out. The crash report says out of memory. This is only occurring on prolonged atmospheric flights

Edited May 16, 2015 by Volt

[taniel0401]

Is it possible that FAR could be causing a slow memory leak with its voxel updates? I'm getting very frequent debug messages about said updates and watching in dismay as my meagre 300mb of free unallocated memory is being eeked away by I-don't-know-what. And my FPS is decreasing in kind. After pretty much every long spaceplane flight, I have to restart my game.

Edit: Wrote this post while making my third attempt at reaching the Pyramids without a crash. Memory left hit 200 and the game froze, then crashed out. The crash report says out of memory. This is only occurring on prolonged atmospheric flights

Are there any greenish bars showing near any of the parts?

[Dedalous]

I have a suspected bug, I think. Or it could be I just fail at atmospheric re-entry. That's a big possibility.

Anyway, when I go to reenter from a suborbital trajectory in the Mk1 pod(haven't tested it with other pods yet, as I haven't unlocked any more in this save), maintaining a trajectory of about 35 degrees from parallel with the ground, I will reenter, and not slow down. This is with the blunt end of the pod pointed retrograde. It will accelerate from my initial suborbital velocity all the way down. And parachutes are no help, as I'm currently using REalChutes, and they snap off at those velocities.

Any help with this would be appreciated.

[Sokar408]

I don't know if this a FAR problem, though given its the only mod I have that messes with the atmo, I'm thinking it is.

Basically what I'm experiencing, is that the atmosphere isn't slowing me down at all. I just keep accelerating until I hit the ground. Anyone know how to fix this?

EDIT: Deleting FAR and ModularFlightIntegrator, solved the problem, but still leaves me wondering how to fix the issue, so I can use FAR

Edited May 16, 2015 by Sokar408

[jstnj]

I have a suspected bug, I think. Or it could be I just fail at atmospheric re-entry. That's a big possibility.

Anyway, when I go to reenter from a suborbital trajectory in the Mk1 pod(haven't tested it with other pods yet, as I haven't unlocked any more in this save), maintaining a trajectory of about 35 degrees from parallel with the ground, I will reenter, and not slow down. This is with the blunt end of the pod pointed retrograde. It will accelerate from my initial suborbital velocity all the way down. And parachutes are no help, as I'm currently using REalChutes, and they snap off at those velocities.

Any help with this would be appreciated.

Take FAR out and test...what do you mean by "not slow down"? Are you hitting the ground at 1800m/s?

[Sokar408]

Take FAR out and test...what do you mean by "not slow down"? Are you hitting the ground at 1800m/s?

I am experiencing the same problem, and removing FAR and FlightModularIntegrator, does resolve the problem. Though it still leaves both me, and Dedalous without FAR, which is less the desired

[Volt]

Are there any greenish bars showing near any of the parts?

Oh jeez, yes, I totally forgot about that bug. It's nothing to do with FAR, I know. Off topic, I guess, then but is there any way to disable those?

[MatterBeam]

Oh jeez, yes, I totally forgot about that bug. It's nothing to do with FAR, I know. Off topic, I guess, then but is there any way to disable those?

F10 toggles them on/off.

Some mods have the option to disable them automatically.

[kcs123]

More precisely, DMagics temperature gauge killer.

Still, even with this I have memory leak somewhere. Suspected mods: Crossfeed enabler, module flight manager and FAR.

Someone suggested to manualy install module flight manager instead from CKAN, but that didn't solve issue.

Thing that helps is GCmonitor, so you can watch memory usage and save and exit game before it CTD. Not a solution, but at least some kind of workaround.

[Dermeister]

Do you guys think it will want to tip over due to aerodynamics forces? I'm trying to create drag at the back of the rocket to see if it will keep it stable.

[blowfish]

Run static analysis and see what the slope of the Cm curve is.

[Dermeister]

Run static analysis and see what the slope of the Cm curve is.

I don't understand the graphics of Far yet but here's what it gave me