NathanKell

camlost: noticed a few more problems in my J58 entry. Updated as follows: MODULE { name = AJEModule IspMultiplier=1 defaultentype=2 defineenparm= true acore=7.31 byprat=0 tinlt = 1700 tfan = 2200 tcomp = 2600 tt4 = 2700 tt7 = 5300 prat2 = 1 prat13 = 1 prat3 = 6.0 prat4 = 1 eta2 = 1 eta13 = 1 eta3 = .98 eta4 = .99 eta5 = .99 eta7 = .83 abflag=1 fhv=20000 } This is still to try to match the dry and wet SFC. Speaking of, I've run into issues with your J93. What source did you use for the stats? I have found the turbine inlet temperature is 2200F, and I've found one source that states, at least early in the YJ93's development it had an overall pressure ratio of 8.8. But on other stats I've come up short. However, I do have sources for dry SFC of 0.7 and wet of 1.8 which I have been utterly unable to match in AJETester with the rated 85 dry and 128kN wet thrust. In effect it appears to require eta3/4 > 1 and eta7 < 0.7 (although values < 0.7 seem to have no effect).

Well, you need to set the gimbalTransformName the same as what the ModuleEngines uses as the thrust transform. (Or, if the model is built such that there is a separate gimbal transform, use that; but few are.)

Stockalike configs is basically without a home right now, we need a volunteer to step up and maintain them. In other news: Changelog: v5.3 \/ *Fix DLL *Upgrade Kethane converter config to eadrom's. *Fix ModuleRCSFX compatibility to be non-destructive *Fix fixed launch clamp pumps (taniwha) *Upgrade to ModuleManager v2.1.0

It's actually higher than some of the overall pressure ratios I've seen quoted for the J58 (everything from 5 to 8.5; I went with 7.5 because it let me match SFC better). As you pointed out, there's no way to account for the bleed in EngineSim, so I just upped the max temperatures some.

Yes, KSP determines situation with them: if < threshold, in Low; else high.

Great! Your other option: add a check in OnStart to pull data from the prefab. This is what MFS/RF and ModuleRCSFX do, to get around stuff not being serialized correctly.

Vessels on rails should stay on rails unchanged, yes.

Not immediately seeing anything. Lemme ponder it some. Also, you might consider hopping on #kspmodders and asking around; maybe someone else has an idea?

You don't need (or use!) Blender to retexture things. You need an image editor, not a modeling program. Use mbm2png (from spaceport http://kerbalspaceprogram.com/mbm-to-png-file-converter/ ) to convert the mbm to png. Rename it something new. Using the above instructions, make a part that references the old model but points to the new texture. Then edit the new texture in an image editor (GIMP and Paint.Net are both good free tools).

Oh, I heartily agree! I definitely do that myself.

Kyle: Then you, um, might want to change the license. Since according to its terms it *is* ok to make derivative works (or redistribute unchanged) so long as attribution is given and redistribution/derivates of those works fall under the same terms.

Units are presumably texture coordinates, so the leftmost coord will be 0 and the rightmost 1.0 (or vice versa if mapping is flipped). Thus 0.25 will offset the texture 1/4 the way around (i.e. 90 degrees).

ATM does actually improve visual quality (assuming you unclamp texture rez and leave both scales at 1): in particular, it will generate mipmaps for some textures that lack them due to KSP loader issues. Also, it will detect and leave normal maps *uncompressed*, even if they are PNGs (which KSP compresses by default). Also note that without ATM any TGA will not be compressed by KSP's loader, even if they are not used as normal maps.

Here's the repo. For the J58 you'll need both the part cfg and my retexture of the B9 turbojet. AJEcode: IspMultiplier=1 defaultentype=2 defineenparm= true acore=6.75 byprat=0 tinlt = 1700 tfan = 2200 tcomp = 2600 tt4 = 2900 tt7 = 3600 prat2 = 1 prat13 = 1 prat3 = 7.5 prat4 = 1 eta2 = 1 eta13 = 1 eta3 = .968 eta4 = .99 eta5 = .982 eta7 = .96 abflag=1 fhv=20000 For the afterburner, I sped it up a bit and increased emission slightly. I've also now made it a bit larger (since the pic was taken). MODEL_MULTI_PARTICLE_PERSIST { name = bninejet modelName = MP_Nazari/FX/flamejet3 transformName = thrust_transform emission = 0.0 0.0 emission = 0.6666 0.0 emission = 0.6667 0.4 emission = 1.0 3.2 speed = 0.0 3.96 speed = 1.0 3.28 scale = 0.0 1.2 // Rescale the emitters to +0% scale = 1.0 1.8 // Rescale the emitters to +0% energy = 0.0 0.05 // Same for energy energy = 0.7 0.21 // Same for energy energy = 1.0 0.99 // Same for energy fixedEmissions = false }

Thanks! Mettworks. I had to fix it up a fair bit, and repainted the texture some. It'll be in RftS Pack v3.

This looks awesome! Even better than Engine Thrust Controller for simulating solids. Given that this, too, will be writing to thrust, (and thus there can be only 1, I think), could you also do thrust curves? I..e. when sum(amount_of_SF_available) / sum(maxAmount) = x, thrust should be y% of stated maxThrust.

Per pages 73 and 74 of the HotRockets thread, the propeller spinner module only supports ModuleEngines, not ModuleEnginesFX. Any way you could do up a wrapper? You probably need to add only a couple more fields to the wrapper I use in RF.

Other than the fact that serialization is screwed up *so* badly (see how much breaks when you clone a part in the VAB or do symmetry...), not offhand. Wait, *what* fields are marked persistent? Can you paste the code block that defines them? Might help some.

Spaceplane guidance does not play nicely with FAR (even with "use stock SAS" on). However, ascent guidance *can* work very well with FAR. This guide is for RSS, but other than changing the turn end height it should work for regular KSP too. https://github.com/NathanKell/RealSolarSystem/wiki/MechJeb-Ascents

Thanks to this I have working J58s with Mach 4 performance (if the heat shielding can take it) J57 giving the F-100 its barely-760kts top speed Avon 301R powering the JRC Mk III to a wopping M2+ at sea level and M2.7 at 14km (accelerating in climb, no less).

Yes. However, be careful, since (as things currently are) changing the module order of a part (so the order of modules in the prefab object that KSP creates at startup doesn't match the order of MODULE nodes in the .craft or .sfs file) will break data-loading from *all* that part's modules.

Mach 2 at SL is very possible, yes. So is maintaining control then. Pulled up slowly to +20, hit Mach 2.7 by 12km (accelerating all the way, Avon 301R is a *beast*)

Styles2304: Nope, that's how it works.

This is why you always install a mod per its instructions, and never, ever rename its folders or extract it differently. Many, many mods depend on being in the exact folder they tell you to install them in. SpacedInvader: looks good! Here's how you edit atmospheres: https://github.com/NathanKell/RealSolarSystem/wiki/AtmosphereFromGround-RSS-Settings

Wow, it's been a while since I was in this thread! Great to see the mod continuing to evolve and improve. I'd been meaning to do this a long time, so: for folks using RSS/Real Fuels, here is a patch designed to give fuels their real cost. When I designed the cost system I (roughly) assumed a "k" was $1000US; in this patch fuels have their 1960 cost; engine costs should also be quite close (engine costs dominate stage costs; I was unable to find costs for engines, but I seem to be able to model the cost of stages decently). So...if folks do use RSS/RF/RO, please try out the patch and see how the costs go (whether rocket costs, and in particular the sub-categories, match 1960 costs). I plan to include it in the next RO (so stick the file in the RO folder). Note this is an MM patch, and therefore goes in the RO folder (or elsewhere if you don't have RO); do not try to replace your existing MCSettings.cfg with it (conveniently, it's not named that).