Blaarkies

Members
  • Content count

    481
  • Joined

  • Last visited

Community Reputation

187 Excellent

1 Follower

About Blaarkies

Recent Profile Visitors

1767 profile views
  1. Cockpits at the front like to heat up. Have them behind something for heat occlusion, or put them inside a fairing/cargo bay. Personally i like building MK3 size drop ships, enough to land a 2.5m ISRU anywhere on Kerbin/Laythe. So the MK3 cargo-tail is excellent...for the front of the ship!
  2. I understand SPRING is the strength/force with which the leg tries to stay extended. So for a still standing base on Kerbin, lowering this will lower the amount of weight the leg can support...it will give in more, the base will end being lower to the ground(on Minmus, that same base would stand high, since weight is much less there). Think of spring as the thickness of the spring inside the landing leg DAMPNER is the same as for shock absorbers. They stop the legs from springing up and down repeatedly(they limit the speed at which the leg may extend). Maximizing these wont make the static base stand higher, but you will see it slowly sinking down to the spring strength's height. Think of dampner like a lot of friction inside the legs, so they can only move slowly
  3. Stop lying, it's a bad habit. Update your game past 1.1, then come back... http://bugs.kerbalspaceprogram.com/issues/9650
  4. THIS^ That is why we get to Mun landings, with the Saturn 1B stage still connected, trying to land with that attached because there is still fuel in it. Don't know about you but I did that too many times when i started out...and fuel isn't even that precious
  5. Do you think the KSP NERV is a "gas core nuclear thermal rocket"?
  6. Maneuver node controls should not be the feature that makes KSP a difficult game, instead the rocket science should be the learning wall. You aren't reading the replies are you? If we are in a 100x100km orbit and we need to change inclination to 74.8'(relative to Mun, at any Longitude of Asc) i would simply want to drag the purple, Normal node handle until the Asc/Dsc nodes show 74.8'(still in a 100x100 orbit as well), then i release and DONE(thanks @DMagic, i love that mod). Why do you want to: - pull on Normal until you get an escape velocity trajectory - pull on Retrograde to further increase inclination and also bring down that Ap of the previous trajectory - repeat those steps 3 more time until you have Incl. around 74' - now comes the fine tuning, where you control 2 dimensions, both have an effect on Ap and Incl. (at this point, it really saves a lot of time by just getting here, then setting up a new node...or eyeballing this by navball) Which of those two methods takes less time? Don't tell me the old nodes are faster/fun/precise. They make sense in the same way that a math equation makes sense...but the implementation of that equation in an electronic device is much more practical. If you want to pre-calculate the amount of dv required in each dimension to rotate your orbit by a certain amount, then i have bad news for you...stock doesn't display the current dv per dimension, it only shows the magnitude of the velocity change. Precise node gives you that though (key in the amount of dv change for each dimension, and much more), and it is good practice since you quickly learn what type of maneuvers are inefficient when you calculate this by hand. It's cool that all the simple calculus tricks for vectors work so perfectly in KSP, but they should since it is a simulation of physics. But stock maneuver nodes are not any of these, they fall in the category of "good enough for average joe, and if you want more well theres a mod for that" Pulling on Normal at Ap/Pe doesn't even touch Radial, why should it? Radial is completely orthogonal to the changes that Normal causes, mainly adding a vector to the final velocity vector(sum of these has a slightly greater magnitude), which we all see as "extra" prograde after the burn. In stock when you pull on Normal in this situation, you mess up you Ap/Pe because you are changing the final velocity magnitude. Then you pull on retro a slight bit to fix that...that is exactly what the intuitive node automatically does. This is like saying, lets keep calculating the sum of vectors by hand, instead of putting in the effort to design a transformation function with expected results as inputs. To be honest, i would like a mod where the screen becomes interactive: - you add a node - alt-click on the future dotted trajectory lines Asc/Dsc node, now your mouse cursor/pointer controls the inclination. you can swirl that line all over the planet where you want it, but the line always intersects the mouse cursor. - alt-click on the Ap. Now you control the height of only the Ap, move mouse cursor up to the Mun orbit line...translunar orbit done - alt-click on on the dotted line, now the Radials component tries to match the line to the mouse cursor. - the cursor is basically saying "at some point in the orbit, i want the craft to go through this point right here" ...just because you can get more stuff done in less time, then why not? Sure, KSP is a great opportunity to learn the intricacies with these maneuver nodes, but once you know and understand them...why should you still calculate them?
  7. You mean to say, that when I add about 80% as much dv to the Anti-Normal and the maneuver icon rotates as I pull the purple Anti-normal hook, that the new direction of the icons makes any sense at all? When you pull on an icon, it should at least add velocity in the visual direction of the icon, not in the original direction it used to point at 5 minutes ago. If the node icons did NOT rotate, then it would be "works as intended and makes sense". But because the entire widget rotates, it also now must do what it displays...but it doesn't, which does NOT "works as intended and makes sense" You don't eject with inclination much do you? Try that, or simply get yourself in an elliptical orbit, change inclination at Ap to get into a 90' polar orbit, then come and tell us how much you enjoyed struggling with the current maneuver node system.
  8. Also change the way that Normal/Anti-normal and Radial-in/Radial-out is applied. At the moment, they just add to the vector's direction and scale which is a bit counter-intuitive. The Normal/Anti-normal should only change inclination at that point(without affecting the final orbital speed). Same goes for Radial, i have seen some mod that does this
  9. Yes, as long as they don't get too close to the Mun orbit. Mun orbits at an altitude of 12 000km, and the Mun itself has a "Sphere of influence" of 2 400km. This means that if you orbit Kerbin, and at Apoapsis(maximum altitude of your orbit) you reach (12000-2400)= 9 600km then you could someday get pulled along by the Mun. That is what happened, but only after some time: your satellite and the Mun finally synchronized their positions in each orbit until they lined up..."luckily" your craft didn't hit the Mun but "only" got sling-shotted around KerbOl So, don't let your "long-term" orbits cross the 9 600km -> 14 400km altitude then you will be fine. Minmus is not really an obstacle, you can go decades before "accidentally" getting an encounter. The next limit is 84 000km...that's Kerbin's SOI limit(after which you reach Kerbol orbit)
  10. No, since KSP 1.1 that doesn't work anymore. Now if a probe is dead, there is nothing the player can activate on the craft (neither functions nor fuels lock)
  11. I support this.
  12. Do you even Math? @Snark just provided proof, so now you want to argue with Mathematics itself? If you really want practical evidence, dont even listen to MJ/KER since they also just do calculations (that's why you added the RTG at the top right?). Instead, barely leave Kerbin SOI. Write down the current velocity. Start the burn, the whole burn and nothing but the burn. When the xenon tank is empty, write down the final speed. The difference is your dv. * You can then reverse the rocket equation to find the effective Isp. * Sure you will lose some speed over a few hours due to Kerbol's gravity keeping you from ascending, but it won't be much more than 100m/s dv over a 10 hour burn
  13. That not impossible . You have at least 1/3 of a Kerbin month to do that maneuver. Heres how you do it: - Launch west(270') - Setup a maneuver of that will give you an AP as high as the contract's orbit, move and adjust this maneuver forwards/backwards in time so that it will be just an hour too late to catch the Mun - After the burn, wait until you are halfway to Ap, then fix you inclination. You want to burn "north"/"south"(Normal/Anti-normal) until you AN/DN(yellow marker) matches up with the intersection point of your orbit, and that of the contract's orbit. You must touch the contract's orbit as close as you can. - Create a maneuver node on that intersection point. Use all directions on the node to define a burn that will match lines with that of the contract. - Wait 10 seconds. Profit. Wait a few days and BOOM! This works because when you change your orbit, you will always pass through the same point in space again no matter how much you burn in which ever random direction*. So you need at least two burns, each in two different points in time, to actually get away completely from your original orbital trajectory in space...in this contract, you want to do the opposite. * not including escape velocities, suborbital trajectories, gravity assists or Jeb staging.
  14. Change the "spring strength" on the legs. For Minmus, you need it really, really low. This will let the legs contract slightly, until all feet pads actually touch the surface. Not sure where to do it in the .cfg though Is that a base crawler there? Cool design EDIT: Never put the dampner on minimum. One would think that for Gilly it would help having the softest possible suspension, but it doesn't...you just keep bouncing, without touching the controls, like a high-bounce rubber ball. Having some dampner should stop this, but minimum spring is also dangerous as legs like to *poof* when they are compressed all the way