rhoark

Sorry for the update spam - I think I'm done now. 1.3 Fixed placement of LV-909 Science jr. now has 0% radio efficiency so there will still be return missions in the late game

1.2 Fixed placement of small control surface and KW 1.25m nosecone

I think you misunderstand. I want there to be strong incentive to physically return samples. The problem is, once you have solar panels you can repeatedly pick up rocks and transmit data, removing any incentive to return the samples to Kerbin. So for now, sample return will just have to be for personal satisfaction.

I wanted to reduce the transmit efficiency of surface samples to 0%, to close the loophole that physically returning anything becomes obsolete with solar panels. I can't get it to work, though, so you're on your honor.

That's not so - its the heavy end that will be forced prograde.

Here you go: http://forum.kerbalspaceprogram.com/threads/53749-VetTech-Lightweight-Tech-Tree-reordering-for-experienced-players

1.1 Added configs for KW Rocketry, KSPX, and Kerbal Engineer Probes other than Stayputnik have kOS if kOS is installed Added the decoupler that was left out from Deadly Reentry Going through the parts one by one, I decided I'm not going to do a cfg for NovaPunch after all, for two reasons: Its node assignments are generally good I only really like the engines, so it would be easier to just cut it down to the engine folder than copy down every part id of what I don't want.

What I'm trying is this: @PART[kerbalEVA] { @MODULE[ModuleScienceExperiment,surfaceSample] { xmitDataScalar = 0 } } No joy.

Or equivalent way to add resources or modules through text .cfgs rather than C#? (Not afraid of C#, but lazy)

My tech tree mod includes the Deadly Reentry parts. http://forum.kerbalspaceprogram.com/threads/53749-VetTech-Lightweight-Tech-Tree-reordering-for-experienced-players Deadly is in its own file, so not required to use my stock reconfig along with it.

Uninstalling NovaPunch shouldn't be necessary. From what I've seen, it adds its parts in reasonable locations. The extension I'm planning is for ensuring consistency and avoiding redundancy when using KSPX, NovaPunch, and KW all together. (KSPX has the best looking escape tower, NovaPunch the best looking Mainsail equivalent, KW has the best looking 1.25m fuel tanks, etc.)

The vanilla tech tree was made as a teaching aid, which is laudable, but it means it deliberately backloads essential components to avoid presenting the concepts they depend upon. This is a problem for the experienced player, who would like to apply the full repertoire of concepts to address science missions - not only after the need for science missions is almost exhausted. The primary aim of this mod is to bring forward the essential concepts and capabilities, such as wings, jets, rover wheels, and docking, while holding back refinements and quantitative improvements in these areas. There are several other mods of this type. To put this one in context of the others, it takes the real historical development path into account more than stock, but is still primarily gameplay-motivated. It keeps the stock arrangements of nodes to maintain forward compatibility. The Stayputnik is available from the start, but you'll still need crew and EVA reports to advance to science parts at a tolerable pace. Probe cores in more convenient form factors remain a fairly late development. Science parts have been reordered to put the basic pre-.22 sensors earlier, and give some science-generation opportunities in the upper (rocket/aerodynamics) half of the tech tree. Heavy and Heavier Rocketry have been rearranged to fulfill the expectation that 2m 1st stages will generally precede 2m orbital stages. A new save is ideal, but not required. Parts that have moved down the tech tree to a node you've already opened can be clicked in the R&D building to enable. Parts that have moved up to a node you don't have will prevent a new launch, but not prevent controlling a vessel that already exists. Download https://www.dropbox.com/s/4pnchiyrrn2l98a/VetTech1-4-2.zip Released under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States Changelog: 1.1 Added configs for KW Rocketry, KSPX, and Kerbal Engineer Probes other than Stayputnik have kOS if kOS is installed Added the decoupler that was left out from Deadly Reentry 1.2 Fixed placement of small control surface and KW 1.25m nosecone 1.3 Fixed placement of LV-909 Science jr. now has 0% radio efficiency so there will still be return missions in the late game 1.4 added configurations for B9, KAS, Infernal Robotics, IonCross Crew Support, and a subset of NovaPunch (liquid engines only) moved the basic ladder down to Start fixed some typos in node names 1.4.2 Fixed problem of missing mod parts

If we get a way to specify speed or storage in the part.cfg, it can be strung along the existing probe core tech progression.

Don't overcomplicate. RT is accomplishing its mission when it makes the design and deployment of a satellite network not just an exercise for show. All that needs is three things: No direct control over a craft without a comm route to a controller (preventing science transmission is an automatic side-effect of this point) Antenna range and power drain balanced so bigger is not always right Non-interference with kOS or MJ carrying out previously issued instructions Other considerations are superfluous.

It is possible IRL to have an antenna with interstellar range. That doesn't mean every kind of antenna has such a range, or that you'd want to put it on every kind of craft. There are size, weight, line-of-sight, and redundancy reasons to give a lander a short-range antenna that communicates with earth via relay. I'm not deep in the tech tree or Kerbol system yet in .22, but so far there does not seem to be any range or line-of-sight limitation to transmissions, which is disappointing.

The hard part of launching a rocket from Kerbin with FAR is not in having enough dV. It's possible to simply come to peace with that.

Anything MechJeb isn't up to the task of launching, kOS can

The way I see it, you build a rocket or a plane on the pad. You don't build an impactor on the pad. It becomes an impactor when you maneuver it into the ground.

Going to need a kerboctopus flag for sure. (From the .22 release cinematic, in case anyone missed it)

Very clear view of the Falcon 9 hypergolic igniter on the video yesterday (green flame, due to the boron content.)

I wouldn't suggest simulating all the pumps and so forth, but it gives an idea of what the limiting factors are in restarting different kinds of engines. Surveying all the options (and thinking of this in the context of Modular Fuels / Real Fuels), I think the examples can be reduced to gameplay pretty simply as a first pass: H2/LOX engines need xenon to start LiquidFuel/* engines need ignition cartridges Hypergolic fuels don't need anything Mainsail-class and larger engines should only start on the pad After some thought, a continuous xenon requirement for pressure-fed engines can be regarded as abstracted away Some further refinements to the first pass could be worthwhile though: Orbital-class H2/LOX engines could have the option of an expander cycle, which compared to the default (turbopump) would reduce engine weight and make it exempt from any minimum throttle (if that gets implemented), but give it a slight throttle lag like jet engines. Rather than 0-restart, the mainsail+ class could need hydraulic pressure for starting, provided by a new (and heavy) hydraulic pump part that you can bring with you or jettison as you choose.

Seems like impact and meteor should be maneuver devices rather than craft.

For now I'll happily play as it is. It's if I ever get going with the resource transformation parts I'd like to make when I'll try to coerce everything into kerbalized chemical names like Propellium and Blutonium.

Absolutely not, and I certainly don't want to be contentious about it. It's just a differing philosophy of what RealFuels should be I suppose. On the one hand, there's maximal realism: assign everything a real-world counterpart. My take on it is that different fuels are exciting inasmuch as they impact the vehicle design. You can't just swap your tanks from LiquidFuel to LiquidH2 - it takes an entirely different vehicle to account for the volumetric energy density. Likewise it would be very Kerbal to have fluorine/pentaborane configs with high Isp but significant chance of going up in a green fireball. On the other hand, the differences in density and Isp between RP-1/H2O2 and RP-1/N2O4 is about 1%. There would be design considerations in a real rocket, but nothing we can model in KSP. Where it doesn't change gameplay, why not be parsimonious with the number of named resources? The differences between the hydrazine blends are a middle ground - on the order of 10%. That's more reason for a division, but I'd argue still not one that changes designs in a big way. In any case though, the thorough research on spot-accurate Isp's will not have been wasted, even if attached to more generic names.

N2O4 is a viable, if rare oxidizer for RP-1. It's a hypergolic oxidizer for any of the various hydrazine blends, including MMH which is a common monopropellant. The shuttle used MMH for RCS and MMH/R2O4 in the OMS. I think they are good candidates to equate with KSP's generic monopropellant and oxidizer.