bac9

Crzyrndm is correct. 1. Impossible to implement without completely rewriting how geometry is generated. 2. Increased root thickness + editor offset tool helps with that, or if you want independent slope just near the connection point, attach a reversed wing segment to the inward-facing plane of your main wing, and make it tip-wide and tip-high. Or use low span root-thick wings near fuselage segments which can have big sloping from thickness without spreading it into the main part of the wing span. 3. I'll look into it once I finish modeling MK2 update for the B9 pack. 4. Already in.

Nope, K3|Chris no longer has the time to do any work on the mod, as far as I understand. There won't be any IVA updates for the foreseeable future.

New cross section is vertically symmetrical so there is no such thing as top and bottom. Rotate it and you have a bomb bay.

Nope, sorry, cockpits with IVA are the most insanely time consuming parts to create and I don't really have an interest in sinking that enormous time into creating a very niche cockpit for HX part set. If I'll have some, I'll probably spend it updating more used cockpits, like MK2 one or S3 one. There are better big spaceplane sets out there, specifically OPT, so I'd prefer not to touch any new cross sections this time around. And I don't think MK4 is a good versatile cross section either, ideally it should be something completely symmetric to cut down adapter modeling time and allow the stacking of payload bays in any orientation.

Some news for your all. Work is underway to update the old configs and plugins (all thanks go to blowfish here), and on my side I'm completely redoing MK2 parts. Since Porkjet introduced his vastly superior cross section, this was long overdue, and with changes to stock and FAR aerodynamics making all old aircraft unstable anyway, it makes sense to completely ditch specific shapes and types of old B9 MK2 and come up with an entirely new set of parts that will play better with Porkjet pieces, will give you more options to build stuff, and will look far better than old stuff ever did. And as usual, it's all extremely optimized, with everything depicted in the following screenshots using just two texture atlases. Here is the album of some new MK2 parts (click on thumbnail to open): No specific dates yet, though, remaining work is enormous and I have a nasty habit of having a job, so we can't be sure when stuff will be done.

Amazing idea, can't wait to see the final version of that cockpit! Btw, upcoming B9 update will have a part that will play really well with it, allowing attachment to horizontal MK2 assemblies.

Just to remind: the shift to DDS format has absolutely zero impact on compression vs. 0.90. Shades of gray were always crushed into miscolored mess in every single version of KSP and in every single other game (majority of them, really), using DDS format. The only differences between 0.90 and 1.0 in that regard are: 0.90: Lossless source files converted to DDS on startup 1.0: Source files already in lossy DDS, startup just loads them into memory You might also want to ask Porkjet for the source files, since editing lossy DDS textures is a very bad idea artifacts wise. Upon saving your DDS texture edits, you'll be applying the extreme compression yet again, multiplying the artifacts. P.S.: As about the color, it's a good idea to never ever use true blacks even in the textures of materials that are supposed to be truly black, because you are not dealing with an unlit environment and past shading your objects might very well be black in many situations even if they had gray textures. Dark gray (e.g. 40/255) is far better for looks and texture readability than black as it rarely turns into a dark void in majority of lighting conditions. Only exceptions are elements like 1-4px seam lines on very dark fills, where black is the only way to provide contrast and depict a deeper element. Anything wider, though, I can't recommend.

@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. Woah, why am I not surprised :^)

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.

Uh, create a box primitive in Unity, remove it's mesh renderer component, scale it to dimensions you need, rotate it into orientation you need and move it to position you need? Not sure why would you ever use external software like Blender for setting up ladders and such.

I don't have any control over this, I think. Spoilers (and control surfaces in general) are handled entirely by FAR, the full extent of my influence is creating a part that can turn on a certain axis and feeding FAR it's dimensions.

This can't have anything to do with Active Texture Management as I'm using it and having no issues myself.

Dermeister, no, unfortunately that's impossible.

See if moving your entire game folder out of C: works.

Thanks. Looks like procedural wing fails to load or save the config XML because you don't have permissions for the folder or because some other process is accessing that file: IOException: Win32 IO returned 1224. Path: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\B9_Aerospace\Plugins\PluginData\B9_Aerospace_WingStuff\config.xml After that the game just spams null reference exceptions from FAR and RCS Build Aid. Can't reproduce it on my side, sorry.

From what I've seen part count can only noticeably influence performance when the difference is in the hundreds or many dozens of parts, and even the sizes you're talking about are unlikely to have more then 10 or 20 parts more with those limits. That's not possible, at the moment 16m offset is the biggest one available. As about extemely swept wings in general, is that an argument about allowing one wrong thing because another thing is also wrong? I'd prefer neither to be possible. Unfortunately that's impossible to do in a performant and general way. I'd like to see them gone too and I'm working on a way to limit offset parameters depending on wing semispan, to make things like 10m offset on 0.25m wings impossible. Another consideration I have to deal with is limited slider precision. I can't stretch them to an arbitrary range without ruining tweaking precision and making lots of values impossible to select. I have some ideas about zoomable range, but those are some time off. - - - Updated - - - For n-th time, please always post a log, I don't have anything to work from. Another person posted one, and I have fixed the reason he had his issue. Your issue can't be connected to his, since it was related to fuel GUI and control surfaces don't have a fuel GUI.

There is no way to do that at the moment. Why can't you just use multiple wings in a sequence, anyway? I think using a 30m long part is quite a bit of a cop out in terms of working with flex and other factors.

Version 0.34 Hotfix for fuel config description corrupting the UI

Are you using stock, RealFuels, or MFT? - - - Updated - - - Ah, found the issue, will update it soon.

Post logs, reports are mostly useless without them. Ideally with all debug options in the B9 debug window from the KSC scene enabled.

Version 0.33 Modular Fuel Tanks mod is now supported Fixed fuel saving in the flight scene, tanks no longer reset themselves to full capacity on quicksave or tracking station loading. Added step buttons to the left and right of the tweakable sliders, allowing you to move through the values more quickly Some minor fixes and UI style improvements

Nope, I don't see any good way to do it, I'm already using every single bit of information you can cram into meshes and every single texture channel. There is no way to render solar panel variety without some surface switching options.

I'll look into it, but it requires some problematic changes so probably not in a next version. No, that's not possible. Look into Infernal Robotics if you are interested in rotating part connections. This is an extremely complicated area and I don't think my mod should touch it when specialized plugins exist.

Version 0.32 Potential fix for resources being replenished on craft reload (capacity correction executed every time volume is updated might have been at fault) Some GUI skin improvements

Looked into part size interface once more, looks like it accepts not an absolute size in meters but a scaling multiplier derived from the current dimensions divided by default dimensions (which is extremely weird). Unfortunately, while this idea seems to be correct for length, width and thickness are still calculated completely wrong when size is sent from my module in that format, so I'm going to assume that the size interface is completely broken right now. Sorry, supporting small career SPH is pretty much impossible. It's impossible to rotate frame of reference for FAR from within a part, so it's a no go, you'll have to deal with rotating the wing parts themselves.