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

[Crzyrndm]

17 minutes ago, blowfish said:

Logs would probably reveal the issue.

6 hours ago, Jerry060599 said:

Here it is: 

https://drive.google.com/file/d/0B-AmS2w7GkSQdXdEQ3dPRXV2VnM/view?usp=sharing

The bad mesh tris was the only useful issue I could pick out (you can ignore the B9PWings exception, it happens when loading the editor scene with a craft already loaded. Haven't been able to prevent it without other issues...)

EDIT

Well there is one issue, that log is still saying it's KSP v1.0.5.1024

Edited January 19, 2016 by Crzyrndm

[kcs123]

16 hours ago, sashan said:

Re-enabling it broke nothing but made my ship rigid like it should be. Airplanes also work just OK. I now want to test compatibility with TweakScale rescaling module.
P.S. YEs, I'm also using the wings for planes. It's jut that they are so flexible that the ships turn out to be are no worse than planes.  

 

What is name of mod used for visual enhancment of water ? Nice looking waves on picture
Does that comes with EVE ? Didn't tried EVE for a while due to memory limitations (too many mods and small memory leaks)

[JoeNapalm]

 

So, the description says "You must FAR 15.3.1 or later. [sic]"

 

However, I find I don't enjoy FAR very much (yeah, yeah...I have a lot of time and designs with the soupy mock aero in stock, lemme alone!) so I uninstalled it.

 

That said, my B9 Procedural Wings seem to work just fine in stock.

 

Am I headed for disaster if I just keep rolling this way? What's the reason behind the bold admonishment to use FAR?

 

Thanks,

 

-Jn-

[kcs123]

8 minutes ago, JoeNapalm said:

Am I headed for disaster if I just keep rolling this way? What's the reason behind the bold admonishment to use FAR?

OP is not updated for a while. It is much easier for moders to create parts compatible with FAR than stock game due to new voxel system and bunch of other things. For stock part there is need for more effort, to write down config files properly and test everything prior release.

There is note in this thread somewhere that is just fine to use B9PW with stock aero, it just get buried somewhere in thread.

EDIT:

OP is last time edited 25 Jun 2015 by bac9. Quite a lot of changes since.

Edited January 19, 2016 by kcs123

[blowfish]

22 minutes ago, JoeNapalm said:

So, the description says "You must FAR 15.3.1 or later. [sic]"

The intent of that statement isn't clear.  It means if you use FAR, then you must use 15.3.1 or later.

[JoeNapalm]

2 hours ago, blowfish said:

The intent of that statement isn't clear.  It means if you use FAR, then you must use 15.3.1 or later.

Ooooooooooooh,

 

Gotcha.

 

Well, that's good news to the crew of my orbiting procedural-winged SSTO. There's a life raft on that one, but they checked the tags and it's a revised model that hasn't been tested yet, and they were throwing roshambo to decide which option to try.

-Jn-

 

[sashan]

4 hours ago, kcs123 said:

What is name of mod used for visual enhancment of water ? Nice looking waves on picture

Newest version of Scatterer. IDK how much RAM it actually takes but its folder is 70mb in size.

[Crzyrndm]

Just as something to be aware of, any future development on my part for this mod is going to be as part of a new git repository. The reason for this is as I work on both types of PWings, I often find myself porting features from one to the other (eg. the improved fuel switching logic I just added to PWings I will also apply to this mod), resulting in duplicated effort, more possibilities for bugs, etc., etc. By using common base modules, I only need to do this once and it just helps me a lot.

There is one possible gameplay advantage (past less bugs and faster feature development...) that I will explore once the merge is more complete, and that is the two wing types being able to work together on one craft (eg. shape matching, edge snapping, joint strength)

NOTE: The merger would only apply to the plugin. The packs can/will still be released separately

EDIT

To give an idea how how much duplication there is, the new root module currently handles all the KSP interfacing, aero, and fuel switching and ends up at about half the code for original PWings, and just under one sixth for B9 (UI related stuff and the texture/mesh math making up most of the extra...). There's still more to go as well... (Updated: 1/3 of the original code didn't become common...)

Edited January 20, 2016 by Crzyrndm

[kcs123]

@Crzyrndm maybe to create three plugins instead of one or two ?

Main plugin could have common code that both mod need and B9PW plugin have it's own additional code for texture/mesh related stuff while PW use different plugin that deals only with specifics used only in PW mod.

Just suggestion if it will be easier for you to maintain it in future. Probably it will be easier for CKAN staff to pick up proper files and does not mess up install.

Edited January 20, 2016 by kcs123

[blowfish]

28 minutes ago, kcs123 said:

@Crzyrndm maybe to create three plugins instead of one or two ?

Main plugin could have common code that both mod need and B9PW plugin have it's own additional code for texture/mesh related stuff while PW use different plugin that deals only with specifics used only in PW mod.

Just suggestion if it will be easier for you to maintain it in future. Probably it will be easier for CKAN staff to pick up proper files and does not mess up install.

Would this actually change anything meaningfully?  Instead of two part mods that both depend on the same plugin mod, you just have two part/plugin mods that also depend on a plugin mod.  I don't think that having a bit of unused code impacts performance meaningfully (and it's entirely possible that loading a separate assembly would be worse).  Plus, maintaining interdependencies between plugins can be painful at times.

[kcs123]

8 minutes ago, blowfish said:

Would this actually change anything meaningfully?  Instead of two part mods that both depend on the same plugin mod, you just have two part/plugin mods that also depend on a plugin mod.

From user point of view, nothing will be changed. I agree, it will be harder for user to figure out dependencies and higher chance of making mistake.
That is obvious downside of idea. However, from developer point of view, on future updates most of work will be on common plugin while two other plugins (hopefully) would not require any change. That is point of whole idea, to make life easier for developer, so he does not have to change same code in two different plugins and does not missplace something or forgot to add some line of code.

Like I said, just suggestion, it is your call, for moders who actually do all hard work.

[Crzyrndm]

As blowfish points out, 1 plugin + 2 part packs isn't much different to 1 plugin + 2 plugin/part packs except the extra plugin complexities. From my point of view, a single plugin has the advantage that the two wing types (four types now, separate modules for control surfaces) "know" about each other, and there aren't really any disadvantages for me or the user except an extra GameData folder if I don't end up sticking it one or the other.

Chance are this will be post 1.1 before its in general use, seems like there will be plenty of time for testing judging from latest dev notes (if I have to, splitting them is a very easy task)

Edited January 20, 2016 by Crzyrndm

[kcs123]

Well, in case of 1 plugin + 2 parts pack, it will be good that plugin have his own gamedata folder. Otherwise MM might be confused if someone want PW parts and no other parts from B9 Aerospace. Plugin wold be in "..\Gamedata\B9_Aerospace\Plugins\" folder and if someone wrote some MM patch searching for B9_Aerospace folder as recognition if something of B9 parts is installed or not it could be missleading.

Oposite way could lead to same misleading result. Better option would be that plugin is in for example in "..\Gamedata\Crzyrndm\Plugin" or whatever folder name you found apropriate adn parts in the same part pack as it is now. Only some changes have to be made in part pack so it can find plugin in different folder if unity need to specify it.

When 1.1. comes out there is high chance for users to keep playing on 1.0.5. until most importants mods are properly updated for 1.1.
We can only hope that 1.1 will not break too many things to discourage mod development. Anyway, I see you already have similar idea to keep common plugin in extra GameData folder, hopefully it will give you more extra free time on the end of the road, to actually play a game for a while, not only moding it.

[sashan]

I want to add a new custom resource to the wings, any tips on how to do that? I only see a mysterious ModuleFuelTanks without any configs of what fuels can it house.

[ABZB]

This is the simplest way, especially if you are new to MM (just replace the i wrote inside the <> (including those angle brackets) with whatever your resource's appropriate field is):
 

@TANK_DEFINITION[*]:FINAL
{
    %TANK[<resourcename>]
    {
        name = <resourcename>
        utilization = 1 //if you want to penalize the tank volume (like you need to simulate extra-thick tank walls for radiation shielding or something) make this less than 1 
        fillable = True
        amount = 0.0
        maxAmount = 0.0
        //the following three only apply with RealFuels, I think delete them all if you don't want the leaking away at high temps
        wallThickness = 0.0025 //this is for insulation calculation, the higher it is the better insulated (it will work but not make sense if you make this higher without reducing utilization (especially if thicker than the tank is wide)
        wallConduction = 16 // higher it is the worse an insulator
        temperature = 90.15 //temperature in kelvin where the resource starts leaking away. if you delete this line, then no leaking will occur
    }
}

 

[Crzyrndm]

if you're using MFT or RF, look up how they are configured. If you're using the release version without RF/MFT, you can't, the fuel types are hardcoded into the plugin. I haven't finished the configurable fuelling on my development version at this time.

tl;dr
RF/MFT or bust

[sashan]

4 hours ago, ABZB said:

This is the simplest way, especially if you are new to MM (just replace the i wrote inside the <> (including those angle brackets) with whatever your resource's appropriate field is):

I'm quite familiar with MM and config editing. Just couldn't find the file which describes tank definitions. So, I guess that that's for a reason  

[V8jester]

B9 P-wings are absolutely outstanding! There's no other way to build stuff like this without them  Thanks guys!

[StarStryder]

Have I missed something?  I can't seem to attach anything to the P-Wings, not even your own P-Control Surfaces.

[V8jester]

4 minutes ago, StarStryder said:

Have I missed something?  I can't seem to attach anything to the P-Wings, not even your own P-Control Surfaces.

There are two different P-wing "wings" in this pack. The "all moving control surface" and "wing" Nothing can attach to the control surface. Only the wing can have things attached to it.

[Almodeon]

I may have detected an incompatibility with Deadly Reentry. I dunno if this is already known, but here goes.

I get NullReferenceExceptions whenever I put a procedural wing (whatever type) on a vessel while DRE is installed. I am not sure if this is caused by B9 or by Deadly Reentry, so I am taking the chance by posting it here. The rather slim rationale is that maybe this last version of B9 requires some sort of config for DRE?

Environment:

win7 64bit

Reproduction Steps:

• Fresh install KSP (1.0.5.1028),
• Install CKAN 1.16.0.0,
• Install B9 Aerospace Procedural Parts - Fork v. 2.1, with dependencies,

Up to this point the game works and no NRE is thrown,

• Install Deadly Reentry v. 7.3.1, with dependencies,
• Launch game,
• Go in SPH and place a pod,
• Attach a b9 procedural wing (or moving surface, or all-moving wing),
• Launch,
• stare at the wall of NREs in the debug menu.

Logs:

https://www.dropbox.com/s/lf8iuaimfajc65w/output_log.txt?dl=0

Installed mods:

• B9 Aerospace Procedural Parts - Fork v. 2.1
• Crossfeed Enabler v. 3.3
• Deadly Reentry Continued v. 7.3.1
• Module Manager v. 2.6.18

[kcs123]

18 minutes ago, Almodeon said:

I may have detected an incompatibility with Deadly Reentry. I dunno if this is already known, but here goes.

I get NullReferenceExceptions whenever I put a procedural wing (whatever type) on a vessel while DRE is installed. I am not sure if this is caused by B9 or by Deadly Reentry, so I am taking the chance by posting it here. The rather slim rationale is that maybe this last version of B9 requires some sort of config for DRE?

Environment:

win7 64bit

Reproduction Steps:

• Fresh install KSP (1.0.5.1028),
• Install CKAN 1.16.0.0,
• Install B9 Aerospace Procedural Parts - Fork v. 2.1, with dependencies,

Up to this point the game works and no NRE is thrown,

• Install Deadly Reentry v. 7.3.1, with dependencies,
• Launch game,
• Go in SPH and place a pod,
• Attach a b9 procedural wing (or moving surface, or all-moving wing),
• Launch,
• stare at the wall of NREs in the debug menu.

Logs:

https://www.dropbox.com/s/lf8iuaimfajc65w/output_log.txt?dl=0

Installed mods:

• B9 Aerospace Procedural Parts - Fork v. 2.1
• Crossfeed Enabler v. 3.3
• Deadly Reentry Continued v. 7.3.1
• Module Manager v. 2.6.18

Two pages back, and few post below this post NathanKell explained. Probably fix will be included in one of next B9PW releases.

[Almodeon]

14 hours ago, kcs123 said:

Two pages back, and few post below this post NathanKell explained. Probably fix will be included in one of next B9PW releases.

I don't know how but I totally missed that...

Thanks!

[sashan]

Apparently the wings work with TweakScale module, but mass stays same and does not scale. I was able to make this tho

It's 200 meters long. Scrapped til 1.1 improves multi-part performance.

[StarStryder]

On 28/01/2016 at 4:00 PM, V8jester said:

There are two different P-wing "wings" in this pack. The "all moving control surface" and "wing" Nothing can attach to the control surface. Only the wing can have things attached to it.

Thanks V8jester, that was it.  Never thought about it since most of the normal control surfaces are small enough that you'd never think of attaching anything to them.

One other question if I may.  This may or may not relate to B9 but I never noticed it in stock.  Of course, it may related to RO or Ferram.  Anyway, I power up and start off down the runway.  At about 45m/s the plane starts veering off to one side of the other, usually resulting in loss of control.  I've double checked the landing gear and it's straight and the wings and elevators were attached using symmetry so they should be equal.  I've also upgraded the runway 1 level to smooth it out a little.

I just wondered if anyone had any thoughts on what's going on?