bobvodka

OK, so it took me a bit longer than I wanted to get back to this but I've managed to reproduce it with only the following mods installed; Module Manager : 3.1.2 Connected Living Spaces : 1.2.6.2 (latest on CKan anyway, only compatible to 1.4.99) Universal Storage 2 : 1.5.1.7 Community Resource Pack : 1.0.0.0 KSP version 1.5.1.2335 Lashed together a quick 'station core' (docking port, 2.5 meter command pod, science lab, 8 core double height US2 wedge, 2.5 double height fairing, 2.5 meter command pod, docking port) which CLS was happy with being one 'space'. Saved it. Made it a sub-assembly. Left, VAB, reentered, built a quick command module + engine + decouple setup, shoved a docking port on the bottom; dragged the sub-assembly in and bam! Disconnected at the same place. Looking at the two files the problem is the same as before; // Working link = USCylindricalShroud250_4294427370 attN = StackNodeUpper,Large.Crewed.Lab_4294507316_0|0.612|0 attN = StackNodeCentral,USCylindricalShroud250_4294427370_0|-0.2040291|0 // Not working link = USCylindricalShroud250_4294427370 attN = StackNodeUpper,Large.Crewed.Lab_4294507316_0|0.612|0 The two craft files in question can be found here; https://gist.github.com/bobvodka/acba0753f82f0f12634d13ca27d259bb With the 'Lifter Start.craft' being the broken one, with the 'Station Core.craft' having been merged in to it. Hope that is all some help

I've hit upon an interesting little problem with US2.0 and Connected Living Spaces and I figure this is a good place to start with the whole 'trying to track down what is going on'. I've got to the point on my most recent play through where I'm putting together the first space station; dead centre of that station is a "Universal Storage: Eight bay service core (2.5m)" which is enclosed by a "Universal Storage: Cylindrical fairing (2.5m)" - above and below that are other parts and everything was either CLS passable or inhabitable. At this point CLS showed everything as one living space and all was good I saved it as a craft and as a sub-assembly and got on with building the launcher. I pulled the subassembly in and, to my surprise, suddenly my station core was two separate living spaces. I swore. I dissembled things and put them back together. Triple checked that the original craft, saved it and pull it back in with nothing going. The living space was always being split at joint/node where the service core and fairing where connecting. So, being programmer myself I the next logical thing and pulled the source for CLS to see about turning some logging on to see what was going on. Checking between the two craft I saw this, as expected; Craft that is ok; [LOG 21:20:45.980] [CLS]: Processing part: USCylindricalShroud250 Navigable: True Habitable: False [LOG 21:20:45.980] [CLS]: Considering the connection between Universal Storage: Cylindrical fairing (2.5m) (266598497) and Universal Storage: Eight bay service core (2.5m) (780669135) [LOG 21:20:45.980] [CLS]: the attachment on 'this' part is defined by attachment node InnerNode and had been given passable=True [LOG 21:20:45.980] [CLS]: the attachment on the child part is defined by attachment node StackNodeCentral and had been given passable=True Craft that is broken; [LOG 21:22:36.332] [CLS]: Considering the connection between Universal Storage: Cylindrical fairing (2.5m) (1659521487) and Universal Storage: Eight bay service core (2.5m) (2974851233) [LOG 21:22:36.332] [CLS]: the attachment on 'this' part is defined by attachment node InnerNode and had been given passable=True [LOG 21:22:36.332] [CLS]: The two parts are NOT considered to be docked together - concluding that the child part is suface attached OK, odd... So next step was the craft files themselves, which I can provide the whole file as required, but the import bits are as follows; Working; In fairing config; { link = USOctocore_4290949664 attN = OuterNode,USACDLarge_4291638566_0|-0.2|0 attN = InnerNode,USOctocore_4290949664_0|-0.05|0 } In service bay; { link = USKASWedge_4290889578 link = USFoodWedge_4290858034 link = USFoodWedge_4290854338 link = USHydrazineWedge_4290765240 link = USHydrazineWedge_4290760976 link = USBatteryWedge_4289834228 link = USBatteryWedge_4289830658 link = USGuidanceComputer_4291802408 link = sspx-core-25-1_4291909982 attN = StackNodeUpper,sspx-core-25-1_4291909982_0|0.612|0 attN = StackNodeCentral,USCylindricalShroud250_4290738858_0|-0.2040291|0 } Broken; In the not working case the service bay/core is missing the attN that points back to the fairing which would explain why CLS can't find the link. At which point I'm stumped; I don't know enough about KSP modding to see what else I can do to track things down, or even if your code controls that serialisation in any way? Unfortunately between now and Monday I'm not about so don't have the time to try with a more stripped down/lower mod count build just to double check it isn't something else causing oddness, although my gut tells me it probably isn't and could well be a strange KSP bug if you guys don't control part serialisation at all.

Those dlls are plugins that A.S.S uses to communicate with the mods in question - so the DMagic one allows A.S.S to talk to Dmagic experiments and is the thing I recompiled previously. It isn't the dmagic, or indeed Station Science, mods themselves.

1. No post. Done via PM. (Mod PM'd me, I replied, I PM'd ST, ST replied, I made post with next version stating ST is OK with it). 2. Frankly; no. I have better things to do with my life than muck about on GitHub to make a complete unchanged copy of the source code. If you want to check, go grab it from the same place I did. If that is a problem, then pull the links... I only put them up because it was close to zero effort for me (I need the mod for me, to give to the community I had to copy to my OneDrive and make a link) - anything over and above that isn't effort I'm prepared to put in because its the very definition of pointless BS... hell, the fact I'm having to make these posts has already got me regretting the whole damn thing, I might not even both carrying on now because I could do without the extra hassle. Consider this my last post on the issue unless a mod wants to get involved.

As noted SpaceTiger is ok with this so *shrugs* As to 'release the source code' - its the source code of the repro on GitHub page for the project... What do you want me to do? Fork it and point people at it? (and, fyi, I really won't be doing that, far far too much bother for something I did initially to fix my copy of the game..) More to the point how do you expect to know if the dll provided matches the source code provided? Release of source code proves nothing about the binaries after all... (Not that it would matter because the source is literally the same as the source on SpaceTiger's GitHub account as that is where I cloned it from...) End of the day if the mods or the author have a problem with this then I invite them to remove the links, its really no skin off my nose, I've got a working game after all... *shrugs*

With DMagic 1.3.2 comes a new DLL to make this work again Download Same as before, provided as is, no support etc - should work ok as I've tested it quickly. It should also go without saying, but I'll add it anyway, that the mod author won't be supporting this; while SpaceTiger is ok with my doing this until they have time to dedicate to the mod again this is in no way official, just a bit of help to keep things ticking over

Nothing jumps out at me in the logs and I've not seen the problem myself so.... *shrugs* I've literally recompiled the mod to fix the dynamic linking issue and check to see if it works - beyond that any support is down to the mod maker I'm afraid.

With the 1.1.3 update and DMagic's update to 1.3.1 the above DLL doesn't work any more... so there is now a new one : Download I'll leave the old one up for legacy reasons in case people need it I've run a quick test and it seems to work ok, but previous warnings apply - and as before, this is just a stand in for now until a real update appears

OK, so I've had this fixed locally for some time, as it really is just a case of recompiling one DLL. I didn't want to release/link anything because I didn't want to step on the OPs toes, however as they haven't gotten around to this for some time now this is a link to the version I'm using in my KSP install right now - Dmagic Science Sampler DLL plugin Just drop it in \GameData\KerboKatz\AutomatedScienceSampler\Plugins to replace the dll that is there already (backup, just in case...) and you should be good to go. (No new features, abilities, or whatever, I just took the recent code from GitHub and recompiled it locally as is - should work fine and cause no problems, but this is very much on your own head be it if something does go wrong )

Yes, there is a degree of set limiting which occurs in the Unity GC which has had a positive effect on GC time however collection cycles are still pretty heavy and noticeably so in some cases. (I happen to work at Unity (opinions my own etc) and recently spent a bit of time in the GC related code looking in to an overhead issue reported by another customer... it's a bit of a confusing rats nest at times.) You can't put a GC on it's own thread; at least with not any real degree of sanity. The GC has to be able to Stop The World for at least the thread in question; trying to run the GC code would involve that thread stopping another and then going over it's memory details. The thread is still stalled (at least; you might still end up stalling the whole system if someone else tries to do something which has any impact on the memory of the thread being GC'd), but now you are burning another thread doing the work. The "best" way to do it would be to pause all the threads and have each thread/core chew on it's own set of memory before coordinating at a global level for aliveness, which might still only gain you a small amount back depending on how the work is split. Ultimately this wouldn't help here however; most of Unity's work is done on a single thread - yes, Physics is threads, graphics has some threading options and there is a task based job system which is getting increasing amounts of work, but the scripting/C# side of things lives in a single thread and from there most of the memory will be allocated and thus tracked. Ultimately the solution is "don't make garbage" - mods might well be Doing Things Wrong, but there is a chance that both them and Squad have just hit code paths which can't do non-allocating ways of doing things which is what is causing the memory to be allocated.

No, I seem to have this problem too - I was going to sort out logs to reproduce it but didn't have time Wednesday night and currently not at home so can't look in to doing so.

wow... dude, chill... I was just mentioning it in case you had an oversight and forgot to bump the compatible version number or something as it was showing a new version available on CKAN compared to what I have installed...

On CKAN, while Contracts Window is updated to 1.1.2 the progress parser and contract parser are both only showing as 1.1.0 which means it won't let me upgrade them, thus breaking the mods (Currently have version 3.0 and 2.0 of the mods install; CKAN shows 4.0 and 3.0 are available.) The same problem impacts Capcom btw.

Well, with over 100 mods installs the log file was a bit too large for pastebin thus I had to trim the first one I posted down - the one before this was pretty much case of 'no time, inform of problem, revisit later if not enough details'; I work as a programmer so I know how annoying a lack of details can be, but at the same time I'm pretty sure I can spot unrelated stuff too, and if in doubt I'd leave it in And yes; this was all on the launch pad for me. Although playing yesterday with a fully modded install I noticed some problems collecting data during the rest of the flight (materials and goo were getting data, but failing to transfer and register in the command pod or MK1-85 backseat from the MOLE plugin, but the science was also missing from the experiments as it was being reset due to my flight crew being a pilot and scientist) - no logs for it atm, might be related to problems above so I'll wait for an update and retest.

Yeah, the moving of the files around was just the OCD monkey in me