johnsonwax

As am I. The upside with the new one is that you can use it as a jail for misbehaving kerbalnauts. Jebediah the oyster.

I posted a tutorial for a simple welding part. It takes two THSS parts - an adapter and a dock and welds them together. One needs to be rotated, and they have a scaling that needs to be coped with. It also keeps the docking functionality. I'll post a more advanced tutorial in a day or two.

What has helped me considerably is two things: 1) Ditch the conventional design. I design with my orbital stage in the center at the bottom. Often a nuke drive or low thrust high vacuum efficiency motor - 3.75m fuselage. Surrounding that are 3-6 (depending on size and design of payload, but usually 4) large boosters. These are usually either 3.75m or 5m single or dual stage with a TWR of 1.5-2.0 and a combined dv of about 4500. Atop the uppermost booster stage is a truss that extends vertically to the height of the payload. This arrangement reduces the height of the rocket considerably by lowering the orbital stage as low down within the boosters as possible (I cut the height of my rockets by 30% or so), and provides additional means to strut the top end of the payload to the main booster stages (much less wobbling). If designed properly, the upper booster stage will run out of fuel at the orbital insertion with a periapsis within the atmosphere. The boosters then break away (sepratrons) and can reenter and be reclaimed, but it keeps the entire craft rigid and stable until its out of the atmosphere. The orbital stage can then do the last 100-200 dv to circularize and go from there. You can use the orbital motor as part of the lift if that helps (usually it does) and have the boosters feed fuel to that tank so it arrives topped off. I can reliably launch 140t with this setup including 50m long station parts. 2) On those boosters add a small rocket to each pointing radially outward at about 45 degrees. I use 20-75 power rockets (like the little orange guys) for this. They use very little fuel but by moving some of the thrust inward along the center of lift axis, it helps with spin and attitude control - just enough to help the gimbals. Make sure they are pointed dead center using the snap adjustment, though. I also add some movable canards on the outer surfaces. They're light and help with attitude control early in the lift but don't help much up around 30KM which is when a lot of large rockets tend to go off - as the terminal velocity really increases.

Well, if you are looking at 3,000 - 10,000t for small deposits, you've already covered my idea of a honey hole. I would routinely mine deposits dry in .18 so a permanent base made little sense for me. I could mine a 3,000t deposit dry, but it'd take some work (certainly more than one ship). If you have ones that are 10x-100x that rich, they'd warrant a permanent colony. And that's enough. We simply run out of in-game time to deplete one of those given that mining must be happening within physics range. But I like the idea that denser deposits should be in difficult locations, but once you get that setup with the big drill and all of the storage, it should be stable and reliable. I think you're doing exactly what is needed.

I would argue that Kethane should be moderately common in low quantities (break-even or worse to extract by ship, but perhaps viable by rover to a permanent colony) but with some occasional massive deposits. 400k is sizeable until you undertake a project of considerable scale. Some of us are operating rockets that would consume that entire deposit in one launch (I've drained two deposits on Minmus using one ship back in .18), and since the game will pick up some sort of even rudimentary economic model, kethane is going to fail that model without some adjustment. It's simply not going to be worth building the infrastructure needed to extract it unless there are deposits of considerable quantity - 10s of millions of units or more. Now, these can be relatively rare, in difficult places, and so on. That's as things work now IRL. Getting to it is always part of the challenge. How do you get to that deposit at the pole? How do you reach the one under the ocean? How do you cover the cost of landing on Eve and getting it off of there (and maybe you don't)? The old system had discrete deposits that were easy to hit - pick any spot and you can drain the pond. The new system sounds much better - we'll have to be more nimble and more clever. But I think a great deal of diversity in kethane density is key - there should be some honey holes and a lot of places with some, but not enough to set up a whole operation. That will let us build both permanent mining colonies and an incentive to do rovers to pick off the easier to access but smaller deposits. Adding to the incentive, the rate at which the drills extract should be a function of the density of the deposit - so those small deposits are also slow to extract, making the rare honey holes even more temping. And if they're large and fast to work, those that just want to get on with things can do so for the cost of adapting to the conditions of the honey hole location. And if you want to take that long rover excursion, mount a drill and a portable converter and there will be plenty of fuel on your journey for that kind of effort, just not in high quantity.

You do have all you need in some/most cases. The size of the parts is gleaned from the node locations in the original. If you want to connect from other locations - like surface attaching a piece, then you'll need to do some trial/error to get the position right, but anything that you want to weld along node/node joins is pretty straightforward. I've got 3 welded parts now - one is 7 models including one animated solar array, and another is 9 models with parts assembled along two different axes, many flipped/rotated, and two stretched along only one dimension. I'll post a tutorial of that one later today.

It comes from the original part that I'm trying to weld. The first excepted code is from someone else's part. They used the 2.57 rescale factor. I'll post some more complete examples using parts with multiple rescalefactors, etc. One trouble: My parts aren't highlighting in-game when you hover over them. Parts from others with multiple models do - not sure what I'm doing wrong. I think I have everything there, but not knowing what's the trigger for that functionality makes it hard to narrow down the problem.

Ok. Was hoping to avoid that. I'll probably write it then. In order to avoid breakage, I'd probably hang off the same format as used by ModuleManager and simply zip the contents of the part folders I don't want loaded. That way modules will still update cleanly. I would just need to run my tool after each update.

THSS Mod are the triangular/orange ones. The round-ish ones at the ends are KOSMOS, same mod as that giant solar panel.

Well, I just learned how to do a fairly simple one with some revealing details, so I'll walk you through it. I'm building a station using THSS - the triangular trusses, and I need to both keep part count in check, and maintain reasonable rigidity. I have several areas where there's a length of 4 trusses to get the right length, a 2x, a 1x, and two 1/3 length. So, I'll create a new part that loads 4 models, welds them, and sets the nodes at the end. We start with the first part which looks like this in the original .cfg file: // --- asset parameters --- mesh = model.mu rescaleFactor = 2.57 scale = 1 // --- node definitions --- node_stack_top01 = 0.0, 1.491, 0.0, 0.0, 1.0, 0.0, -1 node_stack_bottom = 0.0, -1.491, 0.0, 0.0, 1.0, 0.0, -1 node_attach = 0.0, 0.0, -0.25, 0.0, 0.0, 0.1, 1 Unlike the stock parts, we have a rescale factor to deal with, which matters. We can also get the length of the part from the distance between the top and bottom nodes (1.491 + 1.491). The first thing I had to sort out was the scaling. 2.57 was too large, 1 was too small. Turns out the proper scaling is sqrt(2.57). I'm not entirely sure why we do it this way - the model itself would then seem to only be scaled by sqrt(2.57) but the positioning scaled by that much again (which gets us the 2.57 for position, but only sqrt of that for size). We're going to build the model in this way: 6 = 2x part 3 = 1x part 1 = 1/3 part 3611 So, the longest piece will be more or less in the center, with the others balancing it out best they can. We could actually balance it with a bit more math, but I don't think it matters. MODEL { model=JARFR_THSS/Parts/Structural/JARFR_TriStrutDouble/model // 2.982 long position = 0.0, 0.0, 0.0 scale = 1.0, 1.0, 1.0 rotation = 0, 0, 0 } MODEL { model=JARFR_THSS/Parts/Structural/JARFR_TriStrut/model // 1.5 long // Half the height of the first model + half the height of this one // (1.491 + .75) * sqrt(2.57) => 3.5926 position = 0.0, 3.5926, 0.0 scale = 1.0, 1.0, 1.0 rotation = 0, 0, 0 } MODEL { model=JARFR_THSS/Parts/Structural/JARFR_TriStrutShort/model // .516 long // Half the hight of the first model plus half the height of this one // (-1.491 + -.258) * sqrt(2.57) => -2.8039 position = 0.0, -2.8039, 0.0 scale = 1.0, 1.0, 1.0 rotation = 0, 0, 0 } MODEL { model=JARFR_THSS/Parts/Structural/JARFR_TriStrutShort/model // .516 long // Half the hight of the first model plus the full height of the third plus half the // height of this one // (-1.491 + -.258 * 3) * sqrt(2.57) => -3.6311 position = 0.0, -3.6311, 0.0 scale = 1.0, 1.0, 1.0 rotation = 0, 0, 0 } // --- asset parameters --- rescaleFactor = 1.6031 // --- node definitions --- // Half the height of the first, plus the whole height of the second // (1.491 + .75 * 2) * sqrt(2.57) => 4.7949 node_stack_top01 = 0.0, 4.7949 , 0.0, 0.0, 1.0, 0.0, -1 // Half the height of the first, plus the whole height of the third and fourth // (-1.491 + -.258 * 4) * sqrt(2.57) => -4.0447 node_stack_bottom = 0.0, -4.0447, 0.0, 0.0, 1.0, 0.0, -1 node_attach = 0.0, 0.0, -0.25, 0.0, 0.0, 0.1, 1 The comments above show the math (I use calca for this kind of stuff - makes it really easy to keep track of everything) In the first model, we load the largest segment, and position it at 0,0,0. That represents the dead center of the part. In the second model, we load the next largest segment, and set it's position. Since the first part is centered, we need to shift half of its length, which would put the center of the 2nd part right at the end of the first, so we need to shift half the length of the second part to put it at the end. Then we multiply by the rescale factor. In the third model, we do the same as above, but in the opposite direction. In the fourth model, we extend it further, half the first, all of the third, and then half the fourth, and then multiply by the scaling. Sketch it out once and it'll be clear. Finally we need to locate the nodes. These are positioned at the end of the part, so the top node is half the first, plus all of the second, then scaled. The bottom is half the first, all of the third and all of the fourth, scaled. I haven't dealt with any more complex nodes and parts, but I think it's all just variations on the above. What will take some investigation is how to merge parts with different scaling. But for fairly straightforward linear welding jobs, the above should get you pretty far. {EDIT} Ok, you can scale any part along any dimension through the scale parameters, so if you want a part 50% longer, you can go with: scale = 1.0, 1.5, 1.0. By moving the scaling factor inside the model, things get both simpler and it handles the case of models with different scaling factors. The code below produces the same result as that above: MODEL { model=JARFR_THSS/Parts/Structural/JARFR_TriStrutDouble/model // 2.982 long position = 0.0, 0.0, 0.0 scale = 2.57, 2.57, 2.57 rotation = 0, 0, 0 } MODEL { model=JARFR_THSS/Parts/Structural/JARFR_TriStrut/model // 1.5 long // Half the height of the first model + half the height of this one // (1.491 + .75) * 2.57 => 5.7594 position = 0.0, 5.794, 0.0 scale = 2.57, 2.57, 2.57 rotation = 0, 0, 0 } MODEL { model=JARFR_THSS/Parts/Structural/JARFR_TriStrutShort/model // .516 long // Half the hight of the first model plus half the height of this one // (-1.491 + -.258) * 2.57 => -4.4949 position = 0.0, -4.4949, 0.0 scale = 2.57, 2.57, 2.57 rotation = 0, 0, 0 } MODEL { model=JARFR_THSS/Parts/Structural/JARFR_TriStrutShort/model // .516 long // Half the hight of the first model plus the full height of the second plus half the // height of this one // (-1.491 + -.258 * 3) * 2.57 => -5.8211 position = 0.0, -5.8211, 0.0 scale = 2.57, 2.57, 2.57 rotation = 0, 0, 0 } // --- asset parameters --- rescaleFactor = 1 // --- node definitions --- // Half the height of the first, plus the whole height of the second // (1.491 + .75 * 2) * 2.57 => 7.6869 node_stack_top01 = 0.0, 7.6869 , 0.0, 0.0, 1.0, 0.0, -1 // (-1.491 + -.258 * 4) * 2.57 => -6.4841 node_stack_bottom = 0.0, -6.4841, 0.0, 0.0, 1.0, 0.0, -1 node_attach = 0.0, 0.0, -0.25, 0.0, 0.0, 0.1, 1 No sqrt. The outer rescale factor is 1 (which you can change to magnify the overall model). Much simpler arrangement.

Is there a straightforward/preferred way to disable a part from loading? For example, I've got at least 3 separate sets of fairings from different mods, but I really only want to use procedural fairings, so I'd like to stop the others from loading without having to physically disrupt the module sets. If there isn't a clear way to do that, is that a feature you could add?

I'm missing the point of that interplanetary design. If you intend to have each satellite able to point to each body, even if just planets, that's a huge number of dishes. If you task certain satellites with certain bodies, then you're going to lose coverage periodically. I've always used two highly elliptical polar satellites, configured identically, with enough dishes to point to each body. Their periapsis is around 80km and their apoapsis just shy of SOI, usually at 80,000 km, and they're 180 deg out of phase, so when one is at apo, the other is at peri. That means that one or the other is visible to every body in the system not blocked by a local body (Laythe blocked by Jool), but one is usually so high above the ecliptic that they may not even be blocked in that case. And because they're polar orbits, they have 100% coverage of the 3 geosync satellites that provide ground coverage. It's not the fastest hop, but you get almost complete coverage anywhere facing Kerbin for only 5 sats. It does look decidedly less cool, though.

That's what I do as well. With two high eccentricity polar orbit comm satellites each out of phase, they'll spend weeks up near the Kerbin SOI and one or the other will be be far enough outside the ecliptic that at least one will be visible from anywhere in the solar system. Kerbin then has 3 geosync satellites to ensure that those two can reach mission control. Each planet then has 3 geosync (or half geosync) satellites guaranteeing connection from each planet to Kerbin and each moon similar. Jool has two polar sats like Kerbin instead of the geosync since there's no ground coverage needed. Works really well unless you want to live at the poles. But it's a lot of satellites. I also do little ones like you have above along with one polar one per planet & moon for mapping and mount them on a unified launcher which has a nuke engine and enough dv to get to any outer planet or moon. The polar has extra xenon for the large plane change, but the others just need to be timed into geosync which is pretty cheap. The mothership isn't very big itself and just drops the sats off like johnny appleseed.

Sumghai, we need to get you and Semni (author of THSS) together to make some adapters and integrated parts. For station building your sets compliment each other extremely well. Not a lot is needed, but a THSS 6-way hub with a Kerbal tunnel to connect Karmony nodes would really be a fantastic addition along with trusses with Karmony styled tunnels. I see a lot of stations built with both sets and I'll soon put up photos of mine using both sets.

Another vote for a dedicated Kethane tank, particularly in the octo fuel tank sizes. My station needs some kethane green to contrast nicely with all that orange. And I agree with JeBuSBrian that standardized sizes are important for these kinds of sets. This is a widespread problem across all sets - we've managed to standardize around certain diameters, but we're a bit all over the place on lengths. I think this set actually does a pretty good job of it, it's around the edges where this gets hard. If you want to construct a large modular station, using docking connectors as part of that effort throws off your spacing just enough. It requires having either zero height connectors to keep your size standardization, or connectors that have corresponding non-connector parts which can pad them out to a standardize length - and some sets do these kinds of clever tricks, but its neither obvious nor easy to do. You get selection challenges with the former, etc. Rather than put a specific request on this set, we need a structural equivalent to the 1.25m/2.5m/3.75m propulsion standard. It could be exactly the same standard (that would be useful, actually) but that would allow us to mix/match structural elements from different sets, habitation modules, etc. Tall order, but food for thought.