Nils277

Members
  • Content count

    911
  • Joined

  • Last visited

Community Reputation

1034 Excellent

About Nils277

  • Rank
    Sr. Base and Rover Engineer

Recent Profile Visitors

4802 profile views
  1. D'oh! Have missed this one. Sorry about that. Can be locked
  2. Hi, i just read an article on Gamestar und in this video from minute 20 stating that Valve has employed a good portion of the developers of KSP around five to six months ago. I haven't have heard anything of this yet. GameStar is even speculating that maybe Valve bought Squad. The article also states that Valve answered to a request that "they" were hired, not stating if they meant Squad of some of the developers. What do you think about this? I think that maybe squad has employed the teammembers that left Squad not too long ago. Wouldn't such big news have been around for a while if Squad was taken over by Valve? Can maybe @UomoCapra or @Badie shed some light on this?
  3. @The_Cat_In_Space Sorry for the late reply about spawning inside of the craft instead of outside. You are right, it would be cool to be able to walk around with a kerbal inside of the crewed parts. But it is not really feasible with the current state of KSP. First we have the IVA existing as a seperate model in its own coordinate system which is rendered in a seperate scene and then merged into the image. When using e.g. JSI Advanced Transparent pods, one can see, that the IVA is actually occluding the kerbal in the image although he/she is in front of the IVA. This would mean, that you can't actually see the kerbal when the IVA from the game is used. So i would have to make the 'real' IVA invisible for the time and add the model for the IVA to the model of the part itself. Which i then would have to hide when viewing from stock IVA because it would cause all sorts of rendering errors when they overlap. Additionally the interal model would need to have a lot of colliders to allow the kerbal to move inside of it. I guess it would at least triple the number of needed colliders for each crewed part. This would slow down the physics simulation a lot. Last but not least, there would be nothing you can do inside of the parts. All the props (e.g. Knobs, Switches, Throttle and so on) are part of the internal model and can't be used (and aren't even visible) when controlling a Kerbal in EVA.
  4. @Starwaster Good find! You are right. I just looked at the loaded dlls and searched for any "[EXC" and only saw that the dll from KPBS was missing. Weird that a DLL that can't be loaded is only mentioned as an error. I would think that this is something more severe. So yeah, @progressiveMonkey it seems that the DLL is way out of date, it is actually for KSP 1.1.2 way back from June 2016. Oh btw, do you by any chance also have problems with the B9PartSwitch or USITools or others? There are multiple errors for an "UnauthorizedAccessException" for these dlls so they might not be able to load or save some of their settings.
  5. Hmm, it seems that the plugin dll from KPBS is missing. It should be in GameData/PlanetaryBaseInc/BaseSystem/Plugins/PlanetarySurfaceStructures.dll. Can you take a look if the plugin dll is there?
  6. Hmm, can you post a screenshot of the parts/vessels in question. What does it say about the status of the hitch in the right click menu?
  7. You mean the deploy button for the extandable parts? That is weird. What version of this mod are you using and what version of KSP are you using? I think a log file (the one called KSP.log from the main KSP folder) might shed some light into this No it is not dead. Thanks, will fix this soon. Had another report about the same misspelling in the CKAN entry. Damn you copy&paste
  8. @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
  9. 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
  10. 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
  11. 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?
  12. 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
  13. 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.
  14. 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.
  15. 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