LethalDose
-
Posts
1,810 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by LethalDose
-
-
LethalDose, man. I understand your frustration, but getting worked up over this isn't going to accomplish much. I do think their addition of time based mechanics was a tad... unceremonious... but try to think of it this way. Maybe now that they've opened up that particular can of worms, we will see more time based mechanics in the future. Even if they didn't explicitly state this, I do get the impression that devs are listening to us!
If some people out there can understand my frustration, that's all I care about really trying to accomplish. I just hope some of them are actually in Squad and can help them pull their heads out of their freaking exhaust nozzles.
Beyond that, I can only say I envy your optimism.
-
To any one who can't seem comprehend "the point" here it is from two other sources that aren't me:
The frustration comes from SQUAD violently disregarding time-based mechanics because they're, "not fun," and then adding a time-based mechanic at literally the eleventh hour before 1.0 release.Yes, yes it does.That said, I welcome the first toe being dipped into regarding time as something that happens in the game that can be used as an enhancement to gameplay.
Whilst I can't say I agree with how it was done, I applaud that it is done.
As for:
Why are you so angry LethalDose?It seems the only problem you have is "The devs did not outright state that they changed their minds, even if their actions show that they did". Why is this such a big deal?
Do I need to explain how disrespectful it was before and now, AGAIN!? And yes, that is the issue, they should have stated they reversed, or at least modified, their previous position.
Then someone else shows up and tells you this, and you completely blow him off. If you are just looking to argue with someone surely there's a better place to do so.The only reason I could possibly have to criticize the developers behavior is to start a fight? Yeah, thanks.
And yes, I blew him off because he forced opinions and statements on me which I never stated, held, or even implied. Directly, because he said this:
you are making it sound like you wanted SQUAD to make an official letter of apology towards "those who were wronged".I have to deal with this:
It's ridiculous to except a formal apology over nothing.Maybe certain developers have certain opinions, but Squad is a team. Don't mistake the opinions of developers with the statements of squad. In team projects, discussions about the product are always ongoing, and changes to the design and plans are always made. It's all for the best possible product.On another note, it's about time you read the Terms of Service. You should have read it when you bought the game. Especially this line.
In addition to that line, their front page states:
and I can't count how many times they've been "OMG we love our community"The KSP Team is strongly commited to the project, and we are always listening for feedback from the players.So thank you for helping point out that they're hypocrites.
- - - Updated - - -
You're chastising Felipe for doing a "complete 180", towards a position you support, in light of his improved understanding of the balancing. The action of making and announcing the change is an acknowledgement of that shift. While Squad have often failed in communicating with players, I don't think that this is one of those cases. Felipe has acknowledged that it's a complete rethink of his previous decision, that the newly chosen mechanic is time-based, the benefits of that system, and what he's done to mitigate the difficulties of that system:To me, this is satisfactory. What would be satisfactory to you? Write a draft announcement to clearly demonstrate what you'd like to see in such an announcement, so that it can be used as an example to Squad for the future.
I'm not chastising the change, I'm expressing frustration with the way it was done. In general Squad, but even more so with Max and Felipe, have done and absolutely abysmal job with communicating with the community they claim they appreciate so much.
Here, let me quote myself about what I expected or what I would find acceptable, 'cause it really ain't that much:
I expected them to say "We changed our minds about this" or "We looked at this, and realized that we were wrong about time-based mechanics being un-fun and impossible to implement".That's it! That's all I would have wanted to hear from them. It's small, but it's important. And they couldn't even be bothered.
-
I don't know if it's what he was talking about in the post, but a way to generate/consume resources during time-warp almost has to be added now to support the new science-over-time generation capability of the Science lab.
-
I don't think you're gonna get lots of hate for this thread, no. Most people will just disagree.
The problem here is that you are making it sound like you wanted SQUAD to make an official letter of apology towards "those who were wronged". But I fail to see who have been wronged here.
Because you fail to see it, then it doesn't exist?
Well, you're new here, so maybe you haven't seen how dismissive the devs are/were towards ideas like this. To the point of being disrespectful. It's simply a matter of etiquette when you change an opinion about something that you previously dismissed, you acknowledge it. The devs', and specifically Harvester's, failure to do so is, again, disrespectful.
The development team has a long history of doing a crap job of communicating with the community, and this is just another example. Besides, I'm not expecting an "official letter of apology", I said "acknowledge". I never said that, so stop putting words in my mouth.
I mean, you are assuming that SQUAD is now 100% into time based mechanics, when in reality they said that there is a time limit to collect science from the lab, which will prevent players from exploiting the gathering of science. If you think about it, you'll see that what they said is very far from they saying they endorse all kinds of time based mechanics. Right?This is one of the lowest forms of argument. I never said any of this, and I never assumed any of this... you're just not worth talking to.
-
So what? Since they learned that this game mechanic did make sense, they now have to grovel and self-flagellate about how wrong they were? This is their first game.
[sarcasm] Yep, that's exactly what I said. Acknowledgment = Groveling. The two terms are completely and perfectly coextensive [/sarcasm]
Thanks for the hyperbole, son. There's the door.
-
Hate is such a strong word though, what do you expect them to do? Crawl through the dust and apologise for introducing it and acknowledge they were wrong in the past? (even though you say you like the idea)
I expected them to say "We changed our minds about this" or "We looked at this, and realized that we were wrong about time-based mechanics being un-fun and impossible to implement".
And as I stated in the OP, I expected to get lots of hate about this.
- - - Updated - - -
Why are people against time-based mechanics just because of timewarp? Even if you warp, the time has still passed.Ask Harvester! He was DEAD-SET against them! I've always thought it's absurd position!
-
I'm talking specifically about this line:
the data fed to the lab will generate a steady output of Science for a very long time, ultimately yielding far more science than transmitting or even recoveringGenerating science over time. I like that there is a time-dependent mechanic is the game. I dislike that the devs decried such a system being fun or even reasonable for years, and I hate that they're changing their mind without any acknowledgment.
-
Okay, wow... So after years of Harv taking a hardline against including any kind of what he has referred to as "time-based mechanics in the game (namely life support and long-term research labs), we see this:
This week, along with various other tweaks and fixes, we’ve been having a look at the Science systems, specifically the purpose of the Lab module, which so far hasn’t been very worthwhile in terms of effort spent vs. the rewards it brings. We’ve completely rethought how Science Labs work now. Instead of merely boosting the xmit factor of a science experiment for a small amount (something that scientists can do now), and allowing you to restore inoperable experiments (also something scientists can do now), the Lab now works much more like a long-term research facility. Now, when you run experiments, you can transfer data to the lab just as before, but instead of a quick process for a small boost in the xmit factor, the data fed to the lab will generate a steady output of Science for a very long time, ultimately yielding far more science than transmitting or even recovering. This, of course, requires the labs to be manned by scientists, and have a steady supply of electricity. It should greatly increase the benefits of setting up orbiting science stations and surface bases, however, and also give you good reason to visit them every now and then. (The data does decay after a while, and the labs can only hold so much processed data before having to transmit, so don’t expect to be able to timewarp your way to infinite science)In the latest DevNotes.
Wait, I thought it was impossible for time-based mechanics to be fun? I thought the mere existence of time-warp would completely negate such a mechanic!?
I know I'm gonna get hate for this position, but it just drives me up the wall that, suddenly, this mechanic can be fun... It is just so frustrating to see the devs do a complete 180 on these topics without any kind of acknowledgement that of the shift. I really hope they implement this right, but I'm getting really nervous about the quality of 1.0 with all these features being shoved in at the last minute without any time to test balance.
And to be clear, I'm all for time-based mechanics, and if we're including them, then I think life support systems are worth being re-evaluated.
-
Why doesn't he burn into Kerbol orbit, then plot a maneuver to encounter Duna. Easier and more fuel efficient.
You need to check your math. Burning an escape from LKO into interplanetary space, followed by a separate transfer burn from interplanetary space is never more efficient than burning a transfer directly from LKO.
-
I find all this a little annoying, because in the first post I already said:
Well, What you're describing really isn't a bi-elipitcal transfer, but sorry to have wasted your time. I won't make the mistake of trying to help you again in the future...
-
If you're disqualifying games on the basis of procedural generation, then you need to DQ KSP as well; the craters on the Mun, and I suspect several other bodies, are procedurally generated.
-
http://i.imgur.com/PPJooT6.png
This is a Defiance shuttle; probably the only spaceplane I've made that hasn't turned into a lawn dart. I use it mainly for ferrying crew to my station and back. However, after a reinstall, I've run into a big, BIG problem.
The fuel tanks used to drain in a pattern; the outer two (Just inside the wings) drained first, then the inner tank. Now it drains "Right Outermost Tank" first, and I can't tell past that because of all the spinning while I frantically try to shunt fuel. Anyone know what the hell is going on and how I stop it?
I'd recommend removing and replacing ALL the fuel lines on the vessel. The fuel flow rules in this games are, in a word, dumb. It's one of the many fixes we've been promised in the release version. We'll se if that pans out.
It's very possible that something didn't translate well in your reinstall. It's unlikely it's something you did, it's just one of the issues we have to live with in a pre-release game.
-
In most cases, a few days one side or the other of the optimum departure isn't going to make a big difference. The big exception I think is Moho, which has an orbital period of just 102 days. Let's say we miss the ideal ejection time by 10 days, then Moho has moved 35 degrees from the optimal phase angle. This is quite significant and will result in a suboptimal transfer, likely costing several hundred m/s in ÃŽâ€v. Don't forget that it's just not the ejection burn that matters, it's the orbit insertion on the other end as well (unless you're doing an aerocapture). The penalty that you pay for a suboptimal transfer may come in the orbit insertion rather than the ejection burn.
I think its fair to point out that Moho is the single glaring exception where your orbital position would matter in an ejection from a higher-than-LKO parking orbit, but I feel like we're all in agreement that the method is a bad idea anyway. The only reason we brought up the counterpoint was to point out that the problems with the method are not so much the positional difficulties, but increased dV costs.
Also Moho is almost always the exception because Moho is a freaking nightmare of a planet to reach, regardless of method.
But since you brought it up, this paragraph makes gives me the impression that you're doing direct Hohmann transfers to Moho.
And that makes me very sad.
I've found the best approaches to Moho do not determine transfer windows based on relative locations between Kerbin and Moho, but between Kebin and Moho's AN/DN. Moho orbits so fast that you don't need to line up with the planet on your first approach, you can just slow yourself down at the PE (which should be near to Moho's orbit) so you can catch it on the next orbit. This also reduces the TWR requirements for the capture burn, since you've already killed some orbital velocity relative to Moho. Direct Moho transfers are just bad ideas.
And if you're trying to use such a complex method to approach Moho in the first place, you're either (a) smart enough to figure out when to launch from Kerbins SoI OR (
screwed from the get-go because you're trying to imitate what you saw someone else do without really understanding what's going on. -
TBH I would not say that it flatlined, just that a new direction was needed after going in a wrong direction ( I'm from the opinion that the Shuttles the USA and the USSR made in the 80's were a terrible idea that made the space exploration go sideways for a couple of decades ). It is good to see that people started to worry about making better rockets again, though
Well, technically, "sideways" is kind of a flat line
But I agree, in retrospect, the shuttle kind of stagnated the space program, but I largely blame the USAF's involvement/shenanigans for a large portion of why the shuttle never lived up to it's hype.
-
We kinda have real basics of the main thing you would get out of a wind tunnel with the center of lift button.
Eh, not quite. You still need center of drag and, even with FAR, there are nuances of flight at various angles of attack that could be easily assessed via a wind tunnel.
-
The other 10% is Maxmaps "playing" the game and not worth your time. Seriously, there's a reason OWK has so much rep over the summaries. S/he suffers so you don't have to.
THHHIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIISSSSSSSS!!!!
I HAD to stop watching Squadcast because it was such a waste of time. Max's play isn't entertaining or enjoyable in any way, it's just intolerable. I felt like I was being punished for being interested in his announcements because he would usually, but not always, subject the viewers to 45 mins or more of his incompetence before saying anything useful.
In fairness, I don't think the demographic there is the Serious Business rocketry crowd. From what I've seen in the chat during a Squadcast it's more of the Explosions and Improbable Spacecraft crowd, who would likely enjoy watching Max's play more. If you are looking for the info that's almost all delivered in the last few minutes anyway, so you can skip the earlier parts if you don't like them (or just read OWK's summary).Yes, but "Serious Business crowd" are equally worthy of hearing the SquadCast announcements. And seriously, who are your long term players that have worked to help push the game forward?
Here's a hint: It's ain't the ones that giggle and clap their hands everytime anything explodes on-screen.
- - - Updated - - -
I don't know about you, but I can't get more than about two minutes into the stream before I have to shut it off. Every time, without fail. OWK is a saint for suffering through that trainwreck.Amen, brother.
-
I assume the OP was talking about largest game world, and not largest as in HD footprint, content, etc.
And claiming it's the largest game world is a bit of a cheat since KSP re-scales itself at various vessel speeds as part of it's "floating origin" system.
-
The more I look at this:
V∞2 = Vbo2 - Vesc2the more I love it. At least when I rearrange it to:
Vbo2 = Vesc2 + V∞2
This method is so much more direct and easier than the other methods I've used to figure out IP transfer costs. Srsly, thank you for bringing this to my attention.
-
Another potentially big problem with performing the transfer from a high orbit is the timing. The burn has to be performed when the 'angle to prograde' is correct. Minmus has an orbital period of over 56 days. When the ideal time for the ejection burn comes, we could be on the opposite side of Kerbin and 28 days away from where we need to be. Being off by that much means we're likely to miss the launch window altogether. And even if we're off by only a day or two, it still means we're performing a less than optimal transfer.
I don't think the timing is as big of an issue as you've presented it. Yes, the orbital period is 56 days, but these are 6 hr kerbal days. It orbits Kerbin every fourteen 24 hr days, so it's not that bad. And with some appropriate planning, you can completely mitigate the issue. The transfer windows are also typically wide enough to accomodate some fudging by a few days on each side.
I've never done direct interplanetary transfers from Minmus, but I have done a handful of Minmus-to-LKO IP transfers, which are even trickier to time. I have never had a problem with Minmus being in such a bad position that I completely missed a transfer, or even had a transfer that would have cost more dV than a direct LKO escape.
-
Hyperbolic excess velocity, as I explained it, it the theoretical velocity that a spacecraft would retain at an infinite distance (i.e. the real life definition). As you correctly describe, this isn't completely relevant to KSP because of the use of patched conics. Likewise, the mathematically derived definition of escape velocity isn't applicable to KSP either. To "escape" in KSP we just have to raise the apoapsis of the orbit until it touches the sphere of influence, thus it's possible to escape with what is technically an elliptical orbit. In KSP, the residual velocity that a spacecraft retains after crossing the SOI is greater than the calculated value of V∞. The "effective V∞" is simply the spacecraft's velocity relative to Kerbin as it crosses the SOI. Similarly, "effective Vesc" is the velocity needed to raise the apoapsis to exactly the radius of the SOI. The relative velocity that we require at the SOI is the difference between the orbital velocities of Kerbin and our planned interplanetary transfer orbit.
While the escape velocities are calculated slightly differently in the game due to patched conics, the differences are pretty small. For example, the "proper" escape velocity from a 70 km orbit around Kerbin is 3246.9 m/s (dV = 951.0 m/s) where the "effective" escape velocity is 3234.1 m/s (dV = 938.1 m/s). That's a 13 m/s difference in nearly 1 km/s burn, just above a 1% difference.
Now since these escape velocities are practically interchangeable, Vinf is a reasonable approximation of the relative velocity to the parent at the SoI change, and we can use your presented equations to answer some of the OP's questions that have kind of gotten ignored, specifcally this passage:
A = burn to heliocentric orbit/a orbit to the edge of kerbin's SOI
B = the transfer burn from High SOI/heliocentric orbit
C = The transfer burn from LKO
I would expect that A+B > C, but that B < C, and A<C
If I refuel after A, then my craft should be able get by with lower dV capabilties... but this seems to be wrong.
But then I also have to consider some other things... like the oberth effect from orbiting Minmus, doing a bi-elliptic transfer (from minmus, lower PE to just above kerbin, then burn from there, but then the transfer window timing is even more complicated), departing from Mun instead... and so on.
But... something just seems intuitively wrong here... I really expect B < C...
Can anyone help me with the math to show why this is? Supply actual numbers, rather than just "Oberth effect, it just works out that way" (which I've already concluded)
We can translate his A, B & C terms into equivalent terms in your equation:
Vbo2 - Vesc2 = V∞2A is Vesc
B* is V∞
C is Vbo
*Note this is using the OP's "Heliocentric orbit" definition
Your equation can be rewritten: A2 - C2 = B2
Which can be directly rearranged to the Pythagorean theorem: A2+ B2 = C2
In this light, the triangle inequality theorem should support the OP's intuition on the following points:
- A + B > C
- C > B
- C > A
Specifically the second point, because the OP states:
I really expect B < C...However, this would seem to be contradicted by Alexmoon's transfer calculator, which I confirmed gives values similar to those in the original post:
From a 100km LKO orbit to jool needs a dV of 1986 m/sFrom a 47,000km orbit (ie, where minmus is), one needs 2584 m/s!!!
The burn is almost identical to the Minmus orbit at an even higher starting altitude of 75 Mm. And, by my calculations, the dV cost of a burn from a Heliocentric orbit at Kerbin's altitude (which should be equivalent to the hyperbolic excess for the transfer) is greater still at 2760 m/s.
I think what is being missed here is the speed of the vessel relative to the sun due to it's prograde orbit around Kerbin. When orbiting around Kerbin at 100 km, a vessel has an prograde orbital velocity relative to the sun of 9284.5 m/s (Kerbin's orbital speed) + 2246.1 (Orbital speed around Kerbin at 100 km) = 11530.6 m/s. At 47,000 km, orbital velocity around kerbin is ~ 272 m/s, almost 2 km/s slower than LKO, and when starting from a slower speed relative to the sun you have to spend more dV to accelerate to initiate the transfer.
I found it illuminating to to fully comparing the two sets of numbers.
For a 100 km LKO burn:
Vbo2= (2760 m/s)2 + (3176 m/s)2
Vbo = 4208 m/s
dV = Vbo - Vorb = 4208 m/s - 2246 m/s = 1962 m/s
For a "near Minmus" burn (47,000 km):
Vbo2= (2760 m/s)2 + (385 m/s)2
Vbo = 2787 m/s
dV = Vbo - Vorb = 2787 m/s - 272 m/s = 2515 m/s
So while the target burnout velocity is smaller in Minmus escape scenario (i.e. C is reduced because A is reduced, and C > B remains true) , it actually takes more dV to achieve that velocity because the starting orbital speed is lower. Essentially, I think A, B, C's presented by the OP work provided that you remember they're true for velocities, but are not true for the delta Vs in this situation, and I think this may have been where the OP was getting hung up. Certainly was for me.
And this is math doing a direct burn from Minmus' altitude, not dropping down to LKO from Minmus before performing an ejection burn. The latter is still an awesome idea that works well.
Okay, I feel way better about this now.
P.S. the numbers are a little rough because I was dropping decimal places for expediency. Also they won't exactly match Alexmoon's calculator because he tweaks ejection phase angles, which I'm not doing. Alexmoon's numbers should be more accurate.
- - - Updated - - -
One thing I haven't seen considered here is TWR differences. While burning from that high up would take more fuel than if done from lower down, the much weaker gravity means a much smaller engine can push much more fuel. Since the fuel-mass to ship-mass ratio is improved you have higher starting dV. I'm not a math wizard, so I can't be sure if it's even possible that this can offset the costs of an inefficient burn (let alone save anything), but I thought it was an interesting idea (and sortof on topic). Any thoughts?It's true that increasing TWR can reduce dV costs. However, It's basically assumed, for everything presented here, that the changes in speed are instantaneous (essentially TWR is infinite). In reality, all the transfers and burns presented with have slightly higher dV costs than what we've calculated and presented, and as OhioBob pointed out, lower TWR is going to have less effect at high altitudes, but it's never really going to save you anything worth noting.
- A + B > C
-
Can I ask for a clarification, OhioBob?
When you refer to "hyperbolic excess velocity", is that effectively the velocity of the vessel when you leave the SoI? I understand it should be the velocity when the body is infinitely far from the parent and is no longer being affected by the parent's gravity, but with the patched conics, the parent no longer exerts gravity after leaving the SoI.
If this is true, the "hyperbolic excess velocity" is essentially the target velocity to transfer from one body to another, right?
-
Scott Manley did a great job demonstrating
into an interplanetary transfer exploiting the Oberth effect. This is the video that really clarified the Oberth effect to me.OhioBob demonstrated the math very well above for this specific case. Another way to summarize and generalize the "Oberth maths" (and how I think about it) is that that escaping a planet's gravity is about specific orbital energy ("E", and otherwise labeled simply "orbital energy" from here), which is calculated using the equation:
E = 1/2 V2 - mu/r
V is orbital velocity
mu is the gravimetric constant
r is the orbital radiuys
It's basically the difference between the kinetic and potential energy with the mass term dropped (don't worry, it's cool, and I can show you why it doesn't matter if you want. It doesn't make a difference for this application). For any given orbit, E is constant at all points (all r) on the orbit. So long as E < 0, you will have a "closed" orbit (you're captured) and when E =>0, you will escape the body you're orbiting. Put another way, you can escape a planet when your kinetic energy exceeds the gravitational potential energy the planet is exerting on it.
So you want to increase your kinetic energy to escape, and your KE is determined by velocity squared. You increase your KE and velocity by spending dV, and the change in E created by spending a fixed amount of dV at a given altitude is calculated:
dE = 1/2 V2 - 1/2 (V + dV)2 = 1/2 V2 - 1/2 (V2 + 2 V*dV + dV2) = V*dV +1/2 dV2
Since V appears in the expression of dE (the red term in the simplification), the amount of E changes when dV is spent is dependent on the vessel's velocity. Spefically, higher V leads to greater changes in E, so you want to be travelling as fast as possible when you spend the dV to escape.
So, since you tend have lower orbital velocities very high up (as high as Minmus) and you tend to have higher orbital velocities when orbiting at low altitudes, it should be clear that you want to spend dV at low altitudes/high speeds to maximize the effect of that dV.
Hope that helps.
-
Yes that was the whole point of the 3 launches. I wanted a comparison.
Yes, but based on your descriptions, you performed the burns in ways that aren't comparable. Since you did it this way, it seems clear that you weren't aware they aren't comparible and I was trying to explain the source of the problem to you.
Sorry?
But finally, I did'nt understant the "DV-left" I had. Something is wrong with Ker (in the VAB and flight) and MJ (only in VAB).As TheXRuler pointed out, KER can get confused about dV calculations when the rocket isn't a simple "top down" staging.
-
Personally, I don't think it's reasonable to build SSTO aircraft without at least turbojets, which require High Altitude flight, which you've disallowed. Possible, yes, but it's a major hassle. In my book, TJs really are the critical technology that makes SSTO spaceplanes feasible.
With TJ's, you can add small efficient LFO engines (48-7S, 24-77s, or 909s) or O10's to complete the orbit. I know I was to build a low-tech 2-man SSTO in FAR that used 1 TJ, 2 909s, and I believe 3 circular intakes, but that was in 0.24 or maybe even 0.23.5.
PS Expect someone to come in here and get snotty about how it doesn't have to be an aircraft to be an SSTO.
screwed from the get-go because you're trying to imitate what you saw someone else do without really understanding what's going on.
"Time based mechanics" aren't fun, but we're shoving one in at the last minute...
in KSP1 Discussion
Posted
You probably wouldn't be if you actually read what I wrote instead of the rest of community's reaction to it, but I guess I forgot which community I was dealing with.