JadeOfMaar

KER's RDZV panel provides this, along with text input and closest match as you type.

In practice, BSG's jump style sits somewhere between Whipcrack and Warp in terms of convenience and challenge. But in terms of travel time it rates higher (re: shortening that time) than Warp but still lower than Gates. There are three dimensions to the sine wave mini-game where you can shoot for improved jump performance, and each dimension is tied to one of the stock kerbal traits, making you require a 5-star in all 3 to ensure peak performance. That much is given in the documentation in the Git issue. What's not given, or not well settled yet (it's the kind of thing you as a modmaker won't know the limits or effect of until you actually make it and playtest it) is how your orbital parameters get shuffled and ker-fuffled after a jump. All that's said is seemingly your ship accelerates a bit during jump startup, which adds to the offset of those params. As it so happens I haven't given any consideration to how Whipcrack will decide what the minimum safe orbital altitude is before you place a Whipping Post there. Now that you have me thinking, the jump to a Whipping Post should have your destination's orbital params start with that of the Post or, say, baseline altitude of 5x the body radius (just above Kerbin's geosync altitude). If these are the case then in most cases you shouldn't need to worry about your destination Pe being too low and (as you suggest) you appear inside Eve or the Sun. But for the most part you can absolutely expect that the difference in orbital parameters can possibly cause you to arrive in an absolutely suborbital position and need to fix your orbit and fast. This is where the fierce recommendation of a torch drive mod (or Angel's KFS) comes in. Angel's graphic and that it tells you can jump in REVERSE or get yoinked by a Whipping Post that you're NOT targetting really introduces you to the Curve ball that's going to be thrown at you, lol. About the look ahead... idk. It would be nice to be able to get advance warning that a gravity well near your jump vector could deflect you and where you'll get deflected to, so you know which way not to jump. The prospected output would need to be the predicted arrival parameters. But that's only half the calculation, half the data you want to see. The other half is where you'll actually end up when you factor in the variable of how accurately you fire. Unless your trigger finger is already sharp enough there's a high chance your undesired destination will be far worse than the prediction. Overly easy? I doubt (but not too much. I feel the sentiment). Remember that Blueshift's warp, at least, is still an engineering challenge due to needing 3 or 4 types of parts and really needing to watch your ship's mass in order to have a fast...ish, working warp ship. Blueshift being Blueshift, the Whipcrack will have the same requirements as Warp: Graviolium and ElectroPlasma (and subsequently the things you have to do to generate ElectroPlasma). The requirement on Deut and AM will only happen if players bother him to write FFT compatibility. About the Nova Kirbani problem, these points: If using jump gates causes the bug, try using the stock teleporter's rendezvous function instead. See if the bug still happens. If it does then imo it's not a fault of the FTL plugin. As @kspnerd122 said, crossing an SOI "too fast" (not only via huge orbital velocity but especially with high time warp) can provoke this kind of problem. But..... Try using the stock teleporter instead of the jump gate and rendezvous with the same gate or just get into low orbit of some planet there. If using stock triggers the problem then it's not a fault of the FTL mod. Have you confirmed that the bug occurs with other GU systems? With warp and with the jump gates? The further off the system is, the worse any KSP problem that has to do with interstellar distance. If it only happens with Nova Kirbani then I'd say the bug is the effect of misbehavior of Kopernicus and possibly a config item unique to Nova Kirbani.

I can't say which series, if any. This is likely a case of "any resemblance to X is purely coincidental" because that happens. If you're really hoping for a series to watch, you'll find a strong resemblance in Space Battleship Yamato 2199. The basic wormhole timing scheme and needing a human pilot to pull the trigger are there. But there's nothing like the Whipping Post mechanic. That's straight out of my mind and the cowboy train of thought. The FTL techs are setup in parallel branches on the end of the tech tree. (Like a fork in the (ideally one way) road you pick a path and go down that and call it a day. You don't see humankind mastering more than one FTL tech in a given story.) Warp only has 1 tech node while jump gates and Whipcrack have 2. The more capable, larger drive and the Whipping Post unlock later.

Mini-Mag Orion comes to mind. Its pulse units are very low mass and offer very high impulse. The engine is a magnetic nozzle and uses Z-Pinch to implode the pulse unit, sending the fissile fuel to critical mass. The pulse unit is just a sphere of Curium-245 with a magnetic coil and ultra-light sheets of conductive material connecting the sphere and coil. I would argue that hybrid fission-fusion isn't automatically a precursor to full fusion. Some, if not all fission-fusion drives exist to easily trigger one process by using the other as a jump-starter. In the case of bombs: you're mainly a fission process but you use a fusion bomb to kickstart it. On the other hand: Lithium saltwater is mainly a fusion process but uses neutron bombardment to kick off a fission process which leads into fusion. A stock Mini-Mag produced by "Shake-proof" would be quite appropriate. The agency "earns its name" even more by developing it.

You're seriously making IVAs already? Dude?!

BSG style jump drive is precise (fully automated, usually no chance to miss) and involves a jump calculator which takes time to warm up depending on your vessel's mass, possible interference from a gravity well, and the jump distance. Your orbital parameters at the destination are usually handwaved and your orbit is generally stable and perfectly circular. "Whipcrack" is imprecise (requires the pilot's hand-eye coordination when timping the jump ignition, and hence has a high chance to miss). Accuracy falls as distance increases because the far end of the wormhole used by the jump drive "whips around." Whipcrack's accuracy is (or should be) assisted by your vessel's mass and if you have a "Whipping Post" (a specialized vessel that the "Whip" can possibly "wrap itself around" and be caught) in orbit of the destination celestial, but its cooldown time increases with your vessel's mass. Your destination orbital parameters are -not- handwaved and made perfect so you -must- have some form of torch drive on your jump ship and the skills or separate autopilot to fix your orbit on arrival. "Whipcrack" is a fitting name and mentality when you look at Angel's brand "Wild Blue" on the whole and the Wild West and Mexican themes in several of the existing parts. The difficulties with this jump tech mod exist at least partially because the other two FTL techs have plenty "easy mode" in them, and making this one very easy too would make it redundant after them.

The inline heatsinks and all wrapper radiators (so far) are in-game and functioning.

Between [inside Jool's SOI] and full range, 1 AU is too small of an intermediate range as I suggested earlier. I'd look at 5 ~ 15 AU so you can at least hop between two gas planets when they are near each other. If your suggestion is purely from a "Gradual progression" standpoint then I gotta say I'm against it (as it may be trying to nudge Angel to provide more tech nodes, and that's not happening either). Since you need a 2.5m model, you could ask for a specialty mid-range drive that can go 50 AU at a time (a very capable drive but not interstellar).

Pretty much. Jumps could be perfect only when between a parent planet and its moons. But I wonder for players who might want to go between Jupiter and Saturn (5 AU, but assuming they're lined up). Or in extreme cases, 15 AU max (Jupiter to Saturn is apparently just 5 AU, assuming they're lined up). (I'm not suggesting the jumps remain perfect beyond the moon-hopping scale. That's excessive.)

He already said no to this. It already adds a fair deal of easy mode to the warp drive and can be taken as a crutch that novice pilots lean on and spoil themselves with. The jump gates have this by default and players begged for it with the warp drive. Wouldn't having it in Whipcrack basically make all 3 FTL techs redundant? Whipcrack would boil down to warp without the road trip, which Angel specifically wants to avoid. I'd like to entertain the idea of a 1.25m (not 2.5m) model accompanying the 3.75m. Its accuracy could be higher with less falloff over distance, but it would also have a very limited distance. You don't get to jump further than an equivalent of 2 parent planets with this one for example. This technically introduces and forces a ship design paradigm but so does any mod that introduces a serious gameplay change. Rather than try to build a "smaller" main jump ship, always build your larger ship to be a carrier vessel and have your lesser craft hold two or more 1.25m engines. Think "capital ships and their frigates." For sublight propulsion and OMS you're going to want the anti-grav drive cones from KFS more than ever.

Possible use with Extraplanetary Launchpads... It might be weird as heck to have those out on a very alien environment.

Ah. In that case, yes. There's probably an altitude limit of roughly that much.

Atmosphere resources can be detected from any altitude within a body's SOI. I never set an altitude limit, and Spectroscopy also practically knows no limit. Exosphere resources, however, will only show non-zero if you're within their bands.

I was now about to add to my post. Nuclear Family conflicts with Kerbal Atomics' LH2NTRModSupport. The intention and patching targets are the same while the scopes are different. No, you don't need to rescan. The only thing to be concerned with scanners is that RR adds proximity resource scanners (like the stock surface scanner) for all 4 resource types (crustal, oceanic, atmospheric, exospheric). If you plan to scoop the skies or lakes, put the appropriate ones on your ship and keep their PAWs open. The oceanic scanner needs to be submerged (merely being splashed doesn't count) to work.

For MKS: Yes. Kerbalism is incompatible anyway, and the RR Bread Tanks are obsolete in favor of the extra Ore tanks from Stockalike Mining Extension, and added or modified tanks under Procedural Parts. The engines are only demos and possible idea fuel for other engine part makers, and are obsolete now too. Nuclear Family makes all tagged NTRs able to switch propellant so you can run them on things you can mostly just scoop out of nearly every atmo, and this becomes convenient mid-flight or pre-launch if you have a capable build with nuclear ramjets. You can choose between Hydrogen, Carbon Mon/Dioxide, Ammonia, Methane, Water. The README here gives tables of thrust and Isp for all propellants relative to the stock NERVA, and all thrust values scale properly vs the initial thrust before being patched. Your preferred, compatible, large Kerbal Atomics engine absolutely will have 2x its original thrust when you change it to use Ammonia for example. If you're going to use Nuclear Family I recommend you get RCS Family too. This brings the same magic to all tagged RCS thrusters. RR_NTRReactorPatch is an adaptation of a patch from NFE. (I don't know if it still exists now since System Heat effectively replaces it.) This causes all compatible nuclear engines to have a nuclear reactor installed into them and this reactor needs to be running and properly cooled to provide the thermal energy for thrust. You don't use this reactor directly for electric generation. This patch is mirrored in Nuclear Family and affects only nuclear jets but not rockets -- I wanted to avoid possibly causing more tech support issues where some rockets may already have this behavior in them, meanwhile, I'm pretty confident no one does this with jets, and giving them a half-life seemed like a pretty okay decision. A nuclear jet can run "forever" on just IntakeAtm and may seem quite unbalanced if it doesn't have this limitation. This patch also adds the NFE nuclear fuel storage module. In order to refuel a nuclear jet you must wait for it to cool down, and your engineer must have enough rank, same as with any NFE mod parts.

Wrapper radiators. Mid-temp Metal gray High-temp Graphene black More height options than shown exist for all of them. Cooling capacity scales with height options.

They will.

@Ariel Kerman Making something great is the point of the engines. But some of them require complementary parts that haven't been made yet and may span 2 or 3 categories. Such engines are mainly the thermal nozzle engines which require capable nuclear reactors that produce ElectricCharge ThermalPower and are -not- in the KSPI-E mod, and the reactors I make will probably need a Thermo-electric converter (separate part) with them. And at least one of my advisors is explicitly waiting for my thermal control suite to go with the engines before they start playing/playtesting. This is part of that suite: Inline heatsinks. Some with engine cluster variants (off by default). Textures practically finished, at last. Sizes: 5m, 3.75m, 2.5m, Mk2, 1.25m.

Don't be quick to assume that KSP2 will make your work a waste of time. As a beginner your mod is going to be small so it won't be as much of a "loss" when that time comes, and whatever you do while you wait for KSP2 (and who knows how long this wait will still be) will count towards actual modding experience which will help with the learning curve of modding KSP2. I cannot say how helpful because the part model format -will- be different, and "backwards compatibility" is a pipe dream and fundamentally a very bad idea.

Torch drives will, at first glance, be less efficient because the basic thing anyone knows about engine performance is that you trade impulse for thrust. You cannot simply pile on both. But a torch will, by definition, have enough thrust for a manned mission AND the impulse to allow it to burn as long as desired to promise a short or more comfortable ship (see: Thrust gravity). Uranium doesn't have such a short half-life. What you're actually thinking of is Tritium. This is a radioactive variant of Hydrogen, with a half-life of just 12 years, and with Deuterium, makes the easiest fusion fuel mix to ignite in an engine or power source. For a period in your space program you could have a D-T fusion economy going, and express delivery between the mining base on an inner system metal world and a settlement on an outer ice planet where solar is utterly dead, is absolutely necessary because if you use Hohmann to transport it, half of it will have fizzled out by then. The true and first incentive that KSP2 should have for torchships is finite lifespans for kerbals. Let them age and eventually die. No more perfect immortality, then players can't casually "Forget them in a Mk1 pod" or "Maximum gravity slingshot" for mass-efficient ships. (This doesn't even fall under life support. Just add a proper life cycle system so eventually Jeb has to step down and you can legit have his son or his choice pupil take his crown when he's retired or poofed. We know about "boom events" where kerbals are born, but that just means more kerbals. But anything that's born...eventually dies. Fact of life.) And about Antimatter: The highest form of it we may only ever produce (or use) is Anti-Deuterium. There isn't going to be an "Anti-Uranium." You can't magnetically confine most materials and generally, the thing about Antimatter is that it's stable, but it will annihilate if it touches anything that's not Antimatter. As long as you have power to confine it, you can technically store it indefinitely, right? I don't expect the KSP2 devs to come up with some Taurusfecallium resource to try to justify torchships. They'd be going against practically the same reason they're not making warp drives. It's too out there. It's far from being perfectly resolved in Math and Physics calculations and until then it violates known Physics.

Beamed power and laser sails are the best application of sail tech for KSP2. Playability needs to be considered before realism. An engine that realistically produces practically no thrust is going to be useless to the great majority of players who: Don't deal in the Realism Overhaul suite Might not even ever leave Kerbin's SOI Will spam many ion engines into their stock grand tour ship Are itching for MetallicHydrogen or the Daedalus Semi-related: Lightcraft launch vehicles.

Correct.

@bmcmahonwrx Hi there. If you mouse-over most people's profile pic you'll get to see when last they logged in. Sadly, Thrimm has gone offline for quite some time now. If you can indeed write part configs and fix issues and add compatibility, you're welcome to try adopting this mod. Note that "coding" and "configurating" are -not- the same thing. Coding means writing plugins and shaders that add new things that the game itself can do and provide. Configs only tell the game how to identify a part, give it functions, and calibrate/restrict these functions.

Ah. gg. I added to my post above. See: anti-roll/auto-level. If this mod can do those, I'm sure there will be a few happy campers. Stock anchor is nice but it's bugged as anything, and it's useless when you want to secure something after it has been built or landed.

Disable animations, eh? I have ideas for parts that depend on this mod and include animations (just for deploying) to rival the launch clamp and supercede the stock ground anchor. Those parts won't like that. As for your issue with landing legs, maybe don't add the module to landing legs. Then you won't get sproinged. If you need to add code for anything, it would be to maintain orientation (I assume this mod doesn't prevent a very imbalanced base from tipping over, such as on a notable slope angle) such as to auto-level itself and the rest of the vessel with it.