Ruedii

Any chance we could get supersampling in this?

Nice, so you decided to run the QA handling and packaging of the mod. p.s. I see, so you simply moved the actions of the mod to before physics initialize. I thought of something along the same lines, but I didn't know how it could be done, or if it would be possible. It's cool to see that someone else came up with the same solution, as well as a way to implement it fully.

Do you have a brief description of how the new codebase works. I understand you decided to completely redo it because the old codebase was unportable.

OK, so already basic titanium heat shield and refrigeration systems. In that case, only the arbalator heat shield would be favorable to include, and usually wouldn't be needed, so long as proper reentry procedures were followed and the player wasn't using a mode with high reentry heat.

Would matching radial attached heat shields for the bottom be too much to ask. (Available in titanium and arbilating tile varieties both with low heat conduction to attached surface.)

They should be automatic generating, but it would be nice to have an truss structure you could actually attach things to (especially parachutes or RCS nozzles) for an improvement over stock. Also, having it adjustable in size would be really good. (Auto adjust as an option, as well as tweakable manual adjustment.) Yes, that would be great!

Thank you so much! I've missed this mod so badly!

I recommend using ridged attachment as well. As of a feature request, could we get this mod to have inside optional trusses like the stock fairings?

I generally like the idea of using a high/medium poly super-close LOD, with the further out LODs practically being parallax mapped impostor boxes. I noticed most of your parts can easily be simplified down to low-poly-count far LODs in this manner while still retaining all the major parts. The decision to have an outer bulkhead structure on that bulkhead adapter is very key to doing this, because without it, you can't simplify the interior structure to a single parallax mapped transparent face at a distant without creating major side-view artifacts. Similarly your other designs are all simplistic in a manner that allows for taking advantage of high polygon up close, without losing any structural components at low LOD details far away.

That universal bulkhead is nice. If you want to experiment further, you could try making the various components of it toggle on and off using some form of mesh-switcher. Another thing you could do is wrap the whole thing on a small number of polygons by using parallax mapped transparencies.

Yes, but AntennaRange does not include planet occlusion the way stock and remote tech do. Hence, it would be easier to adapt the remote-tech contract then the antenna-range contract.

Could we get this updated to support the stock relay system as well?

Thank you so much!

Thank you!

Good to know. I had a bad problem with SEP parts blowing up on connection to the ground. I wonder if that momentary invulnerability could be used to fix KIS issues with blowing up right on attachment too.

First thing, is that considering it's on GITHUB, you should probably use GitHub's mechanism to make a fork (or copy) of the project and edit it. This way you can file a "Pull Request" to contribute back the changes so the authors can use the work if they want to, and other authors can work with you in the same manner. It's kind of a nice way to do things. You can also make a "Fork release" on your fork's page. This is generally the preferred way to do things when the source is available on a collaberative development site like GitHub. As a note, Github has integrated text editing tools and allows you upload updated copies of a few of the files. You don't necessarily have to run Git. If you do, you probably can find a module to use your favorite development environment to handle moving files between GitHub and your computer.

On a completely different topic, I'd like to ask if you are having problems with KIS causing your asphalt tiles to blow up on attachment to the ground. I know some people have had that issue with KIS in their mods. I do know the (temporary) fix until the issue with KIS is resolved.

As a note, using the command line "P7zip" utility for compression with the command line "7z a -t -mx9 -mm=LZMA <archivename> <directory or file list>" will get you about 10-20% better compression while creating a standard zip archive that doesn't require a 7zip compatible reader. (It might not read on old DOS zip versions, but almost all modern unzip programs support LZMA.) This probably isn't a big deal with your current mod, but if you make bigger mods it will help. There are a few settings you can tune further to get better compression, but it doesn't really benefit to the point that it outweighs the time it takes. (Still, it's a fun experiment.) As a note, 7zip format gets about 5-20% better compression but it usually hangs around the 5% end on smaller archives, and not everyone has a 7zip decompressor installed. It ships by default with OS X and most Linux distros (like zip). However, it doesn't on Windows. Microsoft seems resistant to new more-efficient community developed file formats. Namely that community developed, (i.e. open-source) part. Here is a quick comparison on compression on the contents of the Science Crate pack: Utilizing standard zip utility (same algorithm as PKZip 4.x): 202.6KB Utilizing 7zip deflate algorithm (similar to PKZip 4.x) 197.3KB Utilizing 7zip LZMA algorithm at standard settings 168.6KB Utilizing 7zip LZMA algorithm on ultra settings 168.5KB (Took less than a half second longer) Utilizing 7zip LZMA algorithm on ultra settings w/ tuned fastbyte option 168.4KB (Took about 12 tries to find the right fastbyte setting.) 7zip file format (LZMA default) standard settings: 167.7KB 7zip file format (LZMA default) ultra settings: 167.5KB 7zip file format (LZMA default) ultra settings with tuned fastbyte option 167.4KB As you can see, while the gain is small for ultra settings, it's probably worth it, considering that you might have to use command line anyway use LZMA type compression with zip. Notably, the RAR algorithm on the package was 189.4KB, substantially higher than any of the LZMA compression methods.

The HUD should require an updated version of RasterPropMonitor (RPM). However, that may not be the only patch needed. If it still doesn't work you'll need to check the IVA configs for obsolete entries.

That drop-tank wrapper is really cool. Could you add a matching slanted aerodynamic cap? (Or add an Interstellar mesh-switch for it.) Also, could you switch to zip from RAR. The 7zip version of the zip compression algorithm usually gets better compression than RAR and every major desktop operating system ships with tools built into their file managers to decompress unencrypted zip files. (Windows, OS X and Linux all have Zip decompression programs built into their file managers. This is not so with RAR, which requires the installation of unrar utilities, which for OS X and Windows which use bloated utilities that have to be downloaded from web sites, often including various junkware along with it.)

I was wondering if you wanted to make the smaller science labs have lower science processing speed for balance? This would be appropriate. Less workspace means more time to do research. Considering science labs have already been rebalanced in newer releases of KSP since this mod, doing this would be appropriate.

It seems 2 days ago you updated the version file without creating a release. This has been causing AVC to spew errors. Making a separate release branch on GitHub, that is cloned over on each release should fix this.

The on whole Apache vs. NGINX argument, it completely depends on the server load and server capability. Apache uses older, proven thread-based theory, and is designed to be used with a secondary caching content delivery proxy. This works well for reliable medium-load servers. However, this method tends to have a memory/bandwidth tradeoff. This means to achieve more bandwidth, you need more and more memory. This is not a problem until you are needing to serve while over 10K clients at once with dynamic assets. Since most of the assets on SpaceDock are static and thus cache friendly, this shouldn't be an issue. Under normal expected loads, Apache is more reliable and faster in many cases. (This is why so many sites use it, or variants of it.) NGINX works on an instance based system. While this can handle heavier loads and more scalability, and is friendlier for high-end cloud-based and distributed servers, and interfaces better with modern CDN networks. It's initial resource footprint is a little higher, but it's footprint increases a lot more slowly with additional transactions, because transaction data is kept a lot shorter, and most instances rely on shared memory for most of their data. It is also a little more complicated to set up. It's certainly a better option for many uses. Spacedock might be able to benefit, maybe not. It really depends on how the code is written, and what load it's under for what types of resources. As a note, I strongly oppose running Apache without a caching proxy. A caching proxy is usually a special "static data only" lightweight server. It tends to have a much lower footprint than either NGINX or Apache, however it is very limited, being restricted to static assets, and sometimes basic non-database PHP processing.

Is there a way to make this interact with the steamworks dll to make it be able to send the Screenshots to Steam's interface? Also, if it isn't already, can you make something that will up terrain detail to max and all objects to Max-LOD for the screenshot and produce HDR expanded color gamut and/or compressed HDR color correction enhanced gamut function for the screenshots? While this will consume massive resources, and cause visual glitches when making screenshots, it would make for some awesome screenshots!

I noticed these wheels are a little overpowered, and don't use enough electricity. This is a minor balance issue. (Also, the smallest wheel set is overpowered compared to their friction, causing some play issues as well.) I suspect adjusting the torque and torque curve plot should fix this issue. As a note, they seem to display in the retracted direction, not the extended direction when in the editor. This is a VERY minor issue, but is it possible to fix easily?