Rayder
-
Posts
149 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Rayder
-
-
On 11/19/2018 at 5:54 PM, kostik said:
If I only have Scatterer it doesn't appear.
Does it occur only with Kopernicus installed?
-
I don't know what to tell you. I checked in Kerbal Engineer and my test craft gives 4,239 dV and an Isp of 482. My math was wrong, and I checked the forum post I linked. You're right, the Isp is not simply (a+b)/2. But the math is complex, and I guess it's up to you whether it's worth the effort. Me personally, I just use Kerbal Engineer. Saves me the headache haha.
-
2 hours ago, Brikoleur said:
How can you tell where the centre of drag is, just by looking at the picture?
Centre of lift, different name for the same thing.
You want to keep your CoL behind the CoM at all times. If you don't, without enough control authority your nose will flip around.
-
8 hours ago, 4x4cheesecake said:
...you will definitly need a bit more to do some corrections on your way...
Agreed. Hitting the right windows is already difficult as it is. I can also recommend Precise Manoeuvre. Adjusting nodes really early is almost impossible to do by hand. The adjustments are just way too big.
9 hours ago, 4x4cheesecake said:usually another gravity assist of Tylo and/or Laythe will capture you around Jool
Dropping down from Tylo would be a good idea - no atmosphere means you can get nice and close. You could even try to line it up with Laythe direct then aerocapture - means insertion into Laythe could be almost free.
-
9 minutes ago, bewing said:
- snip -
Agreed, however he claims he's only had this speed issue since slightly modifying the craft. To me, it seems there's a part he added that's adding excessive drag when it shouldn't be.
I know this occasionally happens with some modded parts - Mk IV spaceplanes had serious drag problems with the crew cabin. I've also seen anecdotally that some cargo bays have this problem as well, even if they're occluded. Whether this is the problem OP is facing though, I have no idea. OP also stated he removed the parachutes but didn't say if that resolved the problem.
-
17 minutes ago, bewing said:
As soon as your AoA goes a few degrees above prograde, the drag on an MK2 fuselage goes up exponentially
It's been a long time since I've used Rapier engines but is this because there's limited thrust to overcome the drag? Since only increasing the drag slightly the craft loses too much speed?
OP, do you still have the original version of the craft that made it to space? If so, try reverting back and do another test run. Then start adding parts one at a time until you start having the speed limiting issue again.
-
41 minutes ago, FinalFan said:
But I don't see how it's in any way relevant to the OP.
As far as your original question goes, then no. There's no measurable efficiency loss by having a longer burn time. Even players who use Ion thrusters to go interplanetary, break up the burn into multiple stages do so for convenience, or to ensure the accuracy of the trajectory.
-
Yes my scenario was still very simplistic, and ignored all the extra tanks, converters etc that you'd need to achieve it. But that's not needed to explain the concept.
Reality is, if you add all the extra weight and ore, yes your actual m/s will change - but the difference in efficiency will not. The Nerv would still be worse than the LV-909, and using them both would be better still. Even if you added an extra 100t to my example craft, you still get the same order:
Nerv: 854
LV-909: 881
Nerv + LV-909: 1,192Nerv + Ore: 1,870
Remember that a core part of delta V calculating is the difference in the wet and dry weight. The only way to influence these numbers is to change the fuel capacities or the engines, which in my simple craft scenario we are not. By introducing fuel synthesis we are effectively modifying the available fuel which is why converting Ore the Nerv wins out.
-
When it comes to ore and converting to fuel, it's actually rather easy. Remember, when converting from ore to fuels the mass remains the same (with the exception of monopropellant).
Consider my simple craft scenario. If you change nothing else, it's more efficient to convert to just LiquidFuel and use the Nerv engine. Why? because LiquidFuel is 45% of the tank. Also, LiquidFuel and Oxidiser have the same mass, but are just used in different proportions.
How do we do it? Simple. Since the mass conversion from Ore to LF or Oxidiser is the same, you get the same out. Converting to LFO you'll get 14.4t of LF and 17.6t of O. But converting just to LF you'll get the whole 32t of LF. You get 2.2x the amount of LF as you'd get by doing an LFO conversion.
As a rough guess, you'd get ~7,700 m/s using the Nerv from the same amount of Ore, as it would take to fill the tank of LFO, where you'd get ~5,600 m/s using the LV-909.
I know my example craft isn't realistic, but consider that doing this for a useable craft in the game is much more complex, and it's dependent on the engines used, number of engines, tank sizes etc. There's simply too much to consider to give a generic answer.
-
On 11/7/2018 at 7:42 AM, Cloakedwand72 said:
How should My LG look like?
Your rear landing gear are a pivot point. If the wheels are too far back you'll find you need a high speed before the craft will pitch up.
If you bring the gear further forward closer to the CoM, the craft will pitch easier and you'll lift off easier. Ideally you want it as close to the CoM as possible, but not in front. Being a touch behind is best, so that the craft doesn't tip backwards.
You also need to consider ground clearance. Having your landing gear further forward means the rearmost portion of your craft has the potential to contact the ground. You can either limit how much you pitch up, or you could add a small wheel there to prevent impacting the engine on the runway.
On 11/2/2018 at 2:24 PM, bewing said:You are using some kind of mod for your CoL, is that right? The CoL is in red, and is in front of the CoM?
I'm not sure on OP's mods, but I know in RCS build aid the red CoM indicator is an average CoM (between full and empty tanks). It's handy for placing RCS thrusters so that 'on average' you won't have an excessive torque when translating.
-
A craft using different ISP engines (for the same fuel type) effectively has the average ISP of all those engines.
Multiple engine specific impulse math
This thread discusses the deltaV of a craft with different ISP engines. You can effectively invert the equations to see what your remaining fuel mass will be if you use different types of engines. But overall your average ISP will be lower.
Granted, given your specific case things become more complicated since you're involving different engine types and also fuel synthesis. This is further complicated by how much fuel mass you have, how much extra LF you have for the nuclear engines, the mass of the craft etc. KSP makes things slightly easier since fuel and oxidiser have the same weight and density. So for a given fuel tank, you can work it out. Let's use the nuclear engine and the LV-909
Nuclear:
Mass - 3t
ISP - 800LV-909:
Mass - 0.5t
ISP - 345Since you're carrying both engines we will add them to the weight of our fuel tank. Let's use a Jumbo-64 tank.
Full Mass: 36t
Empty Mass: 4tThis gives us 32t of total liquid mass in the tank, 14.4t LF and 17.6t O. Now we can start working out our weights. Since the Nerv doesn't use the oxidiser, this means we have different 'wet' and 'dry' masses:
LV-909 Wet: 39.5t Dry: 7.5t
Nerv Wet: 39.5t Dry: 25.1tSo if we sub all of this data into our deltaV calculations, for our simple craft of 1 tank and two engines, each engine separately would give us the following results:
Nerv: 3,555 dV
LV-909: 5,617 dVIn this case, you can see that the LV-909 gets more delta V even though it's less efficient as it's burning away a lot more mass. BUT this is not what your situation is. You want to see if using more engines at once gets you more efficiency. For that, we now have to take in fuel usage rate into account. You also need to consider that as you're burning, some LF will be used by the Nerv so you'll have some excess oxidiser left over as dead weight. So let's re-sub all of this in one step, and calculate for both engines.
Averaged ISP: (800 + 345) / 2 = 572.5
Wet Mass: 39.5t
Dry Mass: 12.8t (5.3t of oxidiser remaining)Now I REALLY hope I got all my math correct, because running both engines together results in a total deltaV for this craft at 6,322 m/s.
So yes, @Vanamonde is correct that using both could potentially net you better efficiency.
-
It really depends on the use case. Since you cannot land on Jool you don't need to get close to it unless you want to build a low orbit station or something - or doing science (Jool's 'low/high space' boundary is 4,000 km).
Why it depends is because up to about 40,000 km (which lies just outside Vall's orbit, from memory), you can get huge fuel savings just by circularising up higher. The difference between a 40,000 km and 250 km circularisation is about 1,500 m/s deltaV. Going higher than 35--40 Mm doesn't save all that much fuel.
What's more interesting is that if you go much higher than 200,000 km it actually starts to take more fuel to circularise, so it's the sweet spot to do your insertion. Caveat: this window is HUGE! Going down to 100,000 costs <50dV more, and going up to 300,000 only costs <10dV more. Going all the way up to 2,000,000 km only costs ~200dV more.
This is the premise behind gate orbits. You're balancing the difference between your vessel's velocity and the velocity of your desired orbit. What's more, if you plan on returning to Kerbin then ~200,000 km is the most efficient orbit to leave from, so it could be a handy spot to setup your centre of operations. You'll be fighting Pol for the real estate though, so to avoid any accidents setup a little higher, maybe around 250,000 km. The difference is literally around ~2 dV for your insertion burn.
Ultimately I suppose you could calculate it, but I suspect your instinct is correct - there just isn't enough in it. Your best option I'd say is if you really wanted to maximise your savings using Oberth, consider using manoeuvre node splitter. You can split your insertion burn into two parts: 1st part just enough to capture into Jool's SoI and then 2nd to do the circularisation. I suspect you won't save all that much fuel, however.
-
On 11/11/2018 at 3:45 AM, Snark said:
... what's the situation that requires calculating it exactly? (Or is it just for fun / curiosity?)
Indeed, it is mostly for curiosity / fun.
I've been messing about with gate orbits and they're dependent on the excess velocity, which changes depending on the apoapsis of your transfer orbit (ie. the distance the planet will be when you arrive).
Since the planet will be at a different distance at each transfer window, it was just finding a formula to plug in some numbers and get C3 out. After some investigations yes @Snark is correct: Duna doesn't change much. The difference is less than ~50dV for the whole ejection and insertion. The bigger differences come into play with Jool and Eeloo, which can be on the order of hundreds of deltaV depending on where they are in the orbit. Duna more or less was just used as an example.
-
Hello all,
I've been doing some research on how planets move through their orbit and I've hit a snag. I'd like to calculate for example, what Duna's distance to the sun will be at a specific time and date in the future. Such as, what distance will Duna be from the sun at 'Time = 2y 120d'.
Since we have all the orbital parameters available to us, I figured we'd be able to calculate it. Alas, its turning out to be more difficult. I've probably stumbled upon the equation somewhere but not realised what I'm reading.
-
So I've been able to narrow down where this issue is coming from:Spoiler
The sun shines through Jool from around Tylo's orbit. Closer than that, the sun disappears. This happens in map view and also in-game.The issue is coming from Kopernicus.dll, specifically the latest version (v1.5.1-1). I downgraded only this file to the one from v1.5.0-1 and the problem is gone. So this issue is coming from this file, specifically something added or changed for the latest version.EDIT: Disregard, the only reason it didn't work was because Kopernicus wasn't actually loading, despite not throwing any errors. I'll keep digging, but it seems to be an issue as far back as v1.4.5
EDIT 2: Okay I've realised this is not an issue with Jool, specifically. It's only most noticeable with Jool.
It seems at a certain distance from a body, the sun ignores occlusion from that body and the sun shines - regardless of that body's size. You will see the sun from directly behind Moho at the same distance as Kerbin, or Eeloo and even Jool.
It's like beyond a certain distance, occlusion isn't even considered anymore. This isn't a issue with most planets as they are small compared to Jool. But yes, for Jool the sun shines through the planet quite obviously.
-
-
I've just setup a fresh install of KSP. With only Kopernicus installed, I've noticed that the sun shines through the surface of Jool from about the distance of Tylo. This seems to appear both in the map view as well as from a ship landed on Tylo's surface. Anyone know of a way to correct this?
-
The data for a geostationary orbit around Kerbin is as follows:
Orbital Period: 5h 59m 9.4251830898s
Semi-Major Axis: 3,463,334.059488768Using KER will get you extremely close but for perfect results either edit the save file, use Alt+F12 or HyperEdit.
-
Not sure if it's been mentioned, but is there a way to change the point where scatterer decides the flare has been occluded? I'm getting images like the one here. This one was taken from Moho:
Spoiler
It seems that the flare is centered on a singular point in the center of the sun. If it were say, the same size as the sun the flare would cut out properly once the sun was fully occluded.
Also, is it possible to have a fade out animation for the flare? The same way the stock sun fades out behind planets, instead of turning off abruptly.
-
22 hours ago, Bit Fiddler said:
does the near future reactor plugin auto throttle reactors to only produce what the craft needs? I mean if I set my reactor to 100% but I have solar panels producing enough power to power the craft in the sunlight will it throttle them back to 0% to conserve on fuel and heat? then when the craft enters the dark side,will it throttle up the reactor to what ever level is necessary to keep the ship at full power?
As far as I know there is no auto-throttle feature built in. Your best bet is to fiddle with the power settings to give you just enough power, so that as you're just about to run out the sun will rise and you will recharge.
-
On 4/1/2017 at 4:51 AM, Nertea said:
That's a *lot* of lithium tanks. If there's anything that would inspire me to make larger tanks it's those kind of things. Next update's tanks do store more though!
On the subject of new parts, one idea I had was adding a switchable tank to the octo-girders. It could be like a large heat sink, with elements that glow on the inside as it gets hotter. You could then attach radiators to this unit to dissipate the heat.
Although the benefit of something like this could only be realised with heat pipes, so you could pump the heat into it.
-
Just now, Crimeo said:
Your operating system etc. also take up RAM, so this may add up to the actual limit anyway.
Exactly. It seems either KSP or the system was limiting how much RAM to assign. As I mentioned adding in extra allowed KSP to use up as much as it properly needed without hitting the cap.
-
On 4/30/2017 at 10:04 AM, AwkwardNoah said:
Might be, I was monitoring my computer's usage and turns out when I was using a large launcher for my Duna ship it was using about 7K MB
You might also find adding extra RAM is useful even if you're not hitting your limit or crashing. My KSP install was running on about 6GB in my system with 8GB and it seemed to run fine for a long time. Although I did have the occasional crash. I found that the game actually was running out of RAM and it was just hit and miss whether it was going to crash.
I threw in some more RAM and I'm now running with 24GB. KSP seems to appreciate the extra breathing room and is now routinely using up to 9GB.
-
15 minutes ago, diomedea said:
Still if the result you have from manual testing in KSP is so close to what I get with a purely math approach, the accuracy is clearly good enough for all gaming purposes.
Agree with you here. As I stated in my first post in this thread, getting an SMA approximately right (such as you and I have) will keep your satellite stationary for far, far longer than anybody is willing to invest into a single savegame.
15 minutes ago, diomedea said:orbital period and solar day duration give sidereal rotation period (21549.4251829786, while wiki has 21549.425
Haha another wrench in the works. I checked Kerbin's sidereal rotation period in Hyperedit and the value it threw at me was 21549.4251830898. Not entirely sure how Hyperedit works in some circumstances but I assume that it's pulling the values directly from the game?
[Most 1.12.x] Near Future Technologies (August 26)
in KSP1 Mod Releases
Posted
Not sure if it's been reported yet, but... I've noticed a bug with the Octo-Girders when switching the configuration. When I'm switching between tanks, the pop-out shows tanks being added on, but not removed.
That is, when I switch to a LF tank, it puts that resource in. Then when I switch to the oxidiser tank, the LF tank remains and now it has both. THEN when I switch to the LFO tank it adds in two new LF and O tanks. The part will just keep accumulating tanks every time I switch the part.
The curious thing is, it seems to only be cosmetic. When I unclick the part and re-click it, the part shows the correct tanks. The mass display on the bottom-right seems to display correctly, for the selected tank.
So I guess it's a relatively minor bug, but it's there nonetheless.
KSP v1.7.1-2539
NFT Construction v1.1.1 (with B9PartSwitch and MM v4.0.2)
No other mods installed.