Sherrif

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

12 Good

About Sherrif

  • Rank
    Rocketeer
  1. This was my favorite launcher in Orbiter, loved this thing, mostly because it could easily get anything into orbit.
  2. Sherrif

    Astro/Cosmonaut Heads for TextureReplacer

    Dude... This is epic I freaking love these, but I got a question... I mean if all my Kerbals have "Kerman" for their last name... What am I supposed to do about the second Buzz Kerman?
  3. Sherrif

    [1.3] The Malemute Rover [0.2.0]

    That's what it's used for in the code, :HAS[!MODULE[ConnectedLivingSpace]]
  4. Sherrif

    [1.3] The Malemute Rover [0.2.0]

    DStall if you want to double check the pull request for me before he attempts to merge it, I'd appreciate it. Also I added the :HAS and :NEED statements people like to use, HAS is a mostly pointless addition since we know it doesn't have it, but NEED is probably useful to stop the patch from adding the module to their parts when they don't have CLS installed. my bad on the double post, meant to edit the last post with this.
  5. Sherrif

    [1.3] The Malemute Rover [0.2.0]

    If you hold off on merging I can commit some changes to make the wheel nodes not allow crew transfers. testing changes now on my end.
  6. Sherrif

    [1.3] The Malemute Rover [0.2.0]

    I was just sitting on the launch pad now double checking, about to change it back to yours to see if maybe I somehow got it bugged when I tested your config the first time. I had all the parts in a line... One thing I did notice is that it seems odd to be able to move people through the service module, as the wall between the two compartments is a bit thin for Kerbals to be passing through, but it didn't bother me too much. As with the part view they just straight said "Passable: NO" and had no indication that there was functional ports, it had not allowed crew transfers with SM.
  7. Sherrif

    [1.3] The Malemute Rover [0.2.0]

    I've tested it with and without my changes. I need the 'passable' line for the parts to get the rest of the module to actually activate, otherwise the config does not work. I'd consider following the convention of having the "passable" line with the stock config for CLS, they still use it. I didn't want to replace your work when I found it so I simply added the line to solve the issue that I and other users would likely have with the config. I don't know if it's because of the interaction with Ship Manifest using CLS or not, but I'd consider using the 'passable' line. It works fine with it but doesn't work without it, so perhaps my version of CLS (1.2.1.5) requires the legacy convention. Using the config as I've placed it does not undo any of the work to stop surface attached parts from functioning, But it might allow people to transfer crew through the wheel attachment nodes, unless you make them impassible in the config, so it would undo all the "passable" nodes you created, potentially, however I've never used or seen anybody use that convention so I'm not actually sure. I'm not an expert but a change was needed to make the config work.
  8. Sherrif

    [1.3] The Malemute Rover [0.2.0]

    I did notice a problem with it when I tested it. Added a pull request for consideration at your convenience, I'm aware that you are trying to control 100 canadarms at the same time. I'd salute you but I think that'd be adding too many arms.
  9. Sherrif

    [1.3] The Malemute Rover [0.2.0]

    I did some digging into the repo and it seems you have a CLS config in the development branch but it's not committed to the master. Is there an issue with it I'm missing?
  10. Sherrif

    [1.3] The Malemute Rover [0.2.0]

    Is there any compatibility with connected living space? I'm getting CLS saying "Passable: NO" on all parts without any other CLS information. Crews can still sit in each individual space but cannot move from the airlock to crew cabin or driver's cab. They can only EVA over to the other crew hatches for the parts. I knew the Karibou has CLS support so I assumed this one would work too.
  11. Could there be a way for the meta data to have it as a new separate mod, and rename the other version as *legacy* to stop automatic updates for save breaking updates?
  12. Is it a known issue of the Firespitter landing gears explosively launching you into the air, or does this sound like a mod incompatibility?
  13. It seems almost odd to add the German where they did, it seems like a waste considering much of the log is in English. However I noticed something, the reflection plugin on CKAN appears to be for KSP version 1.0.5 and the RN-SovietRockets plugin is 1.1.2 However, I'm an armchair programmer, the kind nobody likes, so my perspective is usually, rightfully, thrown out the window.
  14. Yeah, he was actually responding to my question there, the Module Manager trick kinda works, though I feel like I'm still sending the command module up with a cracked hull like that, I've never really messed with module manager like that before. Both tricks worked, but ultimately I feel a bit better with your trick (simply deleting TweakScale after letting CKAN install it was like drilling a hole in the hull). For my actual question today, or "just to let you know" Cact-Eye switched hands... again. new thread is Here but I'm not sure if he's updated anything, but he has indeed changed the version numbering.