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

Sure, no problem - I would have done it then but I was a little short on time and couldn't trim like I did before (I had a lot of mods installed so a lot of noise...) - however, fortunately, another mod broke things so I had to restart my install from zero so I figured it would be a good time to do a minimal reproduction of this problem Anyway, the full log can be found here - http://pastebin.com/qMvFby6v What I did; Start a new game giving myself 500 science and 500,000 credits Upgraded VAB and unlocked the science nodes required to get the experiments I needed Build a probes which had One probe core (stock, first level) 3 Universal Storage quad adapters stacked below it 4 Uni. Storage Goo Experiments 8 Uni. Storage Sci. Jr. 2 Mag. Boom experiments 4 stock temperature experiments 6 batteries 4 legs 1 truss (batteries, legs and temp. experiments on it) Launched probe Setup Automated Science Sampler (ticked everything apart from 'debug') Enabled science collection Temperature collected as expected 5 Sci. Jr. collected 4 Goo collected Adjusted science cut off down to 0.01 and 1 Mag. Boom collected - it only has a science level of 1.5 so threshold is a bit high by default for that Recovered vessel Relaunched same vessel from KSC directly Same experiments as before ran (both in terms of numbers and positioning of those experiments) but all reported back zero science Quit KSP via alt+F4 Reloaded KSP and save once I realised I didn't have logging enabled on this mod (so this is where the pasted log kicks in) Selected 'fly' for probe already on launch pad from alt-f4 quit Same experiments fired again Enabled debug output on mod Reverted to launch Same experiments fired again Alt-F4 quit Hope that helps

Hey, so just a heads up - I installed this yesterday and noticed that it broke a few things If I build a simple start of game pod + SRB and tried to launch it then I ended up with no portrait in the bottom right and the pod replaced by a (seemingly random) internal view on the launch pad (although the pod model was still there under it). I got the mod via CKAN and, looking in to it, it seems that you've got your own copies of Firespitter and RasterPropMonitor in there (along with an interesting file structure as it seems to start at GameData and then include the mods below it + ships) which is causing things to break as it is conflicting with another install of RasterPropMonitor I've got installed via CKAN;I'm getting exceptions in the kerbal logs when starting up. If I remove your versions and move the folder structure around so that the mod is in the 'right' place then everything works fine. I've confirmed its not another mod as I nuked my KSP install and built the mods up one by one before stripping back to confirm it was yours - at which point I looked in to the CKAN install and found the problems

After 1.0.4 was released things have improved greatly so thanks for that There is still something I've noticed; it doesn't seem to be playing completely nicely with DMagic/Universal Storage versions of stock experiments. I tend to do much of my science to start with via probes, previously I could use say a Universe Storage Quad Core with 4 Material science bays attached (thanks to DMagic's mod) and it would only run the experiments which would generate new science above the threshold. (So, 1 on the launch pad, one while flying, one flying high and one in orbit). What I saw earlier was, on the launch pad, all four bays opening and doing the science instead of just the one as expected. Interestingly if I retrieved the vessel and then launched it again it would do the same thing but the experiments, when I looked at them, had zero worth of science in them. A quick look in the logs, after the relaunch shows this; http://pastebin.com/uWQ1dpEa It seems like it thinks it gets some science (start of the log), then the ship is unpacked (line 101), and it then says 'oh, science is below threshold so not deploying' (although it has been deployed, as I can see the hatches open and can review the science which shows 0.0 for Mat. Science, Goo and Mag. Boom), then fails to reset due to a lack of scientist (which it repeats over and over at this point.) IMO, the final lack of reset is a bug; the experiment hasn't been transferred after all and stock KSP lets you reset those experiments as long as you've not broadcast them.

I've grabbed the latest version from Curse (as CKAN might be a tad behind) and while science is now being collected I'm having issues with experiment resets still http://pastebin.com/Bkh9XpL3 - a slightly abridged version of the log (mostly removed anything which wasn't related to this mod; left game flow intact as well as mod list towards top so you can see what else I have installed) Steps were; Start new game Build vessel with a command pod and one goo canister attached Change to Bob for pilot Launch craft Goo collects and transfers to pod (yay!) Goo fails to reset Goo can on longer be interacted with via right click Go EVA Collect EVA report with Bob Go back in to pod and EVA data is transferred (yay!) Go EVA again and reset Goo by hand Re-enter Pod Turn off 'reset' Reset threshold for science to 0.01 Science collected (and discarded as option enabled due to duplicate) Turn on 'reset' again Goo does not reset Hopefully that'll be enough to repro it/figure out what is going on

Just a small update on the above; having picked up the new install last night this seems to be fixed... the mag. boom now deploys sanely and science is collected - I'll double check later tonight just to make sure I'm not going crazy

Hey guys, first post and all that Anyway, just wanted to share a quick note for 1.1 testers out there - it seems that the unofficial ForScienceContinued and DMagic1.1 update currently don't get on that well; when trying to run a DMagic experiment with some animations to deploy it seems to get stuck in a loop. (For example the mag. boom slides out and in (or snaps back, I forget which) constantly blocking any more science obtaining.) [LOG 21:28:06.022] [ForScienceContinued] Deploying: magScan@KerbinSrfSplashed Science: 2 [EXC 21:28:06.023] NullReferenceException: Object reference not set to an instance of an object KerboKatz.ForScienceContinued.createScienceDMagic (.ModuleScienceExperiment currentExperiment, .ScienceSubject currentScienceSubject, Single currentScienceValue) KerboKatz.ForScienceContinued.RunScience () KerboKatz.ForScienceContinued.FixedUpdate () That looks like the problem area unfortunately As the fix is unofficial and things are still in beta it is, of course, no big deal just thought I'd give people a heads up (I'd take a shot at trying to fix it, as I'm a game coder by trade, but I figure with new and better things coming I can live with it for now ) Looking forward to see what awesome stuff you've got planned SpaceTiger