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

[Faster]

Noticed this causes some null reference exceptions with the toolbar, i.e.,

NullReferenceException: Object reference not set to an instance of an object
  at ApplicationLauncher.RemoveModApplication (.ApplicationLauncherButton button) [0x00000] in <filename unknown>:0 

  at WingProcedural.WingProcedural.OnDestroy () [0x00000] in <filename unknown>:0 

Perhaps the member stockButton should be checked for null before being handed off to RemoveModApplication at:

https://bitbucket.org/bac9/b9_aerospace_plugins/src/e8e08b27c372ed120ae440757cea7d000c1b1477/B9_Aerospace_WingStuff/WingProcedural.cs?at=master#cl-3256

[Mekan1k]

Hey guys. I run a few (dozens) of mods, and I have never run into this particular problem before.

The procedural wings will not attach when any form of symmetry is active. Any known issues?

EDIT:

If you have procedural wings, then the B9 Wings won't attach. Fixed it, but this seems like an annoying bug.

Edited April 2, 2015 by Mekan1k

[Van Disaster]

I have both, not seen that - perhaps check elsewhere.

[Mekan1k]

Still an issue. Will check-in with the procedural-wings group for solution. Removing allowed problem to 'vanish' for a few hours, then it returned.

[Mekan1k]

Still an issue. Will check-in with the procedural-wings group for solution. Removing allowed problem to 'vanish' for a few hours, then it returned.

Found issue: The un-moving procedural wing is causing the game to throw this according to the debug menu:

[Exception]: ArgumentOutOfRangeException: Argument is out of range.

Parameter name: index

I have no idea what that means.

[taniwha]

Mekan1k: it means you need to upload your log file and link it.

[Mekan1k]

Mekan1k: it means you need to upload your log file and link it.

https://www.dropbox.com/s/mnpzxqkpr9zoq1k/KSP.log?dl=0

[Crzyrndm]

That looks to be a bad interaction with Symmetry Action fix, possibly only 1.7e (it's the same error as this one here reported for a version which Claw pulled after two bug reports)

If you have the 1.7e version, try using 1.7d (the current release). Else, try removing the symmetry fixer altogether.

EDIT

Using 1.7d should fix it. There is a check to gracefully fail for that error that was not present in 1.7e

Edited April 5, 2015 by Crzyrndm

[NathanKell]

Yes, there's apparently an issue between this and symmetry action fix.

bac9, have to say I really am loving these. My only request would be a bit more flexibility--the minimums are a bit too high for a lot of my uses, and the 'steps' are quite large. Otherwise, though, <3

[yohuan]

Such a great mod, the values snapping keeps the shapes consistent which is really good but one problems is i wish the minimal values were smaller, where some places could 0 out.

[riceiq999]

Hi everyone. I'm trying to modify the config files of the procedural winglet to function as armors to coat my spaceship (for I'm using BD armory). So far they work and look great. It just has one small caveat - the "armor" piece still produces lift. I'm also using FAR. I'm wondering is there a way that you can tweak the config file so that ideally the mass will still be scaled based on surface area but lift would be 0. Thank you guys for any input.

[Van Disaster]

Hmm, tricky. The DLL itself passes values to FAR to use for lift data - I can't remember if it initialises from the cfg or if it's hardcoded, I haven't looked at the source in a while. If it's hardcoded I think you're out of luck.

[CorvusCorax]

Hi, I run into a problem with B9 procedural wings. I installed the mod as suggested as part of realism overhaul - so including RSS, FAR, remote tech and RP-0 as well as procedural fuel tanks and real fuels. I tried to play it in Career mode in "hard".

I noticed a bug earlier in the horizontal assembly building that when you put Tank Utilization to 0 in a Wing at minimum thickness sometimes it's calculated Prize becomes a NaN. (But not always.)

Now I built a plane and forgot about that issue, it had a correct prize (although the wings calculated part prize might have been zero, I forgot to check) I did a test flight, then recovered the vehicle.

On recovery the vehicles prize was however calculated as NaN - thus putting my funds as NaN as well as a result of the recovery. Now when I try to launch anything it tells me I have insufficient funds.

Since I'm in career on hard mode I cannot load an earlier safe game to fix this. If I complete contracts my money stays NaN, because NaN+something = NaN

Two questions:

1. Could you fix that issue so the prize of a procedural wing is never 0 / NaN ?

2. How can I hack my career mode profile to set my funds from NaN to for example 0? ( I don't care that I lost a couple of million creds but having to start over completely would suck, considering how much work it was to set up that com-sat network)

[CorvusCorax]

ok 2 was easy, found "funds = NaN in persistent.sfs in the career subfolder - just had to change that to 0 - was a bit off topic for this thread anyway

[Crzyrndm]

For anyone interested, I've forked this to start looking into some of the NRE's that are plaguing it (having 3 craft get NRE'd into oblivion is a great motivator...).

So far I've only fixed this one which occurred when you gave a wing part fuel and then tried to reattach it with symmetry. The only other change is making the fuel tanks fill up after increasing the wing volume so they always default to being full (I found the carried volume not matching the max volume to be quite irritating).

No promises that this won't cause other issues, I'm still getting my head around how this works.

Edited April 12, 2015 by Crzyrndm

[bac9]

For anyone interested, I've forked this to start looking into some of the NRE's that are plaguing it (having 3 craft get NRE'd into oblivion is a great motivator...).

So far I've only fixed this one which occurred when you gave a wing part fuel and then tried to reattach it with symmetry. The only other change is making the fuel tanks fill up after increasing the wing volume so they always default to being full (I found the carried volume not matching the max volume to be quite irritating).

No promises that this won't cause other issues, I'm still getting my head around how this works.

Hey, thanks for looking into it! I'm swamped with two jobs and thesis work so I did not have any time to update this lately.

[NathanKell]

CorvusCorax that's an RF issue, will be fixed in 9.1 (is fixed in git).

[Crzyrndm]

Fork updated with a fix for the nullref that was originally destroying my vessels. NRE occurred when Mirrored parts where hovering over an attach location (green highlight) and then mirroring was disabled before attaching. No other functional changes, this one was rather persistent...

That's the only two exceptions I had logged encounters with dealt to, so I'll be back to vessel designing unless there's anything else.

Hey, thanks for looking into it!

No problem at all. The mod is somewhat interesting to understand so bug hunting is not a total bore for a change

This is the fix for the first issue (fuel setup wasn't being run for symmetry counterparts created on a re-attach)

This is the fix for today's issue (disabling mirror apparently didn't clear the list of symmetry counterparts so there were null parts in the list)

The remainder of the changes is mostly just me grouping like minded functions together and adding linebreaks between the if () and the action (single line if's just don't get read properly when I'm skimming over the code)

Oh, and I worked out how the IPartSizeModifier interface works. It's completely bonkers (and utterly useless), the numbers you return are just added to the vessel dimensions (the input also appears to be the current vessel dimensions...), no checks for sanity or occlusion as far as I could tell (vessel size: -10m). You would need some way of telling how much of the part is not occluded and how much it changes the vessel dimensions in the first place before it would be of any use.

Edited April 13, 2015 by Crzyrndm

[ThorBeorn]

Thanks Crzyrndm for working on it and thanks bac9 for choosing a permissive license. I also agree with NathanKell on sizes, both a smaller min size and a larger max size would be great.

[fatcargo]

I was to read last 10 pages before reporting an obscure bug that crippled my craft editing in SPH and have plagued me since B9PW 0.3x, but i decided to try and hunt it down and have succeeded.

Steps i used to to reproduce bug / observations (in sandbox mode) :

- set fuel utilitization of procedural wing to 0%

- change wing geometry or place wings in symmetry mode

- save and reload craft (or launch and revert) in SPH

- wing editor no longer responds to J hotkey

- wing inherits name of whatever parent part it is attached to (visible with Kerbal Engineer Redux), even re-attaching won't help

- if wing is attached to parent non-bugged wing, J hotkey will target and affect parent wing

- right click menu still works, in some occasions if i hit the right one of the pwings in symmetry after loading craft, menu completely bugs out and is no longer available

- in-game debug log shows multiple

[Exception]: ArgumentException: Illegal prefix
Parameter name: pfx

- setting utilization to 0% also removes "remove all tanks" option from menu

- craft price becomes NaN

- if craft is large enough game will even refuse to launch the craft with message (in sandbox mode !)

Craft is too heavy
The Runway can't support vessels heavier than
2357823976234235645 tonnes {can't remember the exact number but it is just as ridiculous}
Total mass is NaNt

Exception Editor helped me intercept bug events as they occured.

In short, as long as i keep proc wing fuel utilitization above 0%, no bugs will hit. Even i if drop it to 0% and immediatley set above 0% it will be ok.

[bac9]

@Crzyrndm

Thanks again! I guess the best course of action right now would be to link your fork in the opening post so that people can discover it more easily.

Alternatively, I can give you the direct access to the repo if you're okay with that. No need to prune it down to fixes only, I don't mind style changes for readability you've mentioned.

Oh, and I worked out how the IPartSizeModifier interface works. It's completely bonkers (and utterly useless), the numbers you return are just added to the vessel dimensions (the input also appears to be the current vessel dimensions...), no checks for sanity or occlusion as far as I could tell (vessel size: -10m). You would need some way of telling how much of the part is not occluded and how much it changes the vessel dimensions in the first place before it would be of any use.

Woah, why am I not surprised :^)

Edited April 13, 2015 by bac9

[Crzyrndm]

- set fuel utilitization of procedural wing to 0%.

RF or MFT?

@Crzyrndm

Thanks again! I guess the best course of action right now would be to link your fork in the opening post so that people can discover it more easily.

Alternatively, I can give you the direct access to the repo if you're okay with that. No need to prune it down to fixes only, I don't mind style changes for readability you've mentioned.

Heh, didn't even know you had a repo (didn't see a link in the OP and the DL had source so I assumed there wasn't a public one at least ). Probably best to just keep it to a link though, the likelyhood of me not making actual functional changes at some point is rather low.

EDIT

Updated again, fixes the fuel not staying at the correct amount on reloading the flight scene and refilling on reverting to the editor. Geometry changes now retain the current % fuel rather than refilling completely (NOTE: I haven't tested the RF/MFT support yet, may prove troublesome as I just ripped large chunks of apparently unused fuel code out)

Edited April 14, 2015 by Crzyrndm

[Van Disaster]

Hm, we should also investigate the issue with trailing edges & CoL not updating right when you change type from/to the "no edge" version. I did have a good look through the DLL source a while back about that & really couldn't spot anything so it might actually be a FAR issue - I have only briefly looked at FAR source - but it's probably a good time to revisit.

[Crzyrndm]

- set fuel utilitization of procedural wing to 0%

That's a bug in RF (MFT?). NathanKell has already commited a fix by the looks for real fuels (utilisation clamped to a minimum of 1%)

Hm, we should also investigate the issue with trailing edges & CoL not updating right when you change type from/to the "no edge" version. I did have a good look through the DLL source a while back about that & really couldn't spot anything so it might actually be a FAR issue - I have only briefly looked at FAR source - but it's probably a good time to revisit.

I take it you're talking about when the CoP moved back rather than forward after removing the trailing edge? I'll take a look right after I get it updating in the editor again (I done goofed somewhere: FIXED)

EDIT

Center of Mass is not moving in a manner I would consider correct when it comes to the edges either (it doesn't move forward/back at all). This is very wierd

Edited April 14, 2015 by Crzyrndm

[energycore]

Hello! First of all wanted to say as an airplane aficionado, i really appreciate this pack. It's been amazing help to create more or less accurate replicas of IRL aircraft.

I recently made a replica of the F/A-18 Hornet. Sweet looking and maneuverable, this thing has been a blast to fly.

With an exception. I'm not very savvy with aerodynamics, but the outer section of the main wing (as you can see in the image, it's broken up into two sections, the outer one holds both control surfaces) has a very small stalling angle. Like, it will stall at angles of attack as small as 10 degrees. Those flaps will also stall at no less than 15 degrees of deflection. Is this a problem with how I shaped the wings, or the leading/trailing edges? Or is it a bug? I hope someone can shed some light into the situation.

Best Regards, Energycore

Mods used:

FAR, B9 Aerospace, B9 Procedural Parts.