Ald

@Lisias That is why I've mentioned the "template", that would customize the bare "procedural tank" to reassemble its original part, without keeping it as a seperate part. Ergo 1 procedural tank and many variants that look and behave like the original parts. You wouldn't loose anything, the part catalogue would have the same amount of "parts", but you would significantly reduce the physical parts as files in your GameData folder. And the bonus of that would be, that those parts would be configurable to your desire both the contents of the tank, and the external looks/model, to which mod authors could contribute to increase the variety of both.

It is sad to for me to say this, but devnotes have degraded significantly comparing to the things I saw pre 1.2 or so. Having that out of the way... I used to wonder, instead of revamping tanks, why not migrate to procedural ones? Similar to the way it worked/s in Procedural Parts mod. For example, the regular LF/O fuel tanks or SRBs for rockets. Instead of keeping a whole lot of seperate parts, you would have one part. A part that would be tweakable in aspects: Width, height, diameter Possibly making an option to fill the endcaps if you consider the tank has nothing above and under id (attached radialy) Possibility to pick witch what you want to fill it with (similar to Modular Fuel Tanks mod) Choosable style of the fuel tank - model and texture wise Optional: Basic color manipulation (ex. if a model and default texture has three distinct colors, add some sliders for those colors). That would benefit the airplane parts mostly. And to cover the criticism of deleting the tanks as parts - there is a solution. Use templates in place of the deleted parts, to maintain compatibility. I see the template as an direct copy description and picture wise, but done actually with the "one fuel tank which is procedural" part, which has the required characteristics. This way, you would still have FL-T100/T200/T400/T800 on your catalogue list, but without 4 seperate parts. I wouldn't apply this rule to things, that are ment to be distinct, like engines. But towards things that can be scallable - all kinds of fuel tanks and SRBs. Of course I may be wrong about this, but it did work quite well for me in previous versions (I literally deleted all fuel tanks and used the procedural ones instead).

Damn, @linuxgurugamer you must run on BATT-MAN batteries. I was missing this tool so much. Big thanks from me for reviving this.

One question. How do two mods interact with eachother. As I do remember "HullCamVDS" had first person view, but what happens if you add "Through The Eyes Of A Kerbal (1st person EVA) continued" to the mix? Can they coexist? I persume that there should be no conflict (C button and clicking on kerbal). But you can never be too sure. I'll check it probably, but perhaps some of you may already know the answer.

I do remember this backpack had an working antenna Sadly it is covered with a lot of dust.

I really liked the ability to select target for the dish. And the remotetech specific dishes/antennas. But yeah that would pretty much cover it. Also I'd like to remind you all, that Kerbinside had some preparations for openable new ground tracking bases.

No link = no control is included in stock pre edition. Just go to advanced options and turn off partial control.

Indeed, the spacedock version is outdated. Just take it from the source.

https://d-mp.org/ -> Download the Server -> 0.2.3.1 both client and server. I don't see any problems with it.

Ok so we stay with binary 1-0 signal presence. But why not to adapt the signal strength as a trully informative parameter? You'll know if you're reaching the limit of your vessels comm instruments, by watching the percents go down. It could just calculate the effective range, showing you when you'll pop out of range - leaving you enough time to do some preparations (such as sending a kOS program or leaving a set of maneuvers to the flight computer to be executed while you loose signal). Occulsion would be the only thing that would bust your signal from x% to 0%.

If I had to guess: RT has pointing the dishes mechanics, which stock will not have. Big +1 for RT for me RT has a flight computer, stock does not. +1 RT doesn't have such thing as signal strenght, that would be a cool thing if merged from stock in a good way RT has signal delay - if you want to punish yourself with remote control on anything further than Kerbin SOI Perhaps some tweaking in dish antennas to have relay compatibility Rewriting big chunks of code, to use stock API for communication mechanics, while keeping the callsign features of RT And keeping it unforgiving for not deploying antennas in time or messing up with the range. That is the thing I love the most +999(9) As for me, this is a no brainer. I adore RT and pretty much refuse to play without the mentioned behaviour Also I have those wild, wild dreams of integration between RT and Kerbinside ground tracking station bases (only way to emulate it with a hardcoded custom config atm). That would make the communication pretty complete for now (unless some wilder dreams appear).

The thing I mentioned will eliminate the spam and slowdown. Big lag spikes will be the garbage collector mentioned by steve_v. Try both solutions.

No, it won't, and definetly it won't break it. At least it didn't make anything go bad for my save. If you're unsure, just check it on a seperate installation of KSP (distant object + cacteye without the hook) Also from readme for "DistantObjectHook": The thing I found and belive to be the closest to explaining the issue between the two mods:

Somewhat similar

That is the DistantObject hook that resides in Cacteye. It is hard coded to a specific version of DistantObject. If DistantObject gets an update, the hook goes all funky spamming exceptions (and slowing the game), because it expects an older version of DistantObject. The fact, that versions don't mach, creates this error. You have few options with this: 1) Delete the cacteye hook dll 2) Wait for Cacteye to update the hook 3) Use an appropriate version of DistantObject that matches with the hook.

KSP64bit +/- ~23 minutes (with precached module manager patches) installed addons 123 - lots of parts and heavy graphics ModuleManager: 29814 patches applied 175 folders in GameData (3.83GB) - excluding SQUAD folder Phenom II x3 720BE ~2.8Ghz 20GB DDR3 RAM (2x4 + 2x8) Windows 7 64bit MSI Radeon 7850 2GB 1TB WD Blue HDD 8.9GB of RAM usage in main menu The load time doesn't hurt that much - I just do other things while it loads. The thing that actually hurts is the scene change times. If you want to hop between scenes frequently - that is somewhat of an annoyance. Thus I do wonder if a switch to a more modern processor (like i5/i7 skylake) would dramatically change things for me.

Ok - I also did these elimination tests, but not whole set. ScanSat played well with just one of each mod. Mods seperatly did well too. It only happened with all three being active. Just thought it is worthy to mention that KSPedia freaks out in such combination. I'll manage to live without KSPedia for now, though it is sad not to use stuff that you guys put work and effort into. Wonder if it will crash in other mod configuration (ergo scansat + two different mods with kspedia which I don't happen to know right now). Anyway happy to be of assistance.

I'm not quite sure where to post it, and this is my second stop.: There is some weird mumbo jumbo if it comes to coexistence of three mods: DeepFreeze Contunued ScanSat Kerbal Planetary Base Systems Namely it goes about the KSPedia assets: If you combine all three mentioned mods KSPedia borks out without any actual content and that message shows up in logs. The weird thing is that it only happens if all three are present. Is there a chance you could take a closer look if this is just a coincidence on my end, or does something nasty happens with KSPedia assets? Thanks in advance.

I'm not quite sure where to post it, so I'll start with this mod D: There is some weird mumbo jumbo if it comes to coexistence of three mods: DeepFreeze Contunued ScanSat Kerbal Planetary Base Systems Namely it goes about the KSPedia assets: Is there a chance you could look into it? It happens only if all three mods are together: Kerbal Planetary Base Systems + DeepFreeze Continued + ScanSat = KSPedia borking out Edit: Weird observation. Standalone mod works good. It works well with KPBS (2 at the same time). It makes KSPedia unresponsive only if mixed with ScanSat, perhaps I should leave this message over there as well.

Oh... so I guess I don't need to go deeper with checking which mod messed up with Filter Extensions Thank you for your work and a lifesaver mod (for modaholics like me). Cheers!

Used the 2.5.0 from the official channel of distribution. You mean I should try the one dll file? I'm curious with which mod it did crash on regular 2.5.0 and I'm pretty close on narrowing it down from a ton of mods.

I do have the same problem. On a vanilla (or with few mods) there are no problems with regular filter configuration. But with a lot of mods (or just one particular that messes things up) I get this in my output_log: It messes the categories and doesn't filter parts by mod folder names (as shown on the pictures): http://imgur.com/a/HZndN Log file: https://dl.dropboxusercontent.com/u/24969834/ksp_filter_extensions/output_log.txt

Good to hear. Cheers!

I'm not sure if I'm in a position to suggest a feature, but... water. Is there a chance to include it amongst food and oxygen/co2? Seeing as TAC LS is currently seeking a new maintainer I started searching for other options just to try something else. Kerbalism is really interesting and complex in simulating core LS aspects (as well as few quite interesting features seen nowhere before). Water seems the only big feature that it lacks for me. I'm not going to brag about solid waste/waste water along with converters for those because those were in TAC LS. I do have this sweet vision, to use Kerbalism along with DeepFreeze and UniversalStorage (the water part mostly about using hydrogen in Alkaline Fuel Cell and water electrolysis). Would be really neat if you considered this suggestion. All other than that - It's a real nice piece of work. All possible thumbs up.