Phineas Freak

You do have a log, it is under your KSP installation folder ("KSP.log" or "Player.log"): Second, have you installed VSR? If so, is it the latest official for KSP 1.1.3 or the unofficial for KSP 1.2?

ModuleManager is your friend here

@kerboman25 Correct, to change the Isp you have to change the key values listed in the "atmosphereCurve" nodes (global config). Just make sure that your sources make sense .

Yep, new bug probably from the KSP 1.2 update. Pinging @KortexM, @e-dog.

@kerboman25 Correct, the Soviet Engine Pack does not include an RD-0210 engine. You have to specify a different source part (e.g. RD-0124). And yes, TEATEB is not needed here. You can remove it from the global engine config but remember to remove both the IGNITOR_RESOURCE and the RESOURCE nodes for it.

@kerboman25 As with before, i cannot help you if you don't provide your work files.

If you have copied any files from the original engine then they are not needed now and you can delete them. The required files are all included within the Soviet Engine Pack. The first config is a patch that copies the existing RD-191 engine and then modifies it to act like a RD-291. But the magic happens inside the global engine config, as this is the file that sets the engine parameters. To define what engine the part should use you need the "engineType" value to point to a valid engine config. It seems complicated but in fact it is a really simple and clever way to reuse code.

@kerboman25 use these and tell me if they work. I cannot test them now. Save them as .cfg files and drop them anywhere inside your GameData folder. Part config: // ================================================== // Copy the RD-191 engine to make our own. // ================================================== +PART[RD191_StockVersion]:FIRST { @name = RD291 } // ================================================== // RD-291 engine. // ================================================== @PART[RD291]:FOR[RealismOverhaul] { %RSSROConfig = True @MODEL { @scale = 0.47, 0.47, 0.47 } %scale = 0.47 @rescaleFactor = 1.0 @node_stack_top = 0.0, 2.125, 0, 0.0, 1.0, 0.0, 2 @node_stack_bottom = 0.0, -1.840, 0, 0.0, -1.0, 0.0, 2 !node_attach = NULL @attachRules = 1,0,1,0,0 @category = Engine @mass = 1.85 @crashTolerance = 10 @breakingForce = 250 @breakingTorque = 250 @maxTemp = 573.15 %skinMaxTemp 673.15 %engineType = RD291 %engineTypeMult = 1 %massOffset = 0 %ignoreMass = False @MODULE[ModuleEngines*] { @minThrust = 565 @maxThrust = 2090 @heatProduction = 100 %ullage = True %pressureFed = False %ignitions = 4 @PROPELLANT[LiquidFuel] { @name = Kerosene @ratio = 0.349 } @PROPELLANT[Oxidizer] { @name = LqdOxygen @ratio = 0.651 } @atmosphereCurve { @key,0 = 0 337.5 @key,1 = 1 311.2 } } @MODULE[ModuleJettison],* { %isFairing = True } } Global engine config: // ================================================== // RD-291 global engine configuration. // Sources: // http://web.archive.org/web/20140705154556/http://www.npoenergomash.ru/eng/engines/rd191/ // http://www.npoenergomash.ru/dejatelnost/engines/rd181/ // http://www.spaceflight101.net/kslv-stsat-2c-launch-updates.html // Used by: // Bobcat // ================================================== @PART[*]:HAS[#engineType[RD291]]:FOR[RealismOverhaulEngines] { %category = Engine %title = RD-291 %manufacturer = NPO Energomash %description = A smaller RD-191 to make a reusable engine with high efficiency. Diameter: [0.9 m]. @MODULE[ModuleEngines*] { %EngineType = LiquidFuel } !MODULE[ModuleEngineConfigs],*{} MODULE { name = ModuleEngineConfigs configuration = RD-291 modded = false origMass = 1.85 CONFIG { name = RD-291 minThrust = 325 maxThrust = 1060 heatProduction = 100 massMult = 1.0 ullage = True pressureFed = False ignitions = 4 IGNITOR_RESOURCE { name = ElectricCharge amount = 0.5 } IGNITOR_RESOURCE { name = TEATEB amount = 1.0 } PROPELLANT { name = Kerosene ratio = 0.349 DrawGauge = true } PROPELLANT { name = LqdOxygen ratio = 0.651 DrawGauge = False } atmosphereCurve { key = 0 337.5 key = 1 311.2 } } } @MODULE[ModuleGimbal] { %gimbalRange = 8.0 %useGimbalResponseSpeed = true %gimbalResponseSpeed = 16 } !MODULE[ModuleAlternator],*{} !RESOURCE,*{} RESOURCE { name = TEATEB amount = 2.0 maxAmount = 1.0 isTweakable = False } }

Forget it. My mistake.

You mean that you created a new part via MM? If so, can you post this config? The modified engine config comes from RO? If so, can you post this config too? There is a specific parameter (RSSROConfig) that flags the parts as being compatible with RO. Have you specified that in your original part config?

@EstebanLB In order to fill a tank with the correct O/F ratio for a specific engine you need to attach the engine to the tank. No (easy) other way around.

@NemesisWolfe are the "SC-ADPT1-BEIGE-DIFF" and the "SC-ADPT1-DOS-NRM" textures placed inside the "SSTU/Assets/SC-ADPT-3-2-FLAT" folder (along with the model file)? If not then you need to create template textures for them (8 x 8 px "images" will do the job).

The launch windows are instantaneous because that's how they were computed in the first place: the launch profile (pitch/yaw table) for a specific orbital target and payload mass generally remains the same but the actual launch times (azimuth) are computed for specific time intervals and then uploaded to the flight computer(s). This also happens for missions that have large launch windows. They always target the opening of the window. If a delay occurs then they will use the next pre-computed sub-window (and so on), till the closure of the main launch window. Performance for most launch vehicles is there but the compute capability of most flight computers is not, and that's what it is limiting real-time astrodynamic calculations. For example, Delta IV cannot do yaw steering because both the CPU power and the program memory are limited. Soyuz was until recently required to be physically rotated to the correct launch azimuth before launch due to the analog nature of it's astrionics. Edit: the pre-flight computed trajectories may theoretically be infinite but only a single one is actually verified and uploaded. Any dispersions are corrected based on the performance of the launch vehicle and the target orbital insertion point.

I second this. Having more than one EVE config nodes in the game database (be it for clouds, terrain, city lights etc) breaks EVE badly, even when they do not refer to a specific body (KSP loading is halted). It would also make installation and interoperation of cloud packs a bit (or a lot, depends on the configs) easier.

RO does not have a compatible version for KSP 1.2 yet. You will have to wait until the RO team updates it (SoonTM). RSS on the other hand is compatible and it's working perfectly.

@The-Doctor i think that it is possible via Sigma Dimensions (SSRSS has a hard dependensy on that mod). It will take care of the cloud configs but: they might need some tweaking afterwards Scatterer configs are not covered by Sigma Dimensions So the end result might not be good. I don't think so, the RSSVE cloud textures are either public domain or (almost) hacked together. I wish i would be more proficient with the various image editing programs.

@dave1904 these are extra attachment nodes like the ones found in the stock fairing bases. Right click on the PF base and you will find an option to enable or disable them (Interstage Nodes).

@Heady978 you can add extra cloud layers via the EVE GUI. Check the included cloud configs for more info. @Ninadragonborn RSSVE has nothing to do with any of these bugs that you are reporting here. This one is just a visual addon for RSS, nothing more. If you have issues with RSS then it is not my problem and you should report them to the official RSS thread:

Oh, that's how engines (and stages) attach in RSB. Due to some KSP quirks regarding the strength of the attachment nodes and the size of the RSB parts it was much better to make the actual stages be the attachment points than using the engines (like in stock). There was a small discussion about that in the last two pages or so of this thread.

I believe that if you hold the engine before attaching it and press the Mod key (Alt for Windows) it will only attach on normal nodes (and ignore any kind of surface attachment).

Mathematically no, the stock KSP densities are too high compared to real propellants. The end result (payload to orbit) is comparable to real (and not 100% as i wrote, mea culpa). Stage fractions will not be the same of course, as the densities differ. Edit: the best thing would be to open a request to the RFStockalike thread (or GitHub and) request to add support for RSB. Or manually strip the RO engine configs out of RO and add them to as MM patches to RFS.

@Winchester i think that the closest that one could do is the PP parts that @Azimech develop(ed): If you are lucky enough then you can get it to approach the oval shape of the Mk2 parts. But circular parts with specific flat surfaces (like the Mk3 parts) or with non-symmetrical shapes are not currently possible. Maybe maybe in the future someone will refactor PP to support arbitrary shapes. (still, i have no idea how non-circular parts can be done via the current PP, it would be ideal for Atlas-style side boosters)

Thought that your problem was the wrong propellants but as i see now i was wrong... The RO configs have nothing to do with RF or RFS. Well, to make it more specific: the RO engine configs are exclusive for RO. If you select to play without RO then you need a pack (like RFS) to make them compatible with RF. The problem here is that nobody has ever made engine configs for RSB to be included either with RF or the RFS compilation. TL;DR RSB is not directly compatible with RF and somebody has to write configs for it to be so. In the bright side, RSB is 100% accurate with real hardware, meaning that LF+OX will have the same results as LH2+LOX (but without boil-off).

By opening your favorite browser, entering "download realism overhaul" in your favorite search engine and doing a "Search". I guarantee you that the proper link will be between the first and the second result.

@delta wee finally traced it: seems like that RFStockalike has a "Jet_modularEngines.cfg" file and for some reason this config patches every single engine module that uses "LiquidFuel" and "Oxidizer" to use "Kerosene" and "LqdOxygen" instead. Offending patch link If you remove these two patches then eveything should be good.