JadeOfMaar

lol. Happens to everyone.

Hi @Selphadur. The strange electric ball thing with the Viper is "currently" normal behavior. I discussed it with Angel-125, but the behavior has not changed in his mod so I have not changed this behavior here. I never tried the VTOL controls on the Ranger. I'm surprised that such EC demand is happening so I'll look into it. Graviolium has a launch-time restriction applied to it. You must bring it home from a mining location or produce it in the WBI refinery under the KSC (look for its appbar button. It kinda looks like the AirPark button). You're forced to launch empty and then buy/withdraw Graviolium from your cache under the KSC. This is a balance mechanism for how capable Graviolium propulsion tech is, and how costly Graviolium itself is. Similar applies to Antimatter if you use Nertea's Far Future Tech.

You did not install Community Resource Pack You installed OPT Legacy but not Reconfig (which is mandatory for Legacy) One of these. And they're not common. If not, I'd like to see a screenshot of the error message.

I was made aware of the zero negative mass problem and I've addressed it. The 2000 EC in the battery is enough, I'd think. But the fuel cell is as weak as the stock small fuel cell (1.5 EC/s) which of course can't meet boiloff demands. Better to raise its output than to buff the battery. How much EC/s do you need? It's not up to me to raise the reaction wheel power (It would be nice if that got a buff. Maybe 2x.) but Mk-33 has dV to spare for use as RCS. Just budget it well and be more patient when turning the vessel. The current setup is more like how things are IRL (RCS is very strong, RW torque is very weak) than in stock.

* Items given numbered bullets for sorting as I approach them. IntakeAir being processed into Oxidizer on the fly is effectively half of a Liquid Air Cycle Engine. Some mods may already offer this. One of mine (Kipard Skylon) has this as an optional upgrade. I created it as I thought it was part of how SABRE works but I got pointed out by someone sometime afterward that LACE is very much not part of SABRE. LACE (afaik) also requires sacrificing LH2 fuel to provide enough coolant power to flash hypersonic IntakeAir into cryo liquid form. As consequence of this, I made it so that Skylon's tanks could hold LF or LH2 alone (B9's fuel switch) so if ever a player needed much more fuel volume or (through plenty testing) much less Oxidizer volume, they could achieve it without clipping Mk1 LF tanks. See point #2. Part of why I created Rational Resources is so I can answer this fuel ratio problem with fuel switch (as an extras config) so I'll never have to think about changing the fuel ratio in engines. There will always be someone who will want to use your specific engine in a way it's not meant to, or anywhere outside of the edge case you made it for. And you'll get complaints about that. I know this from my WIP mod SABR3 Sterling. Some players gravitated to the discreet rocket nozzle part because it offered higher Isp than the RAPIER's closed cycle. I immediately foresaw this problem and I was glad I never let loose any custom fuel ratio configs. High EC demand to buff the Helium coolant loop's ability, or having the precooler (in-game) use a non-transferrable catalyst that gradually degenerates (instilling a half-life mechanic) due to the hypersonic plasma entering the intake are both good options to consider. Related, my SABR3 intakes use a novel method of producing a metaphorical catalyst resource (named MillPower in my case, representing a converter's capacity to do the job at a given velocity) through its own intake module only when a certain minimum speed is met (see machCurve{} inside ModuleResourceIntake{}) and having an always-on converter consume this catalyst and IntakeAir to produce Oxidizer. On half-life: The SABRE heat exchanger spiral contains countless fine filament like structures or holes that physically stop and flash cool air at the particle level, so surely, the sheer heat will corrode this in due time IRL. Where OPT is concerned, you want to look at the circular ARI-series engines. These can correlate (to whatever degree) with the Fenris. My impression of Fenris is that it is an air-augmented engine which uses ram air effect to complement its rocket engine nature, though, unlike Fenris, the OPT ARI don't use LACE, and no OPT intake or converter offers the LACE effect. In KSP this typically means an increase of Isp, and by extenision, thrust. Note: The OPT ARI engines are specially tuned to not produce insane thrust when in atmosphere (where their Isp is much higher) vs thrust in vacuum. My point #4 above introduces the use of machCurve{} inside of ModuleResourceIntake{} to force a speed requirement on one of the inputs for a converter. You can approach gameplay balance from an existing opposite angle. Assuming Fenris is an air-augmented rocket, you can use velCurveIsp{} and useVelCurveIsp = True inside ModuleEnginesFX{} to have the engine's Isp change with velocity in atmosphere. Players will then be forced to use the engine at length in atmosphere to access the Isp buff. The OPT Mk2 scramjets use velCurveIsp for their Isp falloff at hypersonic speeds, escaping the need for a separate engine module for operation there. Without forcing a dependency on CryoEngines I'd appropriately nerf the max Isp on the engine. 360 ~ 400 is a good upper limit range on any Kerosene engine.

@Alcentar Hi How are you? @PART:HAS[@MODULE[ModuleControlSurface]] { @MODULE[ModuleControlSurface] { %ignorePitch = True %ignoreYaw = True %ignoreRoll = True } } See above.

That might be an oversight on my part (I wrote the Mk-33 cryo patch). Or (by chance) something foreign in your install somehow caused a conflict. Anyway, it's all fixed for the next update, whenever Angel posts it. Deadly Reentry? Drop bays, cargo ramps, and delivering anything that requires them are out of scope for what Mk-33 is based on and meant for. Plane parts mods other than this one will meet your needs. The diffuser might (in practice IRL) interfere with, and defeat the aerospikes in atmosphere as they are designed to use the air around them to form a virtual bell nozzle; and in vacuum as the surface of the diffuser would cause unwelcome thrust torque (especially if there is only an upper or lower one and not both). Mk-33's shape is sleek enough as it is, as the engines are designed to mesh perfectly into the rear profile. If you want to help aerodynamics, try OPT Wings or procedural wings and provide more control surface area.

The article, while it's about a new engine of the same kind, uses an image of the SABRE engine because everyone knows what SABRE is and does, and evidently, no proper image of Fenris has been taken (apart from that view of the intake and some pipes), likely for several good reasons. Note that Fenris is said to be hour-glass shaped. Very different from SABRE.

I'd very much like to see what you have. I'm curious, but I've already laid out my own configuration for resources and I've done only just a bit for the experiment. I'm looking at making a few custom template for such places as the unusual purple spots on Deemo, Deemo's atmosphere, and Heba's atmosphere.

@DefenderX1 Yes there are supposed to be a bunch of .txt files. Actually, MainWings_Stacknodes.txt shouldn't be there but I didn't want to delete it. As the name says, it adds stack nodes to OPT Main's wings (and elevons). But then the elevons become unplayable when the wing assembly is setup in symmetry. They will tend to interpret all control input as roll. (This config has a warning at the top.) Feel free to activate it and mess around if that's your thing. The Classic folder is all valid configs, but they depend on the WBI play mode switcher to rename them to .cfg (and rename all of the configs in the CRP folder to .txt) if you use the Wild Blue mods in Classic Stock mode. These should never be active the same time as CRP configs. That leads to horrible overlap and null ref problems.

I answered a request thread, taking it as a challenge and an exercise to prototype the texture styling for the Sterling parts. Too much (by surface area) of this engine is shiny, not to my liking, but it's shiny within reason (it's not all 100% shiny like some TU patch mods do to the stock parts). First image is a render in Cinema 4D.

@Arthur Marcolino I took your request as a challenge and modeled that engine for myself. Most of its stats don't mean anything to me as far as my knowledge and play style of KSP go. (Note that I don't use RO, AJE and the various realism mods.) The stats I did manage to capture or otherwise apply, much of which through guess work are: 130kg mass Size: 0.3125m diameter "Mk0" Cruising speed of Mach 0.49 at 3km altitude (the target mach number was 0.468) 14 kN thrust and 2850s impulse so that it starts off at using 0.5 kg of LiquidFuel per second. Includes a slow blade spin animation Includes working heat emissive animation. You'll have to find someone to re-calibrate the engine for you if you don't know how to do it yourself, but you have a shiny new dedicated engine for your enjoyment. You can download it here and consider it Unlicensed /Share Alike/ Free for all. Album (has more screenshots)

@micha So you're the reason the Win10 app icons suddenly swung like that just recently/mid-revamp? I noticed. I'm neutral about that issue but I do rather some tone and subtle extra hues in icons.

@The Aziz I think the two ??? buttons are: Controller for cycling between separate and parallel builds in the same [craft file/instance]. The thing that lets you avoid using re-root to do what you do with re-root in cases like building two very different probes and their shared launcher all at once. The devs explicitly told of such a feature. Subassemblies explorer.

Either you have TweakableEverything installed and that is somehow messing with OPT (It is known to cause some other very serious problems) or somehow you have 2x FAR patches affecting OPT. This is a known and very serious issue. This happens if you have OPT Reconfig (which includes a FAR config) and an OPT FAR config provided by another mod.

Noted.

I don't know better (I don't code) but I think this is among the much easier of plugin mods to do. I've seen prototypes or proposals for such mods so definitely this could happen. But I can't help you to make this mod a reality. It's up to you, if you're willing and able, to learn to do C++ (or if you already can) to find plugin mod makers who can spare the time to teach you.

@Kartoffelkuchen KK adds quite a lot of functionality for what it offers. Most space centers that players build likely won't offer anything other than launch sites and -maybe- more groundstations. But there are so many other great features and specially some great fixes that happened just after KSP 1.8 came. Animate on sunrise Animate on click Hangars (craft storage) kinda like Allista's mod. (Put craft away, but for KK, up to a set limit of number of craft and tons per craft) Funds farm Science farm Refueling (buy/sell for $ in career mode) Resource caching Integrated Landing System (only works well when a given base or "group" has only one runway). It would be pretty neat if someone produced a lightweight alternative to KK, I know there's demand for it, but I wouldn't bet on it providing a significant fraction of the feature set listed above. It's just the kind of mod where once one exists, it becomes huge, and no one will ever want enough to build another mod like it, or be able to meet the immense coding requirements to build another one. It easily looks like too much effort to re-invent the wheel. They'll just use the one mod and complain to its dev (or about its dev ). Examples of the exception/ Examples where this rule doesn't apply are: Rocket part mods Small and medium QoL mods like dV calculators, autopilots, and transfer window planners The obvious answer is: Squad created KSP. Of course Squad will be able to create the means within KSP to perform X feature. But just how Squad does things is typically hush-hush stuff. Also consider that there are times where Squad makes a feature that's very difficult or just wasteful for the modding community to prepare to take advantage of: [Difficult] Breaking Ground's ROCs: It's impossible to add feature rich objects like these, and the ones that are given are hardcoded to the stock planet templates. (Every mod planet uses the template of a stock planet for underlying functional details.) So you can't put Vall's cryovolcanoes on a mod planet that's not using the Vall template.-- You cannot mix them like: put ROCs from Eve, Duna and Minmus together on the same body. In response, Kopernicus introduced a feature that lets you lock modules until you're near to certain scatters. This especially applies to experiments. The only things DLC ROCs have over this module are that the ROCs animate and you can chip off a chunk and pocket it. [Wasteful] Making History's launch site selector and selections: Uh. They're not impressive. I built KK bases to challenge them and directly replace them. KK provided the necessary features long before MH existed. I personally find it weird when folks complain in favor of MH over KK. [Difficult] The fancy planet shaders: You can bet money that the Kopernicus devs got some gray hair trying to understand the inner workings of these. [Difficult] The planetary system: Kopernicus' ability to change this is not to be taken lightly. [Wasteful] Variant switching: This is a wasteful one could have been a fuel switcher in addition to mesh switching, and would help to unify the modding ecosystem just a little more (maybe). Other mesh switch mods (B9, Firespitter, Interstellar, decal mods) could have evolved to become extensions of this, however, variant switching made itself irrelevant right out the gate.

Easily done. I believe I can use thrust curve to force the electric mode to die when EC levels reach a certain minimum. I would make this into the inline ducted fan (suggested above), maybe as an upgrade (or not) to the Hartzell turboprop I've shown above, and maybe an airliner engine smaller than the stock J-90. I don't think I want the GE36 to be hybrid. And the Antonov engines definitely won't be.

Extraplanetary Launchpads allows for creating build recipes of any sort, and each part can be assigned to a recipe to fulfill the needs for unique material combos to build each unique part. Progression can easily be restricted to having EL workshops with varying capacities spread throughout the tech tree. The better you unlock, the faster you can build with the same number of kerbals. As for resource placement that's easy enough (but can be very tedious) to do without writing a plugin. And the experiment functionality exists in Wild Blue Tools. At the space center, the mod Kerbal Construction Time makes you take time to assemble a rocket and to roll it out onto the pad. But good luck convincing LinuxGuruGamer to add this kind of complexity to it. Overall your idea is pretty nice. I will say that. I too have had ideas for some of these elements for a progression overhaul.

@Felix Daines EnrichedUranium (that is, actively radioactive material, typically in the form of long and heavy rods and which will irradiate everything and everyone around it if its container, the reactor, is opened) is by definition not allowed to conveniently pump around between parts. Same goes for its used up form "DepletedUranium" or "DepletedFuel." I can't help you with MKS itself, but Near Future Electrical has a plugin for transferring these around. But you'll be introduced the needs to wait for the reactor or container to cool down enough, and for a high level engineer to do EVA actions on the source and target parts.

Hey mcdouble. You may want to consider making stack nodes for these wings. These nodes will need to be oriented forward or backward like with any inline hull piece then with the necessary slanting so that the wings snap on perfectly-- not to be oriented pointing inward from the wing/outward from the hull as that will still leave an issue of rotation in one axis which leaves a window open for phantom roll to plague people's builds of your craft. Go back to using ModuleControlSurface and ignore when the elevons clip into the hull when they're moving to provide pitch and roll. This is the module for elevons, after all. Airbrakes, by nature, will work well for yaw control (see split elevons serving as airbrakes in flying wings) but not for pitch or roll. ModuleAeroSurface was therefore not written to accommodate this use case. Us part makers just have to deal with it, sadly. Yeah that'll give you a few gray hairs. I haven't the energy to do anything about that, though. I'm very sorry. But I can tell you that stack nodes may be something to avoid while figuring out the wheels.

@Lisias That restriction may have an association with the issue of number of seats in the IVA space (when one exists). If you up-scaled a crew part and CrewCapacity increased, where will the extra kerbals appear? Players might go looking for them and then complain about that, in which case it's good that this restriction exists. Also... "Tweakscaled IVA space." Think about that for a minute.

I'm not much of an active pilot here but what I can suggest is to develop a pattern or strategy for reentry. First ensure that your spaceplane can hold its AoA and survive reentry then test your plane with different initial periapses (depending on how shallow or steep you prefer). Typically the safe limit of your dropped periapsis is 35km. Once you have that, take note of the relative longitudes of your craft when you deorbit; where you put your periapsis; where your periapsis moves to at the end of the reentry; the KSC. Once you meditate on this enough and repeat it a few times you'll be able to discern the best location (longitude) for your braking burn when the real reentries (as part of your missions) begin. Install airbrakes on your spaceplane, but don't have your stopping power centered on them. They should always be a reserve for when you need them. Also the stock one is most effective at 15 ~ 20km altitude where it can really grab the atmosphere, meanwhile, you're not moving so fast that they'll threaten to melt in seconds of opening. In the event that you catch yourself about to overshoot the KSC by a large amount, prepare to do S turns well in advance or dive down a bit and grab onto some of that extra drag potential to help you slow down. I typically take it as a very bad sign when I'm 100km from my target and closing in at Mach 5. While this is a bad thing at first, it's better to have excess momentum and overshoot than be short on momentum and have to spare dV for when you undershoot. Be advised that variables in your craft design will require you to adjust your pattern a little or a lot. A very large plane can't use the same parameters as a very small one. A very stable spaceplane (its CoL very far back) can't use the same parameters as a very unstable or maneuverable spaceplane (its CoL very near its CoM). If you're not already the kind of player who deals with standardized crafts, and you have a unique design for every occasion, you're going to find yourself wanting to retire most of them in order to avoid developing this reentry pattern and remembering the parameters for all of them.

It works just fine. But you must install WorldStabilizer too or some of the cargo bays will cause your craft to spawn 1km in the air. This is a problem since KSP 1.4