Korb Biakustra

Thanks for the details Codepoet. I updated CLS (thought it was up to date already, sorry) and it changed things, but I still have issues with connecting the living spaces. It seems it has to do with docking ports with hatch status on "Closed" but no button to open them. On some (most) other docking ports, the button is there and works. I have no idea why some of them don't work properly, they are all attached the same way. Screenshots uploading, I'll edit. [Edit] All right no need for screenshots, I just noticed your answer to Haifi in the release thread. I will try to decouple and then dock the nodes, but that will be tricky as my station is deprived of RCS thrusters. [Edit 2] That was the cause of the issue! The .cfg files were then correct. Ffeeww. Now I have to redock 3 large areas of my station with a robotic arm, makes kind of a good "Station mission". [Edit 3] Arg, the open/closed status of hatches does not persist in quicksaves, or do I have yet another issue?

Sorry for my super-extra-late reply Katateochi, I've been away and then forgot about your request. The problem was actually about git if I remember correctly. The error stated something like "OMG there is no git!", which was not true by the way (Jebretary used to work a few days ago). I updated Jebretary yesterday and it seems to have fixed the issue! Thanks for the automatic tab opening by the way. Two questions/ideas/requests: 1. Is it possible to minimize the two terminals to system tray to avoid overcrowding the task bar? 2. My most wanted one, though a tad bit off the main Jebretary purpose (but not entirely off-topic either): is it possible to synchronize screenshots? If so, what would be absolutely fantastic would be to (i) upload them with their default unique filename (default KSP behavior) into subfolders (inside the corresponding campaign's section) named based on the last .craft file synchronized (i.e., the currently active ship, which means current mission); (ii) provide a way to browse (and delete) them as thumbnails when clicking on the corresponding subfolder in the Jebretary interface; (iii) provide a way to export the URL for mission reports on forums or Reddit. For (iii), I suppose BBCODE and Markdown export templates could be taken from the several FOSS applications used to automate Imgur (or similar) uploads? Git quota is about 1 GB if I remember correctly, and individual screenshot size is quite acceptable in KSP. 1 GB should be plenty enough in most cases, but anyway a special key (not F1) could be used for triggering the "cloud screenshot" feature when the player does not want to upload everything. Point 2 is not about the save files or crafts, but definitely about keeping track of what is done inside each campaign, plus it would provide a way to actually see what a synchronized .craft file is about, which can be very handy when you start to have many crafts! Do that, and I will not only marry you Katateochi, but I will also bring cookies at our wedding.

Thanks for your answer. I have dozens of IACBMs on my station, and four of them won't change state when I "Open hatch" on them (two are 1.25 m, two are 2.5 m). All other IACBMs change state properly. The weird thing is that these "permanently closed" hatches seem not to prevent crew transfer (same living space for both sides of the coupled IACBMs), though I can only transfer crew through one pair because the other one is just next to a dead end (see the issue with CLS I described above). I have tried to close the hatch on an IACBM working correctly: it did divide the corresponding living space. Other contextual options like crossfeed, light and passive/active mode work correctly on these four IACBMs. Any idea on what is wrong with these? They are attached exactly like others. [Edit] OK, figured the "Open hatch" was a CLS feature, not a FusTek one. Sorry for the confusion. Reasons of the issue are explained here: http://forum.kerbalspaceprogram.com/threads/68617-WIP-Connected-Living-Space-API-for-connected-habs-%28new-download-16-2-14%29?p=1174079&viewfull=1#post1174079

Ha! I had only the .cfg files in my GameData\ConnectedLivingSpace\Plugins directory, I guess I had not extracted it, thinking I would never tinker with the .cfg files. Thanks for the swift answer Codepoet. [Edit] I have added "surfaceAttachmentsPassable = true" to both stackpoint1 and science_module, but the live spaces are still disconnected. I probably did something wrong.

Actually I was only thinking about the second solution (your priority), I had not even thought the first one would be possible/beneficial. If you have the second feature working, you don't really need the first one. Well, it might be useful sometimes, but it would definitely require a lot of sweat to be functional, for little benefits. [Edit] The mod was Telemachus if I remember correctly, not sure though, but it was most likely related to my bad connection.

Llorx, thanks for the continued updates! I've faced a problem yesterday with a mod trying to download, but stuck at 0%. There was no way to abort the stuck download, so I had to close LMM and then redownload ALL mods that were in queue for installation (a lot of them, since the download which failed was... My last mod to be updated!). When you are updating large mods, it can be a problem to be force to redownload everything. Additionally, I don't know if it is a widespread service, but I've seen a mod being uploaded onto a host website not yet supported: http://forum.kerbalspaceprogram.com/threads/65365-WIP-MSI-s-Infernal-Robotics-Model-Rework My most anticipated feature now: the options allowing to update mods despite custom files edited by the user, and keep those custom changes through updates. Can't wait!

I have an issue with transfering crew through some parts, described here: http://forum.kerbalspaceprogram.com/threads/62270-0-23-5-Ship-Manifest-%28Crew-Science-Resources%29-v0-23-5-3-2-3-11-May-14?p=1172064&viewfull=1#post1172064 It seems the issue is actually between the Science Jr. and the Radial attachment point, because it is radially attached. They seem not to be connected, surely because of the *radial* attachment: Any ideas on how to make a MM patch that would allow Radial attachment points to actually "connect" living spaces? I know radially-connected parts are not supposed to be really connected from a CLS perspective, but that would be what the BZ-52 radial attachment point part would be for, I guess.

Follow-up about crew transfer through unconventional parts Here is my station: You can see in the back, in red, the ALCOR pod with two Kerbals in it. I want to transfer one of them in the Soyuz orbital module in the front, in blue. It won't work despite the MM patches I *tried* to make for the corresponding parts in the way to the Soyuz (I may have done it wrong). The blue Soyuz module is connected to two coupled Soyuz docking ports (cyan), a Fustek module (green), two Fustek docking ports (yellow), a radial stack point (yellow) attached to a Science Jr. module (yellow), being itself attached to Fustek docking ports (cyan) onto a Fustek module (yellow) where Kerbals do pass successfully. The issue is therefore somewhere between the Soyuz and the Science Jr. module. It means that 4 different parts may cause the issue, and be unpassable: Soyuz Orbital module, Soyuz Docking ports, radial stack point, Science Jr. I consequently created "CLSSovietPack.cfg" in \Kerbal Space Program\GameData\ConnectedLivingSpace\Plugins, and edited CLSStock.cfg. They contain the following patches for the corresponding parts: Soviet Pack, for the Soyuz TMA parts (and regular Soyuz parts, but none on this station): @PART[Soyuz?Docking?mechanism]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Soyuz?Descent?Module]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Soyuz?Orbital?module]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Soyuz?TMA?Docking?mechanism]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Soyuz?TMA?Descent?Module]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[Soyuz?TMA?Orbital?module]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } Additional stock parts: @PART[stackPoint1]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true passableWhenSurfaceAttached = true } } @PART[science_module]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true passableWhenSurfaceAttached = true } } I think there are no other occurrences of these parts in any of the other CLS .cfg files. I am absolutely sure I am doing something wrong, but if anybody has any ideas, please let me know! P.S. I know it is kind of dumb to use a Science Jr. to transfer crew, but I needed a part to make the 90° angle in a small form factor, and found nothing better than this module + a radial stack point. [Edit] Some progress on the actual cause of the issue thanks to two folks on the IRC channel. It seems to be all about CLS and not Ship Manifest, so I posted it in the corresponding thread.

Awesome, thank you. That even made a pretty good and motivating EVA mission! Sumghai, about the CLS and crew transfers: the latest FusTek version fixed the issue with transfering from the Legacy Airlock. Sorry for the inconvenience. I still have problems transfering crew among parts of my station, but that involves non-FusTek modules so I'll ask in the dedicated threads.

Alright, I finally got it after a bit of fiddling! There are a couple modules where I can't transfer crew though. For instance Bob entered the Legacy Airlock after EVA and can't go in a connected FusTek module (the Legacy Airlock is connected to it with two IACBM). I will make a screenshot later today, I am stuck with 800x600 on this computer, you would not see anything in that resolution. Is there a way to change the texture on a ship already in space, by editing the .sfs file? My station has the default texture and I'd like to try out the KSO one, which feels a bit less Science Fiction-ish. By the way, I think it was reported in the WIP thread, but have you noticed that textures are not updated for every hatch on a part? Same with the Legacy Airlock ("roof" part of the widest half, sorry, I don't know how that part is called in English ).

Thanks Sumghai. So was the May update a save breaking update, if the names of parts have changed? Would you have a list of the changes so that I can try to edit the save files? In the save files, I should Ctrl+H every occurrence of "Karmony*" or "Kuest*", right? And new names are in the "name" field of every .cfg file in FusTek\Station Parts\Parts, right? It looks like all parts have had "FusTek" added to their names ([Edit] among other things).

Oh God, I did install the KSO textures, relaunched the game and everything was working. I saw your message so I quit without saving, removed the whole Fustek folder, reinstalled only the main Fustek mod (which was the April dev version), rebooted KSP... And now my space station that took me 15 days to build won't load, because "parts are missing" (but they are here in the VAB). I tried quickloading a quicksave made before I messed up with the mods, and it brought me where the station was supposed to be, but everything was empty and the map view started to show bugged orbits. I relaunched KSP again just to make sure. No station anymore, and no quicksave to load. :[ I guess I will have to build the station in the VAB and Hyperedit it to orbit. :'( I cannot load my craft files anymore. :/ If you have any ideas, I'm listening! No screenshot yet then, it's 3:40 AM here sorry!

Thanks a lot! [Edit] Seems it doesn't work.

It seems that compact nodes do now allow crew transfer using CLS/Ship Manifest. Is it on purpose? My whole space station is built around compact nodes. I think I know how to enable crew transfer through this part, but I'm curious about whether this is a deliberate choice, and if not, then maybe it will be fixed. The problem might be in CLS rather than Fustek though, as I see in this thread that nodes are supposed to allow crew transfer. Where are these Fustek textures from? [Edit] Found it here!

It is unclear to me whether Soyuz docking ports from the Soviet Pack allow transfer with CLS/Ship Manifest. I just reached the space station I built after several days of labor, and couldn't transfer my crew into the modules. Had to do it via EVA to transfer them before TAC supplies in the Soyuz were fully depleted. If I create a CLSSovietPack.cfg in the CLS folder, is the following content correct? @PART[Soyuz Docking mechanism]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } Thanks in advance!

I am really interested in the soviet pack parts, can someone confirm me they are relatively balanced compared to their stock counterparts? I would like to avoid something overpowered, even slightly. Thanks in advance! Does the Soyuz docking port work with the stock ones? I bet it won't, but it is worth asking.

This is the main limitation of this dirty workaround based on thread edit date: it warns you when the mod creator has put something new, but it's not necessarily the mod. Either you check it using the "Browse" option, or you redownload anyway if that is not big a deal for your connection (and if the mod installation is easy, i.e., no custom files).I don't see any way to filter only mod updates from forum URLs, perhaps Llorx does. Perhaps combine forum recognition and domain recognition for the URLs inside the FP, to check if there is an new edition, and if so, go through the links inside the FP and check them if they belong to a supported domain (Github, etc.)? In some lengthy FP, it may involve checking many URLs which may be problematic. Or keep track of last URL that was used inside a thread? LLM already offers selecting one of the several links found in a thread, and keeping that URL for later updates; but then I believe it kind of overwrites the forum URL instead of just hierarchizing them, right? Anyway I find it useful that it actually monitors the threads' FP even when there are no mod updates, but that may totally be just me. Anyway when you initiate the download process but abort it, LMM will remove the mod from the mod list, considering the URL you entered is likely invalid or you cancelled because you changed your mind about this mod. I think this should not be the default behaviour, already discussed it with Llorx in this thread or the earlier one in WIP section, but I do not remember exactly what he will do for that.

Great, thanks!

In want to install some TAC ressources on my space station, as well as recyclers. Ressource tanks will deplete over time and I will therefore design them so that they are easy to remove and deorbit. But can someone tell me if the recyclers will also have to be changed (due to accumulating waste) or if they can stay permanently once installed (for instance by emptying accumulate wastes in space or in the empty tanks)? It will determine the way I build the supply module.

Thanks for the detailed answer Katateochi (and the patch)! I do understand the potential limitations, though those features would really be terific. Mirroring crafts and subassemblies is a great idea. Maybe the synchronization among different machines could just require user confirmation and offer to take the last modified file as a reference? It would not do miracles when an user has modified two save files without Internet connection on two different machines, but it will still synchronize the two computers most of the time based on the up-to-date save file on the cloud. A warning should tell the user not to load the same save from two different machines connected to the Internet and to Jebretary simultaneously, but that would be a weird behaviour anyway. I got trouble using Jebretary the last few days. For some reason, it didn't successfully store my quicksave or persistent saves, although I did change them by playing during the week-end. Jebretary was running, but couldn't go further than the red message stating something like "Wait till I commit your quicksave..." Crafts were not stored anymore either. I have tried restarting Jebretary, or even reinstalling and reconfiguring the associated KSP instance, but nothing worked. I don't know if it is related, but only one of the two terminals stayed open, the other one always closed after a few seconds. I just got back from work and launched Jebretary again, it apparently successfully updated the quicksave this time, but you can see that there was a gap of several days just before that. Liquid.exe closed by itself again after a few seconds. KSP is not running yet.

Thanks for the reply! Yeah I don't complain at all about Fustek folder size! It's just Firespitter that is about 39 MB, and I wanted to make sure I only need the dll. After removing the parts, it's perfect, no worries.

Thanks for your answers. Sharpspoonful, what do you mean by "LLL"? I have another question about Firespitter dependency: this mod is quite large due to the parts, and I'm running short on RAM. Can you tell me what exact files I need to keep to maintain Fustek's dependencies? I guess it's only Plugins and PluginData folders?

Thanks for your quick answer! I found a trick to achieve what I wanted using some SelectRoot wizardry! I'm still wondering about the docking ports, whether I should use the Berthing only between Fustek parts, or if I can use them also for any of my ships.

I can't seem to attach nodes, either compact or regular, using their side attachments. They apparently have to be attached with the longitudinal attachments, and then side ones will start working for attaching extra stuff on the nodes, but not for attaching the nodes on something pre-existent. Is there a workaround? I need to keep the 2.5 m attachments free. Apart from that, do you guys use to put pods on your stations to monitor stuff (not necessarily for navigation, my station will not be symetric anyway), or eventually rotate? In the past I think Fustek parts were considered command pods, but not now so I guess I will lose control of the station if I don't put a pod on it. And last question: I am not sure I understand correctly the difference between stock docks and berthing docks: the latter allow for crew to pass threw it, right? Can I start using them on every ship or are there any significant drawbacks?

Hey, just wondering: is it possible to use Jebretary to configure synchronization among different installation folders and computers? Typically, I have KSP installed on my desktop computer and my laptop, the latter being used at work (well, not for KSP ) or during travel, train trips, and so on. Keeping sync between the saves, ships and mods of both installations is really a hassle. If Jebetrary could identify the git "identity", the computer-name, and recognize "Campaign" names, it could offer an option to synchronize the campaigns of both computers (or KSP instance on different computers, to be exact) based on git (shared) history. A complementary and extremely useful feature would be "GameData" synchronization. Seriously, this would be epic. Perhaps there are not so much users using different computers to play KSP, but for them, it would be terrific. That may be a bit too far for now, but one could even imagine synchronizing GameData folders among a couple of friends, or perhaps KMP/DMP players of given servers. Does that sound useful to you? Doable? Insane? Better to do it using individual Github/Bitbucket accounts and scripts without Jebretary?