Ruedii

Thanks. On to the next question, can you add a function to adjust wheels to increase the maximum damper multiplier in the damper tweak and add steering multiplier and steering response time adjusters? This would make wheels a LOT more usable, especially on small vehicles.

They still deploy in symmetry?

I found the symmetry highlighting very useful. However, if it's too much work to port over, don't bother. I can live without it and it's not a high priority. I would rather see a tweak-able added to control radial flap behavior.

Just a little reminder, there is a need to update the config files on both SpaceTux shared Resources and this contract pack to list as compatable with 1.1.2 As a note, they both seem to work OK from what I can tell. I might drop by and submit a pull request with the patch, but I've been stressed due to some family issues lately so I can't be sure I'll get it done.

Yes, part of this would make the engines far less powerful in their zero-fuel mode unless you are in the lower atmosphere. However, they would be far more efficient than the traditional jet engines at the cost of massive amounts of weight.

Well, for that form of engine, you could have a four burn mode, the first three being "jet" modes with the option of wet afterburner by adding a high-bypass afterburner. That is what I'm suggesting. Mode 1 is dry: A large volume of heavily compressed air is injected into the heat chamber and expanded, it is introduced to the bypass air to create additional expansion in the afterburner chamber (and keep the nozzle from overheating). Mode 2 is standard wet: A small volume of heavily compressed air is injected into the heat chamber and mixed with fuel. This requires less fuel and produces more thrust. Any heat produced combustion would be greatly outweighed by the evaporation, leaving the resulting air actually cooler. It then ignites when mixed with additional compressed bypass air in the afterburner chamber. Additional fuel can be added at this point for "afterburner on" mode for even more thrust, higher ideal speed and resulting guzzling of fuel. Mode 3 is full wet: No air is added, but the bypass turbine is still functioning. The added fuel partially ignites in the afterburner chamber depending on available intake air. This allows for high altitude operation. Mode 4 is full rocket. Bypass turbine is turned off, the output turbine is solely used to power the alternator and thus has lower load. Higher efficiency in full or near vacuum, but uses more fuel. There is no point in adding more fuel in the afterburner chamber, because it won't burn and will expand less than fuel added directly to chamber.

If I recall, 51 is the meaning of life in Star Trek. It's a joke about it being adjusted for inflation or something.

Theoretically you could make a variant of this that uses a "wet" afterburner mode, much like the after-burning engine in stock, except with the dry engine being a nuke-based.

Maybe add an Area 48? (48bits is the maximum virtual address space of current generation desktop x86_64 processors.) The other option is Area 42 (another geek joke, that for all things geeky you better get.) BTW, I love the excellent use of minimalist layout based drawing to reduce texture requirement. If you want to go further, you could look into the old KSP Dev notes about how the current generation KSC's building structure detail is generated using geometry shaders. It looks like portions of your design could benefit from this instead of being built manually.

Anyone who hasn't read the dev notes on a game like this seriously is simply asking for it. The dev team encountered an unprecidented number of upstream bugs in Unity 5 during the transition. The choice was pretty much wait 6 months for several major bugfix releases from Unity, or wrangle the bugs until they are under control and release something. Doing the later was probably the best choice. Believe me, nobody is happy with the bugs, but they are not Squad's fault. The blame squarely rests on Unity and nVidia who have been putting eye-candy over a functional physics engine in their game engine components for the past ten years. This is the inevitable result.

I like the idea of all parts attached to the ground stopping their physics. As long as you can interact with them that's good. I ran into issues where sometimes physics would become exagerated due to improper handling of tension forces by the engine. This should solve that.

Oh, one thing you may want to do is give the option to change the default z-buffer mode (quick reference of the depth of the object each pixel is displaying used to make rendering easier) 16bit is faster but can sometimes result in some z-fighting artifacts. 32bit is slower but is obviously better quality. There are a huge list of other settings you can change. I've been wanting to make a very complete "advanced graphics settings" mod myself to handle quick changing of all the settings, including all the "here be dragons" ones which I would mask behind a warning dialog.

Yeah, they'll be changing a lot of defaults around.

Yeah, refresh and superscaler settings should be added on this mod. (Superscaler provides far better rendering than anti-aliasing on some systems. Mainly due to some systems choking on the Unity Antialiasing shader.) You may also want to see if there is somewhere you can adjust for non-squared display aspect ratios and other advanced rendering settings.

This really needs to be added to KSP's config panel. (Basically in the resolution select box there should be "Manual" which should make a pair of text boxes appear with the width and height. I'd suggest adding "refresh" but unless you have a very advanced or old setup (LVD or CRT monitor, or video cards that require syncing across multiple monitors) there is never any need for it on a game like KSP. (Maybe on some FPS games that can actually benefit from 120p refresh rates, but not on KSP.)

So in other words, there is only one way to find out. Where are you looking for the dependency. As long as it's a Mono/.Net DLL file you should be fine. Unfortunately if it is bundled into a ".so" or other non-Mono binary file, you may not be able to access it on non-Windows platforms without adding an extraction routine. The proper way to look is to make the directory relative to "./" in naming and have the user place the binary in their KSP directory. Only some Operating Systems automatically add the current working directory to the library search path, and Mono gets it's search path from the OS unless the program overrides it. The simplest solution is to explicitly state the location relative to the binary's location or add said location to the search binary specific additions to the search path. Honestly, you should only need that database to make it easier to edit. It basically provides the config tree schema for the unspecified variables. Players will simply have to manually define the config file if you don't include it. You may want to make a second version that falls back on this. If you need a test system, you can launch Linux from a thumb drive. (I recommend a full install instead of a live disk image.) Linux now has the ability to detect plug and play disks by Partition ID so even if the disk moves in location it can find it on boot. (This ability was added quite a while back but was changed to be enabled by default recently.) Mac's file handing system is very similar to Linux so if something works on Linux it should work on Mac.

Since this is written in C-Sharp, it should be portable to Mono. Do you want me to check if it runs drop in, or if it needs some porting work, and assess how much porting work is necessary? I'll test it under the Mono Runtime for CIL-PE files (Mono/.Net EXE file format). There is no point in building separate Linux binaries when almost all Linux distros have the .Net runtime installed by default, and have a link to add the necessary modules for basic .Net compatibility. (Namely, GDI+.NET and WinForms.NET)

Sounds like it would be more a project for someone more experienced with shaders.

I would like to see both varieties available, in both current and classic textures. I might take a look at how much work remapping the textures would be. However, without source textures of at least four times the quality level, I will experience quality loss from scaling the different segments of the texture, unless there is a way to apply a transformation matrix on render to the old texture to make it compatible as-is. I am tempted to make a transformation matrix texture handling plugin, however I would need help as I have zero experience in that sort of thing. I can write out my theory, if you want though, and you can take a look if anyone on the B9 project would be interested in flushing out the algorithm. To put it in very simple terms the algorithm uses an index matrix to select pixels or blocks from a texture atlas that can be loaded as a texture (or sparse texture if the extension permits) Each block or pixel is selected by a pixel on an XY index pallet. For a larger block size 8bit values for each of X and Y are used, for smaller block sizes or single pixels, 16bit selectors are used for each of X and Y. 16bit XY mode would be particularly good for sparse texture handling, which may be possible to add as a mod in KSP 1.1 considering the new Unity release being used. One could also use 12 bit per a dimension XY maps if the video hardware supports it, and one could theoretically truncate the high bits or use them as page selectors to allow for selection between multiple texture maps.

I've heard some rumblings about people who didn't like that the test beta is not available on the store. You might want to look into changing this. It probably should be a separate download, that isn't as easy to find. After installing the opt-in patch the launcher should handle the update. (Users should be encouraged to backup their old game directory first because, otherwise quite a few will forget to read the part about frequent game breaking changes and immediate breaking of 1.0.x gamesaves and become very liquided if they can't get their old games back.)

Cool, but do you have eccentricities and inclinations placed on some synchronous-period orbits as well as the "stationary" one that is equatorial and circular?

Could we get inline versions of many of the radial attach parts. (Batteries, experiments, control cores, etc.) Furthermore, can we get the stock experiments added to this? This would be, temperature, pressure, atmosphere analysis, gravity-meter, possibly mystery goo. An all-in-one unit might be particularly nice for advanced science.

Could you add higher inclination contracts? High inclination contracts should obviously be considered more difficult. (Bascially anything above 20 degrees of inclination.) Also, high eccentricity orbits should be considered. One particularly interesting contract is a synchronous-period orbit that is high inclination and eccentricity, and requests the apoapsis to be over a specific area of Kerbin.

So basically they'd need to be rewrapped, including adjusting scaling on many of the parts, and a few of the parts (e.g. Mk2b Cockpit series) would require complete overhaul. I could take a comparative look at the textures and UV Maps. You certainly can't simply switch out the textures. Do you happen to have high-res versions of the patterns used in the legacy part textures that could be used to make completely new textures using the old base materials

I was wondering how much work was needed to get the "legacy" smooth textures working with the new meshswitch based parts? The same goes with stock textures, of course. Also, what tools need to be used for this, do they simply need to be rewrapped, and if so do you have some high-res original assets you could publish to the repository to work from? I may be able to do something there, but there's no promises. If they only need config files and conversion to DDS then I could gladly help. That would be very easy for me to do. I could add them along with the appropriate assets as a second package and module manager patches. As of ideas on how to better cut down the number of textures and improve options at the same time, if you use add some mesh controller functions to the meshswitch supporting some form a stretchmap, that would work well. Using a 16bit,16bit Ax,Ay texture as a transform matrix could be used as an index that allows you to create a shader to select pixels from a 64Kx64K texture atlas. This resulting textures could be scaled on load of the part to generate MIPMaps. This may be beyond the scope of B9 Meshswitch, though, but would be something for some of the texture modders to look into.