arkie87
Members-
Posts
1,061 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by arkie87
-
I understand. I wasnt trying to be "technically correct" (i think its stupid when people try to be technically correct) and i understand why you think its misleading. I wasnt suggesting its better to do ( and then go to Jool. My question arose from a thought experiment i.e. it doesnt make sense that to get from (a) to jool takes less energy than (, since (a) is inside two gravitational wells (the same as ('s but also in Kerbin's) and should have to expend more energy to get out of those wells. Do you understand where i am coming from? However, it seems like GoSlash27 thinks we are both wrong, and that actually, it takes less dV/energy even from Kerbin's surface. I'd like to see the calculations on that....
-
I meant the question as posed. It was a thought experiment, so for the question's sake, satellite ( originated where it was, and we do not need to factor in how much energy/dV it took to get there. Not sure what the rest of the post was adding though... - - - Updated - - - Please explain to me how what i said about the oberth effect is incorrect. In fact, I am saying exactly what you are saying, but for some reason you think i am wrong. We are approaching the Oberth effect from two different (phase :-P ) angles....
-
Yes, thank you. My mistake was saying it only takes 1 km/s to escape kerbin SOI from LKO. In fact, it takes more, but you already have orbital velocity (2.3 km/s), so therein lies the problem. Thus, in my post above, ( is the correct answer as long as the spaceship doesnt start in LKO but rather on the surface of Kerbin. Otherwise, if it is in LKO, by burning 2 km/s, it can escape Kerbin SOI with (4.3^2-3.3^2)^0.5 = 2.76 km/s (which, incidentally, is more than it burned). Thanks again.
-
Another way of wording my question/problem/confusion: A thought experiment. Which satallite will take less deltaV to get to Jool? (a) A satallite in LKO ( A satallite in the same orbit as Kerbin, but on the opposite side of Kerbol (thus, same orbit as Kerbin, but not in Kerbin SOI) I maintain answer has to be B since A first must escape Kerbin SOI. If I am wrong, why? Please explain in detail, not just quoting Wikipedia articles on Oberth Effect etc...
-
I appreciate you trying to, but its not answering my question (its just repeating about the Oberth effect). The oberth effect is: Let's say it takes 1 km/s to escape a planets SOI from low orbit. If you burn 1 km/s in the right direction, you will end up with 0 m/s velocity. If, instead, you burn 1.1 km/s, you will have more than 100 m/s velocity left over since gravitational wells require a certain amount of energy to escape them rather than deltaV. In fact, you will have (1100^2-1000^2)^(1/2) = ~ 458 m/s left over (an additional 358 m/s). THIS is the Oberth effect. That additional velocity can be used towards raising apoapsis towards Duna etc... In addition, if you were to burn 10 km/s instead of 1.1 km/s, you would escape SOI with 9,950 m/s and as the burn approaches infinity, the dV required to escape SOI approaches zero... However, you will notice that the velocity you have upon escaping SOI is never larger than the initial burn (obviously) and the velocity difference is never larger than the amount of dV needed to escape SOI i.e. 1 km/s.... That said, please explain the following paradox: I understand what Oberth effect is. But i still maintain that these charts make no sense: Consider a spacecraft in the same orbit as kerbin but on opposite side of Kerbol such that it isnt in Kerbin SOI. It would take X deltaV to get from there to Jool. That value is roughly equivalent to the amount of deltaV required for a spaceship that just barely left Kerbin SOI to get to Jool (maybe larger, since eccentricity might be aiming the right direction so some of the deltaV wont be wasted). Thus, the maximum wasted energy is the ~1 km/s wasted deltaV needed to just barely get out of Kerbin SOI. The oberth effect allows you to double count your transfer burn and Kerbin SOI burn... Can anyone explain why this is wrong without a generic "oberth effect rah rah rah"?
-
I understand what Oberth effect is. But i still maintain that these charts make no sense: Consider a spacecraft in the same orbit as kerbin but on opposite side of Kerbol such that it isnt in Kerbin SOI. It would take X deltaV to get from there to Jool. That value is roughly equivalent to the amount of deltaV required for a spaceship that just barely left Kerbin SOI to get to Jool (maybe larger, since eccentricity might be aiming the right direction so some of the deltaV wont be wasted). Thus, the maximum wasted energy is the ~1 km/s wasted deltaV needed to just barely get out of Kerbin SOI. The oberth effect allows you to double count your transfer burn and Kerbin SOI burn... Can anyone explain why this is wrong without a generic "oberth effect rah rah rah"?
-
How is that possible. To get from LKO to outside Kerbin SOI takes roughly 1 km/s. Even if all this energy is wasted, the difference between the two approaches shouldnt be more than 1 km/s? That's like saying that it takes more energy to get from LKO to Jool than it does if you were in Kerbin's orbit around Kerbol, but on the opposite side of Kerbol (i.e. not in Kerbin's SOI)... If im wrong, can someone explain why...
-
I dont see how that table makes any sense. The difference between "simple flightpath" and "advanced flightpath" cannot be larger than the amount of fuel wasted to get out Kerbin's SOI i.e. approximately 1 km/s... #AmIWrong? I agree though that KSP needs better tools for (finding optimal) transfers. I'd prefer a tool that makes it relatively easy to find/tweak rather than information of launch window/optimum angles.
-
Interesting. Thanks for posting. It's a good (better) method, but requires setting up a lot of fragile maneuver nodes, and provides no easy way to time accelerate to this node (without switching back to tracking station). Perhaps allowing you to control the reference body of your orbital trajectory would obviate the need to set up the first maneuver node (see above).
-
True, you still have to wait, but the difference is (1) you can time warp at full speed since you are interplanetary and (2) this method is non-iterative... i.e. you dont have to park yourself in a high orbit around Kerbin, attempt a transfer, see that you need to warp a bit more, warp a bit more, and then try again and again until you get a decent encounter with small wasted deltaV-- instead, you can slide the maneuver node around to find the best transfer burn since you are already orbitting kerbol. Hmm.... That got me thinking: perhaps the maneuver node tool should allow you to select the reference body i.e. Kerbin (or whatever body you are orbiting) or its parent i.e. Kerbol. For the case of the Mun, you can select the Mun, Kerbin, or Kerbol etc... this would make transfers much easier!@!@!@!
-
Thanks for the reply. I think the Oberth effect will be more "efficiently" utilized for farther planets when burning from LKO. However, the relative fraction of extra deltaV to first escape Kerbin SOI from LKO compared to the total deltaV required from LKO to Jool (let's say) is less than from LKO to Duna, since more energy is needed to get apoapsis all the way out to Jook than to Duna. Basically, it takes energy to increase the apoapsis, and if the eccentricity is small compared to the total needed change in apoapsis (w.r.t. Kerbol), the wasted deltaV will become a smaller fraction of total needed deltaV.
-
KSP Community, One thing that intermediate KSP players notice is the relative increase in difficulty/annoyance that comes with going interplanetary. As a new player, I had a lot of fun going to the Mun/Minimus since the available tools/information made the algorithm to get there simple: get into orbit, place a maneuver node randomly on your orbit, drag apoapsis to intersect the Mun’s orbit, and then adjust the location of the node until you get a good encounter. In contrast, going interplanetary is more complicated, and either requires knowledge of phase-angles/calculations of launch windows (or plugins to provide/calculate this information), or requires trial and error setting up maneuver nodes, time warping (preferably in high orbit so you can use 100,000x), and repeating. For me, manually calculating launch windows is out of the question (requiring that would be liked requiring players to calculate CoT, CoL, or CoMâ€â€it is just out of the question). So, either the stock game must give the players the tools necessary to calculate launch windows, or an algorithm must exist that makes it possible without iteration/trial and error. That said, I think I found an easy algorithm that makes getting to any planet (almost) as easy as getting to the Mun or Minimus: first get into orbit, then, set up a maneuver node (if you are going closer to the Kerbol, then place on dayside; otherwise, place on night side) drag out your apoapsis until you just leave Kerbin's SOI, and execute maneuver. You are now orbiting Kerbol in a very similar orbit to that of Kerbin (with a slight eccentricity). This situation is analogous to being in orbit around Kerbin and trying to get to the Mun/Minimus, and the same algorithm can be used from here on i.e. place a maneuver node somewhere on your orbit, drag your apoapsis until it intersects the planet of interest, and then move the maneuver node around the orbit until you get an encounter. Thus, getting to any planet is just like getting to the Mun/Minimus, albeit with one extra stepâ€â€first escaping Kerbin’s SOI. I am aware, however, that there is one disadvantage to this methodâ€â€that is it less efficient than a transfer at optimum transfer window, since some deltaV is wasted in creating the eccentric orbit around Kerbol and additional losses from lack of fully using Oberth effect. However, the loss in efficiency/deltaV becomes less significant for planets farther from Kerbin since the amount of deltaV wasted creating the eccentricity is negligible compared to the transfer burn. In addition, the wasted deltaV also scales with offset from ideal launch window (thus, if phase angle is known to be approximately correct, this algorithm could be used anyway with minimum wated deltaV). Regardless, I think for new/lazy players, this algorithm is good enough. What do you guys think? Is this obvious and/or a stupid idea or was it helpful?
-
Make "flag" contract missions biome-specific
arkie87 replied to Kerbart's topic in KSP1 Suggestions & Development Discussion
Although, in general, i dont like biomes since it gets repetitive (i'd rather have to go to each planet/moon to get new science/contracts), i like this idea, since it prevents players from taking advantage of contract system (alternatively, dont offer multiple "plant flag on X" contracts) -
dead. very, very dead.
-
...when you mess up your staging and decouple a central booster but due to the thrust, the stage is "stuck" to you sending your kerbal heading towards interplanetary space with no delta-V
-
In game Welding tool.
arkie87 replied to komandorroo's topic in KSP1 Suggestions & Development Discussion
I think stock KSP should include this feature and integrate it into sub-assemblies (i.e. a checkbox asking whether to treat sub-assembly as one part or not). This option might be disabled depending on difficulty, but i think if a "welded" part (i.e. a single part for the purposes of physics engine) has structural limits equal to the weakest link, then this feature will just increase FPS rather than "cheat" the physics. Regardless, i think i a feature like this is necessary for the building of large space stations -
What you are suggesting could be easily implemented via contracts (albeit, ones that arent in the game). I would be a fan of logically stringing together contracts that follow a storyline, while splashing in other side-contracts that let you acquire funds, rep, science etc.... to be able to accomplish the main story-line contracts. I also think a mission editor that restrict techs/parts with a clear mission in mind would be awesome for replayability <---- Great Idea!
-
What the fric.....tion?
arkie87 replied to Urb4n0ninj4's topic in KSP1 Suggestions & Development Discussion
why not make mu (dimensionless coefficient of friction) upgradable as you unlock new parts/rover-wheels? Default should be about 1. Perhaps advanced wheels can be 2? Or in Kerbol, maybe they figured out how to make mu = 10? -
Very interesting. I think long strings with counterweights attached are necessary in practice; or so it seems from http://en.wikipedia.org/wiki/Gravity-gradient_stabilization
-
My vote is for the courage-stupidity system to integrate into a kerbal-linked autopilot. Stupidity is how accurately kerbals fly ships i.e. if you tell them to execute a maneuver, how accurately they burn dV as well as timing is effected. Courage is how well kerbals do under pressure in dangerous situations such as landing ships, aerobreaking, lifting off, etc... if the kerbal is too stressed out for too long, his (auto)piloting skills will suffer, and he will crash, and xplode into a million peices. I dont have a problem with autopilot, since it quickly becomes tedious for experienced players to do repeated missions. however, i think players should have to unlock autopiloting abilities such as transferring, landing, targeted landing, aerobreaking etc... by performing these maneuvers manually (perhaps in a contract). In addition, if the autopilot's skills were directly linked with the kerbals flying them, this would help tie the game together as well as make intuitive sense.
-
The way i see it, part contracts are useful in two ways: (1) They give you early access to parts in the tech tree that you havent unlocked, perhaps making bigger/better missions possible earlier on in the game (2) They give you extra funds and science. Even though right now, in my experience, as long as your first few missions are relatively successful, you will never be strapped for cash, I think a few failed missions should seriously deplete your cash stores, and so, you might have to resort to contract fulfillment/part tests to gain some funds so you can retry that failed mission to Jool etc... As it stands now, i dont really do them unless they can be easily integrated into a mission (like any "test landed at Kerbin" contracts or use X rocket, where i was going to use X rocket anyway). Also, rejecting contracts and letting them re-spawn tend to increase payout if the contract was spawned earlier on in the game. I also think the current way of "testing" parts via staging is stupid (i like the "run tests" button better) since you can bypass this method by putting the stage to trigger late and manually activating the engine if you need it for liftoff. For instance, if it wants you to test one of the 10m rocket engines in orbit, you dont need to build a large lifter to lift the rocket engine into orbit first. You can use the rocket to get into orbit by manually activating it, and save the "staged activation" for when you reach the test conditions.