• Content count

  • Joined

  • Last visited

Community Reputation

1032 Excellent

About Nils277

  • Rank
    Sr. Base and Rover Engineer

Recent Profile Visitors

4606 profile views
  1. @megamike That simple construction does not have MetalOre defined is indeed the problem. I will add a check to see of the resource that is added to the storage actually exists. This should fix the problem. Will also take a look at SC and see if i can add support for it if i find the time. @Overland Hmm, i will put it on the list of potential new parts
  2. As @Starwaster said, changing the NEEDS parts would not help. I'm afraid i have to add a more detailled log to the plugin about when the reading of the config fails. I thought that maybe the config file is corrupted or has a missing bracket or so, but this is not the case. Edit: I won't be able to do anything for the next week or so because i'm on vacation
  3. I'm not directly opposed to support TweakScale for all of the parts. Just thought that it would not be really needed and sensible for e.g. the parts that are inhabited. (Is the IVA scaled too and are the kerbals in the IVA really small then? Or is the IVA still small and does not fit the external part?) I have not added support for TweakScale for all parts because i have not checked if there are any interferences between some custom plugin code for the parts and tweakscale. Saw you made a pull request on GitHub. It looks sane to me. Will add it for the next release. Will take some time until 1.3 is officially out though
  4. Will put it on the list of possible new parts The second line is generated by the plugin and states that at least one of the configurations for the storage types does not exist. I'm not sure what exactly is missing there though. Can you post the content of the freight_storage.cfg template?
  5. This sounds like the templates for the resources are missing. Can you take a look at KerbetrotterLtd/FelineUtilityRover/Templates and tell me what files are in there? Maybe completely removing FUR and reinstalling it might help
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. Because the Mobile Lab is way smaller than the stock Laboratory and therefore should be not as efficient as the stock lab.
  11. 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.
  12. 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.
  13. 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).
  14. 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.
  15. 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.