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

[p331083]

Issue;

Wings quickly become bugged and not able to attach to anything after a certain amount of deformation. Not only that but entire SPH becomes bugged and I am unable to select or place any other parts. Only fix is to start new but the bug quickly happens again.

32bit version.

[Horus]

0.11

It was quite unusual to use the new editing approach... seemed quite inconvenient... but a couple minutes later - no problemo at all & totally easy!

Do not experience severe memory leak with the new editing approach for now

Editing using tweakables, however, still insanely memory leaking... ~6Mb/s

Edited January 7, 2015 by Horus

[bac9]

Issue;

Wings quickly become bugged and not able to attach to anything after a certain amount of deformation. Not only that but entire SPH becomes bugged and I am unable to select or place any other parts. Only fix is to start new but the bug quickly happens again.

32bit version.

That's not enough information, I need to know what other mods you are using, at which particular point they are breaking, whether there are any errors in Alt+F12 -> Debug log window and so on.

[Horus]

When using B9-PCST with new editing approach after editing Material A I receive a message for next item (switched by pressing "J"):

Editing: Invalid properly ID

Which must be Material B settings. Then Material C also shows this message.

[bac9]

When using B9-PCST with new editing approach after editing Material A I receive a message for next item (switched by pressing "J"):

Editing: Invalid properly ID

Which must be Material B settings. Then Material C also shows this message.

Ah yeah, forgot that control surfaces have 9 and not 7 properties, so a check in a certain place was rejecting the last two. Fixed, thanks.

[Horus]

Seems that B9-PCSA breaks this new editing mode.

Steps to reproduce:

1. Create a craft hull

2. Attach B9-PW

3. New editing mode popup appears

4. Attach B9-PCSA

5. Editing window title becomes "Inactive" and the message is "Exiting edit mode..."

6. New editing mode is not working anymore.

Extra:

7. Leaving SPH/VAB and entering it again does not fix the problem.

No particular errors or warnings in in-game debug log.

[bac9]

Uh, is that happening when you edit procedural wing specifically and create a new part from the catalog that is an all-moving surface specifically? Or is that happening to the wing property menu when any new part is created while editing is in progress? Or is that happening to the property menu of any procedural part with a specific new part created? Or is that happening with any procedural part when any other part is created?

[Horus]

Yes. All parts are dragged from parts catalog only. No parts cloning (with Alt).

PWings works perfectly. Wing control surface too (not taking textures bug into account).

Only all-moving surface breaks the thing. But weirdly... this breaks only after attach-detach-add-remove in conjunction with pwing.

Edited January 7, 2015 by Horus

[bac9]

I'm not sure I follow. Editing mode window (one with property hints and "exiting edit mode" message on exit) never appears on it's own after just attaching a new part. Have you missed "pressed G while keeping the mouse on B9-PW" step between steps 2 and 3 from the previous post?

[Horus]

Uploaded video regarding this issue - http://youtu.be/I9MHfyPxZns

[AngelLestat]

Good Job Bac9, I will try this mod over the previous Procedural Dynamics.

[bac9]

Version 0.12

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

• Added new surface type (uniform fill) by exploiting other vertex color channels in the shader - even though new texture types can not be added anymore
  
• Fixed alternative UI breaking in some detachment scenarios
  
• Potentially fixed an issue with wing geometry being constructed only after FAR performs vessel checks in the flight scene, which was leading problems like control surfaces stalling when they shouldn't
  
• Added value descriptions to material properties in the alternative UI
  
• Fixed some minor issues

To remind, stock tweakable UI stores min/max values in the craft file for some bizarre reason, which means, for example, that you will not able to make control surface cross sections wider than 1m on crafts saved before version 0.11, that you will not be able to use new material type on wings created before 0.12, and so on for any change to types and value limits. My custom UI still works, though, so you can use that to set new values on old crafts if you don't want to rebuild them, until I figure out a way to override that bizarre tweakable UI behaviour.

[camlost]

The stall problem remains. How does KSP determine the sequence of OnStart() of multiple partmodules being called ?

[bac9]

Well, that's problematic, OnStart is still too late then. I can't use Awake because it's only called on the loading screen, same as OnAwake. What else is there to allow setup before FAR startup? I'm not sure if Start event on MonoBehaviours runs before KSP OnStart.

There is no way to influence execution order of classes without access to source Unity project settings, so if I want my module to run before FAR every single time, I need a method different from OnStart.

[Wampa842]

Here's my random idea to solve it. I doubt it'll be the one that works, though. Also, it's a very cheap workaround.

Maybe you could use the Procedural Dynamics method to create an invisible "dummy" wing that provides the wing data, but is otherwise unnoticeable. You could then use your own procedural wings for visuals only. No lift, no drag, no weight; practically a hologram.

It of course means having to handle two objects using two different methods, which means double the required resources and twice the chance of something going haywire.

I could be wrong, I don't know how FAR works.

Edited January 8, 2015 by Wampa842

[Agathorn]

Really like the new UI. At first when you said it was mouse based like pWings I almost died because I HATE that system. But while yours takes a bit to get used to, it is actually really nice and easy to work with. It also has the bonus of not lagging to heck like the tweakable menu.

[Hektos]

Hey bac9 (or anyone else really), I am currently using your B9 Aerospace plane parts pack. Would you say that this mod effectively replaces all the wings from that pack? Or would I be losing something by removing all of the wing parts from my B9 install?

Thanks for the opinions and inputs!

[blowfish]

Hey bac9 (or anyone else really), I am currently using your B9 Aerospace plane parts pack. Would you say that this mod effectively replaces all the wings from that pack? Or would I be losing something by removing all of the wing parts from my B9 install?

Thanks for the opinions and inputs!

The B9 wings have a slightly different look - IMO the B9 PWings don't quite fit visually with other B9 parts (though with S2 they look alright).

[kofeyh]

These wings are brilliant; cautiously optimistic memory issues are fixed now, they were pretty bad.

Is it too forward of me, as to inquire what priority you are placing on heat shield support, or rather, mechanics to work with Deadly Re-Entry, bac9?

[joebopie]

ignore this

Edited January 8, 2015 by joebopie

[bac9]

The stall problem remains. How does KSP determine the sequence of OnStart() of multiple partmodules being called ?

Discussing it with ferram4 now, and it looks like the issue is not with OnStart order but with fundamentally wrong sequence of actions. Implementation from pWings is incorrect too. The problem is arising from the fact that FAR StartInitialization method computes per-wing occlusion data and not craft-wide occlusion data, so calling it after setup of a particular wing is not correct - you must complete geometry setup of ALL wings in the craft before starting to call that method for every wing in the craft in a separate loop, otherwise checks those wings perform can be potentially done before their eventual neighbors take shape. Looking for a good way to implement that now.

Edited January 8, 2015 by bac9

[fatcargo]

Quick question : where KSP Api Extensions DLL should be placed ?

In KSPApiExt thread author mentions that DLL should be placed along a plugin using it.

Currently, is appears to me that this pack has KSPApiExt placed in it's own folder in GameData, which is not correct ?

I've placed it in same Plugin folder as B9_Aerospace_WingStuff.dll and i did not see any problems.

Oh yes : and kudos for making wing design a fully numerical process, there is no room for error and discrete numerical increments eliminate guesswork.

Edited January 8, 2015 by fatcargo

[Horus]

Discussing it with ferram4 now, and it looks like the issue is not with OnStart order but with fundamentally wrong sequence of actions. Implementation from pWings is incorrect too. The problem is arising from the fact that FAR StartInitialization method computes per-wing occlusion data and not craft-wide occlusion data, so calling it after setup of a particular wing is not correct - you must complete geometry setup of ALL wings in the craft before starting to call that method for every wing in the craft in a separate loop, otherwise checks those wings perform can be potentially done before their eventual neighbors take shape. Looking for a good way to implement that now.

Well... at least you understand what you are saying Hope you'll come to a good way to implement it & fix FAR stalling issue

Just playing around with proper wing mechanics And all this thanks to your inspiring "one-weekend-evening-short" project

Edited January 8, 2015 by Horus
UPD: getting more tests

[bac9]

Quick question : where KSP Api Extensions DLL should be placed ?

In KSPApiExt thread author mentions that DLL should be placed along a plugin using it.

Currently, is appears to me that this pack has KSPApiExt placed in it's own folder in GameData, which is not correct ?

I've placed it in same Plugin folder as B9_Aerospace_WingStuff.dll and i did not see any problems.

Oh yes : and kudos for making wing design a fully numerical process, there is no room for error and discrete numerical increments eliminate guesswork.

KSP will load it correctly either way, - as far as I understand, that advice is only relevant for mods that fork KSP API Extensions functionality, and I'm not doing that, only using custom tweakable types.

[Horus]

I don't think it's the issue of your mod, but I've noticed that when I detached a created & fine-tuned wing with assigned action groups to, say, flaps - the action group will not work for the second wing when the wing is re-attached with SPH symmetry.

Just a notice - always re-check AG.

A funny notice: when activating (in SPH while constructing the wings) both spoiler & flaps for a control surface - the flap opens/closes really faster then necessary. Even when spoiler is not activated This is FAR "feature" I presume.

Edited January 8, 2015 by Horus