bac9

Ah, alright, makes sense.

Brilliant work here, good to see a new way to make those displays. What do you mean by supporting exactly one camera, though? Most internals have multiple possible camera positions, usually accessed by double-clicking the windows. Is the text rendered in screen-space or via some similar way so that it will be missing or incorrectly projected if you'll look at a display from another camera?

Those are extremely simple color filters that have next to none performance impact. Not that I see any point in using them, this is essentially equivalent to throwing away a portion of the color range (which is already tiny without HDR). I'm in favor of good color grading similar to cinema, but this thing here is more reminiscent of a tinted glass. Not to mention that good color grading can't be done without HDR, and KSP has no HDR support, so sweet visuals from Skyrim or GTA4 based ENB derivatives will never be replicated there. Completely incorrect. Like with any other game, KSP will use your GPU to draw everything your see and will use VRAM to store everything you see from the textures to frame buffers. Performance hit is absent because this particular version of ENB won't do anything but simple post processing that's probably achieved by creating another screen-sized texture and doing stuff to it, which is a fairly trivial operation. Film grain is literally random noise overlayed on the image, of course it's virtually free. KSP is using multi-camera setup and scaled world around the player, so depth of field effect distribution will be incorrect, as the depth buffer DoF will be using as the reference in no way represents real distances in the scenery. Can't recommend using it. _________________ P.S.: As a side note to those who will no doubt say that ENB will get better in the future, nope. ENB loaded with KSP won't have feature parity to GTA4, TES, DXHR and other versions in the foreseeable future. KSP is using the forward rendering and not postprocessing-friendly deferred rendering. Expect no AO, GI, reflections or other fancy effects from those other versions. Simply put, there is no data available in the game for those effects to work from. So yeah, ENB here is going to be stuck with simple color filters and some half-working effects like DoF.

1. Composing stuff like those circular habitation modules from dozens of spheres is very, very, very, very bad for performance as you will end up with extremely high polycounts (not to mention unsightly z-fighting between the spheres). At this point it would be easier to just make a donut-shaped part yourself to use for the designs like those. 2. Same for other things: you seem to be using a Cupola part every time you need to make a hexagonal window, which is very expensive polycount-wise too. Make no mistake, those parts aren't performance-friendly and the advice from above to use the reduced stock texture pack won't help in any way here - as the performance hit will come from the polycount, not textures.

Nope, you were never able to do that. No collisions ever happen within the craft hierarchy, and your payload docked inside the cargo bay is the part of that hierarchy, so if it can bend enough, it doesn't matter at all whether you have the floor below it or 50 km of open air, it will move all the same. Collisions only happen between separate crafts, when you are rolling a rover into the cargo hold, for example. If you want nothing to clip through the bay, either use short non-bendable payloads or secure stuff with struts (KAS mod is especially awesome for that since you can set up struts in EVA and re-strut everything as you'd like instead of just loosing all editor-placed connections on the first undocking).

Some small hotfixes, I think they are listed in the changelog.txt from the archive. No plans, it will look ridiculous. There are other large parts underway that will work better for that sort of thing.

If the gear is mounted at the slightest lateral angle instead of staying vertical, it will become unstable, same occurs with the stock gear.

Not doable without an additional plugin as it will continue to provide the lift no matter the animation, and we are unwilling to add any more plugins to the mod. And as KhaosCorp said above, proper designs don't need stuff like that anyway. I'm afraid you are. No, S2 is too small to make the ramp useful, even pretty tiny rovers will hit the ceiling there.

Ha, great to hear it's in there so soon. )

Not really, you just have a core part defining the allowed radius from the central axis and subsequent attachments that increase the allowed length of a craft. Last assembly core diameter can be quite roomy, so I don't see any issues with large crafts here. As I've said above, making a dock one single part that can be upgraded with the parts is the easiest implementation, but it's not very beneficial to the game. There already isn't much to do in the game, so reducing space dock management to delivering completely identical part containers countless times, just like with ship components, is not a very interesting solution. It's best when a system in the game delivers some varied and interesting challenges, which, in this case, would be do design, launch and dock the payloads with the space station components of varied shape and size, - that will occupy the players nicely, making a large operational orbital dock a very satisfying achievement in itself. Speaking of which, I don't think spacecraft construction should be necessarily done with just one resource. Artificially inflating the micromanagement by introducing several faceless types of resources like metal and ceramics is unnecessary, but there are several logical improvements that can be done there: for example, all crafts assembled in the orbit should start with no fuel (and should remove appropriate amount of fuel from the dock to fill them, if the dock has fuel tanks attached) and no crew, which will serve as another interesting opportunity to build service ships like crew delivery vehicles (like efficient spaceplanes) and fuel tankers. Essentially, orbital construction is the opportunity to give players lots of interesting activities and reasons to design cool crafts - it shouldn't be HyperEdit in a disguise.

Sounds good, it's reasonable to start with just one type. Regarding the implementation, though, I don't think it's a good idea to hardcode the position as something like "5m from the dock" - just require an empty game object to be present in the part from which the coords and rotation are used for spawning the craft (let's say, with Z as up). Great idea about making it possible to perform upgrades right through the initial dock, although I think that takes out the fun and challenge of lifting and docking them. Easier to implement, though. As about VAB/SPH crafts, there should be zero difference between them as both are using identical axis as "up" in their craft formats, if I recall correctly. Only thing unique to aircraft is the use of bound colliders for the landing gear which should be irrelevant in space as there is no runway to fall onto.

I can look into the modeling, shouldn't be too hard. It's not that big of a part set, I guess (containers, storage, differently sized assembly enclosures ranging from small 2.5m wide workshops to something like half a VAB). Not sure how to handle large orbital docks though, as making one huge part you need to bring into orbit feels a bit cheaty. How about an implementation that supports not just one part, but multiple ones you should connect together in a certain way? Let's say there is a modestly sized core module, but it checks whether it has certain auxiliary parts connected to it if you want it to work. Component parts of the dock piece can have the docking port modules with a certain unique designation, and can be shaped in a way which prevents them from being docked from an unintended angle (kinda like ports on the PC), so it will be hard to assemble the whole thing in a wrong or cheaty way too (like slapping the parts randomly around some station). Of course, you can assemble it in the editor and launch it together, if you can manage to build a vehicle capable of lifting the ridiculous full weight in one go (and if you don't play with FAR where lifting something shaped like that is not the brightest idea), but it would be fun to make preparations an interesting exercise in docking and delivery of various payloads. Another, implementation of this would be to have core parts of a different radius which have some initial space they are certified to build within, and which you can expand in length by docking the additional modular pieces to the front of them. That's more simple to implement too, I guess. Attach a piece, get +20m to allowed length on the bounding box check.

Nice work! A small idea, though: is it possible to alter the logic of the vessel spawn in the orbit, creating them not in an arbitrary place away from the station, but on a certain transform contained in the space dock part? This way, you can make a very fancy space dock part model (something like installations from Star Trek with empty space in the middle), in the middle of which your spaceships will naturally appear. Let me illustrate. Think of a part like that as of something like a roof-less VAB where your craft will appear. To avoid collisions with too small dock parts, additional check can be implemented: a part can not only include a spawn transform, but also a trigger collider that's used in a check against the dimensions of the craft. If the check is passed, craft is allowed to spawn, if not, well, make a smaller one or use a bigger dock.

Incredible work, ferram4, it was a long time since I've had so much fun flying large ships in KSP! Can't thank you enough. I have noticed stock radial decouplers not ejecting attached pieces properly (Radial Detachment Manifolds, I think), same as KW stack decouplers and KW fairings. Part stays entirely in place and you an only separate from it by changing your velocity (hopefully without slicing something off with a collision). I think it's not something with individual parts, - rather, it looks like ejectionForce parameter stopped working entirely. Not gamebreaking, but would be nice to have fixed. On another subject, I think collisions with the ground are much more unforgiving now, at least with KW 2.5m engines and tanks exploding on a fairly gentle <5m/s touchdown. All the more reason to use nice suspended landing legs, but wouldn't hurt to look into.

No plans at all, full resolution textures work for many 64-bit OS users so I have no reason to throw them away. It is the definitive version. I don't think installing the reduced texture pack using the same tricky skill of folder overwriting you have to use to install B9 itself is a very hard challenge. KSP is already LAA, otherwise it would've crashed at 2Gb and not on 3.5Gb+.

4.0 has just a few more textures than 3.4 (most of the new parts are reusing the old textures), and raw bitmap size of all texture data is even lower than it was (as multiple x2048 textures are no longer used), so there is nothing about the part selection that would push the memory usage higher in comparison with the previous releases. The change of the texture format is completely irrelevant either, we have double checked the peak memory usage with both PNG and uncompressed TGA and it's always at 2.2Gb, identical down to a megabyte (claims that PNG textures reduce the peak footprint are false). Whatever happened with lots of you suddenly getting out of memory crashes is more likely related to 0.22.

Every single other cargohold does that by default, but you can open it right in the editor by clicking on the doors while in action group menu. Your preference will be saved then.

Yes, they are completely compatible.

No and it won't in the foreseeable future (unless you are referring to this mod in general and not just to the latest update, - then yes, there are three IVAs with MFDs, but new ones won't be available anytime soon).

Not sure where you are getting the 100x figure, the pack was around 100mb before and is now 586mb unpacked. Memory footprint is identical because either way raw bitmap data gets dumped into memory even if you are using PNG, and because after initial loading all source files are removed from the memory, leaving only GPU-supported DDS files that have completely identical size no matter the source texture format.

Yeah, by the way, don't use the B9 textures from this thread: http://forum.kerbalspaceprogram.com/threads/51361-0-21-Squad-Texture-Reduction-Pack-B9-and-KW-Packs-also They have been converted incorrectly, with alpha channel lost on all textures, which breaks specularity rendering and renders all glass opaque. From now on, there will be an official low-resolution set of textures included in the archive.

Hotfix with few high-res textures fixed and with an optional low-res texture package will be available shortly. You'll need the Firespitter.dll plugin for the info drive and the generic animation modules in the lights, I guess.

It could be an issue with KSP texture loader which is probably keeping every single source file in the memory until the loading is completed instead of removing them from memory on per-file basis once .dds version is generated. We're looking into PNG memory usage right now (if it's better, there will be an alternative download that loads slower but has lower initial memory footprint), and we'll be releasing an optional download with lower resoltution textures that will probably load for anyone no matter how unoptimized texture loading system is. As I've said in the changelog, the unpacked size has zero effect on video memory footprint as the game is using DDS textures, not TGA or PNG or MBM, which are generated on loading. Unpacked filesize was around 70mb before, with PNG, but PNG is no longer used due to slow loader component that won't be fixed until 0.23. Ideally it should not have any effect on memory requirements, but if the loader is not removing the source files in an efficient manner, the memory usage can potentially peak too high. Investigating.

B9 Aerospace Pack R4.0 released! ___________________________ Changelog: â–¼ R3.5 * 0.22 compatibility update. * Updated ExsurgentEngineering.dll, Firespitter.dll, KineTechAnimation.dll, ResGen.dll * All textures converted to the uncompressed TGA format and will remain in it from this version onwards (previously, the PNG was used). Memory footprint in the game is unchanged. The benefits include sliced by approximately half, the compressed archive size being slightly smaller, and mip maps being generated properly by the engine. * All parts are hooked into the tech tree. Parts aren't dumped to a single node, unlock gradually and, as possible, are arranged in a way that provides enough parts for you to build usable crafts at all stages of the tech tree progression. No SABREs at tier 3, no bizjets at tier 8, no shuttle control surfaces without shuttle wings and fuselages. All parts should also be compatible with the modded tech trees, as they usually preserve the original node names our configs are linked to. * Added new landing gear parts that blend into the parent parts and fit a huge variety of aircraft. Choose between twin-wheeled and single-wheeled configuration, two different clearances and two different colors (allowing them to blend perfectly with all-purpose gray or plated black pieces). All landing gears are equipped with togglable electric motors and can be steered. * Added new solid rocket separation boosters to replace the awkward stock one. * Added the shielded variety of A1 light. It is mostly intended for use as the landing light, as new gear models, in contrast with stock ones, have no light sources to avoid breaking through per-pixel light limits and improve performance. Comes in two colors, same as the landing gear set. * Added the 1.25m (MK1) aerodynamic junction part. Useful for nice transitions to radial engines, fancy boosters on rockets, and stylish UAV glider noses. * Added new struts to finally retire the stock ones from every single craft. First variety is functionally identical to the stock one, just a bit more sturdy * and quite better looking. Second variety is where it gets interesting: it's a strut part with an invisible middle piece. Exceptionally useful when you * want a clean design without all the messy cables: basically, you just place two very suble blocks and imagine how structural integrity was improved somewhere inside the craft. Clean and performance-friendly. Oh, those new parts have no shadow casting, - that might help with FPS on heavy crafts which typically use hundreds of struts. * Added MK2 cargoholds. Not very roomy, but they can still hold some useful payloads like 0.625m satellites or science modules, finally making the MK2 fuselage system useful for useful SSTO designs (!). * Added the smaller 5-port omnidirectional RCS blocks in line with already existing linear and 12-port varieties. Added dark-colored versions of RCS parts to allow them to blend with the shielded areas of the fuselages. * Added three new winglet sizes (2.3x1.6m, 3x2.2m, 3.2mx2.75m) and two new stabilator sizes (2.3x1.6m, 3x2.2m) to completely phase out any use of stock control surfaces from the crafts (2.3x1.6m is equivalent to the stock winglet in size). By the way, all 12 non-modular wing parts (stabilators, wingtips and winglets) in the mod are still using one single texture and maintain perfectly even texel density. No stretching, no duplicates, no distorted proportions. * Added new SH wing module (1x4m) to close the last remaining gap in the system. Added the static trailing edge parts that can be added to the backside of SH modular wings, for the first time in history making control surfaces look passable without forcing you to cover all trailing edges with them. Seriously, those a very nice looking. Oh, and control surfaces no longer have a weird orange cross sections on the side. * As separate ASAS/avionics parts became unnecessary since 0.21, all parts related to them (inline/radial/nosecones) are moved to the role of probe cores or sensor packages for the science system. Only exception is the plain MK2 nosecone, which is now decorative. * Added few small parts, in particular: a green omnidirectional light (crafts can finally have proper colored pair of navlights on their wings), large radial DSI intake that's close in performance to the RBM intake, large air brake with roughly 3 times the surface area of the old one, * All sample crafts completely updated to make use of new struts, lights, landing gears, wing pieces and other parts. Some were significantly redesigned. New crafts added, including a lightweight MK2 SSTO, three maneuverable UAVs and a subsonic glider. Full list: * D-175 Strugatsky: Long-range, short-takeoff subsonic cargo transport. * BRV-4 Heinlein: High-performance heavy SSTO, trading off cargo transport capability for the generous fuel reserves. * I8-L Bradbury: High speed atmospheric crew transport. * SCDV Vonnegut: Advanced SSTO with the cargo transport capability. * TR7 van Vogt: Light and fast MK2 SSTO with the cargo transport capability. * UAS-1 Barnard's Star: Extremely maneuverable lightweight UAV with thrust vectoring. * UAS-2 Polaris: Stable lightweight UAV. * UAS-3 Centauri: Extremely maneuverable MK2 UAV employing RCS and thrust vectoring instead of traditional control surfaces. * UL-1 Kornbluth: Subsonic personal transport with generous lift and convenient landing gear configuration. * VX-1 Vance: VTOL and RCS technology demonstrator, highly maneuverable and incredibly stable for it's class. * YF-28 Haldeman: Four-engine thrust vectoring fighter jet with extreme pitch and roll authority. * Increased connection forces of the laggers and railings, fixed the crash tolerances. * Added the specular maps to a few parts that lacked them. * Revised the descriptions of multiple parts to be more informative and less so kerbal (RCS, radial control parts, etc.) * Hypersonic mode on S3 cockpit returns and works as intended again. * Balance changes to the SABRE Engines: Slightly less efficient air-breathing mode performance with greater thrust, slightly more efficient LFO mode with decreased thrust. Makes the engines less viable for prolonged gliding in the atmoshpere and more useful for space stuff different from barely circularizing in the LKO. * Air consumption of the turbojet engine is increased. * Action names on S2 crew part revised to fit into the fields. * R1A air-powered RCS linear port ISP tweaked. * VTOL engines rotation and steering inverted, enabled the velocity curve on VA1 and disabled the gimbal on it. * Air brakes connection strength values added. * Thrust vectoring engines are no longer trying to participate in roll control when they don't have a symmetrical counterpart. Version R4.0. Mediafire.com mirror Inspiration album: Album with new parts:

I think you're going to like this update.