Jason Patterson
Members-
Posts
337 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Jason Patterson
-
So far the response to bugs reports on here has been to post an unhelpful article about bug reporting and then lock the thread. Not sure if this will last or not, or maybe make a difference in how bug reports are responded to, but to be clear, if you have a bug or wish to send feedback, there is a tiny, unlabeled button in the bottom right of the launcher. A little black and white chat bubble button - that's the one you want to find and click for feedback purposes. The linked article also says that there are a bunch of other ways to communicate issues, but apparently this, their own forum, isn't one of them.
-
Big fan of KSP 1 and not a hater for KSP 2. Early Access <> Finished, and some folks can't see that. Should have gotten a screen shot, but did an optimal gravity turn on the Mun (i.e. barely above the ground) and the game about had a stroke switching between some mode or other as I cruised along at a couple of km above the surface. Auto: Ground, Auto: Orbit were flashing in sequence literally hundreds/thousands of times. It didn't stop until I was high enough above the ground for non-physics time warp to kick in. Polite suggestion - I like the big weird bubble + entrance/exit targets UI addition for encounters, but I can't figure out how to get the piece of my orbit that is involved in the encounter to be shown relative to the surface of the target. Desired behavior: If I have a Mun encounter, the piece of my orbit within Mun's SOI is shown beside the Mun rather than just a weirdly shaped bit of my orbit around Kerbin. (If that's currently possible, would love to know how.)
-
If you're trying to stay somewhat realistic, you'll need to send a rescue mission to the crater in order to save your kerbal. If you're not worried about that, then kBob's suggestion of infinite fuel should do the job nicely since you can fly on the Mun. The other option is to abandon the kerbal altogether and call it a learning experience.
-
[1.1] RemoteTech v1.6.10 [2016-04-12]
Jason Patterson replied to Peppie23's topic in KSP1 Mod Releases
I've got an odd issue. I installed this mod for the first time yesterday in a new 1.1 hard career mode. The long and the short of the problem is that the Reflectron DP-10 is completely missing from my tech tree. I tried a completely new KSP 1.1 with no other mods than RemoteTech and the problem persists. Today I tried the 522 build instead of the 1.6.11 release from the first page of this thread, but that didn't do the trick. I do see other RT antennas in the tree, just not the DP-10... Any thoughts? -
The only reason I was suborbital in my example is because Kerbin has an atmosphere. The periapsis was right at Kerbin's surface. I suspect that some of the confusion in general (though perhaps not in your case) comes from thinking of an orbit of this type as 71x0 instead of the far more accurate 671x600km that it really is. It's only 11% out of circular at the time we were deciding either to coast to a 71km apoapsis or continue burning to a 250km apoapsis. Another way to think of this: If I burnt at periapsis to raise my apoapsis by 1km, then circularized, then repeated until I reached my destination orbit, that would be substantially less economical than a few well-timed burns to reach the same goal due to increased use of the Oberth effect. The limit of how few short duration burns you can make in this case is two - one to raise the apoapsis and one to circularize, and that should be most efficient.
-
Not really. If you're burning prograde prior to apoapsis (or really any direction other than radially) then you're never going to create a circular orbit, as your apoapsis is always going to be higher than your current position, which can't be lower than periapsis. To get a circular orbit you either have to burn at one of the apses to alter the other or burn radially to make your current position an apsis and alter the other side of the orbit. It's 100% possible to do a proper gravity turn and burn hard enough to exceed Kerbin's escape velocity without ever having a periapsis above the planet's surface. The first option is superior. You're taking advantage of your high launch velocity (the well know Oberth effect) to increase your ship's energy enough to reach a high altitude. At that high altitude you can then make a relatively small adjustment in velocity to increase your periapsis to circularize. To circularize at 71 km you need to add significantly more velocity as well as lose velocity to reach periapsis (i.e. waste Oberth effect.) At this point you then step up to 250km, then increase your periapsis to 250km. Though this second periapsis increase would be less than the first version, the savings on that step would not outweigh the losses at other steps. I might try to set up a test later to try this out, but it's going to vary somewhat depending on the particulars of your launch anyway. ETA: Better, I just did the math. I'm assuming burns are instantaneous for sanity's sake. Real burns take time, so the difference is slightly less, but if your burns are taking a significant fraction of an orbital period, you really ought to increase your TWR (or be using a crazy efficient engine to compensate for the loss.) I ran a quick launch to see where my periapsis would be with a reasonable 71km apoapsis, and it happened to be right at the surface (321 meters below it, but that's close enough for government work.) I hit that periapsis at about 40km. Let's assume that you've burned to a 71km apoapsis with a 0 km apoapsis and your ship is at 40km. You're now going 2340 m/s. You now follow one path or the other. A) Circularize at 71km, burn to 250km, circularize at 250km. 1. Coast to apoapsis = 0 m/s delta-v 2. Burn to circular orbit: At apoapsis your velocity will now be 2229 m/s. A 71km circular orbit has a velocity of 2294 m/s. 65 m/s delta-v (This does not include additional losses in this launch due to prolonged time in the atmosphere, perhaps 10m/s total delta-v difference between the two.) 3. Burn to 250km apoapsis: This requires an increase to 2425 m/s at periapsis. 131 m/s delta-v 4. Burn to circular orbit: At apoapsis your velocity will now be 1914 m/s. A circular 250km orbit has a velocity of 2038 m/s. 124 m/s delta-v Delta-v total for this burn from the starting orbit: 65 + 131 + 124 = 320 m/s Burn to 250km, circularize at 250km. 1. Burn to 250km apoapsis: Doing the math here is rough. If you simply increase your speed here without changing direction you would raise both periapsis and apoapsis. You'd have to intentionally orient your ship at some wonky angle to force your periapsis to remain at 0km. Doing a horizontal burn to avoid gravity drag gives me a new periapsis of 35km, and apoapsis of 250km, all at 40km altitude. Your mileage may vary, of course. In any case, this yields a new velocity of 2507 m/s. 167 delta-v 2. Burn to circular orbit: At apoapsis your velocity will now be 1887 m/s. Again a circular orbit has a velocity of 2038 m/s. 151 m/s delta-v Delta-v total for this burn from the starting orbit: 167 + 151 = 318 m/s You save a whopping 2 m/s by my calculations! Totally worth it!!! Contrary to my expectations, there's just not enough difference between a 71x71 orbit and a 71x0 orbit to make a difference here. I'm sure that the difference would increase for a larger destination orbit (say a Mun encounter) and for a more aggressive gravity turn than I made, but it's not going to be much for a typical launch of mine, as a fraction of total delta-v required.
-
Dark Giant may be lurking beyond pluto's orbit
Jason Patterson replied to PB666's topic in Science & Spaceflight
I'm not in any way arguing with the idea that Earthbound observatories cover the entire sky (minus the bit behind the Sun at any point in time), but this is a bit of an overstatement of the field of view of an observatory. The most any single ground observatory can see is 1/2 of the sky, since Earth itself blocks the rest. One near the north pole would have a poor view of anything close to the equator and would see little or nothing of the southern sky (depending on how close it was.) One near the equator could, in theory, see the entire sky over the course of the year, but in reality the poles would too close to the horizon for proper viewing. It only really takes two observatories on the entire planet, properly placed, to get good, clear views of the entire sky - one northern and one southern, perhaps at 30-45° latitude. -
So... Spaceplanes for Duna
Jason Patterson replied to juanml82's topic in KSP1 Gameplay Questions and Tutorials
+1 to this. I really like drogue chutes on Duna. -
For the part of the game that exists prior to flight planning being affordable, you'll just need to burn prograde/retrograde at periapsis in order to change your apoapsis. As long as you're not using life support mods, you can get your orbit about right and then wait for the Mun or Minmus to come to you. Once you get an encounter, it's fairly straightforward to adjust it to fit your needs.
-
Parachute failure
Jason Patterson replied to quantumpion's topic in KSP1 Gameplay Questions and Tutorials
Parachutes have always failed if deployed under too high a load; it's not new behavior. The recent patch made the behavior more common. -
My dumb a** deltaV question
Jason Patterson replied to maceemiller's topic in KSP1 Gameplay Questions and Tutorials
I'm glad it helped. There's a lot of this that is in no way obvious; don't feel bad if you get confused. The Q&A forum is usually very patient with these sorts of things. -
My dumb a** deltaV question
Jason Patterson replied to maceemiller's topic in KSP1 Gameplay Questions and Tutorials
It's not a dumb question at all. Delta-v is a measure of the change in velocity that a rocket can cause if it were in a totally gravity-less environment. Its value is based on how much fuel you bring, the mass of the rocket, and the mass of any additional payload you might have. For an analogy that might help this make more sense: Suppose I have a loaded semi truck that can travel 200 miles on the fuel that it has. If I weld a second truck with an identical load and fuel to its side, it's not going to be able to go 400 miles. Instead it will move 200 miles with twice as much load as the original. That's what you've done here, given yourself the ability to move twice the payload through the same velocity change as the original ship. If you want to add delta-v to a vessel, the easiest way is to add booster rockets that are as minimal as possible: fuel tanks, engines, and whatever aerodynamic or control devices are absolutely necessary to get it where it needs to be. -
PSA: ISRU can be exploited for easy funds
Jason Patterson replied to KerikBalm's topic in KSP1 Discussion
This is a single player game. It's impossible to exploit or cheat. If you find this to be a game breaking way to make money, by simply launching an oil well and letting it run until it makes oil, then don't do it. That said, it's trivially easy to open your persistence file and change the value of "funds" from whatever you have to whatever you want. It takes all of 20 seconds to find and alter, whereas your "exploit" takes time in terms of designing and launching the rig, operating it, and bothering with the timewarp to get it working, all in exchange for a tiny amount of income. They don't even attempt to protect that sort of thing, and why would they? As long as it's not something that is forcing you to play the game in a way you dislike, it's not hurting anyone. -
I've used both, and I personally prefer to stick with KER and skip MechJeb. I like having the additional information when building/flying ships, but I don't like giving control of my ship to the computer, even if it's something I've done a thousand times.
-
Docking Difficulties
Jason Patterson replied to Rithaniel's topic in KSP1 Gameplay Questions and Tutorials
It's not what you want to hear, but two new launches with redesigned vessels will solve the problem fairly quickly. It only takes 10-15 minutes to get them into orbit and docked. I'm not sure if this would be helpful or not, based on your description, but you really only need one vessel that moves correctly to fix your situation. Could you undock the lander can and get something maneuverable out of the parts that are left over? -
There has always been a chance of kerbals surviving impact as long as they hit land rather than water. Water landings are always fatal, but a ground landing often results in a bounce. Oddly, the second impact, the one from the bounce, is more often fatal than the first, in my experience. If you've got a ship coming in too fast to land, the safest thing to do is to bail out at the very last second. You'll bounce more often than not.
-
No exp gain from Flight on Kerbin
Jason Patterson replied to emfleck's topic in KSP1 Gameplay Questions and Tutorials
None of your kerbals have been on an atmospheric flight in a rocket? The game doesn't distinguish between winged craft and not. -
Exploration of Kerbol and heat management near it
Jason Patterson replied to lajoswinkler's topic in KSP1 Discussion
It's actually a fairly significant bug. It causes crashes in roughly 50% of my atmospheric entries. -
I'll confess to not having looked through 37 pages of the thread, but does anyone know if it's still possible to build 300+ m/s boats? I haven't tried since 0.25 or so, and my attempts in 1.0.2 are not going smoothly. I can get nice, smooth floating with no wake, but my speeds are topping out at 10-15 m/s. Here's an example of the type of craft I'm talking about.
-
Linux Camera Rotation Stutter
Jason Patterson replied to Mastermind's topic in KSP1 Technical Support (PC, unmodded installs)
I was experiencing this problem on Windows to a level that made the game all but unplayable. I spent ten times longer than necessary building vehicles because I couldn't rotate my camera properly, couldn't dock at all, and generally wound up swearing at the game a lot more than normal. I was actually typing up a support thread because Windows's default polling rate is 125 hz and I hadn't changed it, so I knew it wasn't that. I found a separate solution to the issue that was unexpected. I replaced my wireless mouse's batteries. Problem solved immediately. The batteries were at ~30%, but it did the trick. -
Like anything it gets much easier with practice. Once you've done it a dozen times it becomes trivial, but yes, that first time can be pretty beastly, even if you know your way around an orbit. Congratulations. - - - Updated - - - I'm not entirely sure what benefit Terwin is getting from it, but to set a node ahead, click out of it (like you're going to delete it) and there will be two little blue buttons at the bottom of the node. One advances a day, the other removes a day.
-
It's a single player game. Unless you're doing a challenge and the rules state that you can't use the thing, then there's nobody to say that you should or should not except for you. For me, fuel lines make the game ridiculously easy. Once you've got asparagus, you can go anywhere and do most anything. If I want a challenge, I build rockets without fuel lines or at least as few as possible.
-
It's horrible, isn't it? I'm surprised that a part swap is giving you issues though - typically if a part like a strut is replaced by another part at the same location in the save file, you'll lose the strut but it won't cause everything to go to pieces... If you'd like to post a copy of your save file I can try to have a look at it. I don't know whether I'd have any better luck than you have, honestly. Ooooh, completely different option C here: Replace the entire vessel with a duplicate. I know you're working on a Let's Play with this save, so I can only assume you want to be honest with your save as much as is possible. Go through and record fuel, RCS, and oxidizer amounts in the tanks, and the identity of the crew in the vessel, then build a brand new copy of your ship and launch it. You shouldn't have to actually fly it, but make sure it's not clamped to the ground. To make your life easier, fill only the seats in the new vessel that are occupied in your broken vessel. Save the game and go into the sfs file. Find the new vessel and copy all of it from its first PART to the last brace of the last PART. Paste this over the corresponding section of the broken vessel. Do not delete the new vessel yet. Don't mess with either vessel's flight state information or ORBIT information at all. You would then go through and edit the new vessel's crew identities to match the original (Find all of the Kerman's and change their first names, basically.) Edit any fuel tanks to the correct amounts. At this point you should be able to load the game, end the new mission normally, and your existing mission should function as intended. ETA: Or better, because I wasn't thinking clearly, build the new ship in a completely separate savegame, then it won't mess up your hiring/firing in your Let's Play. You'll still have to edit in the correct crew, of course.
-
Editing a craft in a persistence file by hand is difficult at best. The problem comes from the way that parts are organized in the sfs file. The entire ship is just a list of parts with relationships identified by their placement in that list. The first is part 0, second is 1, and so on. Each part, except for the first, has a parent object to which it is connected (the first has itself as a parent.) First - if your ship is very large and has lots of parts, you may be out of luck as far as manual editing of the sfs file goes. Someone may have come up with a program to help do it in flight, but by hand it's just not going to happen. The first challenge is identifying the problem part: You would identify it by what it is (or is not) connected to. Struts are unusual in that their parent is the object that their second connection touches. If your vessel is relatively simple (i.e. few remaining parts) you can search through it for all of the struts and look for one that is attached in the way that your problem strut is. Your strut also might have some crazy number as its parent. Any properly placed strut is going to have parent = (some number) and srfN = srfAttach, (same number as parent). If none of the struts is obviously broken, you can see which parts are correctly connected by struts, find them in the list of parts, and identify the problem strut by process of elimination. The second challenge is removing the problem part: It may be that you get lucky and can simply delete the offending strut. If it happens to be near the bottom of the list in the vessel and none of the parts after it are connected, you can just delete it and all of the parts after that will be renumbered without effect. If there are connections among those parts though, you will have to identify their part numbers (by counting, one at a time, part by part through the vessel) and rebuild the ship's connections by hand. You'll need to change parent numbers and attachment numbers for any affected parts. It's a pain for a small ship and absolutely brutal for a large ship (honestly, you'll mess up and it just won't work if there are dozens of parts involved, save your time.) A much easier solution that may or may not suit your needs is to replace the offending strut with another part. Build a vessel with the same root object as in this ship (whatever the very first part in the vessel is.) Place a small object in an out of the way spot on its surface (like a thermometer) and launch it. Copy the entire PART section of the thermometer from that vessel and paste it over the entire PART section of the problem strut. Problem solved.