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

[sand500]

Can you Addon Controller?

http://forum.kerbalspaceprogram.com/threads/94426-0-24-2-Addon-Controller-Toggle-addons-and-parts-on-off-for-individual-saves

[slumpie]

The stock ones from version 24.2, kept using them in .25 so that the crafts are not messed up.

The craft would never infiniglide in stock, it only does it with FAR...

The video is huge though, I must cut it first a little and then I'm going to upload it.

[Master Tao]

The video is huge though, I must cut it first a little and then I'm going to upload it.

Could you also post your platform, as in Linux 64-bit KSP or Windows 32-bit KSP? An output log would help, too.

[slumpie]

Huh? I wasn't really looking for support, but ok...

Log: https://www.dropbox.com/s/3a2a048sez5b0sq/output_log.txt?dl=0

By the way, while the craft weighs 25 tons in the first video, I increased the ballast for the second video to about 40-45 tons. This has nothing to do with the stock infiniglider bug, but it's still a form of gliding for an infinite time.

EDIT: Nothing to see here any longer...

Gravity was NOT hacked, I even showed it in one of the videos if I remember right.

The wing parts are from 24.2, the only difference is the name so that they don't replace the new SPP parts.

Edited November 1, 2014 by slumpie

[ferram4]

@sand500: Nope, not possible from the way FAR works.

@slumpie: That is because they are not the stock wings anymore and are not supported by FAR; those parts are suffering from the infiniglider bug, because they are using stock winglet code. Any infinigliding is stock, as it requires drag to be <= 0; FAR does not allow this under any circumstances.

[jrandom]

I'm seeing a inaccurate CoL during construction. As seen below, the CoL is shown more rearward during construction of the wings than after loading. The CoL as shown in the second image (after loading) is the same CoL used during flight.

I found this out when I went to fly a craft (not shown here) that should have been juuust stable enough to get off the runway at subsonic speeds, but instead had massive pitch instability. After reloading the craft into the SPH, the CoL was indeed shown slightly in front of the CoM, whereas during its initial construction the CoL was displayed aft of the CoL.

So I'm having to constantly save and then load my craft every time I add, remove, or move wings, just so I can see where the real CoL is.

This is with the latest FAR of 14.3.2.

Javascript is disabled. View full album

[Overfloater]

Huh? I wasn't really looking for support, but ok...

Log: https://www.dropbox.com/s/3a2a048sez5b0sq/output_log.txt?dl=0

Videos (both videos are at 1.5x speed):

https://www.youtube.com/watch?v=FbmRbaT2e-Y

https://www.youtube.com/watch?v=LVs5xqgky2k

By the way, while the craft weighs 25 tons in the first video, I increased the ballast for the second video to about 40-45 tons. This has nothing to do with the stock infiniglider bug, but it's still a form of gliding for an infinite time.

Gravity was NOT hacked, I even showed it in one of the videos if I remember right.

The wing parts are from 24.2, the only difference is the name so that they don't replace the new SPP parts.

I definitely seen this plane somewhere before! 8-]

[GabeTeuton]

How do i calculate Vertical Acceleration knowing the vertical speed and the speed of the airplane? (or how do i calculate it regardless of what i have?)

[BudgetHedgehog]

How do i calculate Vertical Acceleration knowing the vertical speed and the speed of the airplane? (or how do i calculate it regardless of what i have?)

a = (Velocity_final - velocity_initial )/(time_final - time_initial) = ÃŽâ€v/ÃŽâ€t or acceleration=distance/time²

Change in velocity divided by change in time. Usually noted in metres and seconds, giving an acceleration of m/s².

EDIT: For example: At 0s, you're travelling vertically at 0m/s. After 10s, you're travelling vertically at 50m/s. This would give an average acceleration of (50m/s)/(10s), or 5m/s².

Edited November 1, 2014 by ObsessedWithKSP

[slumpie]

@slumpie: That is because they are not the stock wings anymore and are not supported by FAR; those parts are suffering from the infiniglider bug, because they are using stock winglet code. Any infinigliding is stock, as it requires drag to be <= 0; FAR does not allow this under any circumstances.

So even though it would NEVER infiniglide in the stock game, it does with FAR and that's not a FAR issue?

EDIT: I guess the reduced drag just makes the difference, not sure though...

I definitely seen this plane somewhere before! 8-]

Certainly, that's why I said this in my first post:

Oh and it's not even my craft, it was made by a guy who thought it would never fly with FAR... I just removed the engines and a few other things, that's it.

Edited November 1, 2014 by slumpie

[GabeTeuton]

a = (Velocity_final - velocity_initial )/(time_final - time_initial) = ÃŽâ€v/ÃŽâ€t or acceleration=distance/time²

Change in velocity divided by change in time. Usually noted in metres and seconds, giving an acceleration of m/s².

EDIT: For example: At 0s, you're travelling vertically at 0m/s. After 10s, you're travelling vertically at 50m/s. This would give an average acceleration of (50m/s)/(10s), or 5m/s².

Okay i'm trying to calculate it in real time, i kind of understood the way it's calculated, but i don't know, i'm confused, i'm sorry, this formula you presented to me allows me to calculate vertical acceleration in a period of time, but how does for instance kerbal engineer calculate it? what "time" (initial and final) does it use to calculate it in real time?

[BudgetHedgehog]

So even though it would NEVER infiniglide in the stock game, it does with FAR and that's not a FAR issue?

It would also exhibit this behaviour without FAR - because the parts are no longer stock, FAR doesn't change them. On a completely stock 0.25 + FAR game, infiniglide planes are impossible. As your game isn't completely stock, it's possible. Not sure where the confusion lies. I'll repeat: you have put parts into your game that are unavailable to a stock 0.25 player which means your game is not stock. If you give that craft to someone who downloaded KSP 3 minutes ago, they would not be able to load it.

(bolded for TL;DR)

but how does for instance kerbal engineer calculate it? what "time" (initial and final) does it use to calculate it in real time?

It probably uses very small increments such as milliseconds to calculate real time acceleration (or indeed, however long you tell it to update).

Edited November 1, 2014 by ObsessedWithKSP

[slumpie]

It would also exhibit this behaviour without FAR

Nope, that's what I'm trying to explain. It doesn't do this without FAR installed. The modules didn't change for 0.25 by the way, so they still work in stock 0.25 as they did in 0.24.2 (without FAR installed, in both cases).

EDIT: Perhaps due to the lower drag... Possible that this makes the difference between no FAR no infini and with FAR with infini.

But it's alright, I'm going to add them to the config.

Edited November 1, 2014 by slumpie

[GabeTeuton]

It probably uses very small increments such as milliseconds to calculate real time acceleration (or indeed, however long you tell it to update).

Got'cha, gonna try that and see what happens! Thank you!

EDIT: yeaaaah got it!!!!! i use a very small amount of time, very close to 1 game tick! THANK YOU!

Edited November 1, 2014 by GabeTeuton

[Voculus]

Never mind. It's all good!

Edited November 1, 2014 by Voculus

[Voculus]

OK, false alarm! Fourth time is a charm, I guess. I'm not sure how I hosed it three times in a row before, but it's working great, now! As ever, thanks for your hard work, Ferram!

[tetryds]

Nope, that's what I'm trying to explain. It doesn't do this without FAR installed. The modules didn't change for 0.25 by the way, so they still work in stock 0.25 as they did in 0.24.2 (without FAR installed, in both cases).

Infigliding is not a FAR issue.

That is the exact behaviour that stock planes exhibit, infiglides are caused by stock forces that FAR did not remove from your non-stock-anymore parts.

Stock control surfaces work by making drag lower than zero and this produces phantom forces, and a lot of other weird effects, and none of these effects will happen if the only mod you have is FAR.

FAR removes all the stock "aerosoupnamycs" (set it to zero) from the parts then apply it's own, if the part is not configured it may show these stock forces.

Tell us what happens after you add the configurations, if it continues to happen maybe you need to do something else too.

Edited November 1, 2014 by tetryds

[ferram4]

@slumpie: Try this: remove FAR, then set the drag on all the other parts on that plane to 0 in the config files (this will approximate the extreme of FAR's lower drag). Then, try flying it and tell me that it's a FAR issue.

Infiniglide requires thrust. FAR always applies some drag force, with the lowest possible drag coefficient on a part being 0.003 (0.006 for a wing). Infiniglide can only occur if the drag coefficient < 0, and it is never less than zero.

[Crzyrndm]

Got'cha, gonna try that and see what happens! Thank you!

EDIT: yeaaaah got it!!!!! i use a very small amount of time, very close to 1 game tick! THANK YOU!

Two small things you may want to consider (if you haven't already)

A) Make sure to use the physics delta-time and the physics update event to calculate the acceleration accurately. Delta time is the timestep of all ingame physics and will be seperate from lag and other wierdness. For reference

Calculated instantaneous acceleration (in this case the difference in speed between this physics frame and the previous physics frame only) is often very unstable and pops out extreme values frequently. You might run into some issues with processing or display of such a value in which case some filtering would be advantageous (eg. rolling average: acc = (k*acc + j*new_acc)/(k+j) where k and j weight the responsiveness of the calculation)

[GabeTeuton]

Two small things you may want to consider (if you haven't already)

A) Make sure to use the physics delta-time and the physics update event to calculate the acceleration accurately. Delta time is the timestep of all ingame physics and will be seperate from lag and other wierdness. For reference

Calculated instantaneous acceleration (in this case the difference in speed between this physics frame and the previous physics frame only) is often very unstable and pops out extreme values frequently. You might run into some issues with processing or display of such a value in which case some filtering would be advantageous (eg. rolling average: acc = (k*acc + j*new_acc)/(k+j) where k and j weight the responsiveness of the calculation)

OMG those 2 things seem pretty useful, but to be honest, i'm no programmer at all so i don't really understand what you mean, i used the formula to calculate Vertical Acceleration with kOS' scripting system, and as far as i can tell is accurate enough, from observation in comparison to KE mod... the whole point of it is the autopilot i'm trying to make, which is currently stuck at how to relate the pitch up "manouver" with the VA and the VS...

I'm waiting for some of the guys from that mod to help me out... i guess if i knew how to make an actual mod this would be much easier than scripting a sort of "program" inside a mod, inside ksp... but the first iteration of my program does work pretty well for long range flights, however i'm kind of perfectionist and until it's perfect or i get bored of trying i'll keep working on it... and perfect would mean 0 altitude deviation once equilibrium is found... Another thing to keep in mind is that when kOS guys release the version that can aswell handle trim rather than the actual pitch, it will be much easier for me, (though all that about trim is out of guessing so far)...

I'm sorry i made you write all that valuable information i can't really understand, or even use! Thank you anyway !

[ctbram]

Two things with 14.3.2

missing texture see here ....

and if I put it on buzzbies toolbar there does not seem to be a way to switch back to the ksp menu???

There are several mods possibly causing this - ATM, TR, native texture size reduction,.... I am hoping that someone has also seen this and can narrow my search. I do not want to do a binary addon search if I do not absolutely have too.

Edited November 2, 2014 by ctbram

[blowfish]

I seem to be having a drag issue with the stock/SP+ cargo bays - they create much more drag than the other Mk2 parts. I think it has to do with the secondary size 0 nodes on each end - the problem certainly seems to go away when they are removed.

[Mekan1k]

Anyone know why the Radial engine body (from stock + Stock Part Revamp) and the smaller version (from Tavarius's Pizza and Aerospace) is listed as having fuel when this mod and the Modular FuelTanks mod is active?

Can anyone duplicate this result, or is it just me?

[ferram4]

@ctbram: Dunno, looks like you either screwed up the installation or something is interfering with it. Don't know what though, I've never seen that happen from any of the mods you listed.

@blowfish: Confirmed, it's fixed by opening and closing the bays (even just partially). Not sure what causes it though yet, I'll need to investigate.

@Mekan1k: Ummm.... yes. In fact, everyone can. That would be because it is part of the stock game.

[iamzac]

I'm seeing a inaccurate CoL during construction. As seen below, the CoL is shown more rearward during construction of the wings than after loading. The CoL as shown in the second image (after loading) is the same CoL used during flight.

I found this out when I went to fly a craft (not shown here) that should have been juuust stable enough to get off the runway at subsonic speeds, but instead had massive pitch instability. After reloading the craft into the SPH, the CoL was indeed shown slightly in front of the CoM, whereas during its initial construction the CoL was displayed aft of the CoL.

So I'm having to constantly save and then load my craft every time I add, remove, or move wings, just so I can see where the real CoL is.

This is with the latest FAR of 14.3.2.

This bug also affects me, as I posted earlier, but Ferram said he can't reproduce it.