[1.12.x] The Malemute Rover

[RoverDude]

On 6/13/2016 at 5:04 PM, Bomoo said:

Small bug report here. When the lights are activated in the malemute control pod, only one of them actually projects a light source. Namely, the right one when viewed facing the pod. Left one projects nuffin'.

This can be seen clearly when you're driving around at night, have the lights on, and view the rover from above.

http://steamcommunity.com/sharedfiles/filedetails/?id=703264547

Github issue please

 

6 minutes ago, Sherrif said:

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.

Not at the moment, but if someone tosses a PR I'll be happy to add it

[Sherrif]

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?

[RoverDude]

Oh, then odds are you will see it next release

(Remember I handle about 400 parts across over a dozen mods with a lot of contributors  )

[Sherrif]

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.

[DStaal]

5 minutes ago, Sherrif said:

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.

Actually, the 'passable' line is no longer needed - it's basically legacy, and would basically override the more fine-grained config to allowing it everywhere, instead of to specific nodes.  I've been using the config that's in the dev branch for a while.  (I wrote the pull request - after testing in my game.)

[RoverDude]

Before I accidentally pull in something that makes things go south, could you two please coordinate and close/update the PRs?  I don't use CLS so I'd be going blind, and I'd hate to mess things up.

[Sherrif]

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.

[DStaal]

My understanding is the process for those configs works like this:

1. Set overall part pass ability - default is to 'false', if you set 'passable' that changes that.
2. Enable/restrict on particular nodes (or surface) in relation to the default.

I'm trying to understand why that config works for me and doesn't work for you.  (I use Ship Manifest as well, so that's not the issue.)  I could re-write using 'passable', but it would need to be a longer, more complex, config.  Question: How are you testing?  Are you just looking at the description, or are you putting a ship together in the VAB/SPH and clicking on the CLS button to test?

As another question: Does it work for you if you set 'passable' to false?  It should, if I understand things right: The part would only be passable through the nodes specified.  (Though it might list in the VAB description as impassable.)

[Sherrif]

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.

Edited June 16, 2016 by Sherrif

[DStaal]

On the service module: Yeah, I thought about having it non-passable, but I decided the utility of being able to pass through it was good, and it can be argued that there's supposed to be some space.    Basically, I had the same thought, but decided that I wanted to be able to put in line with the rest of the parts and still pass through to the rear airlock.

I've asked someone to take a look at it over in the CLS thread.  Hopefully someone there will be able to help us debug a bit better.

[Bomoo]

3 hours ago, RoverDude said:

Github issue please

Oh Lord, and here I was doing so well not learning anything new today.

[DStaal]

Ok, Papa_Joe responded over in the CLS thread - We're not sure why it works on my box, but adding the passable would be the right thing to do.  So, @RoverDude, feel free to merge in the pull request @Sherrif put up.

[Sherrif]

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.

Edited June 16, 2016 by Sherrif

[Sherrif]

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.

Edited June 16, 2016 by Sherrif

[DStaal]

3 minutes ago, Sherrif said:

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.

Looks good - though I don't have time to test at the moment.  I'll try to remember to double-check it next time I can fire up KSP.  And yes, the :NEEDS is a good idea - I can't believe I forgot that.  (:HAS in this case is debatable - but it doesn't hurt.  I mostly use that in my personal additions so that if a future update include official support my patch will get ignored.  This is official support.)

[panarchist]

54 minutes ago, Sherrif said:

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.

HAS is useful for "has not".  It's a good check since another MM patch could remove the CLS module - in which case, the NEED would be fulfilled, but not the HAS condition.

[Sherrif]

3 minutes ago, panarchist said:

HAS is useful for "has not".  It's a good check since another MM patch could remove the CLS module - in which case, the NEED would be fulfilled, but not the HAS condition.

That's what it's used for in the code,

:HAS[!MODULE[ConnectedLivingSpace]]

 

[panarchist]

16 minutes ago, Sherrif said:

That's what it's used for in the code,

:HAS[!MODULE[ConnectedLivingSpace]]

 

Right, I was responding to "HAS is a mostly pointless addition".  It's more like "being a good neighbor" and building in a little extra error handling.  Or error prevention as the case may be.  We wouldn't even need to worry about it if everyone wasn't running installs with 75 mods. (I am one of those people)

[musdancat]

Awesome mod! Always tried to make rovers that fit in the Mk3. Would be cool if the big modular wheels work in stowed position, to be able to load/unload the rover on the Mk3 ramp... Yeah I know there are the mini wheels but they look kind of... "mini". Anyway BIG THANKS for an AWESOME MOD!!!

[Jackaroo0505]

Thanks to KottabosGames for this mod or else I would not be able to craft a good rover. Insta- Download!

[vardicd]

13 hours ago, Jackaroo0505 said:

Thanks to KottabosGames for this mod or else I would not be able to craft a good rover. Insta- Download!

I think you mean "thanks to Kottabosgames for showcasing this mod, made by RoverDude."  Just to be clear on who is getting what credit, and all.

[RaendyLeBeau]

great job, very pro- work !! congrats

[RoverDude]

Thanks

[Mekan1k]

Cute little rover! I love it.

[Yuri kagarin56]

Anyone have a successful launch/landing system for this?