BALANCE: Rescale Flight Testing

[jsolson]

Harder Solar System is not currently supported. It's not Sigma based.

Compatibility\Rescale\BlueSmurff.cfg is the file we're working with.

If you're familiar with SMURFF, this is based on that. We're reducing the dry mass of various parts to get the deltav we want. What gets reduced and by how much is determined by the rescale value from Sigma. Adding fuel is an option, but we want to exhaust the mass possibilities before throwing more fuel in.

Things we need to know to make adjustments:

How do the non-manned rockets fly with payloads. OP/Under-P/About right.

Do Mercury Atlas and Gemini Titan make orbit without too much excess dv. (No using the SM engine or mercury srbs.).

Saturn is a top down problem that should be done last, but we need to keep an eye on it. Enough dv for LEM ascent/descent, CM dv to circularize and return, S-IVB TLI burn, and then the S-II/S-IC stages. We want the S-II to burn out short of making orbit, but not so short the S-IVB can't do the TLI. We have ballast mass built in to Saturn that can be removed to tune the various stages.

Right now the settings look ballpark correct. We need to pretty much fly everything in every rescale and make sure.

[Redleg1]

Tracking that you are working on Atlas, Titan etc. first. I have been testing Saturn V flights with various scales attempting to simulate the Apollo missions and have noticed that while using Kscale64, the SLA does not fit correctly against the bottom of the Service Module. There is a very visible gap between the two as if the SLA was rescaled to an improper scale. Sorry I don't have a screenshot at this moment. This is while using Kscale64 with the latest Sigma Dimensions and Kopernicus.

I was not able to test a full Launch/Orbit/TLI/Mun landing/Mun Ascent/return, but I was able to get into orbit.

I also tested a 3.2 Resize 6.4 Orbit rescale and was able to achieve a Mun encounter just barely with default BDB, down to the last drop of fuel though on the S-IVB. It does not seem that any of the SMURFF changes were applied while using this scale though. Hope this helps somewhat.

[jsolson]

I took more mass off the S-IVB in 6.4x, and Command pods generally. We'll need to recheck the other manned stuff - Gemini and Mercury. They'll have a little more dv.

[jmrd98]

the SLA does not fit correctly against the bottom of the Service Module. There is a very visible gap between the two as if the SLA was rescaled to an improper scale.

@Redleg1 , update your bdb repo, you have an old version. What you describe is true, though. It's actually (was) scaled to the right scale, but we didn't have the right SLA for the scaling.

[jsolson]

"3.2 Resize 6.4 Orbit rescale"

That's a scenario I had not considered.

[Redleg1]

It's based off Kerbin365 . Its an old Kopernicus config that I am in the process of updating for myself, and potentially to release.

[jmrd98]

A good question that occurs to me as I update SigDim: What dayLengthMultiplier are you using for which rescale? A faster/slower spinning Kerbin can have a decent impact on launch dV.

For 6.4x, i've always used 2, for 12 hour days, but I have no idea if this is 'standard'. It's been so long since i've played the original 64x mod (the RSS one!) that I don't recall their day length.

[jsolson]

And what scale factor would we use for that? 3.2, 6.4, something in between? What SMURFF setting would you use?

I moved the rescaled Saturn files to extras. I think that one will probably be desirable in 6.4x. The default size is flying, but its payload capacity suffers.

[jsolson]

The bigger Saturn should be playing nice with the rest of the cfgs now. When using the bigger version, Apollo gets a little more fuel instead of being lighter. It has to be pretty light for the smaller version S-IVB to do the TLI, but the full size version can handle it.

[jmrd98]

I just pulled the new changes. Checking now.

GLV @ 6.4x, 2x daylength, still needing the longer upper stage. Standard tank loadout + 90 MP in the service module did not make orbit. With or without the stretch though, it still flies rock solid, but dV is not quite there.

With the stretch tank + 120 MP, the best orbit I can manage is 111x-457, so a high/fast suborbital hop. This is mostly a note so I remember to tweak later.

[jsolson]

Probably going to have to pull a little fuel and add a little mass to the S-IC/S-II stages. We'll dial in LEM/Apollo/S-IVB first but they look close. I just threw in the fuel numbers from our previous work.

I'll take a look at GLV. We went from 40% pod mass, to 30% getting the small Saturn to work, and now we're at 50%. 40% is probably right.

[jsolson]

6.4x testing with the Saturn rescale. I uploaded a few more tweaks. The S-I fuel just had to come down, it couldn't lift itself. Saturn 1 is still a little OP dv-wise. The Saturn V looks fully mission capable for a Mun shot. You'll want to drop the S-IC stage fuel by 1 tick (90%) and let the engines run a few seconds to lift off at 1.18 twr. I don't think we should nerf the fuel, it leaves options open for non-Apollo missions. Might want to dial down boiloff in upscales. It takes a lot longer to get around a 6.4x Kerbin. The S-IVB does the TLI with a couple hundred dv left. Apollo has enough dv to capture and return with the LEM attached.

[jmrd98]

And I just hit pull too... If S-1 had to get reduced, check S-1E as well, as it was in the same boat last I flew it. Are the new/altered Titan tanks sized correctly for 6.4x? Loading up presently in any case. I like the idea of a pre-liftoff firing. We could really go at it hard and use the engine acceleration feature, but the backlash would be harsh I suspect. It does look nice with the towers retracting/clamps releasing the booster off of the pad, though.

[jsolson]

Theoretically the S-1E can lift 9.6 tons (24ish real so that's acceptable). It has 8000+ dv but I've yet to make orbit. It's a long hard 5+ minute burn for the S-IVB stage with the single J-2S. Same boat as the S-V, 90% fuel in the first stage, run the engines a few seconds and go.

Everything but Saturn is already correct scale. Some of the early rockets are off due to fitting to KSP sizes but I'm not worried about that. Diamant is the biggie, it should probably be 0.9375 rather than 1.25. Keeping it that way is a gameplay choice. We need the 1.25 meter parts more than another 0.9375 rocket.

The new Titan tanks are correct length for 1.875/3.05m scale. And the second stage fuel is way reduced. The real one is two spherical tanks with a lot of empty space. Hypergolics don't use shared bulkeads. It might be my imagination but it seems to make orbit easier. Sometimes you can do more with less. I did a major mass hunt on Gemini to lose a few kg. You should be able to bring some MP now.

I wanted to do Titan I as well but I can't find a decent drawing with exact measurements. It was never anything but an ICBM so details are sketchy.

[jmrd98]

(At 6.4x rescale): Something may be amiss with the larger Block 3 SM engine (The Descent version): It seems over massed. It is coming in at 0.12 t, vs 0.16 t for the block 2 engine. (Just under twice the thrust.)

The descent engine on its own is 0.088 t, while the ascent engine alone is 0.032 t, 0.048 t in Block 3 SM form. One of these seems a bit off, as that implies that the difference in mounting hardware is 0.016 t. Is it the gimble on the larger one that is throwing it off?

It may be that the Block 2 SM engine is undermassed. The more pressing issue at the moment is that there is almost no compelling gameplay reason to select the "Block 4" engine over the Block 2 aside from style points. (The larger engine gets a bit better ISP even.)

Perhaps "not-a-bug", but thoughts? Is this is artifact of slashing mass so significantly, that formerly large differences converge?

[jsolson]

It's because the apollo parts are all scaled together using the apollo pod factor. We're can probably exclude the engines from that. Then check dv. The csm should be ok, not sure about the lem.

[jsolson]

It may be that the Block 2 SM engine is undermassed. The more pressing issue at the moment is that there is almost no compelling gameplay reason to select the "Block 4" engine over the Block 2 aside from style points. (The larger engine gets a bit better ISP even.)

Finally home... They are all receiving the same mass adjustment so it's not that.

The Block II SM, and LEM Ascent/Descent engines are all set to 15.3 twr (in stock) so they're definitely not undermassed. I would set the Block III and V engines to match the specs exactly and ignore the butt plate. Or, if this bothers you, add some mass to the Block II engine to account for the butt plate. The mass difference between the Block III/V and Ascent/Descent is inconsistent. It's 80kg for one and 60kg for the other. It should be the same for all if we're doing it that way since it looks like the same butt plate to me. Or, my preferred solution, yank the Block II engine off the butt plate, and give us one engine mount and three engines. Possible problem with that is the hidden top node for the petal adapter might interfere with the engine node since it's so thin.

[jmrd98]

On the attach node, there actually isn't a problem there/there is a nice solution: Ever since node orientation was fixed, there is the option for things like this where the hidden node only accepts attachments from "above", and the petal adapter from "below". Lower the hidden node slightly so it doesn't attach to the tank before the actual attach node. The engine shouldn't ever hit it because the node orientation isn't correct.

I think. I'd have to test it, as I've only just thought of this.

[CobaltWolf]

Orrrrrr we see what B9 can do. If I understand what Nertea told me, I might be able to have the a) mesh switching on the engines, b) node switching to account for any differences AND enable/disable the extra SLA node, C) adjust the mass if the buttplate is on - though I think it deserves to be aesthetic at this point.

-----Original Message----- From: "jmrd98" notifications@github.com Sent: ‎11/‎13/‎2016 11:18 AM To: "CobaltWolf/Bluedog-Design-Bureau" Bluedog-Design-Bureau@noreply.github.com Subject: Re: [CobaltWolf/Bluedog-Design-Bureau] Rescale Flight Testing (#270)

On the attach node, there actually isn't a problem there/there is a nice solution: Ever since node orientation was fixed, there is the option for things like this where the hidden node only accepts attachments from "above", and the petal adapter from "below". Lower the hidden node slightly so it doesn't attach to the tank before the actual attach node. The engine shouldn't ever hit it because the node orientation isn't correct. I think. I'd have to test it, as I've only just thought of this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[minepagan]

If you want to have a toggleable node, can't you just make it like an interstage node on a fairing? Those are toggleable in stock.

[jsolson]

a) mesh switching on the engines

Do that. If I understand you, there will be one of each engine, each with 2.5, 1.875, 1.5, 1.25 (down to whatever size the bell will fit in), and no buttplate meshes. 2.5 for the SM engines and no buttplate for the other two should be the default since those are their primary uses.

b) node switching to account for any differences AND enable/disable the extra SLA node

Not required with above. The engine is tall enough to separate the nodes.

C) adjust the mass if the buttplate is on - though I think it deserves to be aesthetic at this point.

I say we go with aesthetic. We don't account for buttplates on other engines.

[jsolson]

Flew Pioneer 1 and 3 in 6.4x. It went better for me than it did for NASA. Missed the Mun on the first try, but got it on the next two. I added probe cores to the list of things getting podFactor applied because Pioneer 1 was too heavy for the Wally engine to do a Mun capture burn. The Wally is balanced for this particular mission in stock, so needing a mass drop is expected. Pioneer 3 is way too heavy though. I had to use an Alcyone engine rather than a Sargent for the 4th stage. The real Pioneer 3 was 6kg, ours is 50kg, so I'm considering going though and adjusting some of them.

The "Micro RCS Boom" is another problem (this project is a great way to find mass issues that stock hides with it's tons and tons of dry mass). It's 58kg. That's 232kg in 4x symmetry, which kills anything you might want to use it on. I'm thinking we rebalance the RCS ports mass to be 0.05 * thruster power. Most of them are already in that area, but a few aren't.

[CobaltWolf]

I don't think the Wally is meant to do a capture, it's just an orbital adjustment motor I think..? They weren't even dreaming of orbits at that point.

RE: Micro boom, balance away my dood.

[jsolson]

From reading this around page 57 there multiple mentions of lunar capture. The Wally on the real one is a collection of 8 verniers for correcting velocity after the 3rd stage burnout. Then there's also a capture motor. We've got the Mercury SRB but it's not capable.

[CobaltWolf]

shit I had intended the mercury posigrade SRB to do that... shit...

[jmrd98]

Everything has flown properly this far at 6.4x, with the latest probe tweaks + Saturn scale up + titan II optional tweaks. I think we will certainly be balanced internally. Some things seem very light though, but they may need to be. Gemini/Leo, everything was notable. The service module seemed exceptionally svelte, but I need to get back to my computer to get a hard number. Flight testing continues though, slowly. No show stoppers yet to report.

[jsolson]

Very light as in needs fixing, or just not used to it? I've been playing a casual 3.0x career. No issues with the early stuff. I've been putting payloads in our new wiki.

[jmrd98]

Very light as in 0.105 t for the structure, plus 20 default monoprop. So, it might be 'right', but it seems off. I haven't been in front of my computer until now, blah.

[jsolson]

Gemini has been a pain since day 1. The service module as it is now is massed as the sum of it's parts, and it might even be a few kg heavy since the rcs rebalance. Structure isn't factored in since the sum of it's parts was sufficient. The structure would be < 100 kg at 1x, about 40kg in 6.4x. Check that against a Rockomax Brand Adapter.

I use this site as a reference for Mercury/Gemini/Apollo since it's numbers jive with numbers elsewhere, and it gives a nice breakdown.

The full build capsule in 1x is 1,693 kg dry. The real one, minus crew, fuel, and "misc contingency 100 kg" is 1,705 kg. So that's good. ("payload" in 1x is 100% real world mass).

The real equipment module is 821 kg after subtracting fuel, rcs (we have that in separate parts), and "misc contingency 75 kg". The real one has a retro module that weighs 166 kg without the rcs and retro engine we don't have. That's 987 kg. Our's is 387.5 kg. That's in line with the Apollo service module which is also less than half the weight of the real one. I don't think the Titan II can manage another 600 kg.

Edit: Right now we're subtracting 60% mass from Mercury/Gemini, and 70% from Apollo. I thought we had changed that to 50%/60% but now I'm not sure. It might have gotten reverted at some point. The service module would be 0.19375 at 50% (it's 0.155 now).

[Redleg1]

JSO,

Should the actual SMURFF mod be installed in order to get the mass/fuel changes to work? I am not getting any of the changes from blueSMURFF.cfg when I use Sigma Dimensions for rescale.

[jsolson]

No, SMURFF isn't required. We set the SMURFFExclude flag on all the BDB parts so even if it is it won't touch ours. We haven't tested it yet but you would use SMURFF as well to mass adjust non-BDB parts.

It's the SigmaDimensions Resize variable we're reading. Are you both Resizing and Rescaling?

[Redleg1]

Yes, both. I also just tested it using Harder Solar System 4x, same thing. I just downloaded the latest BDB repo as well.

[jsolson]

Attach a copy of your SigmaDimensions/Settings.cfg, ModuleManager.ConfigCache, and ksp.log.

Make sure you've got the latest files from the repo, and most importantly, always delete the Bluedog_DB folder before updating.

[Redleg1]

Ok, here are the files

ModuleManagerConfigCache.txt

KSP.txt

Settings.txt

[jsolson]

It's working. You're getting the 3.2 scale setup, which is pods and tanks. You're seeing about 80% mass for Mercury/Gemini/Apollo, and your tank dry masses are at 75%.

What are you not seeing that you're expecting to see? The full size Saturn file was moved to Extras if that's what you're looking for.

We don't have an answer at this point for mixed 3.2/6.4 setups. From the pad to orbit is 3.2 deltav's, but from orbit to the mun is 6.4 deltav's. How do we deal with that? If you've ever used SMURFF, what SMUFF setting did you use with 3.2/6.4?

[jsolson]

The most obvious thing you'll see is the atlas balloon tanks. They kick in at 3x. You'll see them on the tanks right click menu.

[Redleg1]

I guess I assumed the mass listed on the part in the editor would be different. For the Atlas 1 long tank the mass is like 1.375 tons default, I don't see it change with resized planet so I assumed the change wasn't being applied. At 3.2x planet resize, the Muo launcher with Hermes pod barely achieves orbit. So far I have not been able to get into orbit without using about half the fuel from the re-entry engine attached to the pod.

With Sarnus V I can do a whole Apollo style mission to the mun with landing and return at 3.2 planet size, 6.4 orbit size just barely.

Maybe I just need a better ascent profile for my Muo/Hermes mission.

On Nov 24, 2016 8:19 AM, jsolson notifications@github.com wrote:

It's working. You're getting the 3.2 scale setup, which is pods and tanks. You're seeing about 80% mass for Mercury/Gemini/Apollo, and your tank dry masses are at 75%.

What are you not seeing that you're expecting to see? The full size Saturn file was moved to Extras if that's what you're looking for.

We don't have an answer at this point for mixed 3.2/6.4 setups. From the pad to orbit is 3.2 deltav's, but from orbit to the mun is 6.4 deltav's. How do we deal with that? If you've ever used SMURFF, what SMUFF setting did you use with 3.2/6.4?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/CobaltWolf/Bluedog-Design-Bureau/issues/270#issuecomment-262786675, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWOSn-J4girKbGA7OUJLcrPdZaGf_693ks5rBZzmgaJpZM4KqtAo.

[jsolson]

I guess I assumed the mass listed on the part in the editor would be different.

That's because the mass is set through B9PartSwitch. I'll see if I can address that.

Maybe I just need a better ascent profile for my Muo/Hermes mission.

Probably. It flys a nice 50% mechjeb profile to 100km if you stage it right.

[Redleg1]

What would have to be done in order to use SMURFF to change stock and other mods mass fractions alongside the BlueSmurff config?

[jsolson]

For 64k: podlever = 1, tanklever = 0.64, enginelever = 0.64

less for others.

[Redleg1]

I guess more precisely does the BlueSmurff.cfg affect all pods/tanks/engines, and not just BDB? If not I know that the config shuts off the actual SMURFF default config if it is detected, So that being the case is it possible to apply SMURFF settings to stock parts and other mods, without jacking up the BlueSurff stuff, and without having to make a config for every single part in the stock folder or other mods.

[jsolson]

We only modify bluedog parts. You would use smurff for everything else. Bluesmurff and smurff can work alongside each other.

[jsolson]

I lightened balloon tanks from 0.3 kg per fuel unit to 0.25 kg per fuel unit to match the LH2 tanks (normal tanks are 0.625 kg per unit). Seems appropriate and we seem to be having more trouble with Atlas than anything.

[jmrd98]

Quick note: Moving Agena A up a level and adjusting the fuel loadout is a small change, but one with a massive repercussion for gameplay. They were much too 'same-y' before, but now they have a distinct role for each. Thor Agena is a great launcher in early branches, especially at the larger rescales. A+

[jsolson]

Neat new feature in Sigma: link

He's suggesting Atmosphere = 1.14 and atmoTopLayer = 1.17 for 6.4x.

[jmrd98]

I saw that new atmosphere feature... checking it out now.

New issue: At 6.4x, bluedog_agenaLongTank.cfg goes to negative dry mass. It may have been doing this for a while, just hiding, i'm not sure. I suspect that it was already artifically light to simulate a balloon tank, and then had an actual balloon type applied atop that, but i'm not sure which number to tweak.

I can't figure out for sure which commit it came in, but I think it was this one.

[jsolson]

It was this one

https://github.com/CobaltWolf/Bluedog-Design-Bureau/commit/de631164b7effce61fac9b7064169c15b580eb3d

The long tank mass needs to be changed back until I get the balloon tank code sorted.

On Dec 10, 2016 7:02 PM, "jmrd98" notifications@github.com wrote:

I saw that new atmosphere feature... checking it out now.

New issue: At 6.4x, bluedog_agenaLongTank.cfg goes to negative dry mass. It may have been doing this for a while, just hiding, i'm not sure. I suspect that it was already artifically light to simulate a balloon tank, and then had an actual balloon type applied atop that, but i'm not sure which number to tweak.

I can't figure out for sure which commit it came in, but I think it was this one. https://github.com/CobaltWolf/Bluedog-Design-Bureau/commit/18fad3d041a6f3b056857a8bc70bfd7788fd6d47

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CobaltWolf/Bluedog-Design-Bureau/issues/270#issuecomment-266251313, or mute the thread https://github.com/notifications/unsubscribe-auth/AQC8INPHSFvGfqiDvPwYwG5k7MgfjXPSks5rGz17gaJpZM4KqtAo .

[Daelkyr13]

I've been playing with Saturn 1B and the S-I tank makes it nearly impossible to get into orbit. I realize you nerfed the fuel because of TWR but it needs to be revolumed. Currently the S-I burns out around 20km, forcing the S-IV/IVB to burn too long at low altitudes. If the S-I cuts out around 35-45km, the S-IVB is able to fit the ground running.

My suggestion would be to increase the H-1 engines thrust to bring the TWR up to an ideal. It does make for a less than ideal situation, however.

[jsolson]

@Daelkyr13 you didn't mention what rescale you're using, if any. Or what your payload is (the csm should be lightened as much as possible - minimum LFO/MP).

I'm pretty sure the current status of the S-I stage is slightly buffed rather than nerfed. I had been thinking about increasing the J-2 thrust. It doesn't have the same double thrust buff the other upper stage engines have to save on weight.

[Daelkyr13]

Sorry about the missing rescale info. I've tested a S-I tank with 18900 volume LFO and a CSM stack with minimum LFO and only 150 MP at rescales of x1.5, x2, and x3. Each ended with the S-I cutting off around 35km using a standard gravity turn.

What would the J-2 thrust be changed to? I'd like to give that a test and see if it's a better fix that tweaking the S-I.

[jsolson]

Double it

On Dec 21, 2016 7:28 PM, "Daelkyr13" notifications@github.com wrote:

Sorry about the missing rescale info. I've tested a S-I tank with 18900 volume LFO and a CSM stack with minimum LFO and only 150 MP at rescales of x1.5, x2, and x3. Each ended with the S-I cutting off around 35km using a standard gravity turn.

What would the J-2 thrust be changed to? I'd like to give that a test and see if it's a better fix that tweaking the S-I.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/CobaltWolf/Bluedog-Design-Bureau/issues/270#issuecomment-268685159, or mute the thread https://github.com/notifications/unsubscribe-auth/AQC8IGtnQ23t5muIroxGeHI-5b7A2PJRks5rKcQ0gaJpZM4KqtAo .