pellinor

I'd love an orbital shipyard as a VAB with a part inventory in space. So you can break old ships apart and use the parts to build new ones.

I'd be fine if they'd just add a framework for experience and skills, and some rudimentary content to show how it works. Then let modders get creative as they were with contracts. Unlike contracts, experience is not essential to career mode, so it can afford to start small. In the end i'd hope for things like * Ribbons like in final frontier * visible changes to the EVA suits, both experience-based and skill-specific. Maybe orange suits for veterans? Or Patches, helm colors, alternate Backpack models. The lights in the helmet could be optional. * Maybe certifications, like for piloting, command seat, science lab. Gardener for greenhouses, cook for snack-oven. * You might need a certain set of skills for larger missions, so you can do it with two veterans or five rookies. I'm not a fan of * (auto)pilot restrictions * physics changes * random effects

Thanks for the update! B9_Aerospace.version still says version 5.2.4 for KSP 0.24.2 (so KSP-AVC still complains).

Because you can aerobrake on your way back. So you first need to burn from LKO to a kerbin-jool transfer. Then you can aerobrake at jool into a Laythe transfer (the horizontal arrows), and then at Laythe into an orbit or a landing. On the way back you need to burn into a kerbin-jool transfer, and then can aerobrake at kerbin (following the vertical arrows).

To me the words sound like esoteric philosophy about ideas that are not well-defined. Has nothing to do with real science. However, the pictures are great! Just imagine time as the orthogonal direction and you get the same plot. Just this time it makes sense.

Nice small solution, well explained. I'd love to see the quickfix in the next game version.

From my understanding the physics-part of welding would pretty much the same as a non-physics joint. Then I guess it could be replaced by storing physics significance for each (instance of a) part in the craft file and fixing the way insignificant parts are calculated (i.e. applying the collective mass and CoM to their root part). In any case colliders stay the same so you'll keep any lag from collision checking. Another part of welding is the merging of part modules, especially RESOURCE nodes. I used welding a lot for joining tanks, so that there is only one tank to refuel, which is easy to find, and the CoM of the fuel is constant without need for any fuel-flow or -balancing voodoo. It would be quite convenient to have this happen in the craft file instead of creating clutter in the part catalog each time you use it. Nice to have, though probably not a priority feature. Edit: flexing joints would be the same as thre 'unbreakable joint' cheat option. But as soon as the joint is allowed any flex, you probably need the full physics calculation. I doubt that you can find a simple spline-like model that handles any sort of weld. What is more important, this probably is something that would need to happen inside unity and not ksp or a mod.

Yes, I could see in the persistence file that parts carry a launch ID that is (usually) constant over the vessel and probably tied to the launch time. However the launch time of a vessel is not the minimum over all parts. I once KAS-attached an old part to a 'young' vessel and it was still considered as young (and having a different launch ID than the rest of the vessel). Maybe KSP takes the launch time of the root part?

@tweakScale: It's probably not good to rely on a fixed number of scales. TweakScale also supports continuous scaling, and the scaletypes are configurable. I sometimes use a 31cm scale for tiny things for example, and ultimately would like an Interface like procedural parts where you can build any diameter you like. The same applies to mods like procedural parts/wings/fairings. Then there are parts with the firespitter texture/fuelswitch, firespitter also has procedural engines. There are KAS-Containers with stuff inside (probably not supporting tweakscale at all). So lots of open questions left. I would just start with simple stuff and test the basic mechanics and interfaces before coming to the tricky special cases.

I'm also still fighting. The following change in Gamedata/TweakScale/Squad_Tweakscale.cfg works for me (only the TWEAKSCALEEXPONENTS is new). Scaling the Aerospike up now gives it 4x the mass, with 4x the thrust. @PART[toroidalAerospike] // Toroidal Aerospike Rocket { MODULE { name = TweakScale type = stack defaultScale = 1.25 TWEAKSCALEEXPONENTS { mass = 2 } } } But I can't get a moduleManager Patch to work. From what I know, it should look something like this: Edit: finally, more similar than I thought. So I need to create a TWEAKSCALEEXPONENTS member instead of trying to modify an existig one. @PART[turboFanEngine]:Final { @MODULE[TweakScale] { TWEAKSCALEEXPONENTS { mass = 2 } } }

As far as I understand, symmetric parts in the SPH are not actually mirrored but rotated 180° around the 'forward' direction. So only engines pointing forward or backward by default will be mirrored fine.

This is not a Firespitter but a Tweakscale issue, concerning all engines. Per default mass multiplies with scale^3 and thrust with scale^2. A fix would be to set the scale exponent for mass to 2 for engine parts. Here is a way to do it on a per-part basis:

It also would be good to have a way of repairing craft files with missing parts. I see that some things might not be well defined, like things that were attached to a missing part. In these cases I would often be happy to have such parts put somewhere in the editor, as long as the set of parts and their tweaks are preserved.

So in principle an inventory could be something as small as a KAS-container, allowing to use the full editor interface for more precise assembling. This is geetting greater than I thought. First saw this mod mainly as a KSC-only solution to manage experimental parts and the like.

Actually far out only means just more time warp. As the suns gravity is weak out there, it also means you need just a bit more fuel and Planets have larger SOIs. If you look for a hard-to-get place, I'd go for low kerbol orbits with extreme inclination/eccentricity.

It works, thanks a lot!

I really think a part mod should not break stock crafts. Anyway, thanks for making it it easy to remove.

Can you set scale exponents on a per-part basis? I'm trying to scale engines so that the TWR is conserved (i.e. mass needs an exponent of 2 instead of 3). So far I only found examples with globally defined exponents. Edit: Version 1.24 lists per-scaletype exponents as a feature, can anyone point me to an example config where this is used?

The stable Lagrange points (L4 and L5) are also (neutrally) stable in ksp. The main difference is that in ksp also any other point on the mun's orbit is neutrally stable as long as it is out of its SOI. So ksp has a lot more stably points than n-body physics. Edit: right, didn't think of L3. This is also stable in ksp and unstable in reality.

I might have just the right craft for this. Planning for something that can be assembled from containers like the packrat. Including different configurations, so one pair of wings should work on kerbin, and two more can be added to transport stuff or fly at duna. My first goal is a working configuration with existing parts. So far it flies like a charm, but balancing different variants will be tricky.

I would only count parts attached to the current vessel. The transparent stuff in the editor might behave in unexpected ways, like multiplying when symmetry mode changes. Just imagine dragging a subassembly including a 'one of a kind' part around. As you pass over a part with symmetry, the editor decides to spontaneously switch to 4x symmetry, and the assembly vanishes because you do not have enough parts. Also, when dragging parts around you'd have to be sure to cover any way such a part could vanish (including gui glitches, other mods or whatever), because you need to put it back into the inventory. The current vessel on the other hand should always provide a list of its parts, so keeping things consistent is much easier. Diagnostic calculations like mechjeb's delta-v are done whenever attaching a new part. This also gives the ability to set parts of the vessel aside to exclude them from the calculation. It would be quite tedious if I need to remove a complete lifter from the editor in order to see the stats of its payload. That is probably the main point why I would consider transparent parts as non-existent.

Have you tried RealChutes? They still work while moving over the surface, allowing drag chutes for landing planes. Haven't used them in water landings though.

Actually you want your part to produce lift (= force when at an angle of attack), in order to act as a stabilizer. Removing the lift is like removing the tail fin, or putting a fuel tank of equal weight in its place. For the mechanic you describe, have you tried to angle the tail fin down slightly? This makes sure its angle of attack is always lower than that of the main wing. So you have fewer Lift when going horizontal (CoL in SPH), but still a correcting force when at a high angle of attack (so it still acts as a stabilizer). For my planes this even makes the plane pitch-stable (so hands-off it always pulls to a certain pitch angle that depends on airspeed). Angling down by 5° works for me, probably less would be better. You'll also see your CoL move forward in the SPH. PS: I don't see what this has to do with ferram, other than general bashing of stock aerodynamics. Even a flat piece of cardboard produces lift when at an angle of attack.

A quick suggestion for the logic of decoupling vessels: I built a vessel that decouples into two parts, say A and B. The root part lies in part A. The active control part ('control from here') is in part B. Now I set up a manouver node and decouple. As expected I stay in control of vessel B, but the manouver node is gone. When I switch to vessel A, the node reappears, so I suppose it sticks to the root part of the starting vessel. It would be better to stick the node to the active control part. This seems more logical to me, but more important it also gives the player control over where it ends up (in flight the root part is both unknown and cannot be changed).

I agree, it might have enough volume for its mass, but not enough features (compared to other cockpits). edit: I'd suggest a lower dry mass. If I remember right it is quite heavier than the old combo of adapter & smaller cockpit.