Nils277

Members
  • Content count

    899
  • Joined

  • Last visited

Community Reputation

1021 Excellent

About Nils277

  • Rank
    Sr. Base and Rover Engineer

Recent Profile Visitors

4341 profile views
  1. Well, my curiosity won and i tried out how to access the localized strings in the plugin and it is really as simple as possible. You'd just have to make two things: 1. Import the localization module: using KSP.Localization; 2. use the Localization class instead of the normal string. e.g.: string description = Localization.instance.Tags["#autoLOC_FUR.cockpit.description"]; In code you can use the exact same names as for the config files.
  2. human-readable IDs are possible. At least in a limited way, the strings have to begin with "#autoLOC_". I don't know yet if a naming with underscore in the subsequent id of the string is possible or if this suffers from the same bugs as the names of the stack nodes. But at least it seems to work with IDs like: #autoLOC_FUR.cockpit.description. So there won't be a huge problem with duplicate ids when they are handled the same way as the IDs of the parts. I just wished the ids of the strings from the stock parts had more descriptive names. This would really make it much easier to find and use e.g. the already existing strings for crew reports etc. Edit: The only thing i have not figured out yet is how the strings in the plugins can be replaced besides making all strings settable in the config files.
  3. hmm, what irony? No it was more like (tan(0.785398163) • THUMB • volumeMobileLab / arcsin(-2π) • TOE • volumeBigLab) • ei•π. Sorry i was a bit harsh yesterday, have been a bit stressed out lately Maybe i should change it to maybe 5 times slower. Anything more would be a bit overpowered in my opinion. Already planned. @DStaal, @Starwaster, @Merkov the obscurity of the scienceMultiplier is indeed a problem. A tough call what to do with that...adding a "warning" in the description would be really needed when i keept it at 4 instead of 5 science per data...Maybe the slower conversion and the missing ability to "level up" Kerbals is enough to make the MobileLab not too overpowered
  4. Why would it be too slow to use? It just takes ten times more time to convert the data, which is very likely for a small mobile lab compared to a fully equipped stationary lab. You really just need more time to convert the data, which you can simply bridge with timewarp. I don' really understand what the problem there is. There is no exact formular for the conversion of data to science. I just used a rule of thumb to lower the rate for the mobile lab.
  5. Because the Mobile Lab is way smaller than the stock Laboratory and therefore should be not as efficient as the stock lab.
  6. This is not known yet. I need a log file to see what goes wrong there. But the parts only use the modules that EPL provides. Is KSP build 1622 the new prerelease? I'm not at home at the moment and can't check any of this for the next few days.
  7. Hmm, seems i have forgotten the supplies...will be added in the next release. I can't say much about this at the moment. Can you post a screenshot of your craft with the autostruts visible? Maybe this helps solving the issue.
  8. Hmm, this is my mistake then, sorry. Difficult...i think the only way to not break too much is that i change the plugin to add this part to the LS category too (by its exact name).
  9. The KKAOSS_LS is only ignored for the KPBS filter that is shown in the "Filter by Category" filter (if activated) to avoid the part from being in both filter (KPBS and Life Support). My guess it that the Recycler starts with KKAOSS (not KKAOSS_LS) but does not have a catagory (e.g. category = none). The parts must either have a name starting with KKAOSS_LS for life support or a valid category to be shown in the advanced filters tab.
  10. Sorry for the late reply, already wanted to make a post. but have been too busy the last week. Would have added a section to the OP where ppl are linked to this thread so they can test this out. Should i do this? Will be probably at the end of the week.
  11. It is still the same. The filter still works with KKAOSS and KKAOSS_LS. The only difference is, that it is inactive as soon as CCK is installed. Then you also need the cck-lifesupport tag.
  12. Multiple joints between the adapters should be possible. The adapters are only there to prevent the autostruts from the wheels from blocking the joints. But i would recommend not to use too many, because the craft won't collide with itself which will make the whole thing unstable
  13. @juanml82 This is weird. Maybe the auto-struts from the wheels are causing trouble then. You can see them when pressing ALT + F12 and click on Physics, in this menu you enable "Visualize Autostruts". When one of the oragen lines from a wheel crosses the bellowed joint or the hitch then this is the cause. Can you post a picture of the autostruts? Is be bellowed part not bending, or is also the hitch rigid? can you also post an image with a better view on the hitch? I can't point the finger on it yet, but it looks like there is something missing.
  14. hmm, the only thing i know that caused performance issues with KPBS and FUR is the support for JSI Advanced Transparent Pods. Especially when RPM and ASET are installed. From your list of mods is can only see the common performance hungry mods like Scatterer, EVE and Distant Object. Maybe on of these mods has some optimization issues with Minmus. I don't now what KSPWheel does, but maybe when using a rover with many wheels, it also impacts performace. You can try out two things to localize the cause: If it is the physics distance you can try out doing the same on an equally sized or smaller moon like Bop or Gilly. You can try to go to minmus with a stock only craft and see if it causes the same problem. This way you can find out if parts from some mod are causing the performance hit.
  15. @regex I think we should agree that we have a very different option about this topic. It somehow feels like discussing politics And yeah, the GPL is far from optimal too.