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

[Guest Jax Pok]

Did you even bother to read posts on the same page ?

I read the last three or so pages and no mention of FAR still being better than 1.0 so I asked. Sorry you all had to take 20 sec of your life to reply to me with a bad attitude. I quit this forum if that's how it's going to be.

- - - Updated - - -

Any point in having this thread if people refuse to read it first?

You were willing to take the time to type that unfriendly message but not a simple yes?

Edited May 7, 2015 by Jax Pok

[tetryds]

Stop.

http://forum.kerbalspaceprogram.com/threads/20451-0-90-Ferram-Aerospace-Research-v0-14-7-4-2-15?p=1913642&viewfull=1#post1913642

[Camacha]

Stop.

http://forum.kerbalspaceprogram.com/threads/20451-0-90-Ferram-Aerospace-Research-v0-14-7-4-2-15?p=1913642&viewfull=1#post1913642

You guys really need to work out a way of communicating what are moderator announcements and what is just part of the discussion. Currently there is no way to tell and moderator remarks (which I suppose the previous one was?) also easily gets lost in the rest of the chatter. If people ever overlook one or judge it wrong they get told off for discussing staff decisions, which hardly seems fair.

This post can be moved to the forum section if that seems better, although the rules do not actually say anything about comments being allowed there either. Discussing in private will not do, as it is a matter of policy and affects many people.

Edited May 7, 2015 by Camacha

[zilfondel]

All the instruments fit into a single service bay, so that is cool:

http://xxml.org/etc/Beagle2.png

And it does look a lot better. But the center of gravity is probably still too high, even with the increased fuel at the bottom. I'll look into the Infernal Robotics. And a mod for better lights.

I think the correct answer is your rocket needs MOAR fairings - specifically, a nice big fairing that goes around your capsule and hides the rocket engines, RCS units and everything else you have exposed.

Also, like was posted previously, procedural fairings has an interstage fairing which you can use to hide your landing legs. Like so or like this.

[pandastratton]

I have been playing with that baby (all stock parts):

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

with airbrakes deployed:

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

dude that is sweet as hell man...

is far going to be updated for 1.0? I'm way to stupid to figure out how to install the nufar stuff...

[CDRW]

You guys really need to work out a way of communicating what are moderator announcements and what is just part of the discussion. Currently there is no way to tell and moderator remarks (which I suppose the previous one was?) also easily gets lost in the rest of the chatter. If people ever overlook one or judge it wrong they get told off for discussing staff decisions, which hardly seems fair.

This post can be moved to the forum section if that seems better, although the rules do not actually say anything about comments being allowed there either. Discussing in private will not do, as it is a matter of policy and affects many people.

I like tvtropes's way of doing it. They have a setting where when someone is making a mod post it turns the background of that one post pink.

[etheoma]

Anyways I'm getting content crashing when I get upto high mark numbers, its definitely some kind of conflict with another mod because I did a clean install of KSP and installed FAR and its dependencies and I can fly as fast as the heat will allow me, probably shouldn't mention it tell I have isolated the particular mod but its 2 am and yeh I wanna sleep I'll do the likely suspects tomorrow.

And see if it is a conflict with FAR or whether its just an other mod but all the other mods I used were stable releases so it shouldn't be the latter but you never know.

Edited May 7, 2015 by etheoma

[xXIndestructibleEVAXx]

There is a memory leak with the heat indicators. Hit F10 to turn them off.

[etheoma]

There is a memory leak with the heat indicators. Hit F10 to turn them off.

That would show up in task manager right as the KSP.exe using more RAM than usual, because I'm pretty sure it was at 1.9GB but I would have to recheck to be sure give me a minute I backed up the broken version so it wont take me long.

Although It is on a mechanic disk so... maybe it will take a bit to load, KSP on a RAM disk FTW.

Although your probably right because before I added lots of parts that pop up heat indicators I was having no problems.

Edited May 7, 2015 by etheoma

[xXIndestructibleEVAXx]

Don't know what it is, then. Sorry I couldn't help.

[etheoma]

Don't know what it is, then. Sorry I couldn't help.

No you were right my bad I obviously wasn't looking at the right times, went from 1.9GB to 3GB... just closed it after that what's point. that is one hell of a memory leak. god squad is on a roll first they release in 1.0 heating and don't include indicators which is like a VERY BASIC no briner, then when they add indicators and they are broken as all hell...

THIS IS SUPER HEALTHY SPACE, SQUAD OMEGA GOOD JOB!

And I was willing to let them off before 1.0 but this was supposed to be the offical release and there releasing broken mechanics, tbh either they should have tested 1.0 to all hell or released 0.91 with all the new features then went 1.0 with just bug fixes and optimization 1.0 is for stability not features.

Anyways a quick hack would be to update them only once every 2 - 5 seconds if your getting that hot any quicker than that and your going to blow up anyway, I assume its due to the high refresh rate that they pile on the memory so fast because the code and graphics behind them can't be too big.

Edited May 7, 2015 by etheoma

[xXIndestructibleEVAXx]

Yeah. The "Stock Bug Fix Modules" Have fix for it, it just disables them.

[ferram4]

@etheoma: Yep, it's great, ain't it? I've also noticed what appears to be a few MB of leak every editor -> flight -> editor cycle, and I'm not sure where it comes from, though I can reproduce it in stock KSP, so it's not anything I'm doing.

[etheoma]

@etheoma: Yep, it's great, ain't it? I've also noticed what appears to be a few MB of leak every editor -> flight -> editor cycle, and I'm not sure where it comes from, though I can reproduce it in stock KSP, so it's not anything I'm doing.

hasn't that been the case with every version though, as someone who runs a lot of mods and rides that RAM cliff edge quite regularly after going from editor -> Flight -> Editor etc always fills up the remaining RAM relatively quickly if your already at the limit.

Usually happens because I'm being fussy about some particular thing little too much wobble MOUR STURTS different place of struts MOUR BOOSTERS!!! and so on.

Na I don't iterate rockets that often any more, space planes are the thing that has me going back the editor 20 - 30 times or so, The active texture management mod allows me to get that down to 2GB - 2.4GB so I have the head room for that leak, well as long as I'm not just being plain pedantic. <--- edited that to say "plain pedantic with my craft" then I released it was a pun so I left it.

Edited May 7, 2015 by etheoma

[Drew Kerman]

hasn't that been the case with every version though, as someone who runs a lot of mods and rides that RAM cliff edge quite regularly after going from editor -> Flight -> Editor etc always fills up the remaining RAM relatively quickly if your already at the limit.

Yup I can relate to this behavior as well. Sometimes I accidentally click into the VAB and I just facepalm so hard...

[Guest]

Hey ferram, don't worry people still love FAR, please take your time for the final version so that it's neat and slick. I mean the voxel thingy is completely new and I wonder how will it interact with aero forces being applied to parts and not areas?

I have another question for you about voxel and aliasing.

So I noticed that wings tend to have aliasing in the voxel model, how will it affect aero calculation, (especially on the wings, where slight orientation/shape changes can have important impact on lift and drag values)

I suppose there's a limit to the voxel resolution before it start impacting framerate.

How do you plan on dealing with these irregularities?

And finally is the matrix' frame of reference the craft, or does it uses a static point of reference like Kerbin and when you fly and steer voxel shape gets recalculated each frame with different aliasing spots because of being at a different orientation in the voxel "box"?

[chootrain]

I wasn't sure where I should ask this, so I figured I would ask you guys:

Is there a way to control flight (pitch) trim without the use of the alt key? The reason I'm asking is controllers and joysticks are going to become popular when flying airplanes, and constantly switching to the keyboard can be annoying. The stock game doesn't have an option to rebind the "alt" key (or any trim control). There were some mods that assigned trim control to action groups (extended trim) but they dont seem to work in the new 1.0 (at least they dont work with nuFAR installed).

I was kinda excited when i saw action groups for control surface deflection, but then I realized that's not at all what I'm looking for (its still a useful feature). If there is no mod that allows this, would I be vilified for suggesting the possibility of adding this feature to FAR?

[UnanimousCoward]

@chootrain: not sure, but Advanced Fly by Wire might be able to help with that.

[Zorbaq]

@ferram4: I may be a bit late to the party but let me just say that reading about FAR now being voxel-based has fabulously brightened my day! I hope the final result ain't too heavy for our already strained CPUs, running 'demanding' KSP physics and all that Can't wait for the release build. Thanks for all your hard work, man.

[ferram4]

@RevanCorona: Well, the forces are still applied part-by-part, it's just that the aero calculations aren't done for each part alone, they're done separately and then divided up among each part.

The aliasing is a minor issue, but most of that has been fixed by allowing voxels to be "partially filled" so that a voxel that is only barely touching something counts as less than a voxel completely filled up by the parts. This seems to have fixed almost all the issues. While increasing the resolution is an option, the issue isn't framerate: it's memory usage. The voxel model generation is rather memory heavy, and it also involves a fair bit of garbage, so if it runs at too high a resolution too often you get the garbage collection hitches. Also, we're heavily memory bound in KSP, so we can't afford several million elements for the voxel.

The system is built in craft-space assuming an unflexed vehicle. Then cross-section data is taken from the voxel model and is used to generate aerodynamic properties that are stored for each section, and then the voxel itself is thrown away, because it's simply not needed anymore.

@Zorbaq: Funnily enough, the way that everything works out makes it seem to be approximately the same or even less expensive than what FAR was before. Most expensive stuff is in generating the voxel (which is multithreaded because it can be) and the initial geometry work for each part (which could be multithreaded as well, but that would require a large amount of work to prevent race conditions, I think).

Edited May 7, 2015 by ferram4

[Gfurst]

Okey guys, just reporting. I'm going to try out the dev version, all I need is the gamedata folder from the voxel port branch in github + modular flight integrator thingie right?

At first with 1.0 I thought the new aero was great, almost as good as FAR in the previous releases. 1.0.2 came and it changed a lot, nerfed rockets and made planes a bit easier.

Essentially they nerfed the whole thing back a bit more like it was before. So after doing some research I found about the drag cube thingie and how should work well but actually can be messed up with several parts.

So I went again to do some testing, one terrible example is how in-line parts on my plane kept having a drag constant, about 1/4 of the front Mk1 cockpit, thats not so bad.

What was actually messed up is the tail section, either A or B since they're practically the same, adding the same amount of drag or more than the front of the plane. Thats pretty bad and ruining it for me.

Anyway, I'm curious about a couple of things: does physics settings conflict with anything in nuFAR? And do you plan on tweaking with thermal stuff? (or is it just Deadly Reentry)

Btw, the atmospheric sound enhancements mod is back, the one that gives sound effects to mach speeds.

[Hodo]

So I am experiencing some odd design quarks in the NuFAR... This craft has a tendency to pitch up until it stalls. At first I thought it was the air brake on the back so I removed it. The craft still pitches up. I then moved somethings around and it still pitches up, not as bad though. Then I thought the CoL was ahead of the CoM so I did some minor rework in the wing design and it still pitches up.

This is where it is now, and it is FINE at supersonic speeds.

[MAKC]

Tailless delta are generally pitch unstable. That's just how it is. Also, your canards are probably stalling while trying to correct for the pitch up moment.

[blowfish]

Give the canards some negative AoA deflection. That should improve pitch stability somewhat.

[etheoma]

While increasing the resolution is an option, the issue isn't framerate: it's memory usage. The voxel model generation is rather memory heavy...

I know I have said this kinda before but in an unreasonable and unattainable wish list which included such ridiculous things as using the double precision GPGPU to compute the voxels when KSP and unity doesn't even have the ability to tap into GPGPU for either OpenCL or CUDA.

But on a more reasonable note but still very sketchy note is it possible if squad moves over to Unity 5 and manages to make a stable 64 bit build that you could up the voxel density or would the limitation be processing horse power at that point, if so how hard would it be for you to make FAR multi threaded.

Completely theoretical and hard to answer because the system isn't in front of you and probably impossible to make a definite answer I know considering even if squad were to go over to U5 and develop a stable 64 bit build it seems from what your saying it would still be a problem to up the resolution by a significant degree due to how the KSP works.

And ontop of that you still have to keep FAR somewhat reasonable in RAM as not everyone has even 8GB of RAM never mind 16GB, but I suppose if it came to that point you could make FAR adaptive based on how much system memory there is, but then you run into the problem of exactly the same craft behaving completely differently based on system spec's which is a serious problem, and thats not even getting into the time into even making it work for 1 size is hard enough.

Ah there go my dreams of building a super computer and run KSP with an adaptive nuFAR on it XD 1TB of RAM Voxel me up baby.

One last question and its something that you could actually answer if there was a stable 64 bit version of KSP how hard would you hit the RAM if you were going to do one size for all, if you were not limited by the KSP just usual system specs, would you be willing to exclude the bottom 10% 30%?

Edited May 7, 2015 by etheoma