bac9

You should ask that from Squad, we don't have any way to fix the problems x64 Windows build has.

You have not installed it properly then.

I see no point in using that, kerbals have very significant impact on performance and showing them at all times is not good, especially with crowded cockpits or large crafts.

Good moment + some photoshop for better lighting and such.

I have added HX4 parts without inner pillars now, but I can't really remove those frames. Two reasons: 1. Lots of work, there are no faces underneath them so it's not removing one mesh, it's adding faces to multiple meshes. 2. I hate how most hangar variations look without them - a part that consists of two entirely disconnected pieces floating in the air makes very little sense. So yeah, I'd recommend to simply use designs that allow you to park stuff by entering from the front.

Yes, we can't fix x64 issues on our side. I suggest filing bug reports to Squad if you encounter them, especially if you encounter issues with x64 while playing stock game without mods.

They have a proper Unity license and support that comes with it, so they have means of working on the issue and bringing it to attention of people at UT even if the problems are not caused by the code on KSP side. Throwing hands in the air with "lol Unity not us" excuse is not a solution.

You don't necessarily need to enable texture compression in ATM (just set the scale setting to 1, that disables it), but it's an absolute must have anyway. Even if you are not installing this mod at all, ATM is a must have. Stock game does something horrifyingly wrong with resource loading, and features of Active Texture Management mode like texture unloading and VRAM offloading free up enormous amounts of memory even if you are not compressing anything. The mod collection I used with x64 took 7 gigabytes of RAM and still crashed with out of memory errors, while with ATM memory use never peaked over 3.5gb and I have managed to play for three hours uninterrupted. Seriously, always use it until Squad will fix their stuff with loading (if they will at all). Also, x64 seems to work fine for me. I'm not using opengl launch key and I'm using a few other mods, not sure why. It's disappointing to see that it does not work for everyone, users with enough memory should be able to run the game fine. Squad should give bigger priority to x64 stability for 0.25, I think, it's absolutely critical for modding support.

As it was requested a lot, size 3 HX hangar now has separately configurable structural supports - you can remove them or choose on of three types for them. There are new context menu options for that after you right click.

Abort button triggers the standard Abort action group you can configure in the VAB/SPH, there is no point in changing it to something that exotic when you can already tie any action to it.

Sorry, I don't understand what you are saying. There already are hollow parts of all sizes.

Read the docking port description. If you want to dock single port spacecraft to a four-port array, you need to build that array from subtypes of the same docking port part. So single port part has three subtypes (normal, 1/2th of 2 port array, 1/4th of 4 port array), two port part has two subtypes (normal and 1/2th of the 4 port array) and four port docking part has no subtypes. It's a bit convoluted system, but there is no other way to ensure reliable docking, stock is not handling simultaneous docking of multiple ports properly so if you're connecting crafts of equal size, single node docking port part is always the best choice. There was never such a part. Why would I make an adapter from 8 meter wide part to a 1.25m wide part? We have scrapped double width HPD engine because stock can't properly handle multi-node attachment and because it served no unique role, being easily replaced with two HPD1 engines.

Because every new cockpit is enormous amount of work and because it makes zero sense to spend all that time on a plane part that would look out of place on any spaceplane, fitting only atmospheric craft. This is a game about going to space after all.

NEAR should work the same as FAR for all parts so that's strange. Actually, we are dropping any and all support for stock aerodynamic model now - all sample crafts provided with the mod are guaranteed to fly ONLY if you are using ferram4 mods, as balancing anything against awful stock "aerodynamics" amounts to torture with some designs. Those of you who prefer not to use ferram4 mods are on your own now - the parts, of course, still have stock compatible values, but we give no guarantees they will be balanced for practical use in stock. Playability with FAR/NEAR is the priority.

Not a single change depicted there has any impact on performance whatsoever.

The new building could use some simple improvements, to be honest.

Looking great, although I'd recommend to up the thickness of the glass, shapes that thin don't play well with limited resolution, causing flicker that is hard to anti-alias.

That would take tremendous amount of time and will kill compatibility with 3.75m parts that HL currently enjoys (you can add HL SAS and many other part to KW part stacks and no one bats an eye), so I don't think that would happen.

Each wing part in B9 has different proportions so it's impossible to replace them with less parts of sliding scale. That aside, I highly encourage use of procedural wings mod whenever possible, and currently existing wings are mostly there for people who don't yet know about that mod or for some reason don't want to use it.

Alternatively, you can open the config file in the Active Texture Manager folder, take a minute to read extremely detailed comments above each parameter there, and disable the texture rescaling by altering one of them. The mod itself is an absolute must if you prefer to run a lot of content, and it's most important features are not about texture compression at all.

Everything is still worked on.

Also, that orbital tug is hands down the best KSP part ever made, very fun to use and very useful.

helldiver, a few small requests here, if possible: - Could you by any chance change the small radial decoupler to use a separate texture instead of one from the orbiter so that it could be used even if all orbiter-related files are removed? Atlasing is an incredibly good thing, but that one particular part is not invariably used with the orbiter parts alone, so it might very well get into a situation where a huge atlas of the orbiter is not available. I doubt it will need more than a tiny 256x256px texture, so one decoupler using a separate texture won't hurt anything. - If it's possible to do without breaking existing craft definitions, could you rename all the remaining configs, textures and meshes to show clearly which part set and texture atlas they belong to? At the moment, if you want to, for example, temporarily remove small orbiter but leave space station parts, you have to double-check descriptions in part configs against the opened game to know which part is which. The super25_ and ss_ prefixes that are already in place were a good start, it would be nice to see all the other parts and textures to be grouped in the same manner.

Looking absolutely great.

There usually is no need to ever use box colliders outside of box-shaped parts. Make sure you have every single collider marked as Convex in the Unity editor inspector properties of the Mesh Collider components, otherwise they will not be used by the game even if their shape is convex.