Claw

Update 1.1.3b.1: Added DockingPortFix, which adds a "Force Undock" option to stuck docking ports. Note: The editor symmetry highlight is not included in v1.1.3b.1.

Help us clean up the Bug Tracker (Reposted Dev article. Please click here if you'd like to post a message.) After the recent pre-release, 1.1 release and follow on patches we’ve finally had some time to look back at the overall bug tracker state and look for some areas for improvement. There are currently about a dozen tracker projects which cover the various test teams, platforms and backlogs, and while investigating the tickets that are currently open we found ourselves wondering if we should make some bigger changes at this point in time: Across all the trackers there are approx. 2700 open “bugs”; On top of these are 800 feedback and feature items; These tickets go back to the start of the tracker (back in 2012) and as a result a lot of them were most likely fixed, but not closed out in the trackers; Doin’ the Maths Now obviously we could start at #1 (“Docking nodes get misplaced on loading certain docked vessels”- it’s already closed, I checked) and work our way through one at a time until we have checked for duplicates, retested or confirmed and followed each one through, but simple mathematics tells us this might be a problem. If we assume it takes 20ish mins to work each of these that’s 112 eight hour days of test time, and that’s if every bug report is perfect and the steps followed don’t need any communication with the reporter to ask questions, clarify, etc. That would be split across multiple people in reality, but it doesn’t include triage of any new bugs, or involvement in development and testing that’s underway currently or needed in the future. The Painful Truth Hopefully many of you reading this come to the same conclusion we did: With the amount of resources we have available within the team, it’s simply not the best use of time to go through all these bugs in this way -- but we do know that there are some very good reports in there that still need to be fleshed out and worked on. So How Do We Tackle This? The idea we are working towards is to tackle this in a couple of stages: We are going to mark all open the bug reports prior to a yet to be determined date as requiring clarification; When this is done we need you guys and girls to eyeball these tickets for clarification and let us know if they are still a bug and still important; After a few weeks any bugs that have not been touched will be archived away – still there but removing a lot of noise for the producers and developers to see what is key; By making these changes we hope to get down to the more important issues that are outstanding and get them front and center in planning and resource allocation. We’ll also be similarly tweaking a number of test and internal projects to help sharpen our focus internally as well. What’s Next and What Can You Do? We do know that this may not be a universally appreciated idea, but we do feel it’s a lot better than some of the alternatives and does give us the chance to improve as well (it’s probably better than TriggerAu’s original “Slash and Burn Festival” idea too). Before we kick this off we will provide more details about what sort of info and updates will best help us to get to grips on each bug, so please keep your [electronic] ears open. The involvement you all have with the tracker is massive, there are very few communities as involved or interested in the state and improvement of the games they play as this one and we do truly appreciate it. I think that together we can really clean out the ancient dust bunnies from the tracker and help clarify the key issues.

How about this for a start? This one might be a bit busy, with the wings essentially covered. I think I will try your idea by expanding the sides a bit and putting the moons around the edges, but maybe leave the planets on the inner part. Also, having the wheel large with the prop on top looked odd. Edit: Okay, second pass with the moons on the outer edge and flipping the wheel/prop size.

Actually, that also raises a difficult question. What to do about a badge? It would feel kinda strange designing my own. I mean, I can make it, but feels weird doing the main design (too much like tooting my own horn). You guys have any ideas for some sort of master badge?

Thanks! ...and indeed I am. Only Eve left, and I'm actually a bit over 3/4 done with it. The mission reports have been lagging (much like they did with Jool).

*dusts off hands* -- Well, my job is done here. \o/

Excellent, someone payed attention.

Update 1.1.3a.1: Deprecated several modules (that have been incorporated into stock) Added a small fix for non-responsive kerbal EVA lights Added fix for fairings that was causing kerbals to get stuck on EVA and docking ports to break (becoming perma-stuck). If you already have version 1.0.2a.X, you should be able to carry over your settings from the previous install. Note: The editor symmetry highlight is not included in v1.1.3a.1. I will work on that and also a utility to help recover broken docking ports.

Even at 4x time warp, it's just...slow. Like those dreams where you are running in mud.

That's a really awesome looking boat. Have any zoomed out pictures of it at speed? I'm guessing it glides on top of the foils. Sort of looks a bit like an A-10 meets catamaran to me.

Stop, now. There are perfectly reasonable points being made by either side. You guys don't need to interlace your valid points with personal attacks, and I don't want to see more threads locked due to third parties having a row at each other. It's perfectly fine to have opinions on something: "X is bad because it causes Y, which I don't like." But if you guys can't stop attacking each other, then this thread is going to get cleaned out.

Well, I didn't mean for this thread to get hijacked by the Oberth Monster, but I suppose that's my fault. My comment about the 100km discontinuity was based on testing I did back in November. I went back and tested again, and either: 1) My original test was incorrect; or 2) Changes to the orbit code in 1.0 has fixed the issue. So I will concede (and retract my earlier statement) that Oberth is not effected by any discontinuities across the 100km boundary. However, there are other effects that still happen below 100km to watch out for (such as apparent maneuver node drift, and occasional issues with "cannot warp while under acceleration"). What's really awesome is that you guys actually did some testing, and didn't just jump back to "no, you're wrong [insert bad name here]." That's the thing I really like about the players/community/game here. I will say that in testing Oberth, one has to be careful about comparing answers. It's not as simple as "the AP was higher here than here so it must be better." Orbital mechanics do not occur as isolated pieces, and Oberth effects total orbital energy. Starting out in a 150x150km orbit already has higher Orbital Energy than starting out in a 70x70km orbit. And testing in a 70x150km orbit will also yield different results than either of the first two. Leaving Kerbin's SOI with a craft from a 70x70km orbit will have less Vexcess than a craft leaving from 150x150km (assuming same fuel load). This trend reverses itself between 1Mkm and 2Mkm. Also, someone asked earlier if there's much of a difference putting a station up at Munar altitude (I never said Munar orbit) and diving down to LKO, vs. just leaving straight from Munar altitude. The difference there is huge, if you're trying to maximize Oberth...Around 40% increase in excess velocity, depending on PE dive altitude. But, back to the original question: It really, really, depends on what you're going to use it for. If you're asking for the straight up lowest stable orbit, then the original answers still apply, no less than 70km. There's still a 100km discontinuity that caused instability in low orbits, but I think (for the most part) that has been fixed in 1.1.3. Though it looks like you've already had your question answered.

This is mostly it. I am squad staff, and pretty much all of the bug fixes are making their way into stock. However, a quick read through the release notes and you'll see that the primary development process is currently focused on 1.2. So for some of these bugs, I try to put out fixes for folk for primarily two reasons. It lets people enjoy the game more, to eliminate some of the more destructive bugs while the main team focuses on the next release. For some of the elusive bugs, it helps to confirm that the fix is aimed at fixing the right thing. There are also some other, more minor bugs that get added into StockBugFixes (usually because they're pretty easy to fix and add to the quality of play). I started out as just a regular forum user and KSP player, and during that time I spent a lot of time digging around and trying to find some of the more troublesome bugs (like the claw causing the universe to come apart). Then I learned how to mod KSP to help improve gameplay for other people as well. Maintaining an addon actually eats up quite a bit of time, but believe it or not, I really enjoy trying to make the game a bit more enjoyable (or less frustrating) for others. The reality of the matter is there is neither infinite time nor infinite money available to ensure the game is completely bug free. The typical QA process usually reveals several hundred bugs. So there are a lot of things that get caught during QA and Experimentals, but this game is so open ended in terms of user-defined experience that it's pretty much impossible to catch every combination of events. Also, some bugs end up being incredibly obvious (like missing body lift). Those sometimes slip through because they're not very apparent during the usual testing process, but become glaringly apparent when users start to really stress the game in unique ways. Or because they have a favorite craft that they've been using for months, and suddenly it behaves differently. When you have a small test team dedicated to checking every corner of the game, it's hard to spend hours and hours on playing with one single craft. On top of that, because of the small team and development cycle, the QA and dev process is iterative. So at times a late bug fix pass might introduce some unintended side effect, and again, the immensity of the game means it might go unnoticed in the short time available to test. It seems like it should be easy to say "just focus testing on those areas that recently changed." Well, we do, but as an example of how code can be a finicky beast, we had a bug not too long ago: When a fairing was the root part, the map mode no longer worked right and the craft's icon would disappear. Fairing->Map, two completely unrelated systems and one broke the other. There's another, similarly (seemingly unrelated) issue going on right now where decouplers and fairings, under certain conditions, can cause docking ports to break (won't undock) and leaves kerbals unable to return to a cabin after EVA. Which reminds me, I promised to put out a fix for that!

I've posted my Gilly mission report, including a bit about the design and launch. Here's the Elcano album! Gilly wasn't all that fun, but I think that was mostly my own fault for not designing the rover a bit better. I thought it would stay attached to the surface a bit better than it did, so didn't bother to attach a "down force" system to keep the rover firmly grounded. This limited the drive to about 1.5 m/s... Sloooowwww....

Oh...My...Gilly! I will fully admit, I looked upon Gilly as a mere speed bump on my way to Eve. Given it’s roughly 13km radius, I expected it to take virtually no time to get around. However, I’ve also not land on Gilly, so turns out I was in for quite a surprise. The Gilly encounter was relatively uneventful, except that it was in slow motion. This should have been the crew’s first clue, but they forged ahead. The landing was pretty easy, but when Julella stepped out for EVA, things began to go awry. At some point during the rover release sequence, Obemy made contact with one of the wheels and nearly went into orbit. Fortunately (after striking the ground again) he regained his senses and was able to jetpack back to the rover, which was sliding downhill... The darn drive...The short story is that I knew Gilly had a low gravity, but I failed to realize just how important a “down-thrust” system really is here. The drive had to be completed at a slow pace (on the order of 1.5m/s) to keep the rover on the ground. The direction of travel ended up being a polar route, and was pretty much dictated by the direction of slide after I released the rover from the Tin Poppy. After nearly an hour of game time, the crew was only about 5km from the landing site. Ultimately, the drive on Gilly took nearly as long as the Moho drive. The terrain is okay and there are some neat shots of Eve and the Sun. But what should have been a quick trip was an agonizing test of patience. It was like watching a car chase scene in slow motion. If you want to do Gilly, I recommend taking some cleats with you. I normally add a map with the route on it, but quite frankly I couldn't tell on the map where I had landed. The map surface is rather nondescript.

No Time for a Breather So...with the prospect of being so close (yet so far away), and fresh off of the successful Moho expedition, the Mission Director ordered the immediate assembly of an Eve system mission. The engineers used the same basic booster system from the Eeloo trip, but heavily modified the payload. This post will be mostly about the testing and runup to an Eve system trip, and I’ll put the actual Elcano mission report in the next post. The engineers went for a practical “get there” mentality, striping the ship down to its bear necessities. To start with, two rovers are required (one for Gilly, and one for Eve). The rovers were slightly modified to lower the suspension a bit more (to account for the extra gravity on Eve), but for the most part, the rovers were pretty much unmodified from the Moho variant. The engineers decided that the Geep has proven itself time and time again, so it’s obviously a fully robust design...Right!? (Hint: This will turn out to be a poor decision later in the mission.) To deliver the rovers, the engineers had been using an inline rocket delivery system. After looking at intra-Eve transfer requirements for Gilly, they went with a semi-brute force method to get to Gilly and back (rather than trying to optimize the Eve arrival). So the engineers stripped off the Eeloo/Moho rover landing system and, instead, elected to recycle the Tin Poppy (Jool tug ship) as the rover delivery system for Gilly. The Tin Poppy was unmodified from its original design, and included more than enough dV and TWR to deliver the crew and Geep to Gilly, then return to Eve orbit. The plan was to also use the Tin Poppy to drop the Eve rover into the atmosphere in much the same way as it was used to deliver the Laythe boat. Additionally, the Tin Poppy doubled as the crew compartment for the interplanetary journey, eliminating the need for an additional capsule/crew compartment. This configuration, however, didn’t leave space for Marissa. The Mission Director approved this decision and came up with an alternative plan for her. The Eve rover was a bit of a new challenge for the engineers. For the most part, rovers (and the Laythe boat) were all delivered without the need for a thermal protection system. The engineers weren’t sure about the rover and all its components surviving an Eve reentry, so they set about devising a protection system. Ultimately, they encapsulated the rover inside an aeroshell, and mounted a heat shield to the bottom. (The crew manages to mount the rover seats through FM.) With all the major mission elements designed, the entire system was assembled. The Eve rover was mounted to the top most section of the rocket, followed underneath by the Gilly mission payload. The Gilly rover and Tin Poppy were mounted to a set of decouplers on an offset midbeam support. The remainder of the rocket is essentially the Eeloo system with an extra pair of SRBs to increase TWR at liftoff. With that, the crew departs blissfully for the final destinations...Gilly and Eve!

In addition to what sal said, try launching without the fairing built and see if it still crashes. I've found an issue with the fairings that seems to be causing some seemingly unrelated problems, so I'm curious if this is the same. I will give yor craft a try in a bit to see if I can replicate it here. Thanks for uploading it. Cheers, -Claw

Well, I'v been thinking about this and I'm not sure I have a hugely satisfying answer. One part is that it was an original rule, and I've kept the rules consistent. But also, with the near limitless planets (and other mods) available, I've tried not to create too many caveats for the rules. And with so many other options, creating badges and categories might become unmanagable. So a bit of a copout, but tracking all that might be quite a burden. Looking forward to seeing it. I see your other post. Hopefully we can help you sort the save issues. Good luck! Cheers, -Claw

Logs would be good, both from the successful resume and the next where it fails. Or perhaps upload the save so we can try to replicate. Good luck on Elcano

Nope, it's not. That's because there are some discrete breaks in KSP's physics, and one of them happens to be at 100km around Kerbin. You actually get a little bit better Oberth response if you have your lowest point just above 100km rather than 70km. I'm not sure where that reverses itself (i.e. is that still the case at 50km). This is also a valid approach, though it wasn't what I was referring to in my post. If the station is primarily for refueling options, then in my opinion it's actually better to put the station up higher for refueling (no higher than the Mun's orbit). After refueling, do a Kerbin dive (drop the PE down to just above 100km) as you eject out of the solar system, taking the relevant ejection parameters into account. This is sort of like doing a split burn (which better harnesses Oberth) except that the fuel tanks are more full since the AP was raised for the station rendezvous (prior to refueling).

Those pictures are specifically for the lighting of the editor scenery itself, which is why there are no parts in the scene. If you take a look at the editor lighting now, probably most notably the ground, it might be easier to spot the differences.

I'll echo that 70km is the absolute minimum, if you ever plan on visiting it. I would highly recommend against putting it below 100km around Kerbin. At 100km, there is a shift in the reference frame that KSP uses, which can cause a variety minor issues. The biggest disadvantage is that Oberth effect is actually reduced below 100km due to physics and reference frames. So if you're using the station as any sort of refueling post, then put it above 100km. Personally I aim for 150km to 250km (usually up higher for time warp). At those altitudes, you get better time warp and I find the rendezvous for craft taking off out of Kerbin to be easier to manage (less compressed to a narrow altitude band, faster to catch the station, and higher time warps available). Cheers, ~Claw

I don't think there is an official comment anywhere else except maybe in the recent dev notes. We're aware of some of the lighting issues in the VAB/SPH and have been working to improve them. For example:

That's exactly how the zip file is set up. There's a single folder at the top of the zip file called StockBugFixPlus (just just downloaded to confirm). Grab that folder and drop it in your GameData directory.

Yeah, my first transfer I actually left a little late, and it took a lot to correct. The second transfer was much better timed and I hit it at its descending node. The whole drive took a little over four game days, so yeah, the sun didn't have much time to move. I think I meant "perpetual twilight" in that I was running on the terminator, so the sun never set (rather than tidally locked). The polar route was really driven by the desire to drive by the Mohole, plus I wanted to visit a few more of the craters. I thought a terminator drive would be interesting, since it doesn't move very fast. Thanks! This was one of the planets where the polar terrain isn't a mess, although there was still some weird physics when stopping there.