Linkageless

Hopefully Take Two can appreciate the ongoing value of keeping the forums running. It's good news that this appears to be the case so far. Aside from potentially attracting new players even now, they might consider the sheer quantity of inspirational knowledge, experience and ideas contained within the forums that might guide them in the creation of future games. Not to mention keeping thousands of existing KSP fans on-side. I'm still hopeful that something might be done to resurrect KSP2. Take Two, if you really see no future in this, turn it over to the community as I'm pretty sure there's enough collective skill and enthusiasm among us to get it over the line!

I'm likely not the first person to suggest this, even in connection to KSP2... Please can you build some versatility into the fuel tank designs. Instead of a limited selection of choices, I would rather see the tank shapes as standard structural elements that you can then outfit with the tank types/proportions/capacities of your choice. I would like to be able to say take a mk3 shell, and outfit it with tanks inside to contain say 300 units of methane, 200 units oxygen, and 100 hydrogen, and perhaps 50 units of empty unfitted space. This might then be saved as a custom part or assembly, for later use. It might even be possible to fit out internal tanks to be capable of storing more than one fuel at different times. Say you have a oxygen tank that is also fitted out for methane plumbing, when the oxygen is all used up or vented, you can then fill it with methane, then later empty it and fill it with oxygen again. I'm pretty sure there's mods along these lines in KSP1, but wouldn't it be nice if this were a stock feature now we have a more diverse set of fuel choices?

Thanks for the report. I would dearly love to play KSP2 on my os of preference, Linux, and am still hopeful it will be a standard option in due course. I did, however, come to the conclusion long ago that I needed to build my first personal windoze machine in about 25 years in order to make life easy for myself when KSP2 came out. I've built an awesome PC with a cheap but legit windows licence and I'm not regretting it.

Welcome, Razgriz78. I was also a long time 'guest' lurker, but it's great to put something back, isn't it?

Arrgh! I can't download it fast enough!! I may have built a new PC for this, and have whizzy fibre at home, but I'm still limited by the speed steam's servers can deliver!

I'm very excited by this and will be tinkering at the first opportunity. Let's not lose sight of the fact this is early access and our constructive feedback at this point (hopefully) will help direct the course of development. Opening things up to coded mods will be a key moment but I can understand that they want to get a number of things right before that.

If placing radially, you may be able to place these parts in a different position without getting hit by the unwanted symmetry, then offset them into place. You might also be able to temporarily offset the other symmetry parts, out of the way of what you are doing. I often do this using precise editor, but that's a learning curve of it's own. Another potential way around this is if you get 4x symmetry, and only wanted 2x, you can remove symmetry on the excess parts in turn, then just delete them. You can also apply this technique to do things like have 4x parts sitting in positions where 6x symmetry puts them, eg to avoid covering a pod window or hatch while still getting precise symmetrical placement.

"For Science!" is another handy little mod for this, automatically running and storing all resettable experiments in every biome you enter, so you don't have to go through the grind of running each of them. For me, nicely speeds up that science tour of KSC. You still have to go to the biomes with this, and won't be able to get any science you wouldn't have been able to gather manually, so I don't consider it cheating. I love this idea. Just imagine the state of Bob when he staggers back into the kerbonaut complex after a lengthy science gathering session!

Dockable RAPIER with Shielded Docking Port I found that a Shielded Docking Port can be nicely offset into a RAPIER to provide handy rear docking for small spaceplanes. It also (as I recall) provides a useful reduction in drag on the RAPIER, leaving the front of your stack clear for an inline intake or whatever else. When closed, the engine operates as usual. When open, the docking ring protrudes just a little bit further out of the back, allowing docking as normal. https://imgur.com/a/3TnmeWN I always bind an action group to toggle the docking port and disable (not toggle) the engine. Throttling up the engine while the port is open is a good method for emergency explosive separation! ... don't forget some RCS. Docking manoeuvres using this without RCS are possible, but inadvisable.

If you consider planetary systems, then Jool has plenty of biomes around on it's moons. It may take you more time, but it's a lot easier to return from and you don't have to do the toughest bits like Tylo landing & return. If you're content to just land unkerbaled on Eve and transmit your science for lower value, then a probe with heatshields and parachutes is easy enough. A final consideration is that a good rover/hopper setup with lab(s) on Minmus surface will provide you all the science you'll ever need to unlock the tree.configurable

Some science data, like a crew report, gets full credit for radio transmission back to kerbin. It's still only a 5th of the value you get out of processing it in the lab, but as @mikegarrison said, you can do both. Be aware that although you won't lose science on transmission, time to process is also a factor here and processing stops when it nears the lab limit of 500 science (tweakable in .cfg somewhere). What's more, the processing rate decreases unless you keep it topped up close to 750 data (again tweakable in .cfg).

You may see an inclination detailed in the [+] note section in the contract, or perhaps in the active contracts view of mission control. Compare that to the inclination you have (shown on the second tab on the left bottom display, just above where it says ORBIT). If you are indeed going the wrong direction, burning retrograde for (about) 822.4m/s can fix it. You have plenty of dv with which to achieve that. I have often wished they made it graphically more obvious which direction these contract orbits are, but then I suppose that's part of the 'charm' of the 'devil in the detail' of the contract system.

yep - that changed in 1.11. Even back before crewable parts were rebalanced the seats were excellent for ultra economy class tourist trips among other things. oh, and 8 years is quite some necro!

I think Reload Database from the meta-F12 cheats>Database menu would be the right thing to do. You'll need to do that from the Space Center view. Have a look in the Audio section below that - it appears to be a list of all the sounds defined. I recall having no success attempting to add stock sounds to otherwise silent parts using .cfg alone, but it seems quite reasonable to expect changes to existing part.cfg AUDIO to work. Try comparing with other engines. It seems the Mammoth in Size3EngineCluster/part.cfg like many others has more detailed EFFECTS config. For example you could try the "clip = sound_rocket_spurts" from the running_closed definition. I've successfully used the Mainsail's Squad/Sounds/sound_rocket_mini audio in place of the Mammoth's sound_rocket_spurts, also the sound_jet_deep worked well. I'd not tried, but I wonder if it would be possible to transplant other definitions like flameout and engage into the mainsail, or if those definitions are connected to config elsewhere that we're not seeing. In the end, it may be the Mainsail's age as a part that has meant it's configured in an older, less flexible manner.

Yes, returned from all individually, and some after local tours, but yet to do a grand tour. I'm proudest of taking an SSTO spaceplane, the Buzzard, to Eve and back with 3 kerbals. It flew under its own power to LKO. I sent its 3x relay/survey sat piggyback payload ahead to Eve, while waiting to be refuelled, then followed once topped up. On arrival at Eve orbit, the buzzard descended, gilding down to a suitable equatorial landing site to deploy the drill & ISRU, plus surface science payloads. Once refuelled, ducted fans powered by fuel cells took the buzzard out of the thickest atmosphere. Vectors and Nervs took it the rest of the way to orbit. From there it refuelled from the relays transfer stage and returned to Kerbin for a smooth glide landing.

I'd not noticed this yet, and haven't double checked but certainly it seems to have been run in situations I'm doubtful I had the kit while on EVA. I'm guessing the evaScience might be triggered using a similar mechanism to the evaReport or surfaceSample yet ForScience! doesn't know to check if the evaScienceKit is available in the Kerbal's inventory.

No, it simply collects science at every opportunity and moves it into the first defined science container in the current vessel. The mod is intentionally simplistic to keep it as version portable and robust as possible.

I have feeling these problems increase with CPU load. If you are able, try the same setup on an otherwise empty game. Perhaps copy the game folder and terminate all the other vessels. I recall the world stabiliser mod was created to address this. I've not used it myself. I believe this is what the physics easing is supposed to be mitigating also. Since using KJR, I've not suffered so badly with this. I also mostly use autostrut grandparent on structural parts. On occasions I've tinkered with the cheats like gravity, unbreakable joints etc to mitigate these things.

Hi @ttikkoo, I'm still getting to grips with all that this mod can offer, and can't be sure my interpretation of any of it is all that great. The best guide I know is from the start of this thread, and have worked stuff out from there. An obvious example is the Flight Envelope > Excess Thrust, which shows you how much extra thrust you have available over what is needed for steady, level flight. From @Booots's opening example, you can see the area in red in the middle of the graph is the best combination of speed and altitude for excess thrust, meaning the most acceleration is available, or alternatively I suppose they would be the most economical speed+altitudes to cruise at. That example specifically indicates altitude 10088m (vertical scale) at speed 762m/s (horizontal scale) should allow you 539kN of thrust spare for accelerating. If you were at the same altitude (10km) but already going 1450m/s, you'd struggle to find much excess thrust, so wouldn't be able to accelerate much more. You could get just a little more speed if you climbed to 12km. If you were at 762m/s but at 22km altitude, you'd be in a similar situation, unable to accelerate much, but in this case could get much more by dropping to 18km. On those Flight Evelope charts, I imagine a climb profile being a smooth (if not straight) line going steadily up through as much as the red as possible. The point where my imaginary line exits the blue, I know I'm going to have to have swapped to closed cycle or other rocket engines to keep accelerating. The second example, AoA Curves > Lift/Drag ratio, shows you what Angle of Attack your vessel needs to be pointed at to get the most lift versus drag. (This angle is measured from the root part I think, rather than the incidence of your wings.) In that example, at sea level (altitude 0) and speed 100m/s, you would get the best lift/drag at about 2 degrees nose up from horizontal. So, that would be the most economic angle for climbing at that altitude and speed (in this case probably at takeoff). I hope that helps! Linkageless P.S. - I forgot to mention the part highlighting, a feature that drew me to the mod in the first place. Drag highlight in particular is useful for spotting those parts that you may need to rethink when making a super slippery spaceplane!

My gut reaction is to ask for it as the Aerodata GUI shows it, negative drag. However, I found that counterintuitive initially so suspect others would, too. Would it be difficult to offer both, or one or the other depending on a tick box? Could there be situations where the drag of hub, spinner and blades would outweigh the blades thrust, hence show as neagive thrust?

Certainly, my machine often is running with >2 load average and plenty of cpu use, so this doesn't surprise me. As ever, looking forward to the fruits of your efforts.

You weren't kidding about props being difficult. Again, it's a wonder they work at all, eh? Hopefully this is not too naive... How about if you calculate potential max thrust/power and allow the user to apply their estimated percentage of that across the board. This is assuming there will be a linear relationship between what is calculated and 'real life'. Oversimplification, I know, but if by testing they find practical thrust they achieve is only 50% of what is calculated, they can feed that back in. Perhaps the scale would need to go up to 200% if you think the opposite could be true. On the subject of of the CTDs, I'm wondering if I clear out references to 'WindTunnel' or whatever in settings, persistent.sfs, etc, I wonder if this will reset whatever apparently accumulated issue it is. Maybe through this I could narrow down the problem. What should I be looking for and where?

Mostly in use for helis, I think Brikoleur has demonstrated this at various points. A motor is mounted without being motorised, blades attached, then another motorised motor attached on top, with blades attached. The motorised motor on top is powered up, and the torque is split across the two rotors, in contra-rotating directions. Myself, no. I've only build hybrid vessels, usually that tuck their blades away by closing bay doors to dodge the drag when the rocket engines are engaged. I know Stratzenblitz75 and Bradley Whistance have exhibited some amazing stock prop designs that might achieve near orbital velocity. One might consider these corner cases, even exploit-ish and certainly don't use the BG blades. They still work but I don't know if I'd be insisting that's something you must cater for. Here's a selection of mine, for your amusement, none of which can be categorised simply as prop planes:

Ah, of course! No need to iterate like we have to do when controlling it. Manual control won't get you exactly what's predicted, but be something to aim for at least. As you no doubt know, a common kerbal way of torque cancellation is to use contra-rotating blades, the first rotor just freewheeling in reaction to the second. (Engineering it that way in real life must be an extra challenge, much like variable pitch props or heli rotor swashplates.) Would this the best thrust or power need to be applied to the whole nested approach would be needed to cater for such a setup? Perhaps only to the second (or predefined number of) nested rotor, as when more nesting is applied we're getting into ksp physics exploit-ish territory. (I understand there's a Unity RPM limit not far above what a standard BG rotor can achieve.) Yes, come to think of it, max rotor power is what is needed eventually for top speed. Something I suppose we to work to maximise if transitioning to rocket power for orbital ascent. (ie Max rotor power output => max speed under rotor power => less dv to orbit.) Correct me if I'm wrong. Would I also be right in saying that initially, we want max thrust for acceleration purposes? That would be awesome. It does get a bit grindy tweaking those blades as I go, and I still don't know if I'm getting it right basing my adjustments on maximising -ve drag. I suppose by doing that I'm maximising rotor thrust but not necessarily power, in which case there may be a slightly higher top speed and/or service ceiling I'm missing out on! Alas, yes, I've started having them when I click on the wind tunnel icon. First time, my machine was even more overloaded than usual at the time with a lot of active pages in Firefox and I had a large vessel, but now I find it happens every time even with no vessel loaded, like it's remembering it's broken again. Frustrating! To test again, I built a simple Flea powered plane, then hit the wind tunnel.... here's the log output: I tried again from my sandbox save I use for craft development (where I hadn't had a problem thus far) and experienced similar results when building the same craft, although there were 3957 lines from that - I'm guessing it got slightly further through the calculations. Anything I can do to improve/tailor the log verbosity for you? Perhaps the verbosity of logging is causing KSP trouble.

Yes, typically I bind pitch to the up/down translation keys and regularly adjust while watching the aero gui so I can maximise the -ve drag while they're in use. I have built some in-atmosphere fixed props, or at least preset to a pitch that gives me sufficient takeoff thrust while still allowing a reasonable top speed and service ceiling, but any vessel of mine that leaves Kerbin with a BG prop I'll be wanting to tweak the pitch on the fly. All I've achieved in this respect is through iteration, and you're absolutely right, it can be hard work! All I can suggest is that you either have it optimise blade AoA (around 3-4deg from the PAW readout seems to be it) to provide maximum -ve drag from those parts, or have it do calculations based on just the current build preset pitch. The latter would require us to iterate adjusting it for different scenarios and then recalculating, perhaps resulting in much of the calculated graph each time not matching the actual performance. The former approach does indeed sound rather processing intensive. Could you separately calculate an optimal pitch based on certain increments for various forward airspeeds on blades sharing an axis? Perhaps those values could be provided as a simplified 'thrust' in place of the rotor. Would that be any easier in any way? How many situations would that not suit? At this point, I'm sorry I feel I must mention rotors that aren't pointed 'into wind' (eg for VTOL or helicopters). There's also something I often use now, ducted fans in bays. Again, I suppose you'd just take the current build default state of the bay into account for that. If it's all too much, a simple approach might be to calculate for static blades, set those calculations aside and only include them if someone ticks the 'include static rotor blades' box. That way we could at least see how our vessel performs without the rotors or with no power to them (albeit as a glider in many cases). Wouldn't it have been simple if they just created rotors as pre-built thrust units? But then perhaps that's not Kerbal enough. ugh... and then there's the rotor rpm, not always up at 440... 400 seems to be a fairly stable value, but if I'm after saving power I'll nudge up the pitch and drop the max rpm a little. The motor might not be able to provide sufficient torque or you may have throttled that back, so rpm will drop lower than max from that. The more I think about this, the more I'm amazed that rotors work at all in KSP!