Fendrin

Hello space travelers, to satisfy the TAC Live support needs for the Kerbonauts on their Mün base, mission control took a look at the hardware K&K offers. So far the Kerbals in charge are rather impressed with the product palette offered but there is a question left regarding power management. During Mün's daytime the Electron can split water into its contents to store energy in a more compact way than it could be done with accumulators. But K&K's fuel cell operates only with liquid fuel and oxidizer with no way to switch to hydrogen and oxygen for the process. It is possible to use a fuel cell from several other vendors thus the solution is still in consideration. Still the question lingers, why isn't K&K offering a closed cycle without the need for foreign parts? Are the brains at mission control missing something?

Yes. Well, the installation is about 5 years old. Maybe it's time for a fresh installation.

Yes. I tried everything mentioned there. Using mozroots and removed the X3 certificate. I tried with the mono that came with the distribution and with both, stable and dev packages from the Mono project's PPA.

It happens for every mod which is only available from SpaceDock (otherwise CKAN falls back to an alternative host). Sadly those are a lot of the over 100 mods I use...

HebaruSan, thank you for the response. Here is the output of CKAN executed on the CLI: fabi@sepia:~$ ckan install UniversalStorage2 About to install: * Universal Storage II Finalized 4.0.0.4 (spacedock.info, 104,7 MiB) Continue? [Y/n] Downloading "https://spacedock.info/mod/2960/Universal%20Storage%20II%20Finalized/download/4.0.0.4" One or more downloads were unsuccessful: Error downloading UniversalStorage2 4.0.0.4: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED at /build/mono-6.12.0.147/external/boringssl/ssl/handshake_client.c:1132 What else can I provide? Many thanks in advance.

Hello. I am suffering from the https://github.com/KSP-CKAN/CKAN/wiki/SSL-certificate-errors problem ever since the upgrade from Ubuntu 21.04 to 21.10. None of the solutions found at the mentioned github page does any good regarding the issue. Without CKAN mod handling is just to ugly for my taste. Please help me restore its functionality.

I like to discuss the balancing issues I have regarding the SpaceDocks, although this is also true for possible other parts using ShipYard or depending on different build mechanisms. The biggest problem I have is to balance against Extraplanetary Launchpad hardware. Let's have a look at what ground based infrastructure is worth in the stock game. The player needs to upgrade the VAB twice for unlimited part support: 225,000+ 845,000 = 1,070,000 ==> unlimited part support Same for the Launchpad at the KSC: 75,000+ 282,000 = 357,000==> unlimited mass and dimensions Makes a total sum of 1,427,000for the VAB/Launchpad and the same amount again for SPH/Runway. So unlimited vessel building capability on Kerbin is not cheaper than 2,854,000. This is of course not entirely true, the physical conditions at the KSC will still limit a vessel in size and mass. The amount of money the player spends using EL to build in orbit: USI's UKS Orbital Shipyard costs 84,000and weights 10.28t. This part comes with 4 seats and "Productivity Factor: 2", good enough to build vessels in a reasonable time. There is no part, weight or dimension limit featured by EL (afaik). So how expensive/heavy/whatever must SpaceDocks be to be balanced with EL in mind? In order to build entire new vessels from resources only, a ShipYard needs OSEWorkshop hardware, enough KIS-Container space and some crafting tools. The only point of launching a larger ShipYard/SpaceDock is its ability to process larger vessels than the smaller version. Even the largest SpaceDock will not be able to process vessels (in one piece, without docking) which don't fit inside. Thus the MegaDock's total cost (including OSEW + KIS + Tool parts) still need to be less than the 84,000 the unlimited build capability offering USI part costs. The OSEW's "3D Printing Lab" costs 75,000. Leaving 9,000for containers + dock + tools. I have already asked in the EL thread about size limits but got no answer. An early post on the thread mentions that EL is supposed to balance the lack of limits with the costs of the resources. I had only a quick look and compared the building costs between OSEW and EL only roughly, still I think they are not that far away from each other, leaving me completely helpless.

Development Thread for the SpaceDock mod SpaceDock is a mod providing parts meant to be used with the ShipYard plugin. Revision Control Release Thread

@Shadriss, my first impression was those modules would have to be moved in place by the player using some sort of vessel or kerbals on EVA. @steedcrugeon explained me that the structures connecting with the dock are not yet defined, haven't asked him about details I suspect them to use similar mechanics to what we have seen on the dock before this one.

The modified KIS.dll is still linked in the OP. I would be glad to hear about how it does.

Okay, so the last "B" version fixes most of my concerns. Put some attach nodes on top of the T-Beams and used a scaled version of the KIS "SM-62 Container Mount" for attaching the storage: The container mount is pretty useful gameplay wise since it allows uncoupling/coupling the cargo easily. It pretty much looks like being made for fitting onto the T-Beam although not being exactly designed for the containers. Regarding the new light panels, I wonder if I shall put attach nodes on top of them. Maybe they should move a bit more away from the T-Beam to allow attaching the smaller sized containers in 2 rows? I am going to experiment and will show screenshots if they lead somewhere. The telescope pipe situation is far better than before. Although the collapsed state is still only about half the size it needs to house all the pipes we see in deployed state. Assuming I get it right how telescope pipes work. I know you want to make the collapsed state as compact as possible but I wouldn't do that on cost of plausibility. The dock is still quite long, so you can safe some space by reducing the length a bit. I am also still obsessed with making it a bit more stable. But I can't put my thoughts into words well enough, will think some more.

Hello, I have made some small modifications to KIS which allows me to attach the ModuleKISPickup on regular parts. The new feature is used by the SpaceDock mod linked in my signature. I do not dare to submit a pull request at github before I don't have some feedback if the modification causes troubles. Thus please give me some feedback.

Yes, because it works with directly connected tool arms instead of using the PAL Truss. A ShipYard needs a lot of them since the KISPickup will move to the tools in future releases. Sounds like a nice addition. The SpaceDock/ShipYard vessel itself could make use of some more konstruction tools. Currently (in my local repository) the PAL Clamp is used for both, attaching and moving parts. It does not make sense for it to have the attaching/detaching capability. Thus I like to request another part from you. Can you take the arm from the PAL Clamp and replace the clamp with some screwdriver tool? One that looks like it can detach parts? This is the one you showed animation for first? Okay, I will rewrite ShipYard to support multipart SpaceDocks.

Okay, I must say, I really like this design a lot. The last post sounds a bit harsh, so let me say, the part is already quite nice and the animation is amazing. This is a step by step list of what I would do to finish the part. It is ordered by severity. The Truss Let's start with the biggest problem first, the Truss. It is flawed in so many different ways, let's just get rid of it. Removing it and its arm solves 2.3 completely and the biggest part of 3.2. The Telescope Pipe I would go for 4 sections. Meaning the Dock is still 1/4 of length in that dimension when folded. More might make the pipe a bit thin. The extra size is fine, the dock will still be compact enough for a launch. There is now also more room to make it look more stable. Solving 3.1 Storage Node Attaching the truss at the top of the T-beams with a brace to avoid the container-T-beam-intersection. Some more lights attached at the bottom of the truss. Solves 1.3 and 2.1 The dimension The double beam connecting the T-beams with the center is larger than the double beam connecting the center with the telescope pipes. I would use the current T-beam-connector for both. Then every part of the Light-Construction-Arm stretched a bit longer. Solving 2.2 Stability coming soon

Let's work out what still needs to be done. Legend Cool Fine as is Okay There is room for improvement but no show stopper Halfway done Makes me cry This really needs to be done Dislike Would be cool to get fixed Checklist Nodes Assembly One with room for the middle sized docking port, fine. Konstruction Assuming you agree it is fine to attach the tools like shown lately? Storage The pictures show surface attached containers. There is currently no place to put a node without having the container clip into the T-Beam. Station The top node's surface is a bit large If the dock is meant as an early entry, being more at the left of the tech-tree. Not much parts fitting there are available at that time. Game-play Light Only from below. Better than nothing... Dimensions 8m x 8.6m x 21.2m Vessels build in orbit most of the time don't need to feature an aerodynamic design. Thus the long but narrow rocket shaped one is suboptimal. Mechanics Tools can reach the construct Yes, but the need to navigate around the truss Tools can reach the container Yes, but they need to navigate around the truss Tools can transport parts from container to the construct No, blocked by the truss Well, that is not entirely true, let's say the truss only makes it necessary to pass the part from claw to claw around half the vessel. Immersion Deploying The vanishing telescope pipe looks really fake and cheated. It reminds me about the fact that I am playing a game. That is pretty setup specific. In a high fantasy setup with pretty much hammerspace everywhere such a transformation would be fine. Stability A single part can only have a single set of values describing how it behaves when stressed. Mixing structures which look quite durable with very fragile looking ones is a configuration problem. Shall the whole Dock break at a value that seems to be suited for the truss? Or better take the value suiting the telescope pipes (Which still do look quite fragile)? Or take values suiting the very stable looking T-Beam? Or the center? Most parts have to make some compromise regarding this issue, but usually you break a part into several pieces to solve the issue when it is extreme like in this case. edit: I have already some proposals in mind, give me some more minutes to find words for them.