Technologicat

Just a compatibility info update: @clusta's recompiled version runs fine on KSP 1.12.3 on Linux. @The White Guardian: Thanks for the mod! Reviving old thread to emphasize that KS3P is still relevant for Linux users looking for a postprocessing effects visual mod, since the other popular option TUFX has no OpenGL/Linux support.

@blackrack: In Scatterer-0.0835, the paths in GameData/Scatterer/config/Sunflares/Sun.cfg that point to the sunflare PNGs (all four of them) are incorrect on case-sensitive file systems, such as on Linux. Should be e.g. Scatterer/config/Sunflares/Sun/sunFlare.png. Note uppercase Scatterer, matching the directory name inside GameData. Everything else is correct, the whole path should just begin with an uppercase S. I noticed the sunflare was missing on Linux, and upon investigation, there was an error in Player.log saying that the file was not found. Fixing all four paths in Sun.cfg made the sunflare appear, and the error went away. This difference was probably left over from the time the directory used to be called scatterer with a lowercase s. I searched this topic if anyone else had mentioned this, but didn't find anything, so I thought I'd let you know. Many thanks for keeping Scatterer working all the way to KSP 1.12! This is one of the best visual mods out there.

I realize this might not help on Mac, but something that helped me on Linux: I initially had trouble making KSP (1.12.3) find the library, but then noticed in Player.log that you can place native .so files in KSP_Data/Mono/ inside your KSP folder. Create the Mono subdirectory if it doesn't exist. The log also tells you the filename the game is looking for, in this case libSDL2-2.14 (which means it's trying to load libSDL2-2.14.so). So, if you can get a binary of the libSDL2 2.0.14 DLL compatible with your system, place it (or a symlink to it) as KSP_Data/Mono/libSDL2-2.14.so, and it should work. For Debian-based Linux, such as Ubuntu or Linux Mint: PPAs may have already updated beyond 2.0.14, so that version is no longer readily available. In case of Linux Mint 20.1 (see /etc/lsb-release), which is based on Ubuntu 20.04 LTS (see /etc/upstream-release/lsb-release), I used the amd64 package for Debian 11, from here. DO NOT INSTALL IT - instead, just open it in Archive Manager. You can find the DLL inside the data.tar.xz package that's inside the .deb package. Path therein is ./usr/lib/x86_64-linux-gnu/. You only need libSDL2-2.0.so.0.14.0, the actual DLL file (the file with nonzero size). To check whether your system can load the binary, open a terminal, and ldd libSDL2-2.0.so.0.14.0. If that prints no "not found" errors, the binary should be good to go - just place a copy as KSP_Data/Mono/libSDL2-2.14.so, and test if KSP can now load AFBW without errors. If no suitable binary is available, it might be possible to compile SDL 2.0.14 from source. Instructions on the SDL site. Related to this, I would also be interested in a possibility to switch configs easily. I have a both a HOTAS and a gamepad, one of which is much more convenient for traveling... For now, I think I'll do the usual - keep a file manager bookmark handy for the PluginData folder, and switch XML files manually. It's not something I need to do very often anyway. The most important thing is that joysticks work in KSP 1.12! Thanks @linuxgurugamer for your continued support of the mod!

That's.... a lot of white 1xN bricks. Nicely done! Is that a 3368 inside the VAB? Sometimes I get the feeling LEGO should check their staging.

At least in my KSP 1.9.1 install, that option currently does nothing except drops FPS to single digits, at least when trying to drag a maneuver node handle. Could be exception spam, but I haven't looked at the logs yet. If you have time and interest to look at the issue, I could help by making a clean install with only Precise Node Continued, test it again, and post more detailed findings, with logs. What the option should do, and indeed used to do, is to use post-maneuver coordinates for adjusting the burn. This means that, in particular, when you drag the normal handle, the orbit keeps rotating also for large values of dV used for the burn. For example, if you drag it far enough, the planned burn will change inclination by 90 degrees. Drag more and you get 180 degrees, and so on. Mathematically I'd describe the behavior such that for the delta-V increment that is currently being added to the planned normal burn, the calculation uses the orientation the orbit normal vector would have, if the burn planned so far (without this latest delta-V increment) had actually already been executed. This doesn't matter for prograde/retrograde, which don't change the orientation, but it makes it easier to perform large inclination changes. Of course, for small x, from the Taylor series sin x ~ x, but the post-maneuver coordinate system approach works also when x is large. Say, if I accidentally captured into a retrograde orbit around Minmus, and want to correct that by changing inclination by 180 degrees. A silly misuse of delta-V, I know, but the expedition needed the fuel on that particular resupply probe to be able to leave orbit. Long story. A slightly more realistic example is changing the inclination by, say, 30, 45 or 90 degrees, which is faster to do if I can skip the mental math to represent the required delta-V in the original pre-maneuver coordinate system. With post-maneuver coordinates, just drag the normal handle when you want to change inclination. By however much, or little, doesn't matter, so it's simple to use. Right now I have that base covered in my install with Maneuver Node Evolved, which offers the same option. So although I like Precise Node Continued, debugging this hasn't been a high priority for me.

Thank you! Installed AFBW Revived in KSP 1.9.1 on Linux (Mint 19.1), and my HOTAS setup Just WorksTM beautifully. (Thrustmaster 16000.M and TWCS Throttle.) Flying spaceplanes with this mod is a wonderful experience. I especially like the mod's ability to map SAS modes (prograde etc.) to joystick buttons. QuickSAS does that for the keyboard, but doesn't feature joystick support. The buttons on the base of the 16000.M are pretty much made for that. With a full complement of SAS modes and a plane/rocket preset toggle (swapping the yaw/roll axes), exactly one button was left over. (Well, there's the SAS on/off toggle, but I have that mapped to the trigger.) For others considering using these particular joysticks, the only thing to know is how to calibrate properly. When calibrating the TWCS Throttle in AFBW, both the throttle handle and the antenna axis (the analog knob for the little finger) should be physically set in the 0% position. Then pressing AFBW's calibrate button maps the whole range of each of those axes to [0, 1]. This way KSP uses the full range of motion for the throttle (and similarly for the antenna axis). Now, to learn to build planes that don't suck in FAR... 10/10, would fly again.

Updating suit packs has the technical issue that the suit mesh was changed in KSP 1.7, so suit textures for made any version older than 1.7 are not compatible. The texture itself must be redrawn to fit the new geometry. (But I haven't looked at how major the changes are. Texture creators may know more.) The suit color pack by Xeraster is the only suit texture pack I'm aware of that works in KSP 1.7 or later... but then, I mainly use TR to get some variety for the heads, so I don't know much about suits. Head textures are easier. Heads made for any KSP 1.x are still compatible with 1.9, as long as the folder structure (how the files are organized) of the texture pack is updated to follow the conventions of current versions of TR. (EDIT: Araym recently posted a template that shows the new UVs. Off the top of my head, I don't know how different that is from the old suit textures, i.e. whether those could be photoshopped/GIMPed onto it or not.)

The 1.2.11 on Spacedock works fine with KSP 1.9, except the "intuitive maneuvers" option, which (at least for me) isn't currently working.

Thank you! Package updated.

Hi @shaw , I posted an updated package of GreeningGalaxy's Diverse Kerbal Lasses a couple of days ago, for TR 4.1.3 (tested in KSP 1.9.1). The original creator hasn't been seen for a long while, the download links have been dead for a while already, and the internet didn't have these textures anywhere. But the license allows re-posting them, and I happened to have a copy from back when the downloads were available. Care to link the updated package from the first post? Or is it better if I make a dedicated thread in the add-on forum? Everyone: Is there an interest in other repackages for TR 4.1.3? At least in cases where the original creator has vanished, and the license allows, I think it would make sense to provide updated packages, to reduce the installation effort. In my own KSP install, I currently have TR 4.1.3 versions of Repimped Farmer's female Lasses by Bizz Keryear, necKros's female heads, and Hotaru's Simple female heads (none yet posted, links go to the original posts). The first one is licensed CC BY-NC, so it's clearly ok to re-post. The second one is a borderline case, because no explicit license was specified. Maybe better if I provide just a bash script for converting the original download into the format used by TR 4.1.3? The third one is CC BY-NC-SA, but Hotaru is still active, so I'll ask them first.

I tried again last night, and... lo and behold, Impact marker was there, in the Surface category, where it belongs. Got it, now I have it in HUD2. Problem solved. (Having it in the HUD allows easily disabling the bullseye marker during EVA. Having the marker is useful when flying long distances with the jetpack, but it's mostly a distraction when you're just trying to jump into your lander's cargo hold to retrieve some equipment.) So it may have been just me. Thanks for the reply. Another readout I couldn't find in any of the categories of the editor the other night is the compact combined stage/total dV, which is displayed in HUD1 by default. Other dV readouts are listed, though. I'll look again when I get the chance and report back.

Sorry, I don't know, I'm just coming back to KSP after a pause of a couple of years (1.3.0 -> 1.9.1).

Is it just me, or do the KER presets have some readouts that are not listed in the KER view editor? For example, the default LAND view has the Impact marker readout enabled, but the impact marker readout doesn't seem to be listed under any of the categories in the KER view editor. There are other similarly missing readouts too, but I haven't compiled a list yet. This currently makes it impossible to add those readouts to custom views, or to get them back if (accidentally) removed, short of resetting to a default configuration. I tried searching this forum thread, but couldn't find anything on this. I have KSP 1.9.1 on Linux, with KER 1.1.7.1... and a couple dozen other mods. If this is not a known issue, I could make a clean install with just KER, and post the logs.

Intuitiveness or lack of thereof aside, I find this particular feature essential for inclination changes. As long as the initial orientation of the GUI handles is sensible, I don't care whether they rotate or not when I drag the normal. But at least in my opinion, the whole concept of "burning normal" means to continually adjust the orientation of the spacecraft so that at each point in time, the burn always takes place in the current normal direction. The resulting behavior is easy to reason about. This feature currently doesn't work in the latest Precise Node Continued with KSP 1.9.1. When enabled, I get a severe performance hit, but no other effect. Maybe exception spam? I could post a log if you (@linuxgurugamer) want to take a stab at debugging this. For the record, the similar feature in @DMagic's Maneuver Node Evolved currently works fine. He (and/or the source code) would probably know how to do it in the 1.9 series.

Thank you for the mods, and especially this! IMO this feature is a must-have for making inclination changes. I also like the GUIs, they have a very polished stockalike look and feel.

Introducing: Diverse Kerbal Lasses continued! This set of Kerbal head textures by @GreeningGalaxy is very nice, and deserves better than to be lost to the mists of time. The original download links have been dead for a long while, and the internet did not have these textures available anywhere else. The original creator was last seen in 2018. So, following the CC BY license specified by the original creator, I'm taking the liberty of providing this updated package to keep this set of textures working and available. The texture files come as-is from the original Diverse Kerbal Lasses packages, which I downloaded back in 2015 when playing KSP 1.0.4. The template file I didn't have; it was kindly provided by Corax. All credit belongs to the original creator, GreeningGalaxy. This package has been tested in KSP 1.9.1 with TextureReplacer 4.1.3.

Making the FAR patch run last, by adding :FINAL, may help: @PART[*]:HAS[@MODULE[ModuleKrEjectPilot]]:NEEDS[FerramAerospaceResearch]:FINAL { @MODULE[ModuleKrEjectPilot] { %deployHeight = 700 %deployedDrag = 1000 } } As @ss8913 suspected, addEjectionToAll.cfg (or some other patch) is probably overriding the setting from FAR_patch.cfg, since they both specify deployHeight. As @linuxgurugamer suggested, the end result of the MM patching can be verified from the MM cache file. Or in detail: there should be a text file called ModuleManager.ConfigCache in your GameData directory. Open it and search for "vanguard". The actual PART names are "EjectionModule" and "EjectionCover2A". For both parts, look under the MODULE named "ModuleKrEjectPilot"; there should be entries for deployHeight and deployedDrag showing the end result after all the MM patching from all of your installed mods. If these say 700 and 1000, respectively, the parachutes should work properly under FAR. This version of the patch works at least for me, the resulting values are correct and EVA parachute landings are survivable under FAR. I'm playing without addEjectionToAll.cfg, but that shouldn't matter. Ah, and thanks @linuxgurugamer for resurrecting this! Ejection seats and parachutes go very nicely with Kerbal Launch Failure, in case the LAS fails catastrophically or for designs where one cannot be installed (spaceplanes).

Kerbonov adds the Heavy Duty Command Seat (although not updated for KSP 1.3, latest available is for 1.2.x). Yes, with parachutes. Ah, also more easily. Never mind then. My hat's off to you both @Vorg and @HaArLiNsH for this exchange

@Yemo: I agree, such bonuses are difficult to play with due to the added complexity. However, this is how Snacks! does it, so it's probably more in spirit of this particular LS mod to keep the bonus also here. Testing this further, I noticed the KPBS greenhouse doesn't show up by typing in the VAB parts search bar, either - but all greenhouses, including the SETI ones, are now listed under Life Support when Filter Extensions is installed. Curiously, searching for "planetary" finds many KPBS parts, but not the greenhouse. Whatever the issue is, it's hitting KPBS, too. Maybe something in KSP 1.3 has broken the parts search for some mods? I tried also with Malah's QuickSearch installed, still no dice. Couldn't find anything definitive on this on the forum, either. Between the lines, the description of QuickSearch on SpaceDock seems to imply that stock KSP searches at least in tag, title, name, description, author and manufacturer (QuickSearch allows filtering this). IIRC the search used to work in KSP 1.1 when it was introduced, also for all modded parts that I tried back then. Which gets me to: Excellent strategy, let's do that! The current version should be good enough for now. PR sent, check your GitHub. Nice working with you

Thanks! I see you already fixed the Nutrients definition to only run with TAC installed. To prepare the PR, I made a fork on GitHub and added Snacks! Continued support to it (see here). I could either make the PR now, or tune it a bit further. The gameplay balancing is my best guess based on the specs of the various parts. Some documentation on this is in the comments of the updated Greenhouse1.cfg. It should be ok, but I may tune it later once I get the chance to actually launch a Duna mission with greenhouses on board and get some actual data on how it feels. As planned, the greenhouse acts as a recycler; no point in having a snack generator (ore converter) in space. The stock science lab (with Snacks!) already provides one for the players that really want one, and KPBS provides a snack-generating planetary greenhouse (higher rate, lower ore efficiency). Two mysteries remain: As I mentioned, the example provided with Snacks! Continued says it's calibrated for 4 kerbals at 1 meal per day, 100% recycler efficiency. However, the numbers don't match. I'm thinking the comment must be out of date - it talks about a rate of 4.63e-5 (1.00008 per Kerbin day), whereas the actual config says 3.4723e-5 (~0.75 per Kerbin day). Indeed, in the parts list in the VAB, the converter in the hitchhiker can advertises itself as converting 0.75 units per day. (Same for the SETI greenhouses, as I used the same conversion rate.) Now, this is supposed to be the base rate, before RecyclerCapacity is factored in (as I understood, by simple multiplication). But when a part is actually placed in the VAB, the number in the right-click menu on the placed part matches RecyclerCapacity times 0.9 (not times 0.75). There is this snippet in the config, copied from the example: UseSpecialistBonus = true SpecialistEfficiencyFactor = 0.2 UseSpecializationBonus = true // almost-duplicate; typo or old API? SpecialistEfficiencyFactor = 0.1 // duplicate, maybe overriding the previous value? ExperienceEffect = ScienceSkill EfficiencyBonus = 1.0 which makes scientists on the vessel boost the conversion rate. So, I'd understand this if either the un-boosted or fully boosted rate matched RecyclerCapacity times 0.9. Searching the forum, I found this, but the end result doesn't seem to match. (I'm assuming SpecialistBonusBase defaults to 0, as this config doesn't specify it.) TL;DR: the balancing should be ok, since it is scaled from the working example provided with Snacks! Continued, but I don't fully understand where the exact final number comes from. Following the example of KPBS, I also added some tags, including the cck-lifesupport tag. This last one is prepended dynamically to the list of tags when either TAC or Snacks! is installed, using MM's regex substitution. This should place the part in the correct category if also Community Category Kit is installed, and otherwise it should be harmless. But curiously, something here seems to break the search filter in the VAB: typing "green" no longer brings up the greenhouse. It seems KSP generates default search terms (presumably from the part title?) when tags are not specified, but when they are, something unintuitive happens. I do have FilterExtensions installed, so maybe I should test without it to make sure it's not messing things up. So I'm not sure what to do about this change - continue debugging, or leave tags out? Comments?

Ok. Ping me if you need help testing new RPM betas on Linux. FWIW, Texture Replacer Replaced and Vessel Viewer are also suffering from the same issue. The KSP 1.3 compile of the old Texture Replacer works fine, which supports the finding that something has changed in shader creation or bundling.

Ok, sounds good! That will make it easy to create a PR. BTW, I checked the MM docs: https://github.com/sarbian/ModuleManager/wiki/Module-Manager-Syntax and it said that :NEEDS is supported anywhere. I'll take a look as soon as I can. EDIT: works as expected. The only change required is to change the header line of the resource definition in Greenhouse1.cfg such that it reads RESOURCE_DEFINITION:NEEDS[ThunderAerospace] and the definition will run only if TAC is installed. I'll include this change in my eventual PR. Existing installs, with KSP Alternate Resource Panel and without TAC, can then be cleaned up by manually editing TriggerTech/KSPAlternateResourcePanel/PluginData/settings.cfg and deleting the Item section that has name = Nutrients. To be sure, I went to the GameData folder and did shopt -s globstar grep -niRHI nutrients **/*.cfg in GameData, and beside the SETI greenhouse configs, this was the only match. Checked also all files (**/*) in saves, no matches. Ok, we'll do that. Thanks for the input!

Ok, thanks for the info! Just for good measure (Lebesgue or Borel? Take your pick...), here is a complete log. Clean 64-bit KSP 1.3.0 (Linux) with just TR and some textures installed. Used the same test sequence as for TRR. Resulting EVA screenshot. The icon, maybe it's on vacation

@Yemo: That's fine, I can send you my config. More supported LS mods better than fewer, right? Right now I have the following snippet saved as a custom patch SETISnacks.cfg (open spoiler to view). This is pretty much just the example config for Snacks!, with RecyclerCapacity bumped, part description patched, and both Soil and Snacks resources included in each of the two greenhouse parts. It still needs proper gameplay balancing - which I can look into, but no promises about schedule. I'm looking to play some KSP this summer, but no idea how much time I'll actually have I'd also like @Angel-125's opinion about this, as he's the maintainer of Snacks! Continued. It should be simple to place this stuff in Greenhouse1.cfg and Greenhouse3.cfg, similarly to how the parts already include support for TAC. If needed, I could do this and post the result on Dropbox or GitHub for you (Yemo) to pick up. GitHub could be useful as it makes it easy to view diffs between versions. There's also a minor issue that I could try to fix while at it - currently, installing SETIgreenhouse introduces the Nutrients resource even if TAC-LS is not installed, cluttering up e.g. the KSP Alternate Resource Panel config screen. If MM allows tagging resource definitions with :NEEDS, this is easily solved.

Complete log, clean 64-bit KSP 1.3.0 (Linux) with only TRR installed. Startup, load save, jump to a craft (stock AeroEquus on launchpad, crewed by Jeb), EVA, quit to main menu, exit. While doing this, the clean log helped me notice that the CXXABI in Linux Mint 17.2 was too old to support liblingoona, which broke string substitutions. Fixed the problem (solution posted in this thread) before generating this log. EVA screenshot.