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.

I just wanted to follow up on the launch pad 2. I just stuck a bog standard advance inline stabilizer on the bottom attachment point along with a couple batteries and was able to land it just fine. There was some pitch correction the stabilizer had to apply but it was very small. Even one of the 5 torque mini reaction wheels should be sufficient. Bumping the reaction wheel torque on the pad up to 10 should more than take care of the off-axis issue. However, I now have some other questions. I've landed one of these launch pads next to my minmus drilling facility. However, I can't see any way to put my Kerbals into it to staff it. Am I missing something?

If it helps, it pitches downward with respect to the cockpit(?) at the front when it's in folded mode.

Thanks, I ended up just bumping the productivity of the mobile processing lab up to 2 for the time being. PS: any thoughts on why the Kerbals wouldn't be showing up in the portrait bar when they are in the workshop? Also, I'm getting a strange bug with the launch Pad 2. I'm trying to land one on Minmus and it keeps veering off course when I engage the onboard engines. The off-axis thrust quickly overcomes the built-in reaction wheels and I lose control of the landing. I'm not sure where the off-axis force is coming from, looking in the VAB, the force vectors seem to line up fine.

I've been using EL for a few days now and it's been great! I'm mostly using it to generate small parts on demand so I don't have to ferry them up from Kerbin. I'd like to put in a request. Can we have a 1/2 size workshop? I'd like to integrate some fabrication capabilities into a nuclear-powered ship that I'm sending around the system. I'm not planning on doing any huge builds on this ship, just small survey scan sats and landers and the ability to create repair parts for anything that gets destroyed. Unfortunately, the construction workshop is way to big to fit into my design - it's nearly as long as the entire rest of the habitable potion of the ship by itself. Also, I don't need 10 workers for this. Would it be possible to have a 1/2 sized version. Perhaps slightly lower performance to represent the non-scalable portions of the module. Say, 8.5 tons, crew capacity of 4 or 5 and a productivity factor of 4.5. A shorter, squatter version of the existing module would be awesome. In the meantime, I might mess with the config files to make the survey station have those attributes but it would be nice to have that built into the mod itself. PS: I'm getting a bug where Kerbals in the construction workshop don't show up in the portrait bar at the bottom of the screen. They show up in the right-click context menus and can be moved around, etc. However, since the portraits are missing, I can't get their profession and stats easily. I am using the DMagic Portrait Stats mod, if anyone else has reported issues with that. Thanks!

Hey, does anyone remember if older versions of this mod had a MK3 passenger module lab? I took some time off of KSP and just started up again in anticipation of 1.1. I distinctly remember one of the mods providing a jumbo lab that was just an MK3 passenger module with lab functionality. It had capacity for 10 or 12 scientists and just used the standard textures and IVA - a bit lazy but I was using it for the core of a lot of my larger station builds. I'd love to find that part again but haven't had any luck. I could have sworn that is was part of this one. Did it get removed at some point?

Funny you should mention that. I was frustrated with the lack of good large diameter command/crew modules and decided to start teaching myself 3D modelling to make my own. So far, I have two variants of a cupola inspired by the Stockalike Station Parts Expansion cupola. (it's in the second screen of the imgur album in that link). I have a 3.75 to 2.5 and 3.75 to 3.75m variant finished as meshes so far. I also made a tiny side mount pilot blister that provides a single seat, very high visibility from a hemispherical set of dome windows, an airlock and a little integrated KIS container. I'm about 90% done with the mesh for a variant of the 2.5-3.75 cupola that is intended for use in large stations as the pilot housing. It's going to have integrated reaction wheels, battery, monoprop and thrusters, an integrated version of the pilot blister and a single small side mounted docking port. It loses half the window space for the thruster/monoprop/blister/port integration. It's intended to have space for 5 pilots - one in the blister and 4 in the main body. If I ever get an IVA made for this, the idea is that one pilot is flying the craft from the blister and the other 4 acting as navigators from radial couches in the 4 remaining window sectors. I haven't decided if it should have an integrated power source such as some surface mount solar or a small emergency RTG to ensure that there's always power for control. Next on the list is an engineering pod and a science pod in large format. The engineering pod would have integrated airlocks, radial docking ports and be a large volume integrated KIS container. Not settled on the radial docking port config yet but I was planning on 4-6x small ports. However, reading your comments, it might make more sense to have something like 2-4x small docking ports and 2x 2.5m docking ports. I haven't even started the rough design yet but it's going to be a large diameter, flat format. This one will probably be a 5m core with variants for 5m to 5m and 5m to 3.75m. Not sure if I want to have integrated reaction wheels or not. The intended crew capacity is going to be 6-8ish. The science pod is pretty simple, just another 5m core with options for 5-5 and 5-3.75 endcaps. Possibly a couple of integrated docking ports. It would have a large amount of integrated battery and possibly an integrated communication comm system. I'm thinking a ring of Universal Storage docking sites to integrate science instruments would be a good idea as well. It would probably have a max scientist capacity of 8-12 with a minimal complement of 4. Large stored science and data capacity as well. Probably at least 1000 incoming science data storage and at least 5000 produced science capacity. Still a looong way to go as I haven't started the colliders, texture mapping or any of the other stuff necessary for bringing it into KSP yet and I literally just started learning Blender a week ago. Progress in the album below. If anyone with actual experience in making KSP mods wants to help, I would certainly welcome it. It's a steep learning curve and I'm sure I'm making all sorts of noob mistakes on the mesh design.

First off, I wanted to way that this mod is awesome and that this finally made rovers fun to drive. My KSP stress reliever lately has been taking a 22 ton rover off sweet jumps and jousting buildings. Some of the Kerbals have been expressing concerns about Jeb's unhealthy enthusiasm for this. I did have some questions about the K.F.L.E.R.B. though. It's awesome but is a bit hard to integrate with other components. The K&K colonization elements kinds of sort of fit the front and aft nodes. (as seen above) but I keep seeing screenshots of it being used with some sort of roll-cage cockpit. Is that something from a different mod or is it a beta item that hasn't been included in the library yet? I did find one small bug, the rear attachment node is a tiny, tiny bit low. If you put a procedural tank in that spot that is fit to the port diameter, there is a small gap above and a small overlap at the bottom. If work is still ongoing on this part, I would like to make a few feature requests: - A separate version or a switchable variant that gets rid of the air intakes and instead uses those side lobes for a ton of reaction wheel control (say 200+). It's always tricky to maintain fore/aft balance when using vertical thrusters. (in this case, a pair of the K&K colony thrusters) Even if it's balanced in the VAB, things can get out of wack pretty fast as the CoG moves with fuel usage. Having a lot of reaction wheel command authority really helps to counteract this but my rovers are now studded in reaction wheels and it looks kind of dumb. It doesn't have to have a visual change but if there were one, I was thinking that the side lobes would lose the yellow intake grids and gain a series of circular lumps along their length. - Fore/aft RCS ports! 0-G maneuvering requires adding some fore/aft thrusters and doing so tends to mess up the cool lines of the body. - More powerful thrusters - given the mass of the rovers that get made with this part, 1 kN thrusters are a little wimpy. Maybe bump them up to 2? I went into the part definition and edited this and 2 seemed to be pretty good for maneuverability without being overpowered. - At least one bottom node - making it simpler to attach this part radially onto rockets. - Some sort of vertical bipropellant (or NTR if I'm wishing for a magic pony) thrusters that can be plugged into the fore/aft of the craft. Or if Santa comes early this year, integrated into the main lander body? I'm using the K&K "Meerkat" thrusters right now and it works but it's really janky. Also, being able to lower part count and having fewer tanks to juggle would be nice. - A set of items sized for the cargo bay - fuel tanks, KIS containers and crew modules. Thanks again for the awesome mod, I've been having a blast driving around. Often quite literally.

Ah, that explains a lot. That's why all of the Infernal stuff is static objects that move past each other, not things that expand or shrink. Do you know if anyone has tried a set of nested tubes that extend out like an old portable radio antenna? Actually, now that I think about it, the radial attachment point isn't necessary at all. I had the idea in my head of attaching legs or wheels directly to the base but given the scale of the node, that makes no sense. Just a simple multi-pipe attachment system with top and bottom nodes would be very handy - basically the existing gaslight base with the light pole removed.

Hey, I just got the gaslight update from CKAN and it looks awesome! Can't wait to test it out in the field. I had a couple of feature requests/suggestions that are inspired by it though: - A light-less version of the gaslight with the top of the boom replaced with an attachment point so one can attach solar panels, different lights, etc. - A center node-only version with 4 pipe junctions, a top attachment point and bottom/radial attachment points. This would be a simple pipe extension node that helps to keep part count down. A player could also attach a rover body to the bottom and an autopilot so that a bunch of nodes can be landed and driven to various locations to pre-prep a site for astronaut arrival. - A standalone version of the gaslight extendable boom. I've been looking *forever* for something like this. Infernal robotics has some linear slides that I use a lot but they're big and heavy. Also they don't expand or contract, just move linearly so compact designs are difficult to make. I would absolutely love the ability to have a space station that deploys small docking ports radially after it gets to space, landers that can lower KIS/science modules from the bottom of the lander down to where the astronauts are on the surface, etc, etc. - A larger version of the above that's scaled to be the same width as the stock modular girder segments for heavier duty construction. - Integration of both of those into the Infernal Robotics control system would be an awesome bonus.

I can confirm, I rolled back to 0.7.3 and the missing parts are back. Haven't tried 0.7.3.1 since CKAN makes my life hell while versioning mods.

Hey, quick question, have there been any changes to the larger aero blisters? I just reloaded all of my mods and the 2.5m blisters are missing. This is somewhat disconcerting as now my main station with all of my Kerbals on it won't load. :/ I can find the blister2.cfg file in the mod directory. Have there been any changes to the mod in the last couple weeks? Alternately, do you think that something else might be conflicting? Thanks!