DanHeidel

Awesome! I probably won't have a ton of time in the next week or two but I'll start working my way through those.

Sorry for the slow response, got crazy busy these last few days. So, I'd be limited to pretty basic help. I last took a stab at modding almost a year ago. I wasn't ever able to get past the Unity install. Though at the time I was able to get Unity 5 running on Linux, just not the version KSP was using at the time. I got familiarized with Blender and felt reasonably comfortable with the work up to the point it gets pushed into Unity. I'd be happy to help, I might need a bit of help getting up to speed to be of much value, though. Is there a decent place to go to these days to get up to speed on modding? Last time I did it, a lot of the tutorials and links were really outdated and obsolete. In particular, I was never able to get a handle on how IVAs were supposed to work - saw a lot of conflicting info that I assume had to do with varying old KSP versions.

Quick question, is there a known issue with TweakScale? I was just playing around with a design. The VAB display shows it as needing 4962 rocket parts but in game, it requires 24720. It took a bit of messing around to understand the issue but it's because the design has engines that are TweakScaled down from 2.5 to 1.25m. The VAB display correctly understands the TweakScale conversion but in game, it does not. Is there a known workaround? Also, is this the proper thread for this question or would the original EL thread be more appropriate? Thanks!

I started poking around with some basic modeling last year but never got very far. I could give a hand with at least getting the base models with skins on them. I left Windows a long time ago so C# coding is a bit tricky for me. (though I could install Mono, I suppose) About a decade back, I did professional C# software dev for a few years so I might be able to at least be a second set of eyes for the coding side of stuff.

Just wanted to say that I've been using the crap out of this mod lately! As someone that like to make stations out of 3.75 parts, this has been incredibly useful. The service modules have also been great for reducing part counts. I was wondering if you were close to another release for the 3.75 to 5 basic parts. I was mulling an orbital lab that could really use the lab module in that size. If there's anything I can do to assist with some of the grunt work on getting these parts made, I'd love to help.

I love this mod - there's a big lack of crew parts in 3.75m and larger. Some quick requests I'd love to see added to the mod: - Variants of the Abode module or sub-types (as done in the Near Future Construction Octo-Truss stuff) that terminate the ends of the module in 2.5 and 3.75m diameters. E.g.: the default version that has 2.5m ends on both sides, one that is 2.5/3.75 and one that had 3.75m diameter on both ends. - A large capacity science lab, similar in capacity to the Abode module and maybe a little larger to accommodate the workspaces. - A version of the Cradle that's designed to connect to the other modules and has a landing for EVA kerbals to have handholds to attach to they can access the KIS pallet modules without having to deal with floating off into space. - A set of super large capacity habitation modules. Either longer 3.75m or (preferably) 5m versions of the Abode, etc. I would love to have the ability to create stations and spacecraft that can accommodate 20+ Kerbals without being huge, spindly affairs. Might make sense to have these be on a higher tech tree node. - A super large capacity science lab similar to the previous point. There used to be a mod (now gone) that had a modded Mk3 passenger fuselage that provided a 16 position science lab for qiuckly racking up research points. I would love to see a similarly sized lab again. Thanks for your work, it looks great so far!

@Ippo I'm not expecting CKAN to police the metadata - that's unreasonable. However the problem is that the metadata is a fallible source of information. There's mods that are clearly out of date that claim to be fine. There's mods that work fine that CKAN refuses to let you load. The final call should always be made by the user. For example, I heavily use Porket's Atomic Age mod. Most of my craft use engines from it. I haven't been able to play KSP for 2 weeks because Porket is too busy to fix the version metadata. Several users have confirmed that the mod works fine on current versions of KSP. Now I'm left with a decision. Do I not play? Do I remove Atomic Age from CKAN and manually install it? Now I've got to keep track of that somewhere else. I've got to manually scan SpaceDock and check for updates and install them. Then I've got to check CKAN to see if the metadata has been updated there. If it has, I have to delete my manual install and re-enable in CKAN. Now do that for about 10 other mods. It's a mess. CKAN seems to have the same issue that a lot of open source software suffers from - prescriptive workflow. (don't even get me started on older versions of GIMP) The creators have a particular workflow they like. They design the application around that workflow - nothing wrong with that. the problem is that they then try to enforce that particular workflow, which makes no sense. If the user wants to use the tool in a different way, why are you stopping them? That's like making a shovel that's been designed with a curved handle that's optimized to be held in a particular way. That's fine but what CKAN is doing is putting a bunch of spikes on the rest of the handle so you can't hold it anywhere but the official hand positions. Maybe I'm really short or tall or have back issues and can't hold the shovel handle the way it's intended? Why are you going out of your way to prevent me from using the shovel the way that works for me? If CKAN simply had a provision to do a force install on a mod, that fixes the problem. It can mark the row in yellow or put a warning icon on it or whatever. CKAN is perfectly justified in letting me know that I'm ignoring the metadata and potentially breaking my game and that any problems that result are mine to deal with. If I complain on the forums or Github, they simply ask, "Do you have any forced installs?" If the answer is yes, they can tell me to stuff it and figure out the problem myself. I can still use CKAN. I can track the forced install mod like the others. When the version finally updates in the metadata, I can remove the force install flag and everything goes back to normal. Maybe I have game issues as a result but that's my conscious decision and I can live with that. It's been particularly frustrating since 1.1 came out. I was patiently waiting and watching all of my mods as they updated to 1.1. Finally, it was down to 2 out of the ~20 mods waiting on an update. I was eagerly anticipating playing KSP again. I'd been doing some throw-away career/sandbox runs just to check out the new features but wanted to be able to sit down and do a serious career runthrough with all of my favorite mods. Then 1.1.1 drops. Back to square 1. Then 1.1.2 drops. Many of the mod makers don't even seem to be bothering updating right now. They seem to be waiting out this update storm and are holding until Squad gets to a stable version before they bother doing updates. That leaves me to either drop CKAN or stop playing KSP. And that's sad because other than this one issue, CKAN is an awesome utility that greatly simplifies the whole mod management hairball. But because of that issue, I literally have not been able to play my favorite game for 2 weeks. Doing this manually is going to kind of suck. But at least I can actually play my game then. I'm considering writing my own CKAN-like utility because of this. And that's really stupid. Seriously stupid. It's going to basically be CKAN except with one little added feature. That's got to be one of the most trivial and unnecessary applications of all time. Yet I'm considering it because CKAN's functionality was great but now actually makes mod management harder than doing it by hand.

I just want to start by saying that I greatly appreciate the work done by the CKAN team and that there's no ill will here. That said... I am uninstalling CKAN and have no plans to use it again. CKAN's blind enforcement of versioning makes it completely unusable. There needs to be a way to allow the end user to override incorrect or outdated version numbers. This would be a trivial change to implement and despite constant and overwhelming user demand for this feature, has been consistently ignored by the dev team. I honestly cannot understand such a strong aversion to a needed and highly requested feature. It is perfectly reasonable to have the versioning controlled by the mod creator. However, ultimately this is my KSP install and I should be able to install a mod with the understanding that a version incompatibility might break my game. That should be my decision to make. I've seen arguments that the end user can just do a manual install of the mods. What is the point of using CKAN then? Right now about half my mods are versioned at 1.1.0 or 1.1.1. I would have to remove them all from CKAN and do manual installs. Then I've got to regularly check spacedock for all of these mods to see if they've updated, manually delete them and re-enable them in CKAN. That's worse than nothing. I'm keeping track of CKAN mods on post-it notes and hammering Spacedock. You're better off just doing it all by hand at that point. Using the mod creators as the definitive version control is a good place to start but hardly flawless. You see plenty of mods that have version requirements like 1.1.99 or 0.25.0+. Are we to believe that a mod creator that was working back in version 0.25 knew for a fact that their mod would be compatible with 1.1.2? There are other cases where the mod creator has confirmed that the mod works with the latest version but simply hasn't had time to update the version listing. CKAN is correct in that the mod creator should be the go-to information source but assuming that the input data is flawless is provably wrong. I wish the CKAN the team the best but request that they reconsider their hard stance on this issue. This single issue is taking an otherwise awesome utility and basically making it useless for the purpose it was created for - managing KSP mods.

It's up on CKAN, however CKAN still thinks that SimpleConstruction is not 1.1 compatible and refuses to install it on a 1.1 installation. I'm not sure how the CKAN upload determines version compatibility but there might be a config file somewhere that refers to 1.05 still? Of course, it can be manually installed but many CKAN users are not going to be aware of that and will simply assume that this mod isn't 1.1 compatible yet.

In CKAN, version 1.7 of SimpleConstruction is still listed as only being 1.05 compatible. This prevents installation with CKAN. Was that deliberate? I'm anxious to move from EPL to this. EPL has great functionality but as you've said, it's memory hungry and the parts are... homely.

Has anyone else had an issue where your orbital speed suddenly shifts when changing craft? I just started my first orbital rescue mission and can't complete it. Here's the sequence of events: - Approach the stranded capsule, do a Hohmann transfer to the target and match speeds at ~150 m. - Check the relative velocities. In the game, I can see the target and the distance info is sitting rock steady at about 150m. However, on the ball, the target relative speed indicator shows roughly 55 m/s, which is weird. - Switch to map view and my rocket and the target have a large separation in the orbital display, probably 20km or so. It also shows highly divergent orbital velocities, roughly 55 m/s difference. However, the orbital tracks in the map display are perfectly overlaid on each other. - Switch back to normal mode and the target is sitting there at 150m, 0 m/s relative velocity according to the data on the overlay. The ball display still shows 55 m/s differential speed. - I switch to the target capsule to get the target kerbal to EVA and I immediately notice that my rocket is now quickly receding at roughly 55 m/s. This is now consistent between display on the ball and what is happening in game. - I jump back to my rocket and the departure speed from the target is now consistent here s well. My periapsis is now inside atmo and I have to do an emergency maneuver to keep from re-entering. - I re-establish a high orbit, redo the Hohmann transfer and velocity match. - The same scenario plays out, everything looks fine in-game, ball shows relative velocity difference, map view shows identical orbital tracks, but with a large separation. When I shift to the target craft, the two vehicles now have large differential velocities and in-game, ball and map view are all consistent in that I'm moving away from the target at high speed and I have a non-circular orbit, as if I had just applied a large radial burn anti-normal to the surface of Kerbin. Has anyone else seen this behavior? I'm running quite a few mods but they're almost all just part mods that shouldn't have any effect like this. I did use MechJeb to do the transfer and velocity matching but it's hard to imagine that being the root cause since it's just a fancy SAS. I wanted to see if anyone else has seen this behavior before reporting it as a bug. Running in Linux, 64-bit.

ss8913: There's several mods that I know have 1.1 patches out that aren't up on CKAN yet. They can be a bit slow on the update at times. Must be the same folks that maintain the Debian repos.

I just tried using Portrait stats with 1.1 (Linux, 64-bit) and I think I'm just seeing the default Kerbal view. Is there something I have to do to activate it? EDIT - Nevermind. CKAN was being screwy and telling me that it had updated a bunch of mods but, in fact, had not. Turns out a bunch of other stuff was also malfunctioning too. I guess running Linux, just because I *can* run the system for 7 months without a reboot doesn't mean I *should*.

Thanks! I actually just ended up launching a new base with an orbital dock on the side, which ended up doing the job. If I could make a suggestion, if you do rework on the part, a static 1.25m port or two on the side to allow attachment of other modules would be awesome.

Ah, I was wondering when a 1.1 update would come out for these mods. Sweet! Of all the mods in KSP, these are the ones I would love the most to be incorporated into the actual game. All the other mods add a bit of functionality here or there but this fundamentally changes just about everything about how the game is played in a positive way.