[1.0.2] B9 Aerospace | Procedural Parts 0.40 | Updated 09.06.15

[bac9]

Version 0.6

https://bitbucket.org/bac9/b9_aerospace_plugins/downloads

- Fixed control surface lengths being incorrectly clamped in the flight scene

[bac9]

Version 0.7

https://bitbucket.org/bac9/b9_aerospace_plugins/downloads

- Implemented trailing and leading edge surface material switching (4 types available for each on both wings and control surfaces - again, through the shader at no additional rendering cost)

- Implemented a fix allowing crafts saved with version 0.5 to migrate to new tweakable UI without breaking

- Improved debug output

- Fixed some issues with startup

- Included two sample crafts

[Horus]

bac9, you are fetching releases faster than I can test Tested against 0.6.

Digged deeper into FAR usage. Wings are ok, flaps & spoilers are also quite stable. But this was mostly because of stable craft. Testing with different craft types - maneuverable, super-sonic, etc.

Funny "feature": when you attach anything to a wing tip & then change wings span - the attached part stays in mid-air

- - - Updated - - -

0.7:

- Procedural Wing: Side A (type) & Side B (type) do not change texture. Visually.

- Procedural Control Surface: Material A, Material B do not change texture.

- - - Updated - - -

0.7:

While playing around with these wings in SPH noticed that memory builds up little by little while constructing. After some time was out of memory & client crashed.

0.7:

FAR.

Testing control surface with different flaps setups revealed some strange stalling effect at lift off position for flaps. The very same settings for stock elevons worked perfectly nice without this effect.

Edited December 30, 2014 by Horus

[How2FoldSoup]

bac9, love the new style of wings! I only played with them for a few minutes in sandbox before starting my first .90 career so I didn't get much use from them yet. I'm digging it though.

Slightly unrelated question: What engines are you using in that second plane?

[Horus]

@How2FoldSoup:

These engines are stock replaced with mod: Stock Part Revamp

[How2FoldSoup]

wow! Those parts look great.

Thanks for the heads up

[Voculus]

Finally got the chance to test these out today, and they are very cool. Nice work!

[Deathsoul097]

Is the thickness of the wing tweakable? (Like normal P-Wings?)

[falken]

Is the thickness of the wing tweakable? (Like normal P-Wings?)

Yes, that's entirely possible.

[doudou]

Hello, I can not find the files in the zip .craft 0.7

[bac9]

Hello, I can not find the files in the zip .craft 0.7

Forgot to add it into the last archive, uploaded a separate archive to the repo now.

Funny "feature": when you attach anything to a wing tip & then change wings span - the attached part stays in mid-air

Unfortunately it's not possible to fix this. Attachment positions of parts should be controlled by the editor, not part modules. It's a very, very problematic area I'd rather never touch and leave to mods that really require it, like KAS and robotics.

Procedural Wing: Side A (type) & Side B (type) do not change texture. Visually.

Procedural Control Surface: Material A, Material B do not change texture.

I'm unable to reproduce this, so I'll need more details and a log.

While playing around with these wings in SPH noticed that memory builds up little by little while constructing. After some time was out of memory & client crashed.

Thanks, investigating that, likely linked to switching of trailing/leading edge meshes on the wings.

Testing control surface with different flaps setups revealed some strange stalling effect at lift off position for flaps. The very same settings for stock elevons worked perfectly nice without this effect.

At the moment aerodynamic values calculation for control surfaces only accounts for root/tip width and length, not root/tip offsets, which will probably account for the difference if you are using slanted control surfaces on a swept trailing edge.

[doudou]

Forgot to add it into the last archive, uploaded a separate archive to the repo now.

Super thank you for cratf

[falken]

I think maybe the control surfaces should have a max length of 1.5 or 2 rather than 1.

Having trouble making my shuttle design fly without immediately sideslipping and falling from the sky. Running the latest build of far on github. As it is otherwise all stock could I maybe post the .craft to see if the problem is just on my end? FAR calculation say it should fly ok.

e: It's definitely not the fault of the wings. I just tried one of the two example craft and it flew flawlessly. Something in my design is just not interested in flying correctly! It seems like a shape that should work fine, though.

e2: B9 Procedural example 2 (Dreamchaseresque thing) has the same issues. Loses stability instantly and turns into nothing more than an impending crash.

e3: Bac9, will you be planning having a tweakable curvature to the leading/trailing edges? So one could for instance get the signature curve of the delta wings on the Space Shuttlle.

Edited December 31, 2014 by falken

[bac9]

I think maybe the control surfaces should have a max length of 1.5 or 2 rather than 1.

Sure, should be possible. I'll need to modify offset implementations a bit to prohibit very distorted triangular shapes possible with those sizes, though.

B9 Procedural example 2 (Dreamchaseresque thing) has the same issues. Loses stability instantly and turns into nothing more than an impending crash.

Sample 2 is not supposed to be particularly versatile atmospheric craft. I mean, it takes off alright and I did a few roundabout flights with successful landings with it, but mostly it's simply designed to glide back from orbit, not do aerobatics around KSC, as it has too little control authority and can stall easily. Requires flight assistance and gentle turns like any other design of unorthodox shape with suboptimal control surface placement.

[SchildConstruct]

Would curved leading edges be possible, for a more 'organic' look? Or does KSP's engine not allow for curves? I'm certain there'd be all kinds of attachment issues, too.

[Agathorn]

This is just outstanding man. Literally the first procedural parts I actually want to use because they don't look like crap.

The main note I would like to make right now, after just a few minutes with them, is that they don't scale down to small sizes very well. I was trying to use them as control fins on a .3m rocket and it just wouldn't work.

[Hyomoto]

Well shoot, I've been using pWings for quite some time but it looks like you are on your way to surpassing them. I don't know if you considered this, but like procedural fairings does, integrating various limitations on the size/shape of the wings based on research levels could mean we'd not only get great looking wings, but ones that integrate nicely with career mode as well! I'll wait for the official release but it looks like you are doing some great work.

[bac9]

Would curved leading edges be possible, for a more 'organic' look? Or does KSP's engine not allow for curves? I'm certain there'd be all kinds of attachment issues, too.

Not sure what you're asking about - leading and trailing edges already have two curved cross section types available. Edges do not affect any collisions, though, as is tradition with KSP parts to make multi-part wings and control surface attachment less infuriating.

This is just outstanding man. Literally the first procedural parts I actually want to use because they don't look like crap.

The main note I would like to make right now, after just a few minutes with them, is that they don't scale down to small sizes very well. I was trying to use them as control fins on a .3m rocket and it just wouldn't work.

The texture is not meant to be used on a small scale like that, and leading/trailing edges do not have scaling proportional to semispan and width, so at the moment those parts are unfit for small craft like that, yeah.

Well shoot, I've been using pWings for quite some time but it looks like you are on your way to surpassing them. I don't know if you considered this, but like procedural fairings does, integrating various limitations on the size/shape of the wings based on research levels could mean we'd not only get great looking wings, but ones that integrate nicely with career mode as well! I'll wait for the official release but it looks like you are doing some great work.

I'm not interested in career in it's current state, but I'll look into implementing that if it's not too problematic.

e3: Bac9, will you be planning having a tweakable curvature to the leading/trailing edges? So one could for instance get the signature curve of the delta wings on the Space Shuttlle.

I don't think I understand the question, curved cross section types for leading and trailing edges are already there. If you're talking about some other curvature, specify the axis it occurs on.

[DaMichel]

Outstanding work! Wing configuration via the part menu works very well for me and the wings have more options and better looks over PWings.

Just one minor thing you could fix for the next release: the temperature threshold of 850 deg is way too low! PS+ parts get 1500 from DRE. Scratch that. Must be DRE messing with maxTemp ...

Edited January 1, 2015 by DaMichel

[falken]

I think what I and Schildconstruct meant was the curvature of the wing on the shuttle. Where the delta wing's a leading edge angle changes there's a curve.

Also, what settings do you use for FAR flight assist?

e: Going to guess it's AOA limiter. I changed mine down to 15 and -15 respectively and stuff seems a bit easier to go with.

Edited January 1, 2015 by falken

[montyben101]

Looks amazing! This will work well with the Mk3 parts

[Horus]

I'm unable to reproduce this, so I'll need more details and a log.

> Procedural Wing: Side A (type) & Side B (type) do not change texture. Visually.

> Procedural Control Surface: Material A, Material B do not change texture.

Thanks, investigating that, likely linked to switching of trailing/leading edge meshes on the wings.

Seems that it was connected with previous version save. Created a new save & the issue is gone.

> Testing control surface with different flaps setups revealed some strange stalling effect at lift off position for flaps. The very same settings for stock elevons worked perfectly nice without this effect.

At the moment aerodynamic values calculation for control surfaces only accounts for root/tip width and length, not root/tip offsets, which will probably account for the difference if you are using slanted control surfaces on a swept trailing edge.

Hope that will be fixed at some time

The planes became really much more beautiful with these wings Thanks you very much

[bac9]

No ETA for the next version yet, but here is what's changed so far:

• Changed control surface geometry to allow topside and underside borders to go all the way to the trailing edge, improving the looks and readability of control surfaces with gray surface types.
  
• Added an additional wing edge type (evenly round)
  
• Improved texturing on wing edge cross sections

Only thing left is figuring out what is causing the memory leak. I eliminated one of the potential reasons (wing leading/trailing edge type switching is no longer reliant on mesh instantiation), but it still seems to occur over time, so something else is in play.

I would appreciate if some of you will do the testing of that particular issue. In particular, I'm interested in the following test setup:

• SPH
  
• New craft created with the latest version of the mod
  
• One part (say, stackable MK2 cockpit), one wing attached to it, no symmetry
  

Open the game in windowed mode, open some process monitoring tool next to it, and observe how RAM usage of KSP.exe is changing. I am interested in the following questions:

• Is there a situation where memory usage is not raising while the wing is present in the scene? (check it with wing dragged from catalog but not attached, with wing previously present on the craft but detached, with craft loaded but untouched, and so on - maybe there is a particular situation where memory leak is not happening, and if there is, it will help narrow down the source
  
• Is any particular action performed through tweakable UI causing noticeably accelerated rate of memory usage?
  
• Is there any difference in the rate of memory leak between fully stock game and a game with FAR?
  

Depending on results of those tests, I might be able to find the source of the leak, but so far search for it was inconclusive. I have eliminated all the obvious suspects like .mesh/.material calls and instantiation use, so I need more information.

[falken]

I'll do some testing (FAR)

Probodobodyne OCTO probe (nothing else) Ram Usage: around 2,080,000 (Stable)

Attachment of single Procedural wing: RAM Usage: 2,112,000 (Stable)

Changed Edge T (Material) from 4 to 1: RAM Usage Increase from 2,124,000 to 2,683,000 1000/3000kb a second

Removed wing from craft and deposited into the part menu. RAM usage stablised

Placed a new procedural wing into the editor, did not attach to probe core. (Stable)

Right clicked on part, RAM usage begins to climb at 1000 to 3000kb a second. Right clicked away from dialogue box to close it, RAM usage stabilises

Deposited part to the catalogue, picked new wing out and placed it on probe core. Same results as above occur.

It seems that something strange is happening in the right click menu. I was getting huge ram usage per second just by having it open.

e: Loaded straight from this craft to another vessel using B9 Proc wings and the RAM usage dumped from as high as 2,800,000 to 2,200,000.

[Darren9]

Could you add something similar to the standard canard or winglet? A standalone re-shape-able control surface that pivots at the center rather than have to make a small wing and trailing edge.