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

[Van Disaster]

If it is, this is the first I've heard of it. The latest version is the one that supports 0.9

voxelAero branch, not master.

[tetryds]

Supermaneuverability they say.

http://i.imgur.com/4anwVL4.png

Nice one!

I am going stock, and the engines thrust and gimbal is painfully low, I managed some stuff but it's not really fun.

Will wait for 1.0 release, the engines are much stronger there.

[mariohm1311]

Nice one!

I am going stock, and the engines thrust and gimbal is painfully low, I managed some stuff but it's not really fun.

Will wait for 1.0 release, the engines are much stronger there.

Thanks! This plane is a Kulbit machine. And why would you need more powerful engines? If you have enough gimbal...

[Juandimix]

I cant wait for your update

[SkyHook]

So glad to hear that this is updating for 1.0! Now I have to wait to start my career/sandbox playthrough!

[Instresu]

Um, does this mean realchutes will become obsolete if I have nuFAR installed?

Probably no.

[DundraL]

Wow! Great too see FAR is not only coming back so correct stock erro, but being improved as well!

Glad to see the best mod in the game getting better, and THANK YOU for all your hard work!

How do voxels handle air intakes? Their aerodynamic properties seem to be far from what the shape of their model suggests: Tube (actual) vs Bucket (model shape)

Jet engines... will they still have a flat reduction of power?

Wings: will we still have the same strength-mass slider?

Oh, I also heard someone say something about hyper-maneuverability...

Yea, I got nothing to edit videos with... so I dont have a way to take out pandora in the background... or the crash! XD

EDIT: Ugh they reallly messed up jet engines... I keep asking then to transfer some weight of air breathing engines to intakes but they just added mass to engines instead =/

http://forum.kerbalspaceprogram.com/threads/92819-An-arguement-for-a-simple-intake-jet-engine-tweak

I brought this up alot but I cant keep ressing the thread =/44

Edited April 29, 2015 by DundraL

[taniwha]

DundraL: blender has a decent video editor in it. I use it for my vids.

[Gfurst]

LoL, that was pretty neat flight, must been fun doing it.

Btw, my recent attempts with the stock aero were pretty good, stock is indeed much better, looking forward to the new FAR though.

I have a small request, if anyone takes on it, to make all wings capable of carrying fuel, major oversight as basically all aircraft in the real world carry fuel on its wings.

Should be easy enough to do just applying the proper modules with cfg files, but I don't know how to do this.

[Lord DC]

Gfurst there's a mod for that called Wet Wings.

Also, some of B9's stuff works like that, but i see your point

[ferram4]

Alright, so a status update for people:

There are two major holdups on release right now. While I've got the parachute module in and running, it suffers from the same issue that stock has in that deploying chutes during reentry is a great big, "I win, avoid all heat" button. Trying to set parachutes being cut (and destroyed) based on part temp doesn't work, because while that works for reentry it also leads to them auto-destroying when you try to deploy them later because of the heat remaining in the pod / chute. I'd rather not do a simple, "check shock/ambient temp, if > x, cut" because that doesn't provide much feedback in the way of, "you set the chute on fire." So something will have to show up there.

The other holdup is getting ModularFlightIntegrator up and running. FAR has to extend the FlightIntegrator class to override stock's drag, but anything wanting to override heat or add anything to aerodynamics also has to do that. If we all just tried to extend FlightIntegrator itself we'd either A) have multiple FlightIntegrators running resulting in everything going completely wrong or only one of them runs. In any case, this is one of the few places where there are actual mod compatibility issues, so Sarbian, Starwaster and I are going to work something out to make it work (mostly Sarbian, he's written most of the code for it). We'd prefer not to step on each other's toes in this.

More minor issues involve tweaking the aerostress failure criteria to feel good and the slightly irritating fact that anything using stock's new see-through module causes it to draw on top of the nice pretty overlays I've created. I'll have to figure out if there's an effective way around that.

Alright, so more good dev news and slight hyping.

After some justifiable complaints from tetryds that there were a few voxelization artifacts in vehicles (most of which were caused by the voxel resolution being too low), I tried increasing the resolution to see what would happen. Previous pictures showed voxel models with up to 125000 voxels within the bounds of the vehicle. I tested increased versions up to 500000 with no apparent loss of performance in the flight scene (testing a 114 part spaceplane, with many wings so extra overhead from that). I'm sure it can go higher, but larger voxels require more memory to be put up to hold them; the 125000 versions required 2 MB for the duration of their existence (which is only long enough to generate aero properties before it's recycled), but I have concerns about how much memory this will churn if I test higher resolutions. And besides that, higher resolutions also take longer to generate, which makes them less viable for real-time aero.

In any case, the obvious solution for this is to expose the options, so the voxel counts for controllable vessels and for debris (which are much lower) are now exposed. In addition, the rate-limit on updating the voxel has been exposed as well, to prevent situations like deploying landing gear from turning into a hitch-fest due to the garbage collector being slammed with cleaning up unused voxel memory. Fortunately, since the generation of voxel models and aero properties is done in separate threads, none of this actually has any impact on the game's framerate as a whole, just the few times the GC gets punched in the face. So woohoo for minor things.

[HafCoJoe]

Ferram could you say "cut chute if speed is above Xm/s"? X being reentry speeds. This would make sense in terms of chute strength too.

[Svm420]

Isn't speed the issue with re entry what was wrong with the method realchute already had used that over 350ish m/s ripped chutes?

- - - Updated - - -

Ninjad

[ferram4]

Because raw speed has jack to do with the actual heat load on the parachute. Deploying a chute at 600 m/s in the very upper reaches of the atmosphere should still work great, because the forces and heating up there would be incredibly low for that speed. It also falls apart on Jool, where 350 m/s is only Mach 0.3, so it's not even getting shock heating.

No, I don't want to hear hack-solutions that don't provide any feedback to the player about what happened and about what caused the issue. That's what's caused every single problem in oldFAR, and is the cause of every issue in newStock. Adding hacks because it's a fast way to make things work is a terrible idea, because however temporary you say they are, they always become permanent.

[Svm420]

Thats makes more sense thank you for elaborating.

[ss8913]

"because however temporary you say they are, they always become permanent." --ferram4

This belongs in a book of great quotes. I find myself telling my boss this quite often... I work in the software industry as well.

[NocTempre]

I'm rusty on my propulsion so please forgive me if I'm way off base - are you doing anything special for intakes/exhaust? I honestly don't remember if there would be any logical way to estimate the drag from that without knowing the full internal path. I suppose some sort of generous minimum drag assumption related to p_1 (inlet), p_9 (nozzle exit) and v_inf? I saw the question posted already more generally, and was just curious how if there were any specific plans yet.

Your work is an inspiration, looking forward to your 1.0 release with such massive improvements.

[youkofoxy]

two questions: can I call this version of V. FAR?

the second you've answered, I'll be able meltdown my CPU .

on the development, I would use a function of parachute temperature and ambient temperature to solve the super-parachute-problem.

after all, when you have melting nylon in contact with hot air...

and it would be nice to have common instances (such as enabled landing) in memory, but 32-bit.

apparently, avoid "workaround" (thats is how we call hacks) is the priority, good judgment about it, only heard about many try and end up failing.

I will wait to see how you solve the problem: performance versus accuracy.

though I struck the idea of using a low-accuracy model and a high-precision model together.

has its advantages, but it will be a ....

better not talk...

seriously, my best idea so far was the parachute, and I still think it's too complex for users to understand.

after all, everyone knows: "the User, not knowing it was impossible, went there and did"

[dc4bs]

"because however temporary you say they are, they always become permanent." --ferram4

This belongs in a book of great quotes. I find myself telling my boss this quite often... I work in the software industry as well.

It also holds true in data centers.

Me: "Say, what's this old server with no label on it?"

Other Admin: "Ummm... I think that might the temporary server for project XYZ that was brought online 3 years ago..."

Me: "So why is there no labeling of any kind on it?"

Other Admin: "Because it's temporary and should be gone in a few more weeks..."

Me: "Argh!!!"

[eddiew]

Me: "Say, what's this old server with no label on it?"

Other Admin: "Ummm... I think that might the temporary server for project XYZ that was brought online 3 years ago..."

Could be worse... ever tried to find a computer that is on your network, but you're not sure where it physically is?

[AndreyATGB]

Could be worse... ever tried to find a computer that is on your network, but you're not sure where it physically is?

No but the other way around happens all the time.

[marach]

Because raw speed has jack to do with the actual heat load on the parachute. Deploying a chute at 600 m/s in the very upper reaches of the atmosphere should still work great, because the forces and heating up there would be incredibly low for that speed. It also falls apart on Jool, where 350 m/s is only Mach 0.3, so it's not even getting shock heating.

No, I don't want to hear hack-solutions that don't provide any feedback to the player about what happened and about what caused the issue. That's what's caused every single problem in oldFAR, and is the cause of every issue in newStock. Adding hacks because it's a fast way to make things work is a terrible idea, because however temporary you say they are, they always become permanent.

I suppose one way would be to poke the ships average temp and see if it's rising or stable/falling (though it would of course be rather hackish). It is a tricky problem isn't it

Could be worse... ever tried to find a computer that is on your network, but you're not sure where it physically is?

In such cases I've known certain people to just disconnect it and wait for the complaint call to hit of course nobody here would sink that low...

Edited April 29, 2015 by marach

[ratchet freak]

Or use the actual force the chute exerts for one cuttof parameter (deploying at mach 5 on sea level should rip it to shreds faster than it should destroy off the vessel)

When deploying you can force set the temperature to the surrounding air and then let it apply shock heating and then let it burn up after temp>x

And set a custom message in the flight result window with how it got destroyed (if possible)

[etheoma]

Would be nice if you could create a hole new process which is addressed separately from KSP in the RAM and just communicates with the KSP client because most people have oddals of spare memory its just the limitation of the KSP client which is the problem, I understand implementing it would be far far far far far far far more difficult so its not a feasible solution because you would basically have to completely overhaul the hole KSP client but you could go nuts with a lot of mods if there was a way to communicate with KSP without being addressed within the processes memory addresses.

Although as Ferrem said the problem isn't really memory its also the time it would take to process the information, but if you were overhauling the KSP client to such a degree building a 4 threaded - 8 threaded voxel processing module would be easy in comparison, which would accelerate voxel processing on 4 - 8 core machines by almost that amount.

I know I'm completely in dream land, because it would probably be more efficient to just build the game from the ground up using a more malleable engine than unity and just build a game that can utilize 4 threads effectively as well as being able to utilize CUDA/OpenCL for phyic's and obviously 64 bit. Again obviously dream land but what a dream.

Also CUDA/OpenCL would be brilliant for this kind of processing, because of the granular nature of the of voxels which can be highly parallelized which is the prerequisite for anything you want to do in CUDA/OpenCL but again complete dream but nice dream.

Edited April 29, 2015 by etheoma

[marach]

Although as Ferrem said the problem isn't really memory its also the time it would take to process the information, but if you were overhauling the KSP client to such a degree building a 4 threaded - 8 threaded voxel processing module would be easy in comparison, which would accelerate voxel processing on 4 - 8 core machines by almost that amount.

I know I'm completely in dream land, because it would probably be more efficient to just build the game from the ground up using a more malleable engine than unity and just build a game that can utilize 4 threads effectively as well as being able to utilize CUDA/OpenCL for phyic's and obviously 64 bit. Again obviously dream land but what a dream.

Also CUDA/OpenCL would be brilliant for this kind of processing, because of the granular nature of the of voxels which can be highly parallelized which is the prerequisite for anything you want to do in CUDA/OpenCL but again complete dream but nice dream.

On a pleasant note Unity 5 IS thread safe so the move over when it comes will make things a little more enjoyable for FAR with regard to multithreading. I do wish Unity had gone through with the switch to Bullet that they hinted at before the U5 announcement though since it would have meant a platform agnostic acceleratable physics base...