codepoetpbowden / connectedlivingspace Goto Github PK

I have an issue with your mod (its a nice mod)

When you have a non-docked docking port you can open the hatch. imo this should not be possible.
After you have opened it nothing special happens ofcourse but you can not close it again. So at that moment the situation is as it should be.
If you go away to the space centre and come back to your vessel the situation is back as before, allowed to open the hatch again.

Sometimes, when trying to load a vessel .craft file into the VAB, I get the following exception. I have not been able to figure out why it is happening.

CRFFix.Start()

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

SAFix.Start()

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

[WeldingTool] - UbioWeldingLtd.EditorToolbar => initToolbar

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

CLS highlighted parts gathering Error: System.NullReferenceException: Object reference not set to an instance of an object

at ConnectedLivingSpace.CLSAddon.RebuildCLSVessel (.Part newRootPart) [0x00000] in :0

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.LifeSupportModule[FFF84D52][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.TacGenericConverter[FFF84516][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.TacGenericConverter[FFF844F4][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.TacGenericConverter[FFF844D2][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.LifeSupportModule[FFF844BE][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.TacGenericConverter[FFF84482][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.LifeSupportModule[FFF8446E][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.LifeSupportModule[FFF83C02][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Tac.LifeSupportModule[FFF83B8C][214.06]: OnStart: Editor

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

[MechJeb2] MechJebFARExt adding MJ2 callback

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

FAR Raycast mask: 557059 557063

Since last update I'm getting this CLS related stuff in logs:
Part Bill Kerman is habitable but does not have ModuleConnectedLivingSpace defined in the config. It would be better if it did as some infomation used by CLS will not be saved in the savefile.

Is it SM related or purely CLS message?

after opening/closing hatches and merging/separating living spaces they all have the same name (maybe it's because i use russian letters?).

The API wrapper scan the assemblies at each call, this can take up to 2 ms. While is true that the CLS handler returned can be cached as long as the active vessel doesn't change, the following replacement for the wrapper will avoid the assemblies scan:

static class CLS
{
  static PropertyInfo cls;

  static CLS()
  {
    Type cls_type = AssemblyLoader
      .loadedAssemblies
      .SelectMany(a => a.assembly.GetExportedTypes())
      .SingleOrDefault(t => t.FullName == "ConnectedLivingSpace.CLSAddon");

    if (cls_type != null) cls = cls_type.GetProperty("Instance", BindingFlags.Public | BindingFlags.Static);
  }

  public static bool has()
  {
    return cls != null;
  }

  public static ConnectedLivingSpace.ICLSAddon get()
  {
    return cls == null ? null : (ConnectedLivingSpace.ICLSAddon)cls.GetValue(null, null);
  }
}

So the issue is that MK3 parts have no none tank adapters, by default fuel tanks are impassible which makes sense. Except the mk3 fuel tanks all have doors in them for fuel transfer. any chance of CIS not restricting mk3 part transfers

Removing the root part of a ship in the VAB while the CLS window is open breaks the mod: the window stops updating, and it can no longer be opened and closed from the toolbar. The problem can be fixed by exiting and re-entering the VAB.

Deleting the ship while the window is closed causes no ill effects. Deleting any part other than the root causes no ill effects.

Do to the recent version of Contract Configurator breaking some mods that use Blizzy's Toolbar, the code wrapper will need to be updated. This is one of the affected mods.

For more information about how Contract Configurator causes the problem: here

For the most recent version of ToolbarWrapper.cs: here

When attempting to dock two parts of a station together, using stock clamp-o-tron docking ports, the living spaces were not connected together.

Testing against a station that had node attached docking ports, no issues at all, living spaces connected properly.

Anything attempting to dock to a port that is radially attached will not connect living spaces.

The CFG file variable documentation is not very clear, I had to guess at several things. It could do with a clearer and more concise layout. Not a major issue but it'd make config writers' lives a tad easier :) Also they are in a file buried in the mod directories.

I haven't needed the API docs for the DLL but they didn't look that clear either and are on the forum.

It would very likely be beneficial to all developers working with CLS if the documentation was cleaned up and kept in one easy to find location that could be linked from other places. Why not use the wiki or Readme.md system included with GitHub?

A forum user reported problems with surface-attached parts from the SSPX mod.

Further investigation seemed to indicate that breaking symmetry (eg, by re-rooting) broke CLS. Needs further investigation.

Follow the thread for several posts here:
https://forum.kerbalspaceprogram.com/index.php?/topic/192130-191-connected-living-spaces-adopted-2005-2020-06-15/&do=findComment&comment=3790717

Issue

In the Editor, when adding or removing parts from a ship, the CLS highlighting will break and not correctly show the currently selected Living Space.

Condition:

KSP v1.12.x
CLS v2.0.2.0

In Editor with a vessel consisting of one or more Living Spaces. Have CLS window open and a Living Space selected which is correctly highlighted.

Action:

Add or remove a part.

Actual Result:

Vessel's CLS spaces are incorrectly highlighted.

Specifically, it seems only structural parts and docking ports which are part of a Livving Space are highlighted, parts which can contain Crew are no longer highlighted.

Expected Result:

The selected Living Space of the vessel is correctly highlighted.

Workaround:

Toggle highlighting on/off in the CLS UI for the Living Space. It will now be highlighted correctly.

Additional Notes:

This may be an issue in the way KSP handles highlighting in the editor in general.

With CLS closed, on mouse-over a part, the part and all of its children are highlighted.

Now click-drag the current vessel's root part. When letting go of the mouse button, only the vessels' non-habitable parts are highlighted while the mouse remains over the vessel's root part. Moving the mouse off the root part performs proper highlighting again.

When you open or close a hatch, the hatch status on the part tweakable does not update.

I've found a bug regarding the CLS module descriptions that show up in the VAB. Their descriptions in terms of which nodes are passable/impassable appear to reflect only the default settings. For instance, I changed the lander cans to be passable only through the top node, and this functions as intended in game, but the description still says they're passable through all nodes. Also, for whatever reason, the Hitchhiker module seems to lack a CLS description altogether (though it still function as intended).

After undocking CLS does not seem to rebuild itself and the gui seems to be out of date,

Both CLSDefaultPart.cfg.txt and CLSDefaultPart.cfg ended up in the distribution, when it looks like it shouldn't be enabled going by the repo.

(Also, I think the logic's inverted -- the intent is to make any part that is an engine or fuel tank or size 0 impassable, right? What's it supposed to do?)

Proposal is to allow different passability for different PartVariants of a part. Example use-case: PorktoberRevolution/ReStocked#959 where the Size1to0ServiceModule is given a docking tunnel variant by the Restock addon, but the docking tunnel variant is not passable with CLS since the overall part is not due to the vanilla bare variant

Still need translations for :

• 中文
• 日本語
• Português
• Français

Please create pull-requests against the feature/localisation branch:

This seems like an oversight to me as the supplies storage from TAC are passable as are the station science experiment modules.

Sometimes when adding parts to a new vessel in the VAB, CLS will not properly update the spaces. If you disconnect and reconnect the parts. CLS updates.
Ref: Forum post: http://forum.kerbalspaceprogram.com/index.php?/topic/109972-130-connected-living-space-v1253-1-jun-2017-localization/&do=findComment&comment=3078341

When testing my CLS configs, I noticed if I remove the root part the CLS panel locks up, won't open or close and won't interact. Hitting 'new', loading a craft file or going out and back in (basically, resetting the VAB) resolves the issue as a work around.

CLS panel needs to reset upon removal of the root part.

All crewable pods need to have CLSModules on them in order to be able to persist the CLS data to the save file.
It might be best to provide a catchall bit of config to add it, but also log a warning if it is not present.

For some, as yet unknown, reason, this.vessel is null when switching to the flight view, resulting in an empty CLS window.

https://github.com/austizmo/ConnectedLivingSpace/commit/5582664037c9ac2c1949c4de5e8db4357ce1f88b?w=1

The above commit resolves the symptom, but I'm still unsure why this.vessel isn't being built correctly in the first place, nor why a subsequent call to the rebuild function succeeds when, presumably, an earlier call failed.

The Inflato Storage Container F.L.A.T from PorkWorks 0.3 (part name "inflatoFlat") has three nodes that behave much like stock shielded docking ports. These nodes are not recognized by CLS, even when connected to a passable component. The bug may apply to other part packs that have integrated docking ports.

EDIT: Test was done using CLS 1.0.2.0. None of the parts in the testbed had any module manager tweaks applied to them.

When changing a part's CLS configuration using a Tweakable in the Editor, it should force CLS to rebuild and/or re-highlight the current vessel.

Workaround: add/remove a part.

The InflatableAirlock part from Making History expansion is configured with

CrewCapacity = 0

and accomplishes dynamic crew capacity through ModuleAnimateGeneric.CrewCapacity

	MODULE
	{
		name = ModuleAnimateGeneric
		CrewCapacity = 1
		animationName = AirlockDeploy
		actionGUIName = Toggle Airlock
		startEventGUIName = Open Airlock
		endEventGUIName = Close Airlock
		allowAnimationWhileShielded = False
	}

This does not fire OnVesselWasModified, so CLS is not notified of the change, and does not update (or, more precisely, mark dirty) the CLS state of the vessel, leading to incorrect behavior.

For instance, launch a simple craft consisting of only a pod + inflatable airlock (initially retracted).
Checking the CLS window shows that CLS detects a single living space, consisting of only the pod, since the inflatable airlock starts with no crew capacity.

Deploying the airlock does not update the CLS state:

Attempting to perform a crew transfer from the pod to the deployed airlock does not work:

I don't really have any good solution for this -- looked over GameEvents again and did not find anything that looks like KSP will fire upon changing crew capacity of a part, or for ModuleAnimateGeneric completing its animation.

Options to consider:

1. Lobby TT/Squad to fire OnVesselWasModified for crew capacity changes, or add a OnPartCrewCapacityChanged event -- this would be the ideal solution, but it's not something we can do on our own.

2. Try to do something with onPartActionUIDismiss, assuming that the part action menu button is the only means of deploying/retracting the airlock. This would be a terrible, convoluted kludge, if it even works. This wouldn't work if animation is toggled using action groups.

3. As a stopgap measure, add a button to the CLS window that will force a refresh the active vessel's CLS state.

The following part is missing from the "Freedom" alternative configuration.

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

The CLS config for HGR only includes one part. It needs to be reworked.

User Grokit from the forums provided the following patch:

@PART[Mk2Pod]:HAS[!MODULE[ModuleConnectedLivingSpace]]:NEEDS[ReStockPlus,SquadExpansion] { MODULE { name = ModuleConnectedLivingSpace passable = true impassablenodes = top } } @PART[landerCabinSmall]:HAS[!MODULE[ModuleConnectedLivingSpace]]:NEEDS[ReStockPlus] { MODULE { name = ModuleConnectedLivingSpace passable = true } }

CLSAddon currently keeps a CLSVessel representation of the active vessel, listens for vessel modifications, and update the CLSVessel (and fire onCLSVesselChange) as needed. None of this is currently possible for other vessels. The newly implemented (#82) getCLSVessel returns a snapshot of the requested vessel's CLS data, but does not hang on to a copy of it or keep it updated. This means that each time another mod uses getCLSVessel on the same vessel, its CLS state has to be recalculated from scratch, even if there would have been no change from previous invocation.

In more concrete terms, here is one example use case. In my mod AirlockPlus, when a player clicks on an airlock, I call getCLSVessel to fetch a the vessel's CLS data, in order to determine which kerbals in the vessel are able to reach that airlock (obeying CLS rules) and exit through it. Suppose the player realizes this wasn't the airlock they'd wanted to use, so they cancel out of this action (without board/alight any kerbals) and instead clicks on another airlock on the same vessel. AirlockPlus will call getCLSVessel again, but since no "cache" of the data exists, it must be recalculated.
I cannot safely "reuse" the CLS data from it's earlier call, since there is no guarantee that it hasn't changed in the meantime (e.g. the player might indeed have alighted a kerbal from the first airlock, and then wants to alight another kerbal from a different airlock).

To get around this, we'd need to separate the maintenance of vessel state from GUI and other functionality. CLSAddon currently contains a mix of code that does all of this.

• The keeping+updating of a vessel's CLS state (upon loading, modification, etc) can be moved into a VesselModule, that would be active for loaded (off rails) vessels.
• CLSAddon is then left handling only the GUI aspects, and serve as the CLS API "point of contact" for other mods.

This approach would also confers advantages to CLS itself. Currently, when the player switches between vessels, the CLS data is recalculated upon each vessel switch. This also leads to "unnecessary" recalculations, e.g. in situations where a player is operating several vessels in close proximity to one another and is using [ and ] to switch between them frequently. By moving vessel state maintenance out from CLSAddon into VesselModule for each vessel, CLSAddon would only need to modify its "active vessel" reference to point at the corresponding VesselModule on vessel switching. There is no need to trigger a recalculation, since the vessels' CLS states aren't actually changing.

I've got the beginnings of this already started, but will need help making sure I don't break any existing functionality + ensure recoupler support is preserved.

The new KIS system has two internal containers that don't have config files for them. I've put together the file for this. Allows the player to pass through the container.

file name CLSKIS.cfg. Just drop it into the plugin folder.

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


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

This NRE shows up in the log when USI's Karibou rover and its dependencies are loaded with the stock Squad folder, CLS and Rasterprop Monitor (nothing else, other than MM). All mods and dependencies were downloaded direct from their Github repositories so versions are latest as of today:

[EXC 22:56:32.575] NullReferenceException: Object reference not set to an instance of an object
  PartModuleList.Contains (Int32 classID)
  PartModuleList.Contains (System.String className)
  ConnectedLivingSpace.CLSAddon.AddModuleToParts ()
  UnityEngine.Debug:LogException(Exception)
  ConnectedLivingSpace.CLSAddon:AddModuleToParts()
  ConnectedLivingSpace.CLSAddon:Start()

output_log.txt

I've also just seen similar behavior with the USI Otter minisub

In stock KSP v1.1.3.1289 (gog/Windows version), CLS v1.2.3.0 (installed via CKAN) does not merge spaces upon docking and hatch opening, with every save (even new). In CLS v1.2.2.1 it works fine.
It can be reproduced by making a single craft from bottom to top like [Mk2 Lander Can] -> [Clamp-O-Tron Docking Port] -> [upside down Clamp-O-Tron Docking Port] ->[upside down Mk2 Lander Can].

Then decouple, and fly away a bit to re-engage docking ports

After redocking, and opening hatches

"but" and "and" are used the wrong way around. Examples:

Can't stay but can't pass.
Can't stay and can pass.
Can stay but can pass.
Can stay and can't pass.

I suspect this may related to chances in 1.1 related to CMAssignmentDialog.
Now that class is alive but it does nothing. The data is in KSP.UI.CrewAssignmentDialog instead.

@codepoet,

I've found a behavior I'd like to tweak.

highlighting is hit or miss when you mouse over parts highlighted by CLS. Crew Manifest currently exhibits this behavior as well. I had the exact same issue in Ship Manifest, early in development. I solved it using a delegate function attached to the affected part's mouse out event.

This allows proper mouse behavior until you leave the part, and reverts the part to your desired highlighting. Very clean. Just remove the delegate function when you hide the control window or change the space(s) selected.

Also, I'd like to be able to control the colors for part types. I'm thinking static properties would due nicely.

Thoughts?

The offending line is CLSAddon.cs#L526.

The forced order of the individual substrings that make up the entire sentence may prevent a correct translation in some languages if the target language grammar requires a different ordering of the words.

That line also forces punctuation characters for colon ":" and period "." which may not be appropriate for all languages. (e.g. zh-cn and ja terminate sentences with "。")

Ideally, ConnectedLivingSpace.cfg#L18-L20 should just be a single string:

#clsloc_014a = <color=orange>CLS has prevented the transfer of: <<1>>. <<2>> and <<3>> are not in the same living space.</color>

Upon placing a docking port against another docking port where both are set as passable the second port is not connecting the living space together, anything attached above it is not included. However, removing the second port and re-attaching it resolves the issue and anything attached above it now works OK.

WIth the update of KSP 1.4 to the Unity 2017 engine, ApplicationLauncher textures throw a warning in the KSP log and appear very blurry in the UI.

Research shows that in order for compression to work the image size needs to change. Original image size is 38x38 px for earlier versions of KSP.

Testing shows that if the image is resized to 128x128 px, the image quality is restored and the compression warning is removed.

Currently, it seems that the [mk2LanderCabin_v2] has impassable nodes on bottom, which makes some lander and station configurations unusable. I have attached two examples that I in fact built in game before realizing that I had created impassable living spaces.

Of course I've changed it since then, in my personal copy, but I can't be the only one looking to do this sort of construction.

I would suggest that either by default, or in the freedom config, the bottom node should be passable.

.

I added CLS to a stock 1.02 install and saw the multiple CLS buttons were added to the stock toolbar. When I installed the blizzy toolbar the behavior stopped even though the blizzy toolbar was not being use for CLS.
I had a look at the code, but I have forgotten how it all works!! Also I could not get it to build as it did not understand IButton - is there a missing update to the project file?

Although I connect a Mk1 Cockpit to a Mk1 Crew Cabin, I can't move kerbals from one to another, neither through stock transfer, nor through ShipManifest transfer...

Believe this is because the NetKAN file in https://github.com/KSP-CKAN/NetKAN uses a $kref to spacedock, and the spacedock file shows 1.3.0 as the latest version supported.

If you either override the version, or point it to GitHub and add a .version here, it should reappear for those using 1.3.1.

@PapaJoesSoup I'll be happy to submit a pull to add the version info here and one to CKAN to change the $kref

Is there any reason this won't work with 1.3.1?

Is this planned for an update