li7in6

In the readme under the changelog for 10.8.5 it indicates the throttle response speed is tuneable in RealSettings.cfg and in per-engine configs. I've looked in these and cannot figure out any settings that directly effect the engine spool up and response behavior in game. I thought it might be under the tech level settings as TLTHROTTLE# but changing these values doesn't seem to have an effect. I have also changed the useEngineResponseTime and engineAccelerationSpeed/engineDecelerationSpeed values on a per engine basis with no effect. In the changelog for version 10.6 it mentions using throttleResponseRate for tweaking engine response rate. However this entry is not present in any of the configs and adding it seems to have no effect. I am trying to create my own engines mod and am struggling with the inbuilt engine response and spool up behavior from realfuels that should not be present for certain types of engine. Any help would be appreciated.

You seem to be confused with how trim works on real aircraft. The simplest mechanism for adjusting trim are trim tabs (small control surfaces) mounted to the larger primary control surfaces. These tabs do set trim by changing the ''default' neutral position of the primary control surface. The trim tabs essentially "fly" the primary control surface at a new neutral position which in-turn adjusts the relative aerodynamic forces produced by the airfoil it is mounted to. This technically DOES reduce overall control surface travel in a given direction dependent on the amount and of trim imposed. But trim adjustments are typically so minor relative to the large amount of control deflection this is never an issue. A control surface has a finite amount of design deflection within which control authority can be achieve, including the trimming of the aircraft. The less common method for trimming an aircraft which is used on heavier aircraft with hydraulic and/or computer actuated control surfaces is to forgo the trim tabs and simply fly the control surface via hydraulic actuation at whatever amount of defection within it's limits in order to trim the aircraft for the desired flight characteristics. The effect at the control surface is the same as if the pilot were applying the desired amount of pressure on the controls constantly, but obviously this is not the case, it is just a matter of adjusting default position for the hydraulic actuators. But practically to the pilot the effect is the same as the trim tab method. In either case, the absolute position of the primary control surfaces within their range of motion is changing to adjust trim. Thus affecting the amount of additional degrees that control surface is capable of deflecting from it's neutral (for that trim setting) before hitting it's design limits.

Understood. Slightly unrelated but a general request. Do you think you can put in a single/stand-alone SL and vacuum version of the Raptor engine and single SL version of the Merlin?

My mistake, I thought you were announcing 1.1.1 release a few posts above. I'll delete.

-Redacted-

It appears to work in 1.4 except the Rodan capsule is bugged where it is in zero gravity on the launch pad, all reaction/rcs/thrust inputs do nothing.

Not sure if there is any interest in this beyond plebs like me but figure I might throw it out there. Would it be beneficial to throw some instructions in the first page on "de-real" this mod with some regular expression config edits to take away the really difficult parts and prevent people from having to rely on other simplification mods that may or may not stay updated. Namely ullage, ignitions, and throttleability are what I find really sucks the playability out of this mod for me. Find/Replace in files in the realism overhaul folder with notepad++: Remove ullage requirement for all engines: ullage = .* ullage = False Remove ignition limit for all engines: ignitions = .* ignitions = 100 Allow full throttle-ability for all engines: minthrottle = .* minthrottle = 0 I really appreciate and enjoy all the work that went into this mod but I find the supreme realism really frustrating in certain respects and turns my play sessions into long periods of success followed by a sudden outburst of rage and failure when I put myself in an unforeseen situation or mess up in some way. The above three changes really make this mod much more forgiving in-line with the stock game while retaining the other more interesting (to me) aspects of a realism overhaul.

Not sure if you're aware or if this is part of the bug but using forced surface attach mode with the editor extension mod for some liquid engine's (like KW) causes them to appear halfway clipped into the stretchy tank. This means you have to use cubic struts to get an engine cluster setup on the bottom of a tank. Not a big deal just thought you should know about it.

Anyone else have an issue when trying to radial mount Stretchy SRB's like in metaphor's pics? When I do it, initially it works fine and the first launch they're where they're supposed to be. But on a reset or if I load back into the VAB the SRB's are floating out a couple meters from the radial couplers. I'll get a screenshot.

Used small cubic struts to attach the motors to the bottom of my fatty fuel tank. She gives me JUST enough to nudge my ~50 ton moon payload into orbit. Not enough to actually send it to the moon though. Need to tweak it more to get it mission capable in one launch... Or refuel in orbit. Edit: Nathan. That fixed it, thanks!

Ah yes, that's where I've seen that functionality. I've been using pfairings but never used it in that way. Tried it out and while effective it is a bit clunky to implement, what's e-dog's mod called/going to be called? Also, I've been experiencing some inconsistency in launches and I don't know where it's coming from. For example I'll build a LV with a surface TWR of about 1.35 that weighs about 1200t. First launch everything is fine it slowly lumbers into the air at full throttle then half way up I'll do something dumb like hit spacebar too early and it will disintegrate. Reset on the launchpad from Esc menu (same craft), launch at full throttle, and now it rockets into the air and mechjeb shows a TWR of ~2.2 then the TWR will drop back down to 1.5 or so and start climbing again as I burn off fuel. I haven't been able to note total weight yet when this happens as it's pretty inconsistent. Edit: Just recreated it and mass is consistent it's thrust that's starting out about 10,000kN (~25,000kN) higher than it should be and quickly falls down to where it should be (~15,000kN) about 10 seconds after liftoff. LV is using 11 KW Maverick-V's. When it loads out of the VAB it seems to have the correct thrust, but on resets it does this. Pics to clarify, just before and just after launch out of the VAB: And here's right after a launch from an Esc Menu reset:

Nathan, one thing I can see a big use for is some sort of procedural tank that allows the smooth adaptation between various diameter stages (changing the diameter of both faces independently). For instance RSS sometimes requires very large diameter lower stages to get the dV to get larger payloads to orbit, however there is no good way to aerodynamically adapt from say: a 3.75 meter upper stage to a 6-8 meter lower stage. I seem to recall stretchytanks allowing this but I can't remember. If this is already a 'thing' and I'm just missing it somehow let me know.

redacted...

Oh really? MFS does isp thrust correction? I was having issues with StretchySRB's being incompatible with KIDS thrust correction and was trying to work out an exclusion workaround. But if that functionality is already in MFS then I'm just wasting my time. Guess I should pay more attention.

Can confirm KIDS thrust/isp correction is incompatible with the stretchy SRB's themselves. Any workaround? On my machine it defaults to stock-ish thrust (50kN) and the SRB's have a ridiculous burn time.

Sure, I definitely like the sound of the new model. Let me know. Also, a note. RT2 with RSS causes some problems with stock probe bodies not being able to communicate "home" from the launch pad. Stock RT2 they have 3km range but it seems KSC is 15-20km away from where RT2 thinks it is. I think I read you moved KSC closer to the ocean so it's probably just that. I included the RT2 probe config in my dropbox link with their values moved up to 20km so that should fix any problems you might have had with your probe being uncontrollable on the pad without the passive antenna (DP-10). I also changed the launch clamp range to 20km so it should work as intended now too. Dropbox Link

Sorry for the delay, I went to bed the other night then figured I should probably do a better job rebalancing the numbers. Tried to follow stock RT2 balancing as close as is feasible (less going off part descriptions) with less of my personal twist which people might not like. Although this way there is a bit of overlap/redundancy with several of the smaller dishes/antenna. This is balanced current as of the 5.1 RSS mod. Passive probe ranges upped to 20km to account for distance KSC was moved with RSS. The antenna ranges are as follows: DP-10 [RTShortAntenna1] 2,000,000 meters. Communication to the edge of LEO (LKO?) Communitron 16 [LongAntenna] 45,000,000 meters. Communication to just past geostationary orbit. EXP-VR-2T [RTLongAntenna3] 54,000,000 meters. Reaches about 20% further than the Communitron 16 Communitron 32 [RTLongAntenna2] 80,000,000 meters. Just under twice the distance of a geostationary orbit. Won't get you to Mun. DTS-M1 [MediumDishAntenna] 1,250,000,000 meters. About 1/2 the range of the SS-5. Will easily reach Mun. SS-5 [RTShortDish1] 2,500,000,000 meters. Communication anywhere in the Kerbin SOI and then some. Communitron 88-88 [CommDish] 400,000,000,000 meters. Interplanetary class. Shorter range than the LL-5 but will still reach to Duna and then some. LL-5 [RTLongDish1] 650,000,000,000 meters: Interplanetary class. Just under twice the range needed to reach Duna. Can get you to Jool with the right planetary alignment. CommTech-1 [Gigadish2]: 3,000,000,000,000 meters. Interplanetary class. Should get you talking out to Minmus in all but the most extreme cases. GX-128 [GigaDish1]: 6,000,000,000,000 meters. Interplanetary class. Should get you talking out to Vall in all but the most extreme cases. Dropbox Link Drop configs in RemoteTech2 folder.

I changed them to reach just past the body of their intended use. i.e. the big dishes reach just under and just beyond the farthest orbiting body, the LL-5 just beyond Duna from Kerbin, Communitron-32 just beyond geosynchros orbit, SS-5 just beyond Mun, etc. Not sure what the policy is on sharing other people's config files here? Should I just post the new distance values or upload the config to dropbox?

If anyone's interested I've done some back of the napkin adjustments to remotetech 2 antenna/dish range's to better fit the new solar system scale and still fall in line with their description/assumed intended usage.

Challenge accepted.

I made a quick Delta IV analogue (using stock and KW parts) and used a 1km turn start and 200km end with a "50%" profile. Seemed to work out fine. This mod just rubs in how much dV is needed to get up to real(ish) Earth orbital velocity even after you make it up to 100km altitude compared to stock KSP. Of course these settings will depends on your ISP fixer settings and any changes you've made to part configs.

Is the inclination of the Mun supposed to be this extreme?

I registered just to comment on this mod as I think it's a fantastic idea. I understand the current issues with this mod (and general realism modding in general) have to do with the way the game handles space ship size, the required dV to carry out realistic missions, and the resulting size required of ships. I wonder if instead of scaling the planets up to match in the in-game parts/distance. If it would be better to scale the in game parts/distance to the planets. For example setting a standard to scale to (easy/obvious one would be Kerbin) and scaling the rest of the game as if Kerbin was an Earth sized planet. This would mean an across the board recalculating of in-game units by a factor of ~10.9. Then modifying the scale/orbit of other bodies in the system would be mostly trivial based on what is currently done with this mod. This would have the beneficial effect of an across the board reduction of the in-game size of spacecraft as a matter of scale (potentially easier to handle by the engine), increasing the usable size in the VAB/SPH (10.9 times as much space!), and keeping planetary body textures scaled correctly. Conceivable problems would be obviously figuring out an intelligent way to rescale all in-game measurements, rescaling all GameData parts down, possible compatibility issues with mods taking units at a low level and being incapable of handling the rescale (mechjeb), potential unforeseen physics/collision issues from really small parts, etc. I realize from a game development standpoint units and scale are arbitrary but from a practical modding standpoint using preexisting assets and rescaling the game around these assets might make more sense. Especially when the realism mod direction will necessitate things like more space to construct spacecraft, potentially massive rescaling of planets/moons, and greatly expanding the solar system to meet realistic astronomical distances. Essentially rescaling gameplay to fit 'the box' we're given in a realistic way instead of trying to expand everything within 'the box' and potentially ending up with having to cut corners and run into a plethora of issues when things like ships, and orbits get to big for 'the box'. If that makes any sense. I'd do some experiments to see if this was feasible but it's unfortunately beyond my skillset.

I'm having a problem with the Kethane nodes not showing up on the grid at all. It shows the white nodes when nothing is found but when a kethane node is found it simply does nothing on the map screen and leaves a hole in the detection grid.