[1.7-1.9] SMURFF: Simple Module adjUstments for Real-ish Fuel-mass Fractions 1.9.1 (02019 Nov 12)

[Kerbas_ad_astra]

Heat shield testing, the Kerbal way:

1. Take a rocket used for suborbital launches (3-5 km/s of delta-V).
2. HyperEdit into orbit.
3. Burn downward at 45 degrees until atmospheric periapsis and velocity are similar to lunar return (10.5-11 km/s, 40-50 km).
4. Decouple the rocket and assume the retrograde attitude.
5. Repeat, reverting failures as necessary.

To compensate for the reduction in heat shield Ablator capacity, I've had to increase pyrolysisLossFactor -- I assume that this scales the amount of energy carried away per unit of Ablator ablated.  Keeping the product the same (halving Ablator -> doubling pyrolysisLossFactor) should therefore keep constant the total amount of energy that the shield can dissipate.  @NathanKell, is this correct?

I've also come up with a way to catalogue the "reserved mass" to set aside for tanks and batteries, so pod and engine buffs now only remove 62.5% and 50% of mass that isn't allocated for any of those things.  This means that the Twin-Boar LFB is viable again.

Edited January 14, 2016 by Kerbas_ad_astra

[NathanKell]

@Kerbas_ad_astra You assume correctly!

Also it's heat shield testing the real way too: https://en.wikipedia.org/wiki/Project_FIRE

[komodo]

On 1/8/2016 at 9:27 PM, NathanKell said:

@Kerbas_ad_astra @komodo I just realized I should mention. I don't think ROMini does this, either. Need to rescale any override drag cubes when the parts rescale.

Happily I wrote some code in RO to do this, which you're both free to use ( @komodo you should do it in a script, since that avoids having to pre-specify the number of cubes ). https://github.com/KSP-RO/RealismOverhaul/blob/master/GameData/RealismOverhaul/DragCubeRescaler.cfg

Note relevant to present-SMURFF since you don't rescale, though, right?

@NathanKell: I... Well, i've been out of KSP land for a bit, new job and all that. I think I grasp what this is doing, in theory at least. I'm unsure where the rescalex/y/z variables come in from though. Scripting it looks no difficult than the prior patches that i've made, but i'm going to play with it to see what it actually does, haha.

Thanks for the heads up though, this might explain some oddities i've seen. (Does FAR even care about drag cubes? That is one i've wondered for a while...)

[NathanKell]

They come from adding them at the same time you do the rescale. I.e. in RO when we patch a part we change its visual scale and then (instead of manually changing the drag cube in that patch, as we used to) we drop a rescale-cube marker for that rescale script to handle later. There are three separate dimensions because RO often needs to do non-uniform scaling.

 

FAR doesn't care about cubes for aero, but FAR doesn't replace any thermo code (or buoyancy) so cubes definitely still matter.

 

@komodo

[raxo2222]

This is so smurftastic mod

Fun to play with RSS, can we also get some real world rocket replicas?

And why this mod isn't in CKAN?

[Kerbas_ad_astra]

It's not on CKAN because I don't use it, so I've felt no particular urgency to get it listed.  I understand that the process is straightforward, so after the latest work crunch has passed next week, I'll see about changing that.

As for real world rocket replicas, there are already mods that do that, and I don't yet have the skills for modeling parts.  What are you looking for?

[raxo2222]

40 minutes ago, Kerbas_ad_astra said:

It's not on CKAN because I don't use it, so I've felt no particular urgency to get it listed.  I understand that the process is straightforward, so after the latest work crunch has passed next week, I'll see about changing that.

As for real world rocket replicas, there are already mods that do that, and I don't yet have the skills for modeling parts.  What are you looking for?

Ah okay.

And I meant rockets made from stock parts, that can launch satellite on Earth in RSS.

[Joco223]

@raxo2222 You can use this mod in RSS and it does it job very well I can say  . I'm playing with it right now and its pretty awesome. But be sure your PC can handle the rockets if you don't use procedural parts. Rockets need to be pretty big for manned missions. Unmanned missions are fine with fps for me

[Kerbas_ad_astra]

On 1/23/2016 at 11:44 AM, raxo2222 said:

Ah okay.

And I meant rockets made from stock parts, that can launch satellite on Earth in RSS.

Once my new patch is released (with the mass reduction for command pods), the Kerbal X will actually be capable of reaching LEO (provided you take the legs and ladders off first), though I wouldn't recommend actually trying it, since it doesn't come with a heat shield.  Take the landing parts off, add a heat shield, and extend the upper stage with another X200-16 fuel tank, though, and you'll be in business!  You'll be able to launch anything that weighs a few tons with a rocket about that size.  I'll see about putting together a craft library on KerbalX or something, and maybe even with the download (though this will delay the CKAN release even further).

One more upcoming feature: "overdraft" protection.  Since SMURFF works by (among other things) subtracting the mass corresponding to the excess weight of a stock tank, parts with mass ratios significantly better than stock can have their masses sent into the negatives.  In my testing, I have found three parts in this category -- the adapter tanks from @Orionkermin's Home Grown Rockets and the big xenon tank from @NecroBones's Modular Rocket Systems (though his Real-Scale Boosters will probably be the same way) -- so there will be a second-to-last pass that will flip the sign of any modified parts which have negative masses.  Since the "most negative" that a part's mass could be is if it were massless in the first place, and I'm subtracting less than a stockalike tank's mass, this means that, at worst, parts in this boat will have better performance than an unmodified stock part, though it's generally impossible to say by how much.

Finally, much like I tested SMURFF 1.1 with a moon rocket (see this post for a blueprint, and this one for the mission album), I just got done with another test for SMURFF 1.2.  Having the lighter command pods helped make the rocket smaller -- the "Uranus V" only weighs 1640 tons vs. 2470 tons for the Sarnus VII (and the 2970-ton Saturn V and 2750-ton N-1), mostly because it only has four boosters instead of six (which was in turn enabled by the lighter lander and command pod) -- but it's still a massive beast.  The launch was not without unexpected issues, but the lower stages successfully placed the CSM and LM on a trans-lunar injection, the lunar segment of the mission happened without a hitch, and the reentry was successful the first time -- in fact, Trajectories's prediction was within ~10 kilometers of where the actual landing occurred, so three cheers for @Youen!

Spoiler

I promise, it's shorter than the Sarnus VII -- 56 m vs 78 (vs. 110 for the Saturn V and 105 for the N-1).  Still brakes for nobody, though.

Now, all I need to do is put together a new logo to include the command pod, and I'll have 1.2 out before too long.

[NecroBones]

3 hours ago, Kerbas_ad_astra said:

Modular Rocket Systems (though his Real-Scale Boosters will probably be the same way)

 

Yep, just something to keep in mind there. RSB is already starting with realistic mass ratios (to the best numbers I can find by googling for those particular rockets).

[Kerbas_ad_astra]

You're splitting fuel tanks and engines, right?  If a standard fuel tank has a mass of 1, then a realistic fuel tank has a mass generally around 0.25.  I knock 0.75 off the mass of LFO tanks, so if the RSB tanks start with mass 0.25, they'll get knocked down to -0.5, and then inverted to 0.5.  Not as good as they should be, but not bad (that's still a mass ratio of 94% fuel).  Engines will get insane TWRs, but that's mostly going to be from mass reduction, which doesn't bother me too much, since most of the mass of a booster is in the tanks (and RSB's tanks are going to be too heavy).  The 50% boost to thrust will let a Saturn V get away with 4 engines instead of 5, which doesn't terribly offend me either.

I could define a "ModuleSMURFFExclude" and not buff any parts with that module (and then apply that module to any parts that start with "RSB", assuming you name them in a pattern like your other mods), but I'd really rather not take that step -- that starts to get too far into per-mod and per-part tinkering than I think SMURFF should go.

By the way, thanks for MRS and SpaceY!  I plan to make a stock-parts-only version of the Uranus V (and a couple of smaller lifting rockets) to complement the stock rockets, and I'm certainly going to miss them.  Having to use the lander as a structural element (seriously looking forward to the built-in-struts for interstage fairings coming with 1.1), no fuel-tank nose cones, radial control panels or sepratron-decouplers...shivers me timbers just thinking about it!

[NathanKell]

Probably easier to just check for a value on the part itself, i.e.

@PART[*]:HAS[~SMURFFExclude[True],other_has_checks]:FOR[....

and then in a PART {} you do SMURFFExclude = True

 

To avoid logspam, you also do:

@PART[*]:FINAL

{

!SMURFFExclude = DEL

}

 

since any extra values in a part will trigger logspam on part compile.

[Kerbas_ad_astra]

Since tanks are the only parts that have mass subtracted from them (and thus are the only parts at risk of being sent into the negatives), I've made a change so that I bookkeep their initial mass and roll back any that get sent below 0.  So, no need to worry about marking fuel tanks or LFBs.

For engines, I can maybe do an initial pass and filter by TWR, say cut off at 55 to ensure that SpaceY engines get buffed (could even do 50, but that's cutting it close), but this one is a little trickier.  Since there aren't many engines that need to be excluded (engines that have realistic performance metrics while burning stock Oxidizer -- zero, by my limited sampling, until RSB is released), there's an argument to be made that it's okay to put the burden on the mod maker to mark engines for exclusion, but I'm opposed to burdening other mod makers for the sake of some nobody's addon which is used by a fraction of a fraction of players.  On the other hand, without any marking, with the TWR cutoff at 55, the RS-68 (since I see the Delta IV is on the docket for RSB) is going to get stupendously buffed.

@NecroBones, your mod is the number-one beneficiary/victim of whatever gets implemented (or doesn't get implemented, if SMURFF stays as it is) -- thoughts?

[NecroBones]

40 minutes ago, Kerbas_ad_astra said:

 

@NecroBones, your mod is the number-one beneficiary/victim of whatever gets implemented (or doesn't get implemented, if SMURFF stays as it is) -- thoughts?

I'd say go ahead and add the flag. I'll be happy to add it to my engines (assuming it doesn't cause other problems, but I don't see why it would). Plus, it'll add lots of flexibility, not just for other modders who want to exclude parts if they notice a problem with the mod interaction, but also for yourself, since you'll be able to exclude entire mods or specific engines by setting flags yourself before the pass that reduces the mass. Seems pretty win/win to me.

[Kerbas_ad_astra]

35 minutes ago, NecroBones said:

I'd say go ahead and add the flag. I'll be happy to add it to my engines (assuming it doesn't cause other problems, but I don't see why it would). Plus, it'll add lots of flexibility, not just for other modders who want to exclude parts if they notice a problem with the mod interaction, but also for yourself, since you'll be able to exclude entire mods or specific engines by setting flags yourself before the pass that reduces the mass. Seems pretty win/win to me.

Alright, I'll add the flag.  Put "SMURFFExclude = true" in the part config to exclude a part from getting buffed.  Or "True", or "supercalifrue", or anything that ends in "rue".

It's only going to be necessary for engines in your case, but I'll also make it apply to tanks and pods (and any future buffs I dream up).

Release coming after the major RL crunch this week!

[NecroBones]

12 minutes ago, Kerbas_ad_astra said:

Alright, I'll add the flag.  Put "SMURFFExclude = true" in the part config to exclude a part from getting buffed.  Or "True", or "supercalifrue", or anything that ends in "rue".

It's only going to be necessary for engines in your case, but I'll also make it apply to tanks and pods (and any future buffs I dream up).

Release coming after the major RL crunch this week!

OK cool. I've added it to all the liquid fuel engines in RSB. I'll probably put up a 0.2 download link tomorrow.

[Kerbas_ad_astra]

Version 1.2 is released!

2016 01 27 (1.2): Entry, Descent, and Landing

• Masses of crew containers and heat shields are reduced by half, to permit reduced (and reasonable) capsule ballistic coefficients. Now pods are more likely slow down in time to get their chutes open.
• Added a "reserved mass" system so that engines and pods only modify mass which is not accounted for by fuel tanks and batteries.
• Added a "SMURFFCONFIG" section -- adjust the "tanklever", "enginelever", and "podlever" variables to control how much of a buff is applied. 1 for real-ish performance (default), 0 to leave stock values alone, and everything in between is in between. Try 0.5 for the likes of 64k or SKY.
• Changed patches to run FOR[zSMURFF], so that the patches run later. SpaceY's engines now get properly buffed when Cryogenic Engines is installed. (SpaceY replaces the ModuleEnginesFX modules of some engines in that circumstance, and since SpaceY comes after SMURFF, the thrust buff was being overwritten.)
• Added a "fix" for parts whose mass gets sent into the negatives (i.e. any part which weighs less than it "should" by stockalike standards): their masses get restored to their initial values.
• Added support for "SMURFFExclude" -- add "SMURFFExclude = true" to any part you don't want to get buffed.

Also, check out the snazzy new logo:

[Joco223]

Why does Module Manager give me 2 errors when loading SMURFF.cfg? Latest version of MM and SMURFF

[Kerbas_ad_astra]

That must be from a bad interaction with another mod -- what else do you have installed?  I know that I need to make an update to deal with the new version of Cryogenic Engines (in particular, the tanks have changed).

[Joco223]

I have Cryo engines installed. Should I remove them?

[Kerbas_ad_astra]

The error should be harmless, since (if I'm reading Interstellar Fuel Switch's source code correctly) IFS uses the list of resources to decide how many tanks to make, so there shouldn't be any problems in flight.  That said I should get a fix out the door sooner rather than later.  (Then I'll have to get some serious balance work in on the cryo-tanks' actual contents and mass fractions, because they got reduced in the latest update, so the LH2 tanks are actually a little too light...)

[Kerbas_ad_astra]

Actually, testing it myself just now, I'm not getting any errors from SMURFF and CryoTanks.  (I'll still have to make an update, but that's because the variables CryoTanks uses have changed such that SMURFF just isn't acting on LH2 tanks at all.) Could you give me your log please?

[Joco223]

@Kerbas_ad_astra The errors are harmless because I tested a few rockets with it and it seems all fine

[Kerbas_ad_astra]

5 minutes ago, Joco223 said:

@Kerbas_ad_astra The errors are harmless because I tested a few rockets with it and it seems all fine

In case our notifications crossed -- when I tried using CryoEngines myself, I didn't reproduce any errors like I expected I would.  I'd like to get your log because there's something else causing trouble.

[Joco223]

@Kerbas_ad_astra I'll look into it because I have about 20-30 mods