Technologicat

Members
  • Content Count

    78
  • Joined

  • Last visited

Community Reputation

23 Excellent

About Technologicat

  • Rank
    Wandering Assistant

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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).
  2. 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
  3. @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
  4. 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?
  5. 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.
  6. 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!
  7. 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
  8. @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.
  9. 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.
  10. @arctangent: Thank you! I can confirm that the DLL libstdc++.so.6.0.22 from libstdc++6_6.3.0-18_amd64.deb fixes the issue perfectly on Linux Mint 17.2. This version of Mint is otherwise problematic: the default libstdc++.so.6 is too old, whereas the one from the ubuntu-toolchain-r PPA (as suggested on StackOverflow as a solution to a similar problem) is too new (libstdc++.so.6.0.23, newer ABI) for KSP 1.3.0. In case anyone else runs into this problem (and upgrading Mint is not an option for them), instructions: Open your KSP_linux directory in the file manager For 64-bit KSP, download the deb package, for the amd64 architecture, from the Debian site. Link posted by arctangent. Open the downloaded deb package with Archive Manager In Archive Manager, inside the deb package navigate to /usr/lib/x86_64-linux-gnu/ Extract libstdc++.so.6.0.22 into your KSP_linux directory Open a terminal in your KSP_linux directory In the terminal, create the symlink, since KSP will look for "libstdc++.so.6": ln -s libstdc++.so.6.0.22 libstdc++.so.6 It is possible to just rename the file to libstdc++.so.6, but this has the advantage of preserving the information about the ABI version in the filename. Create a startup script (run.sh) that tells Linux (technically, the dynamic linker) to prefer this libstdc++.so.6 over the system one when starting KSP: #!/bin/bash LD_LIBRARY_PATH=. ./KSP.x86_64 Basically, this first tries loading any DLLs (.so) from the current directory before defaulting to the system paths. Set the startup script as executable: chmod +x run.sh Then, to start KSP, open the KSP_linux directory in the terminal, and execute ./run.sh Final note: a startup script can be useful in other non-standard configurations. For example, my run.sh says #!/bin/bash LD_LIBRARY_PATH=. __GL_THREADED_OPTIMIZATIONS=0 primusrun ./KSP.x86_64 which runs the game through primusrun (to run the graphics on the NVIDIA GPU). I'm not sure if __GL_THREADED_OPTIMIZATIONS=0 is needed any more, but I've left it in just in case
  11. @Yemo, @Angel-125: Any interest in a small MM patch adding Snacks! support to the SETI greenhouse, that I put together for my own campaign? The motivation is that KPBS already adds planetary greenhouses, but right now there is no Snacks!-compatible orbital greenhouse to include on the mothership for those long interplanetary flights (or on a space station). I'm just getting into playing with a life support mod myself, and ended up choosing Snacks! for its simplicity and stockalike feel. I was thinking that in Snacks!, the greenhouse could act as a soil recycler, like the stock hitchhiker can does. To compensate for greenhouse's mass and the zero crew capacity - indeed, its dedicated role - it would be a higher-output recycler. Out of the box, the hitchhiker can is calibrated to provide enough recycling capacity for 4 kerbals, so, for example, the small greenhouse could be similarly calibrated for 6 and the big one for 8. The patch was rather trivial to make, based on the working config examples provided with Snacks!. Beside modifying the capacities, I only patched the descriptions to match the behaviour. The difficult part, of course, is to get the gameplay balancing right. So far I've just tested that the patch poked the right things to indeed make the SETI greenhouse work as a recycler in Snacks!. I haven't yet thought about the numbers. The calibration of the stock hitchhiker can is at 100% recycler efficiency, 1 snack per meal, 1 meal per day. In Snacks!, all these values are set by the player, in the game difficulty options. The recycler efficiency, in particular, can be anything from 10% to 100%. The KSPedia screenshots in the OP of the Snacks! Continued thread imply that the official recommendations are 1 snack per meal, 3 meals per day, 40% efficiency (correct me Angel if I'm wrong ). At these settings, one hitchhiker can is sufficient to recycle enough food for 40% * 4 * (1/3) = 0.53 kerbals. Given the dedicated role of the greenhouse, maybe the small one could recycle enough food for 2 (maybe 3?) kerbals and the big one for 4 (maybe 6), at the officially recommended settings? This would give theoretical capacities of 16 (24) and 32 (48), respectively - but on the other hand, these values are insane when run at or near 100% efficiency, and less than 3 meals per day. Comments?
  12. Linux user here. I tried TRR in KSP 1.3.0, but with reflections enabled, the EVA visor shows as a pink blob, which probably indicates that the shader didn't load. Linux Mint 17.2, KSP 1.3.0 (64-bit), NVIDIA GTX 960m, driver version 352.79 running OpenGL 4.5. For comparison, the version of TR updated by Ger_space has working EVA visor reflections in Linux. It seems TR and TRR use different shaders for this - TR has tr_reflective_emissive_alpha.ksp (lowercase, 58.3kB), DirectX.bundle and OpenGL.bundle, whereas TRR has TR_Reflective_Emissive_Alpha.ksp (CamelCase, 96.0kB) and TRVisor.ksp. I've switched to TR for now (which may also be more appropriate for the time being, considering existing suit packs), but I can drop TRR back in and provide a log if you want to investigate this.
  13. @Ger_space: It does! Thank you! Confirmed working: Linux Mint 17.2, KSP 1.3.0 (64-bit), NVIDIA GTX 960m, drivers 352.79 running OpenGL 4.5. I'm still getting these messages in Player.log: WARNING: Shader Unsupported: 'ShaderNG/TR_Reflective_Emissive_Alpha' - Pass 'FORWARD' has no vertex shader WARNING: Shader Unsupported: 'ShaderNG/TR_Reflective_Emissive_Alpha' - Pass 'FORWARD' has no vertex shader WARNING: Shader Unsupported: 'ShaderNG/TR_Reflective_Emissive_Alpha' - All passes removed ...but the visor reflection on the EVA suit works. If you want to investigate, I can make a clean install with TR only (my current install has dozens of mods), and then dropbox a full log. Second @Kerbart's suggestion about appIcon.dds. Not a major issue if you happen to have an old install to pull it from, but would be more convenient if it was included in the download
  14. @MOARdV: another Linux user here - I'm having the same pink blob issue. Linux Mint 17.2, KSP 1.3.0 (64-bit), NVIDIA GTX 960m, driver version 352.79 running OpenGL 4.5. I'm getting the exact same shader error messages in Player.log as @martinmike2 already reported.
  15. @kBob: Thanks! I have seen that, but thought it might be out of date since the wiki still talks about migration problems and the warning has been there for a long time. Checking the history of the key bindings page, though, says that it's last been updated on 19 May 2016, so it's probably fine. In fact, looking at this diff, which lists the changes to that page between KSP 1.0.5 and 1.1.0, it seems the only changes in 1.1.0 are the addition of '/' to stop timewarp (unfortunately, useful only on keyboard layouts such as EN-US that need no modifiers for '/'), and the change of the modifier key from LAlt to RShift on Linux, which is indeed very nice since many window managers on Linux tend to reserve LAlt for other purposes. I didn't actually notice the latter - I'm playing on Linux and I think I had to remap Mod in settings.cfg with the help of this. In Linux KSP 1.0.4, Mod was RShift, while 1.0.5 used LAlt, and I could have sworn that when I installed KSP 1.1.2 with a default settings.cfg, the default modifier key was LAlt. Would need to do a clean decompress to check, though. In case anyone is wondering, 'Y' is indeed unused. Problem solved. Now to hope there won't be many more key conflicts