NathanKell

The only pitfalls to that would be catching ElectricCharge or IntakeAir propellants. (Xenon presumably you're fine with making STACK_PRI). In addition, SolidFuel should probably be left as NO_FLOW, unless you want it grabbing the solid fuel from other motors.

Raptor831, would you mind chiming in here? http://forum.kerbalspaceprogram.com/threads/91998-0-90-Community-Resource-Pack-0-3-3-2015-01-27?p=1761371&viewfull=1#post1761371

Answered in the CRP thread. Apologies for delay.

Apologies to all for my absence; my net was out earlier, and then when it got back, RoverDude caught me on IRC and we hashed some stuff out. Basically, RF has two reasons for using STACK. They are: 1. Crossfeed must exist (no getting fuel magically after six steel plates, you have to actually run a fuel line there). The problems with KSP's lack of bidirectional crossfeed are mostly solved by CrossFeedEnabler, and it could be extended to make bi-directional fuel lines I'm sure. 2. Non-STACK modes have a hard clamp of 1e-5 units per physics tick. If you request less than 1e-5 units, whether you are sending or receiving, your request is summarily refused. This means that if you twitch a reaction wheel only slightly, it will not produce anything because it doesn't request enough EC and thus gets a "no EC left" response. If your antenna requests less than 0.0005 units of EC per tick, well, it thinks it's out of power because that's refused. STAGE uses the same logic as ALL_VESSEL for that. Now, in talking with RoverDude, here's what we came up with. 1. RF will depend on CRP. 2. RF will remove, via MM, any "non-real" resources. 3. RF tank code will still implement boiloff etc. 4. Realism Overhaul will be the thing, not RF itself, that changes cost and flow mode of resources; if one does not have RO installed (like all the RF Stockalike players, who play stock career) they'll get stock-career and stock-CRP prices and flowmodes, unless RF Stockalike changes them. However, that bit will need signing off by Raptor831, since Raptor would have to add flowmode overrides to every single engine and RCS...

Sorry? You still do, and RP-0 continues to have a configuration for NoMoreGrind. Not sure where you might have seen anything related to that in the changelog...

Just to reinforce Crzyrndm's point: the only way to really know how much wing you need is that panel. You can input whatever speeds and altitudes you like; I would suggest first checking takeoff. Increase Mach (and hit calculate) until your AoA is reasonable. If the m/s turns out to be more than 120 or so, you need to add flaps or more wing; 270mph is rather fast to be taking off. Then test up at your cruising altitude and speed, maybe 10km and mach 2? See what the AoA is like there. If it's more than 5 degrees, worry.

Before you write off EL changing, I suggest you just ask taniwha, he might be fine with 1L.

Wow, I misread that rather badly. Only way to get hi-res planet textures is by doing what Chris did but in color, or using the built-in CreateMaps() method that he despises. You can't get the existing scaled space textures (unless you dig in the assets) because they're loaded (and set to read-only) before plugins are, to the best of my knowledge, but besides they're only 2048x1024.

https://github.com/Pingopete/RVE-KSP-0.90/wiki/Installation-Instructions

There are two ways to do this: 1. Replace MultiModeEngine and its two ModuleEnginesFX with a single ModuleEnginesFX and ModuleHybridEngine module. That lets you switch configurations on the fly (it's basically a ModuleEngineConfigs where you can change config in flight). That is suboptimal in this instance. 2. Add two ModuleEngineConfigs modules. In one of them, add engineID = (engineID of the first engine) and vice versa for the other. You will then get two GUIs in the editor, so you'll have to select the same fuel mode for both, but...does what you want. (A few versions back I added support for multiple MECs on a single part. They can apply to a certain engineID or, if the part uses multiple ModuleEngines [with no ID] they can base off index.) Here's an example, set up for SXT's X-405 engine. https://github.com/KSP-RO/RP-0/blob/master/GameData/RP-0/SXT_Engines.cfg

I highly recommend you all watch where Mike talks about how planets/moons are made.The voronoi crater system is just another PQSMod, same as the heightmap mod (which, let me point out, only some planets have) or simplex noise, or whatever. The terrain is already procedural for all planets and moons; the question is which mods are applied. (Craters also aren't scatter; scatter doesn't support deformation anyway, just adding static meshes atop the terrain.)

The interface in EVE was by mod-N, IIRC, the one in EVE Overhaul is mod-E (alt-E for windows, either mod-E or still alt-E for nix).

Do you have an RSSTextures folder?

RF picked 1 unit = 1 liter for good reason--not just because the math gets much easier, but also because of how KSP clamps resource transfer so less resource per unit is very good. TACLS did the same thing, I think for the same reasons. Now, as to how to proceed. I obviously don't have a stake in CRP, but there are certainly players who want to have both RF and CRP-dependent mods in the same install. That gives rise to, IMO, three options. 1. Things stay as they have been: CRP defines its own resources, as does RF, with names that don't collide. That means that we have to deal with the silliness of converting between Ammonia and LqdAmmonia, but it means we're not defining the same name of resource twice (that's very bad). 2. We entirely give up on any kind of interaction; CRP and RF are left in a "use one, not the other" state. Since our aims are very different, that won't affect that many people, but it will affect some. 3. One side adopts the other's convention. All three routes have obvious downsides. The "feel" of RF is very different than CRP and CRP-related mods (regex once referred to it, the last time this got discussed, as "realismz!" vs "lolsokerbal"), so us standardizing might not make sense. It also, of course, doesn't make sense to have two sets of resources floating around that do the same thing, and it would further be a problem to have things colliding and completely incompatible. As to RF itself, RF must not compromise completely-real densities for things--even were I to accept the use of returning to 5L units, which I don't (I think 1L makes more sense for a real-resources world, just as 5L makes more sense for a kerbal world), RF certainly would need 100% real densities for whatever volume standard it uses. I'd be interested to hear your-all's thoughts on this.

The diffuse and normal maps used for scaledspace are linked to in the material applied there, yes, but they're marked as unreadable so you can't extract them. But we were talking about the heightmap, which is neither of those.

Severski I-15 “Fireplug†(Aug 1937): The successor to the I-13, the I-15 was perhaps Alexander Kartvelishvili’s finest achievement. Entering squadron service in August 1937, with volunteer units flying it in the last months of the French Civil War, the I-15 was in an entirely different class from earlier hunters. Much larger than its contemporaries--tipping the scales at over four tonnes dry--Kartvelishvili was said to have remarked on designing it that “it will be a dinosaur, but it will be a dinosaur with good proportions.†The reason for its size was due to the turbosupercharger it carried, mated to the most powerful engine Russia could produce. That allowed for an incredible armament of 2x 37mm cannon for anti-bomber and anti-panzer work and 2x 23mm cannon for general purpose use, as well as armor to match. Indeed, in contrast to the delicate General Electric turbocharger in the H-25, the turbocharger in the I-15 proved quite rugged, significantly more rugged than the models used by the Starship and Rapier or the Eule. All this meant that the I-15 was a juggernaut of the skies: hard to kill, packing an exceptional punch, able to out-dive any League piston-engine hunter and able to fight at altitude on even terms with the Falke and Rapier and nearly match the performance of the early Eule. It would fall to the I-15's successor, the I-15bis "Firebolt", to match the later Eule and the early League jets. I-15 Type 9: 10075lb dry, 13007lb loaded, 2350HP, 447mph, 2x 37mm and 2x 23mm cannon. I-15 Type 10, Russian "Volunteers", Italy, 1938.

The problem with reading real information on things is that KSP is decidedly not real. There are many mods available that make it behave more in line with real physical laws, but reading about real rocketry you will learn things that either do not apply (reentry corridors and the danger of reentry generally, boiloff, liquid hydrogen's low density, problems reigniting engines or throttling them), apply much more weakly to KSP due to how small things are (staging), or are wrong for how KSP simulates things (aerodynamics and what a gravity turn actually is, Thrust and Isp, etc). If you want to be able to apply real life knowledge to KSP, you at least need FAR. Just as a side note, you don't need a TWR of 2 at all once you're in orbit; you can make do with as little as 0.2 or so. Even getting into orbit you don't need such a high TWR; at least with FAR you'll do better with a first stage of starting TWR of 1.2 to 1.5, and an upper stage starting TWR of no more than 1.2.

v0.24 of RP-0, OTRAG, has been released. **Note this is a save breaking update. Engine parts have changed roles. You may have to rebuild your craft, and in the case of the AJ10 you will have to do more. Any vessels in flight with an AJ10-early will be removed.** This release brought to you once again with massive help from Agathorn. He's an official contributor now, but he still gets thanked for what he slogged through. - Add AJ10-104D config (Ablestar engine, restartable). - Switch to using SXT parts for the X-405 and early AJ10 engines. **NOTE:** Save-breaking, since the old "AJ10 early" engine no longer exists. Make sure no inflight vessels use that engine; you will have to recreate (or hand-edit) craft files using it. Sorry, but this one just looks soooo good and the old one was a placeholder. Requires SXT v20 for obvious reasons. On the bright side, the new X-405 has roll control from its turbopump exhaust jets! (That's the second "engine" listed in the part info window). - With all VSR engine changes backported to Realism Overhaul, and with an SXT X-405 engine, the LV-T30 is now once again the LR-105 sustainer. - S1.5400 / 11D33 configs moved off the RD-0105/RD-0109 (since they are unrelated) and combined with the RD-58 configs (RD-58 is a development of 11D33), which is now on the LV-T45. - Fix pricing for Redstone/Juno I engine (slightly cheaper in A-6/Redstone variant, more expensive in A-7/Juno variant). - Cost and place XLR-11 (X-1 and the like) and XLR-99 (X-15) engines. - Place and price F-1 engine. - Fix up RL10 configs and pricing. - Place and price FASA Gemini. - BevoLJ: Place and price Salyut stations and Soyuz ferries and Skylab (from Raidernick's mods). - Fix Flight Control node typo. - Place standard KW fairings in the start node. - Fix Bell 8xxx configs (Agena engine). - Add a new part, the Tiny Tim booster (for sounding rockets) from Agathorn. - Procedural SRB now unlocks with your first solid booster (Castor 1), not before. - WAC/Aerobee sustainer engine upgrades now cost money. - *We now recommend TestFlight for all your part testing/failure needs.*

In stock KSP, closing an intake lowers its drag (not to zero, AFAIK). FAR, quite properly, adjudges that nuts and leaves it the same. That's probably about correct--an intake is a pretty draggy thing, but "closing" it is going to put at best a low-fineness-ratio cone in the way.

Hotfix uploaded.

Changelog: v8.4 *Fixed stock KSP mass calculation (for engineer's report and for pad limits). *Added TestFlight integration support. *Remove KSPI config so that RF will no longer be a bottleneck. *Add support for per-CONFIG effects settings (running, power, or directThrottle FX not listed in the current CONFIG but listed in other CONFIGs will be turned off). *aristurtle: add support for TurboNisuReloaded. *Maeyanie: add missing SXT LMiniAircaftTail, Tantares tanks. *Raptor831: add Firespitter helicopter crewtank. *Raptor831, Starwaster: Fix & to , for MM. *ImAHungryMan: add support for missing tanks in RS Capsuldyne (Taurus), Nertea's Mk IV system, RetroFuture, SXT; Convert some Mk2 and Mk3 tanks to cryogenic and add missnig Mk3 tanks.

Here is a dll that hopefully has fixed the mass bug. Please let me know if it has not; I will be posting 8.4 (later) this evening unless anyone mentions problems. https://www.dropbox.com/s/0lbpr6sewbgxbub/RealFuels.dll?dl=0

NorthStar, as I said on the Real Fuels thread, I have literally no idea why you think I have it out for you. As to the patch itself, as I just said on the RealFuels thread, it is clear that my being busy recently and not keeping RealFuels on a development cycle which accords with your wishes means that the best policy is to not tie you to the RF development cycle. For that reason RF will not ship integration configs for KSPI. This makes no real difference to the patch code (whether a patch is part of RF and :NEEDS[WarpPlugin] or whether it's in KSPI and :NEEDS[RealFuels] ) but means I am not a bottleneck for you or FreeThinker. Apologies for having been one so far. I do hope to get 8.4 out tonight, having finally fixed the mass bug. I agree with you that engine packs should determine engine stats. RF attempts to ship no engine configs of its own, and it makes sense for part mods to do likewise.

Wait...do you have an earth heightmap hanging around? ScanSat gets its data from the game itself, and that would also explain your terrain issues...

Skyler4856, that's because you still don't have a properly installed texture pack. Please follow the instructions in the OP to download and install one.