[0.90] [Up for adoption] Connected Living Space v1.1.2.0 (27th Feb 2015) Hatches and Highlighting

Papa_Joe · May 2, 2014

Out of interest - what other mods are you using?

CodePoet,

I noticed the same thing with my test environment. At first I thought it was my plugins, as I had made some changes, but I managed to get it back to a working state from backups, and tested again with the latest dev version you released. I experianced it again.

I would lose all SDHI. clampotron parachue Docking ports. Really messed up the game save. fortunately I had good backups for test, and I was able to recover.

I hadn't responded yet as I'd been under 2 heavy deadlines at work and released new Reports for customers. I just got finished, and came here first. (I know, I'm a geek, I code for pay and for play)

My apologies, as we could have addressed it sooner. }(

Edited May 2, 2014 by Papa_Joe

MrWizerd · May 2, 2014

wow, I was wondering what was causing this problem, because I had done some other stuff when I updated this mode, after speaking with you codepoet. I have had too many distractions to think straight and finally narrowed it down to here. Hope you figure out the problem soon. I am liking the new additions.

codepoet · May 2, 2014

wow, I was wondering what was causing this problem, because I had done some other stuff when I updated this mode, after speaking with you codepoet. I have had too many distractions to think straight and finally narrowed it down to here. Hope you figure out the problem soon. I am liking the new additions.

I went to bed and thought it through as I slept. I them woke up with what I think is the solution:

The new version of CLS includes a ModuleManager file that replaces all the docking nodes in all the parts with docking nodes that have hatches in them. I test using a slightly older version of MM and is all worked fine, but with the latest version of MM it seems to be changed the name of all parts with docking nodes to be "ModuleDockingNodeHatch" rather than changing the name of the MODULE in such parts to ModuleDockingNodeHatch! Hence various parts suddenley disappeared and other wierdness happened!

I will try to get a fix sorted out asap, but I have a busy day - 2 funerals and I need to go and hang out with some nuns this morning as well. If you want a quick fix then disable the file "CLSAddHatchesToDockingNodes.cfg" (or even better fix it and let me know what the fix is!).

Fraz86 · May 2, 2014

(or even better fix it and let me know what the fix is!).

My aforementioned fix (see below) appears to work as intended, except that I don't see any option to open the hatch in game.

@PART[*]:HAS[@MODULE[ModuleDockingNode]]
{
	@MODULE[*]:HAS[#name[ModuleDockingNode]] 
	{
		@name = ModuleDockingNodeHatch
	}
}

codepoet · May 2, 2014

Sorry about all this folks - I am dreadfully embarased about shipping something with such a hideous bug in it!

Fraz86, can you explain how the # syntax works for Module Manager.

Fraz86 · May 2, 2014

The "#" preceding "name" signifies to ModuleManager that I'm looking for the value of a variable named "name". This accomplishes almost the same thing as:

@PART[*]:HAS[@MODULE[ModuleDockingNode]]
{
	@MODULE[ModuleDockingNode]
	{
		@name = ModuleDockingNodeHatch
	}
}

Except that the above will only look for the first module named ModuleDockingNode, rename it to ModuleDockingNodeHatch, and then move on to a different part. @MODULE[*]:HAS[#name[ModuleDockingNode]] should (I think) find all modules named ModuleDockingNode within a given part.

Also, just to help with troubleshooting, the change in behavior that you observed relative to your development version is not caused by the ModuleManager update. Every version of ModuleManager going all the way back to when wildcards were first introduced would have interpreted that file the same way: find all parts containing a module named ModuleDockingNode, and rename the entire part (not the module) to ModuleDockingNodeHatch.

codepoet · May 2, 2014

OK, thanks for that.

As it happend I am now trying to get the hatches working using a different approach. There seemed to be too many strange thigns happening - I expect changing the stock behaviour of docking nodes is not a good idea. Hopefully I will have it cracked soon...

Fraz86 · May 2, 2014

I think that's an excellent decision. Outright replacing the stock docking port module would likely continue to cause a variety of unexpected problems, as well as creating incompatibility with other mods that interact with docking ports.

softweir · May 2, 2014

Might you be able to simply add an overload module to the stock docking ports? Allow the stock module to handle docking and undocking, use yours to control hatches?

Papa_Joe · May 2, 2014

New version of SM out. the Enable CLS switch is now available from the settings window (among others).

Moon Goddess · May 4, 2014

I did a config for KSO shuttle


@PART[KSO_Cabin]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = top , avio , gear
	}
}

@PART[cgholdkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom04 , bottom05 , bottom06 , bottom07
	}
}


@PART[dockingkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom
}

@PART[dockstandardkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ss2pointextkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ss3pointhubkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ss4pointhubkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ss6pointhubkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ssauxfuelkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_Observation]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom
	}
}

@PART[KSO_DockingModule]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_Habitat]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_Hydroponics]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_KerbaLab]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ssport1kso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}


@PART[ssport2kso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true

	}
}

@PART[sspowerkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_SST]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom
	}
}

However, the docking ports don't seem to work.

Fraz86 · May 4, 2014

I did a config for KSO shuttle


@PART[KSO_Cabin]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = top , avio , gear
	}
}

@PART[cgholdkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom04 , bottom05 , bottom06 , bottom07
	}
}


@PART[dockingkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom
}

@PART[dockstandardkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ss2pointextkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ss3pointhubkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ss4pointhubkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ss6pointhubkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ssauxfuelkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_Observation]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
	MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom
	}
}

@PART[KSO_DockingModule]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_Habitat]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_Hydroponics]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_KerbaLab]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[ssport1kso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}


@PART[ssport2kso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true

	}
}

@PART[sspowerkso]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[KSO_SST]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
		impassablenodes = bottom
	}
}

However, the docking ports don't seem to work.

You're missing a "}" in the config for dockingkso.

Moon Goddess · May 4, 2014

Ok, thanks... Strangely that's not even the part that's not working that one is.....

It's the ssport1kso and ssport2kso that are the docking ports.

codepoet · May 4, 2014

Thanks, that is great.

Someone else sent me a KSO config, which you can see here. Would you mind having a quick compare and let me know if your is "better" somehow. I am not familiar with the KSO mod, so it is hard for me to judge any differences.

Thanks

Moon Goddess · May 5, 2014

Oh well, darn, I like searched to see if anyone else had before I did all that, didn't find it.

The one you linked there, does not mark the strange extra node on the tug as impassable, and makes the small size docking ports passable, which is debatable, they look too small by observation, but the flavor text describes them as passable "without a helmet" The KSO docking ports are problematic all the KSO docking ports are declared size1 so they link up to each other and stock docking ports regardless of size or appearance.

S4qFBxkFFg · May 5, 2014

Moon Goddess:

I was trying to make a KSOS config as well, the code that seems to work for the tug is:


@PART[KSO_SST]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passablenodes = top, bottom
		impassablenodes = bottom01
	}
}

codepoet · May 5, 2014

OK, thanks for that.

For all those folks that are putting configs together, can I suggest that you all have a read of the HOWTO on writing configs that I posted earlier on this thread. This is how the config will work of the coming release (1.0.4.0+) that will be released very soon, and it is wil this release that any new config you offer will be shipped. However not all the config option will work with the current version (1.0.3.0)

Papa_Joe · May 7, 2014

Hey codepoet, I have a good one.

I just corrected a bug in SM with the Stock Mobile Processing Lab.

When people tried to transfer, I would get an error. Turns out the lab has no internal Model. as a result, there is no seat, and no place to put a kerbal. So, it should not be listed as crewable. However, since the CrewCapacity is set to 2, we see it.

I added a "part.InternalModel == null" check to filter out parts with no internal Models. you may want to force it as passable and not crewable, so it highlights appropriately.

Edit: Nevermind. I realized that I can still move kerbals to the part, I just cannot refresh the portraits. I'll skip that and all is well.

Edited May 7, 2014 by Papa_Joe

codepoet · May 7, 2014

Thanks for this. Could we (not sure who) add a default internal to it?

Papa_Joe · May 7, 2014

lander can is 2 man... maybe possible with a MM config?

Fraz86 · May 7, 2014

lander can is 2 man... maybe possible with a MM config?

I would recommend against requiring crewable parts to have an IVA model in order to function properly. Many mods add command modules with no IVA. It seems to me that CLS and ShipManifest should refer to the variable "CrewCapacity" to determine the number seats available, and that CLS should deem a part "crewable" if CrewCapacity > 0. If an IVA model is available, then the Kerbal portraits should be updated as appropriate, but I would recommend against any dependency on portraits or IVA models.

However, if there's truly no other way around this issue, and all crewable parts need to have IVAs in order for CLS and ShipManifest to function properly, then I would recommend a MM config to add IVAs to all parts with CrewCapacity > 0. If it's important that the number of IVA seats match the intended capacity, then I suggest something like this:

@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[1]]
{
	INTERNAL
	{
		name = landerCabinSmallInternal
	}
}
@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[2]]
{
	INTERNAL
	{
		name = landerCabinInternals
	}
}
@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[3]]
{
	INTERNAL
	{
		name = PodCockpit
	}
}
@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[4]]
{
	INTERNAL
	{
		name = crewCabinInternals
	}
}

codepoet · May 7, 2014

I agree with Fraz I think. CLS only considers crew capacity, and I would prefer that it remained that way. The lack of an internal only causes a problem for portraits, and I think that is best addressed by ShipManifest.

Papa_Joe · May 8, 2014

I would recommend against requiring crewable parts to have an IVA model in order to function properly. Many mods add command modules with no IVA. It seems to me that CLS and ShipManifest should refer to the variable "CrewCapacity" to determine the number seats available, and that CLS should deem a part "crewable" if CrewCapacity > 0. If an IVA model is available, then the Kerbal portraits should be updated as appropriate, but I would recommend against any dependency on portraits or IVA models.
However, if there's truly no other way around this issue, and all crewable parts need to have IVAs in order for CLS and ShipManifest to function properly, then I would recommend a MM config to add IVAs to all parts with CrewCapacity > 0. If it's important that the number of IVA seats match the intended capacity, then I suggest something like this:
@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[1]]
{
	INTERNAL
	{
		name = landerCabinSmallInternal
	}
}
@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[2]]
{
	INTERNAL
	{
		name = landerCabinInternals
	}
}
@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[3]]
{
	INTERNAL
	{
		name = PodCockpit
	}
}
@PART[*]:HAS[@MODULE[ModuleCommand],!INTERNAL[*],#CrewCapacity[4]]
{
	INTERNAL
	{
		name = crewCabinInternals
	}
}

I agree with Fraz I think. CLS only considers crew capacity, and I would prefer that it remained that way. The lack of an internal only causes a problem for portraits, and I think that is best addressed by ShipManifest.

Perhaps I wasn't clear. I was responding to codepoet's post about a default iva. I was thinking in terms of if a person desired that. I have already implemented a fix for the internal model issue. crew can be moved as normal. there will simply not be a portrait for the crew member in the non Internal Model part. I completed testing that fix last night (CDT), and it will be in the next release.

Btw, the config looks like it should work. that would allow for people to have an internal view if they wish, and SM would like it just fine. thanks for the effort on that. I'm sure it would add value for some.

Edited May 8, 2014 by Papa_Joe

codepoet · May 8, 2014

I have just released v1.0.4.1 which should fix the botched release of v.1.0.4.0.

Change Log

* Warning no longer logged for EVAs

* Added instruction for writing config files.

* Added support for surface attached parts

* Fixed bug of space names being lost.

* Added CrewCabin to stock config

* Added config for KSOS part pack.

* Moved implementation of hatches into the ModuleDockingNodeHatch

* Changed the handling of docked connections to support docking ports that do not use an attach node, and also parts with more than one docking port.

* Fixed spelling mistake in the name of Sun Dum Heavy Industries

* Added support for Large Structural/Station components part pack

* Added support for Home Grown Rockets part pack.

* Added support for Universal Storage part pack.

* Added support for B9 aerospace parts pack.

* Added support for KSPX parts pack.

Papa_Joe · May 9, 2014

I have just released v1.0.4.1 which should fix the botched release of v.1.0.4.0.
Change Log
* Warning no longer logged for EVAs
* Added instruction for writing config files.
* Added support for surface attached parts
* Fixed bug of space names being lost.
* Added CrewCabin to stock config
* Added config for KSOS part pack.
* Moved implementation of hatches into the ModuleDockingNodeHatch
* Changed the handling of docked connections to support docking ports that do not use an attach node, and also parts with more than one docking port.
* Fixed spelling mistake in the name of Sun Dum Heavy Industries
* Added support for Large Structural/Station components part pack
* Added support for Home Grown Rockets part pack.
* Added support for Universal Storage part pack.
* Added support for B9 aerospace parts pack.
* Added support for KSPX parts pack.

Got it. Off to test!

[0.90] [Up for adoption] Connected Living Space v1.1.2.0 (27th Feb 2015) Hatches and Highlighting

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites