New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BALANCE: Rescale Flight Testing #270
Comments
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. |
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. |
@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. |
"3.2 Resize 6.4 Orbit rescale" That's a scenario I had not considered. |
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. |
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. |
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. |
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. |
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. |
Reduced S-I fuel. S-II stage mass tweak Fixed too much mass in RL-10 upgrade. It adds, not replaces. BlueSmurff - S-IV balance with S-IVB, adjust mass in engine upgrades. #270
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. |
And I just hit pull too... |
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. |
(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? |
It's because the apollo parts are all scaled together using the apollo pod |
Finally home... 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. |
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. |
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----- 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. |
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. |
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.
Not required with above. The engine is tall enough to separate the nodes.
I say we go with aesthetic. We don't account for buttplates on other engines. |
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. |
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. |
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. |
shit I had intended the mercury posigrade SRB to do that... shit... |
Explorer 1/7, Pioneer 1/4, and Ranger. Cost, mass, resource, ec consumption and feature adjusted. Generally lighter and less power hungry when idle so hibernation micromanagement isn't required. Sargent motors set to 19% fuel mass, 25% dry mass in line with other srbs. Balance should be in line with everything else now, OP below 3x. Seems to be scaling well. Still play testing. #187 #270
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. |
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. |
We only modify bluedog parts. You would use smurff for everything else. Bluesmurff and smurff can work alongside each other. |
Adjusted Agena so you don't need extra tanks for correct fuel amounts. Add 50 fuel to the Agena A/B engine (D get's the extra fuel in the secondary engines). Made the grey 200 tank a Balloon tank. Agena D is very light compared to B. Still heavy but better. Reduced onboard monoprop on both engines. bluedog_agenaLongTank should be moved in the tech tree to the Agena D engine if we keep this. BlueSmurff should now be showing correct masses for B9PartSwitch tanks in the VAB list. Balloon tank types no longer replaces LH2 tank type. They replace the standard LFO tank type instead. Added MonoProp tank type to all B9PartSwitch tanks. B9PartSwitchTanks have thier cost recalculated in the cfg. Added cost modifiers to each tank type based on dry mass. Half the mass twice the price. #276 #270 #189
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. |
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+ |
Neat new feature in Sigma: link He's suggesting Atmosphere = 1.14 and atmoTopLayer = 1.17 for 6.4x. |
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. |
It was this one
de63116
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" ***@***.***> 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.
<18fad3d>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#270 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQC8INPHSFvGfqiDvPwYwG5k7MgfjXPSks5rGz17gaJpZM4KqtAo>
.
|
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. |
@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. |
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. |
Double it
…On Dec 21, 2016 7:28 PM, "Daelkyr13" ***@***.***> 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
<#270 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQC8IGtnQ23t5muIroxGeHI-5b7A2PJRks5rKcQ0gaJpZM4KqtAo>
.
|
I doubled the thrust in the J-2 and that did the trick. I've been able to get the Saturn 1B into an 80ish by 120ish km orbit from scales of x2, x3, and x4. The Saturn V also gets into orbit and burns for TLI without issue. However, at x4 scale the CSM doesn't have enough delta-v to to perform TEI. It ends up about 75 m/s short. |
We might need to use the 594/726 configuration for the SM tank then (that's what we use in 6.4x). Did you have the sense that there was enough surplus dv in the S-IVB and below to take the extra fuel? It's going from 1000 LFO to 1320. |
I'll add the 320 extra LFO and see if it can handle the weight in x5. I have yet to actually test the LM. (It's next on my list of testing.) Going back to the S-IB stage of the Saturn 1B, what is the goal TWR your looking for? I still think we could pour just a little extra fuel into it. |
I checked in double the thrust and 33% mass increase on the J2 family. It really should be double mass, but I'm not sure the S-IVB can take it - it's got no ballast mass left on it I can take off to compensate. I'll do some testing on the S-IB today. Last I checked it was fine. Keep in mind the entire Saturn family is underscale. While the S-V stack can absorb that below 6.4x, the S-I/S-IB/S-IE will underperform a bit. There's a full size Saturn rescale in extras. |
I've got an extra 150 dv in 4x. With the unmodified CSM fuel at 1000 LFO plus a full load of 250 MP, and TAC life support supplies. I'm spending 22 dv on correction burns, 545 to circularize at 100 km, and 553 to return. I took the S-IB for a ride in 4x as well. Seems fine. The uprated J-2s make it easy. |
I think there is a problem at 6.4x in bluesmurff. Regarding apollo, i'm tracing my way back through it as all of my apollo parts have negative mass. This raised an eyebrow... BDBRESCALECONFIG Talking through it... At systemScale >1, podSubtract starts at 0.5 and is multiplied by the scaleFactor ((6.4-1)/5.4 = 1) giving 0.5. podFactor (1) is subtracted by this 0.5 giving 0.5 again. apolloPodFactor is set to 0.5 at this point. At systemScale >6, apolloPodSubtract is set to 0.6. This is multiplied by scaleFactor (1), and then subtracted from apolloPodFactor (0.5) giving -0.1. Aha! DINGDINGDING! It looks like this was last touched in f4da240 in november. Am I nuts here, or more likely blind and didn't notice this in testing before? The initial check in in 5ab970d would be even more out of whack, from my reading, apolloPodSubtract was at 0.7. Clearly this doesn't seem right, so i'm wracking my brain trying to figure out how this got missed (if it's real). It would only manifest at rescale >6, so ... Yeah, I got nothing. I should have seen this prior. Also... Rimworld is a hell of a drug >< Sorry to be absent for a bit! E: There's no way I missed this... negative mass parts, well, levitate, after they rip themselves off the stack on the launchpad... But i'm vexed as to when this started. ... A problem for the morning, I think. |
Yup. The Saturn_rescale.cfg resets it back to match podFactor. Makes me wonder how much of those HAS[#systemScale[>6]] adjustments are even valid. |
Yeah, that'd do it... I'll make the adjustment to match. I hadn't put it together, although obvious in retrospect: I'd just disabled the saturn rescale to test the 'stock' version at 6.4x. Didn't occur to me that it would catch the pods as well. Nevermind, saw your commit just now. Checking presently. |
Is scout supposed to make orbit? |
|
It doesn't have enough delta-v for 3x. |
@IronCretin even empty? We're in the unfortunate position where, even with it oversized, the payload is still likely smaller than any of the probes in BDB. |
In 3x I was putting Sienno based sats in polar orbit this morning. There's also Amba (Pioneer 4). There used to be a microsat mod. Not sure if Coatle has any tiny probe cores available. I gave it some thrust curves, and I've been lowering the thrust in the vab 10-20% to keep it from going hypersonic. |
@jsolson let me know what you think. Added some white. I'm sure there's more spots I can put it in to make sense. Do you have any good pictures of the raceways on either side of the rocket, with the avionics and stuff? I thought I had some good pictures but I guess not.
oh whoops lol |
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.
The text was updated successfully, but these errors were encountered: