Fourjays

I much prefer them. Especially the ability to switch it to a truss. Fits really well with the base plates for making engine clusters too. I just did 3x Terriers set to the "base" appearance attached to a 1.875m baseplate for my rocket's trans-Munar stage. With the old appearance that would have been impossible without it overhanging the edges.

I love KER, but I do prefer the simplicity and clarity of Basic Orbit/Delta-V. With KER I always find the VAB/SPH window getting in my way so the way Basic Delta-V handles it is perfect for me. I do have one tiny feature request.... would it be possible to split the "Display Active" option for Basic Delta-V between flight and the VAB/SPH? Right now, if you turn off Basic Delta-V in flight via the Difficulty Options, it is permanently off in flight. If you turn it off via the Settings in flight, it is then off in the VAB/SPH too. What I'd like is for it to default to on in the VAB/SPH and default to off in flight, but still be accessible in flight if I do need a Delta-V readout. So basically, just treat "Display Active" as a separate option between scenes?

They are terrible at anything but a distance. At a distance they look good (see the picture by @Frozen_Heart) and I think probably more representative of what they were aiming for. But at anything closer they are pretty bad. Ignoring the translucency, the main issue is the weird "artifacts" (see @Enceos picture) that jump, grow, shrink and move as you scroll in/out.

Just done a fresh download of Spectra (from Spacedock) to check I didn't save via EVE earlier. The blue config is definitely defined in both atmoMain and atmoScatterer in the fresh download.

Follow up regards the Duna "colour blend" as I've found part of the issue.The Duna-atmoScatterer-blue layer for EVE is defined twice. Once in EVE_atmoMain.cfg and again in EVE_atmoScatterer.cfg. I believe only the latter should be defined? Removing the one from EVE_atmoMain.cfg partly fixed the issue by reducing the intensity. This gives results similar to adjusting the cloudColorMultiplier value in scatterer. However, the harsh blending is still present. Strangely, opening EVE config, ensuring the layer's textures are enabled and hitting apply seems to fix the issue entirely while retaining the rather nice blue hue. I've tried saving via EVE after hitting apply, but the issue reoccurs when I restart the game. I think it goes beyond my limited knowledge on EVE/Scatterer. Hopefully some of what I've tried will help you narrow it down further.

@Tiptonian@Avera9eJoe I think it's a typo in the skyExtinctionMultiplier on point 6 for Kerbin. It is defined as 0.0600, but I believe it should be 0.6000 (based on point 5 being 0.7000 for Kerbin, and all other planets having a final skyExtinctionMultiplier of 0.7000 or more). You can temporarily fix it until Spectra is updated by editing Spectra\Spectra_scatterer\Planets\Kerbin\atmo.cfg and changing the skyExtinctionMultiplier value to 0.6000 (line 178). I've also discovered an issue with Duna, running on 1.4.3 (just the atmospheres and clouds due to Kopernicus not being updated yet). It may be down to me skipping Kopernicus (although I think that's just needed for ground textures and scatter), but the day/night "colour blend" on Duna is quite harsh: https://steamcommunity.com/sharedfiles/filedetails/?id=1372253494 https://steamcommunity.com/sharedfiles/filedetails/?id=1372237616 I divided the cloudColorMultiplier, cloudScatteringMultiplier and cloudskyIrradianceMultiplier values by 10 and it looks much better, but at the cost of vibrancy: https://steamcommunity.com/sharedfiles/filedetails/?id=1372253452 Is there a better way to fix this? None of the other atmospheric planets have this issue, and after trying various things in the configs I've not found another setting that changes this.

It depends. The game I develop mods for (Arma) it is impossible for us to test every single aspect for every single change and update (we're also depending on other mods). What we do though is test the things we know have been touched. This means of course, that if a change impacts something we don't envision from changelogs, a bug possibly slips through. The question regards KSP is was there any reason for Squad's QA to suspect that the landing legs may be broken? Or did they make a change without ever suspecting the landing legs would be broken? I've no idea, but I can give them the benefit of the doubt on that. You've obviously never developed mods for Arma. It's a mess and often the logic you'd expect to find doesn't exist. I'm sure we'll find the bug eventually and what the difference is between the items that works and the items that don't, but it is a weird one. With all due respect to what you do, KSP isn't life critical but a game. I'd have a similarly harsh attitude if it was.

I decided to bite the bullet and update to 1.4.2 last night. The reentry effects were actually worse than I expected. It's not just that they show through the craft, but they also seem really big and as you zoom in/out they constantly change shape in weird ways. The previous effects were definitely better and I'm not sure why they even changed them. Hopefully a fix for those is included in 1.4.3 too. As a developer myself (10+ years web dev, 3 years leading a team of modders and recently started game dev), I think some people in this thread are being too harsh. Debugging and fixing bugs can be really hard sometimes (in my modding team we currently have an item that exhibits a bug that no other items have, yet the configs for all items are exactly the same - go figure) and you've unfortunately just got to be patient. It's better that they take the time and get it right than try to rush another patch out and break something else. I also think others here are being too forgiving. Some of the issues in 1.4.2 are things that QA wouldn't necessarily spot easily (legs/docking) and take time to debug/fix. But other issues give me the impression that developers aren't even checking that their work "works" (reentry effects/5m fairing). It'd be fine if the QA was very thorough, but it isn't. It wouldn't be unreasonable if KSP was still early access either, but it isn't. It is probably down to pressure from above to meet a specific date, but regardless it isn't a good look for a "complete" game. Hopefully they've learned from their mistakes though and are going to treat future patches with more professionalism. That they are taking the time to get 1.4.3 right is a good sign. In the meantime I'm going to have fun with 1.4.2 because it is a nice update despite the bugs and the ugly reentry effects.

Cheers, I found the options and it is working now.

Quick question... I want to increase the Hab/Home timers to double their current values (so my basic 2-man pod can go for 14 days instead of 7). I've tried editing the BaseHabTime and the HabMultiplier values in both the USI-LS/Settings.cfg and MKS/Patches/USI-LS.cfg files, yet it doesn't seem to be taking effect in-game. Am I editing the wrong value or will it only apply to a newly launched ship? Thanks

Ok that makes sense. My suggestion would be either change the opacity of the lines (but my 6% craft would probably appear to have no connection ), or have a toggle to turn signal strength indication on/off, where "on" replaces the constellation colours with green/yellow/red to indicate strength). No idea what is possible, just the first ideas that popped into my head. I write mods for other games so I'm fully aware that sometimes a game engine just won't do what you want it to do. Thanks for the work you've done on this mod though. It is a really good addition to the stock comm system. Hope to see it in RemoteTech in the future too.

Thanks for helping me figure it out, even though it isn't entirely related to your mod. I better cancel my outer planet probe missions until I unlock some stronger communications equipment. Is there a reason for the red-line on the final hop instead of a blue/green one? It does seem to be strength related, as if I change my "red" constellation to yellow, that final hop remains red.

Frequency is because I've been experimenting with different frequencies/colours trying to see if I find anything different with that red line. I've got 11 set to green, yet just like 10 that single jump appears red. I just checked over both Atlas and the nearest COMSAT, and all antennas are extended. Atlas has 4x KD2 Antennas (from BDB) rated at 500k each (combinable), plus a probe antenna rated at 20k (the "fourchette" probe body from BDB). COMSATs 4/5/6 each have 4x HG5 High Gain antenna rated at 20M each (combinable), an F21 Helenical antenna (from BDB) rated at 500k and the probe antenna rated at 2M or 5k (the "Obelix" probe body from BDB - seems to list two antenna ranges). I set three of the four relay dishes on the nearest COMSAT to frequency 11. Signal strength is reported at 6%. Here's a screenshot of the latest setup and I've also just uploaded a new output_log with the extra antennas set to frequency 11: https://www.dropbox.com/s/rm4j1j0z2eayahc/output_log_2.txt?dl=0

Done. Replaced the one I uploaded before, so it uses the same link: https://www.dropbox.com/s/ff59f5jctuu27wk/output_log.txt?dl=0

Think this should be it: https://www.dropbox.com/s/ff59f5jctuu27wk/output_log.txt?dl=0 Not sure if I'll be able to check into this any further until mods get updated. KSP just updated to 1.3.1 so loads of stuff is disabled. Tried reverting to 1.3.0 via Steam Betas but then KSP just crashes. Edit: Fixed it from a backup. If you want me to check anything else let me know.