Vim Razz

Stage recovery takes extra time that I'd generally prefer spending on the fun parts of the mission, so cheap & disposable it is.

The links got broken as a result of a major forum update back in late 2016 or early 2017 or thereabouts. The OP stopped updating the index back in 2014. It's still a nice thread to browse through for inspiration at times, though.

I spent a few weeks derping about with Panthers to see what I could do with them. These are some highlights from that:

The most annoying thing is when orbital lines of nearby ships fade out when you zoom in on map view, making early game rescue missions (from, say, misaligned Minmus returns before 1st radar upgrade) really obnoxious. Making final course corrections requires zooming out and back in again constantly in order see how close your trajectories are aligned. Also, I sometimes want to throttle whoever switched the positions of the LV-T30 and the LV-T45 on the tech tree (version 1.1 or 1.2, if I remember right). It makes starting up 10% science games far more tedious because the LV-T45 can't manage Munar flybys, and it seems impossible to get a part test contract for the LV-T30.

This bug is still around? There's an old solution here, but I can't vouch for it being up to date:

All of them, depending on what kind of mood I happen to be in lately.

oh..... I just replied to a 3 year necro.... >.<

I don't know that that's the case. The i7 machine I use at work crunches drawings a lot faster than my gaming/toy i5 rig at home. The time saved over the course of a year more than pays for the extra cost of the chip, and you don't need to understand anything about how or why it works to benefit from it in that regard. At home, though, it would be a lot of money to spend on a very marginal improvement for the stuff I use this computer for.

Well put. It's worth noting here that you're using a more technical (and more precise) definition of the term "rescheduling" then I did. I can certainly see how the vagueries of vernacular usage could ruffle the feathers of those familiar with the jargon, and probably should have chosen a better term, but I didn't think of it at the time. So thank you for that clarification. So, how to best communicate the consequences of that to people who's entire understanding of hyperthreading may be that the salesguy told them "it makes 4 cores behave like 8 cores" -- a statement that may-or-may-not be true depending on the nature of the load? I suppose I'm still at a loss of that front. Game threads generally need to stay synchronized with each other and with the user. If you're waiting for one to stall out before running another, then your entire game is stalled and you've not gained much by having the additional thread.

It's but no means a complete description, but if you can describe the core function more effectively in a few brief statements then that would be great. I'm not exactly sure what you're taking an objection to, though, tbh. Rescheduling tasks on the processors to maximize load efficiency is quite literally what hyperthreading is intended to do.

Oh, well troll'd, @regex. It got me as well. Given the amount of general confusion regarding hyperthreading and games, though, it may be worth taking a moment to note what hyperthreading is: It reschedules processing threads to get more of them done within a fixed amount of time. This is awesome for bulk data processing, because you don't really care when each individual thread runs or finishes. You just want the end result when all of them are done. It's less useful for games, because game threads generally need to stay synchronized with each other so that they can be interacted with in real time. Rescheduling them changes the timing and breaks that. You can get a small benefit to games from system background tasks being rescheduled, though.

tbh... It doesn't make a huge difference. At a certain point, "getting payload X to location Y' becomes more of a chore than a challenge. The fun thing about this thread is that the truck itself is such an amazing build, not the technical elements of moving it from one place to another.

This isn't a vanilla contract condition (stock contracts are not tied to individual ships), so you might have the best luck asking in thread of the relevant mod.

A little trick I picked up from someone on the forums here (I've forgotten who) for figuring out when to travel from one planet to another (without using external tools or resources) is to pitch a small probe just outside of Kerbin's SOI so it orbits the sun in an orbit very similar to Kerbin's. Then you can use that probe's orbit to plan out maneuver nodes, and compare how much it's going to cost to travel from various departure times in Kerbin's orbit.

In this case, they're the old version of the Structural Fuselage. If you like the look of the old fuselage model better than the current model, then I think there are mods that can add those part again. Both the old and new models are passable in stock or with Connected Living Spaces installed, though at the time that particular base was built their use was purely decorative. (It uses Temestar's old modular base building kit from a few years ago.)

That would be awesome. The current version would work on Laythe, but I think I have other places that are in need of this as well. Actually, I know I have other places that are in need of this. For reasons. That explains how quickly the power drained whenever I wasn't burning. Good to know.

It isn't always about difficulty. Some things just need to be put into space. It's a moral imperative. Clearly, great minds think alike, because I had also determined that the Mun is in desperate need of large dump truck. Notes: Apparently, it has a probe core in there. I hadn't bothered including solar panels or anything, so I ended up having to burn in often-random directions every time I needed to charge the batteries to maneuver. That was a big annoying. Confirmed: Air-breathing Wheesly jet engines are not an optimal mode of propulsion on the Mun. We've done science! The bed seems have challenges in low gravity environments. The plow seems to work fine on the Mun, though. Verdict: Good times had by all.

The additional biomes on Duna, Ike, and other bodies outside Kerbin's SOI didn't exist yet when this spreadsheet was created. At the time, each planet just had one biome covering the entire surface. You will get a full set of science for each current biome on the surface, though, similar to exploring the Mun or Minmus.

What @RoverDude said. They can be run together if you're not running anything else with them that wants you to pick either one or the other. (MKS/OKS, and some of the configurable container mods, I think. I forget which ones have trouble.) I'd recommend setting up a separate game install, though. That makes it easier to experiment without permanently screwing everything up if you don't like the results. Also, ships or stations built around TAC-LS don't translate to USI-LS well, so it would be hard to switch mid-game. USI supplies and containers so heavy and bulky that you have to design around from the start them rather than trying to tack them onto existing hardware. If you play with habitation space requirements enabled, then that brings even more creative constraints into play that just aren't an issue with TAC-LS.

Wow, that must be a rather large orbit around Kerbin if it's period is months long. You will need enough fuel in the rescue vehicle to "match orbits" in the end, or at least come close enough for your stranded kerbal to EVA over from one ship to the other, and enough to get back to Kerbin again afterwards. So if you're not certain that you have enough dV in your rescue craft, then that might be something to verify before getting another vehicle stranded in the rescue attempt. How circular is the target vehicles orbit?. I've assumed based on the "Minmus return" comment that it was pretty oblong with one end much closer to Kerbin than the other, but if that's not correct (that is, if it's more circular), then the periapse might not be the easiest place to catch it, timing wise.

Put your rescue vehicle an orbit that touches your stranded vehicle's periapse. Then set up a maneuver node where your orbits meet and see if you can get a reasonable encounter. If you can't, wait for an orbit and see if you can set up a maneuver then, or if you need to wait another orbit and try again. If the encounter indicators don't seem to move as you play with the maneuver node, you might need to pass them first before experimenting with the node for the next possible encounter.

For all the grief that the Thud gets, I very rarely see rocket designs where a 5-15 ISP difference and a small amount of drag would make any critical (or even noticeable) difference in their effectiveness.

Lots of good stuff in this thread. If you plan to spend a lot of time rovering, it might be worth mapping a set of drive controls to something other than WASD. I've got them on the arrow keys (with camera controls re-mapped to the number pad) with "roll" double-bound to left and right so that rovers with reaction wheels lean into the turn. Also, you can use trim control on drive keys (ex: hold alt+forward to set in forward acceleration, alt-x to clear). Using trim this way works the same as rotational trim (the longer you hold, the stronger the setting), but there are no UI indicators to tell you what your current drive trim settings are.

Calling these brief installments "chapters", as I've been doing, feels odd. They're too short. I considered renaming them to "sections", but that didn't sit well with me, either. So I'll be calling them "parts" for now, and we'll see how that feels. With this part done, I'm caught up to where I'm at in-game. In theory, I'll be a bit more organized and it will take me less time to find the correct screenshots and stuff from here on out, but I don't expect that to last very long. Part 3 -- Parking Some Smaller Pieces. I'm not really concerned about keeping this project under budget. I expect cost over-runs to be amortized by reduced mission expenses and marketable research opportunities in Duna's sphere of influence. However, Mort ~has~ made a point of alerting me to the fact that I've already spent about 1.4 of the 1.8 million funds that we can expect to gross on the installation contract (including the advance), and that a lot more spending is still on the horizon. It certainly doesn't hurt to save a few funds where possible. The next few modules are small and self-contained, so packaging them for launch by spaceplane seems like a good way to cut a bit off my launch vehicle expenses. I'll be parking them at a station in LKO for now, then haul them to Duna by tug and ferry them to the surface with a lander. Lab Module The lab module is a composite of other modules I've installed on the Mun and Minmus, so it takes no time to complete at all. The packaging does require me to be a bit more creative. There isn't enough room in a mark 3 cargo bay to put it on motorized wheels, so I'm putting it on retractable landing gear instead. A lot of RCS will be used to push it around, and in a pinch it can be used as a little tug for pushing other things around. Two reaction wheels may seem excessive, but the extra torque can be helpful for maneuvering this sort of package into position to dock on the surface. Radiator Block If I understand things correctly, three medium radiators should be enough for four drills and one ISRU. This module also contains a few more fuel cells, because it's a convenient place to put them and they look nice. There should be enough cells to keep things running when I crash into if some unfathomable calamity should happen to befall my solar panels. ISRU I expect the ISRU unit to be a pain in the neck to install because of the way the docking ports are situated, but it looks nice this way. Solar Array Although I'm including a lot of fuel cells in this build, I plan on running solar most of the time. Getting the module to "loop" back on itself is a bit of a trick. The main construction branch follows the girder assembly, while two of the structural tubes are not directly connected in the SPH at all -- they contain docking ports positioned directly against each other. If placed properly, then the docking ports will lock onto each other as soon as the craft loads into the world for the first time. While a strut could be used instead, having that sort of massive breach in the tubes doesn't feel right to me. Flight Preparation I will not be using my own spaceplane designs for these flights, as I am not feeling particularly masochistic at the moment. Instead, I'll be flying the Z-1 Double-D Mk.2 and the H-7 Shark Mk.2 designed by @Val, who knows far more about spaceplanes than I ever will. The Z-1 Double-D is built as a Single-Stage-To-Mun craft and comes packaged with a very nice little lander, but I wont be using it for that. The amount of fuel it carries allows for some pretty aggressive maneuvering in LKO, and it's very easy to extend the cargo bay and adjust the wings for long-ish payloads (which most of mine are). It can be quite challenging to find a decent SSTO for long payloads that isn't built for much heavier lifting than I need. The H-7 Shark handles long, lightweight payloads very well, and the Mk 2 version has a lot of passenger capacity. It's not as nimble as an extended Z-1, but it looks cool as all hell and I have some crew and tourists to shuffle between KSC and LKO right now so that's a great excuse to take it out for a spin. Delivery The flight record is slightly spotty. I'd fire my cameraman, but he's my mother's sister's niece's brother so I may be stuck with him for a while for family reasons. Nonetheless, all four base modules are delivered to Hebron Station in lower Kerbin orbit for storage until I can arrange a tug for them. There's a significant gap in time between the first, second, and third flights as kerbals are shuttled between work assignments or tourism hotspots around the Mun and Minmus. There are still a few odd bits of tubing that I need to arrange transportation for, but I think I'll wind up tacking them onto the side of something else. We'll start looking at rovers in the next installment. It may take a while. I need to make some decisions, and my decision-making process is not always fast. After that, I'd like to design some new landers and utility craft, and then we'll be on our way to discover what horrible mistakes I've made in my preparations.

Okay, that is pretty cute.