damerell

If removing the mod doesn't fix this, it's probably nothing to do with this mod but some other change made at the same time, but the thing to try next is reassembling the mod set in a fresh install and reproducing the problem.

Rule 1 in the first post in the thread: The main mission and support missions must be launched from the launchpad or runway and delivered to the destination body. Part of the journey is getting the crew/ship there. (i.e. No HyperEditing or save file editing the vehicle into position.)

Most of the bodies it's practical to land on have no atmosphere anyway. You're obviously not going to land anything on Venus and, equally obviously, there's nothing to land on on the gas giants. Mars is very much the odd one out here and from Project Orion p. 185 there was a proposal to descend on Orion to within a few thousand feet of the surface of Mars (I suspect the nuclear airburst issue is less bad than one might think because our spaceship can be much more robustly constructed than normal, and the original researchers clearly thought it could be overcome) and finish the descent on chemical rockets. The only issue mentioned is the fallout (aha) from nuking the surface of Mars. I don't think you need enormously long landing legs; you just have them extend slightly past the pusher plate at the last minute (we'd better land an uncrewed probe first to find a nice hard spot) and you'd then dig a great big hole before takeoff. It's certainly tricky to time the last pulses if one is eyeballing it in KSP, but I'll bet even with 50s computing you can have the last one go off at just the right time... assuming the effective yield of bombs is very tightly controlled and the effects from a near-ground detonation are known, of course, which I admit is nontrivial. I wonder if it is practical to design the ablative plate with a series of thin slices on the base? Then perhaps we can ditch any slices that are damaged in landing to produce a pristine surface. Tiktaalik is quite right above that it is more delicate than one might naively suppose an enormous steel plate is, but it is still vastly less delicate than any other system you might be using for landing.

I've not been playing much - I dunno if the old issue with the mole tracks where the rear wheel droops was fixed. I reported it a long time ago, I'm afraid - IIRC we found the problem but it needed some of the source files for the part to fix. Landing gear certainly needs to do that, but I'm not sure that quite explains why a part weighing one tenth as much as the rover wheel _can_ do that. What's all the mass in the rover wheel do?

I'm not sure what the point of the picture you have is. Yes, a 20 man Jupiter mission is much larger than an 8 man Mars mission, but it's not needlessly oversized; it just must carry more crew, more supplies for each crewmember, and more dV (and these are multiplicative effects on the total mission size). Leaving the Orion drive in orbit is an astonishingly bad idea from the point of view of making a smaller spacecraft. The Orion drive is ideally suited for landing and takeoff because of its good power to mass ratio, and of course you've got it there already and just need some extra pulse units, whereas a bunch of conventional aerospace would just be additional mass for the rest of the journey. (Some projected Orion missions did have chemical landers, but that was either because of concerns about nuking the surface of Mars or because a small instrument package was to be landed somewhere and not returned, rather than the entire crew+supplies landing somewhere and returning.) There isn't a "chance" it would take too long to get back - transfer windows are predictable. It's just that you might have to wait a long time for an opportunity to start the mission from Earth. As Tiktaalik says, if you've got an incredible amount of dV, there are many more "windows" and so you have a much wider choice of times to launch the mission. You do have to wait 4 years on Mars for an optimal return transfer... but if you aren't bringing 4 years' supplies, you may be able to make do with a non-optimal return transfer. I doubt "most of the ideas" you have seen suggest a 4 year wait; it's just that that optimal figure is well known and does tend to get mentioned. The one-way missions are proposed not because the wait time is long or because there's a chance of having to wait a long time but because landing a spacecraft capable of returning humans from Mars (and having it work) might be too hard, full stop - much harder even than landing a lifetime of supplies.

I've used both your mod and Roverdude's mod. I think we are talking at cross purposes here. I certainly agree that the ability to dial down bombs would be useful, saving having to bring a vast armoury of carefully selected charges; all I meant was you'd still have a minimum vessel mass, because you'd plan to do all the major dV stuff using your pulse units to maximum capacity.

I certainly suspect that the actual Project Orion knew the minimum size too, but I don't know for sure (and if either of us did know different, we couldn't talk about it). I think we have both read George Dyson's book; some years ago, when it had just been written, I had the pleasure (at the Festival of Inappropriate Technology in London) of seeing George and Freeman Dyson discuss Project Orion. Your second paragraph is interesting, but surely you would design the craft to be massive enough so you'd only have to dial down a small fraction of pulse units for very specific circumstances. You'd want to use the maximum yield for most pulse units - or why not just bring a bigger craft?

There is, but that only tells us you can make one that small - what we don't know is if you can go smaller, and if so, how much. IIRC there's also an issue that efficiency is poor with small pulse units - a modest increase in size there might yield a much larger increase in, aha, yield and hence in vessel mass.

I think you should consider that they are still better than no configuration at all.

It's not at all clear that the old designs for Orion were "too big". One thing we don't in general know about Orion is exactly how small one can make a thermonuclear bomb; that is a closely guarded secret. However, this determines a minimum efficient mass for an Orion vessel; go under that and you just have to have more mass of shock absorber to avoid squashing the crew into paste, and you might as well just add more vessel instead. (A rare case in aerospace where you have no reason not to make a craft heavier). The 1950s designs were not "too big" either in that they were sized for their missions. You do need a bigger craft to go to Saturn than to Mars - and with 1950s technology, if you want to do anything more than run the most basic instrument probe when you get there, the craft has to be crewed, and since the crew are going to be on the trip for months, that means a vast mass of life support. Of course, changes in modern rocketry haven't affected the minimum size at all. Developments in nuclear weapons may have, but we aren't allowed to know about those.

I also would be delighted to see this return. It's not in any sense your fault, but what I was doing in KSP is kind of on hold absent a sensible Orion drive mod.

I'm pretty sure sturmhauke meant what they wrote; it is how the expression normally goes.

Quote (eg via pastebin) the errors verbatim. Not just for this. Every time.

Quite so. Of course RD can do as he pleases with his own mods, etc, but I think the very idea of "balancing" Orion against other propulsion is a somewhat quixotic endeavour. Someone who uses an Orion mod expects something ludicrously effective, just as (say) if I use the "Grim Reaper 2000 Lethal Extreme Difficulty" life support mod I might be disappointed if it can't kill kerbals.

I don't think there is any problem with other parts, whose aerodynamic behaviour simply follows from their shape. I think upthread you have probably inferred something incorrect from a botched mod install of your own. It's unfortunate that other users have been misled by that. As you'll see from the Airplane Plus thread, a user who has been using them together for a long time reports no problems other than the lack of support for control surfaces.

Just upthread there is a shim to tell you if a given control surface or wing is supported.

See the previous version of the challenge. It includes a map and rules for water-based circumnavigations simply omitting the unavoidable land crossing.

Real roll cages protect from impacts at a low closing speed (as any motorcyclist knows, there is a difference between hitting the ground moving sideways at high speed and running into an object directly at high speed); a hard outer shell is useful, but can't stop every internal component from suffering from deceleration in a direct impact. A KSP roll cage made of these 80 m/s impact parts is artificially too good. As I said, also, I'm not criticising you; it compensates for how KSP rovers are artificially overly prone to rolling.

I'm not faulting you (the peculiar behaviour of stock wheels means you're going to roll for no reason sometimes) but I try and avoid that kind of thing myself - it stretches plausibility to smack into the side of a mountain with no damage because the first thing to hit it was a steel plate...

No, they aren't - on an airless world, a rover leaving the ground at a given speed and angle will describe a trajectory entirely independent of its mass.

This is making the same error again. When one wonders about whether or not to produce a game, of course one plans on a price (well, a series of prices) that will pay for the costs of development, but that's not where Squad are; the money has been spent and the game has been produced. They do not now have to pick a price that will recover those costs; it is still worth selling the game even at a price that will not recover the costs if the alternative would be to recover even less of them. That is not to say I think Squad is in that position! The continued development and current price suggest to me that they think there are plenty of sales left in the game even at this price, and long may it continue. Your example of a game that costs $10 million to produce and that one expects to sell a million copies includes the same error (well, also it seems to think the demand is highly insensitive to price, but let's take that as read). During development one has to plan to make at least $10 a copy - but even then one can hope to get some copies out the door at $20, and also expect to sell some at $5 - and it is still worth planning to sell those $5 copies once no-one is buying it at $10, even though they don't amortise their share of the fixed costs. But once it's developed, it may turn out to be a flop; it's worth then selling half a million copies at $5 if that's what one can get, because having a quarter of the development costs back is better than nothing. The price a game comes out at initially will reflect the intention of making a profit over the fixed costs, but the price it sells at after a while doesn't.

While I think KSP's price is quite reasonable, this doesn't follow. The marginal cost of selling a copy of a videogame is very low - it was pretty low even before digital distribution, and now it's almost nothing. Even if it turns out a game is a flop and the expenses will never be recouped, it's worth selling copies at a price that doesn't amortise the production costs because they are already spent; it still reduces the losses. The only minimum price point they can't go lower than is the marginal cost of distribution, which is tiny. Of course, I expect Squad, like anyone, to sell all the $40 copies they can before they start selling $5 copies...

You may wish reaction wheels to be operating either for MechJeb Rover Stability Control or for manual air control in jumps (especially on worlds like Minmus); worse yet if you are using realistically capable reaction wheels hence reliant on RCS, you certainly don't want to burn up monoprop every time you touch the controls. It's not just the "Hog" - for any serious roving, you want to disconnect the rover controls from the ordinary controls.

Nearly all laptops have a way to type keypad keys via some sort of chord or extra meta key. Failing that, there are programs for temporarily remapping the keyboard or letting you type missing keys via chords for all the OSes KSP runs on. If there's no support in the mod, I would look into those.

Clearly someone who wants stock behaviour wheels over KSPWheel wheels has suffered an unplanned disassembly above the neck, but I see the problem. More seriously I'll try and provide some sensible replies to the coming questionnaire, and thanks awfully for sorting out the stock parts.