nyrath

No. As far as I know, the only thing that changes the rate at which it consumes fuel is the specific impulse, which is vaguely analogous to "gas mileage." It is in the configuration files in the ModuleEngines section, atmosphere curve subsection. In the nuclear engine MODULE { name = ModuleEngines minThrust = 0 maxThrust = 60 atmosphereCurve { key = 0 800 key = 1 220 } } the first key says that at zero atmospheric pressure, the specific impulse is 800 seconds, and the second key says at full atmospheric pressure the specific impulse is 220 seconds. Chemical rockets tend to max out specific impulse at about 450 seconds. For various real world propulsion systems there seems to be an inverse relationship between thrust and specific impulse. Chemical engines have high thrust but low specific impulse. Ion engines are the reverse. There does not seem to be any propulsion systems with both high thrust and high specific impulse, except for outrageous extreme rockets like Orion nuclear pulse and Zubrin's infamous nuclear salt water rocket.

New Version 0.17 available for testing See first post for download The new added feature is to allow two docked Orion ships to transfer bombs between themselves. I'm sorry Mecha Pants, I'm still working on transferring between 3.5MN magazine and 3.5MN array. Warning, this new version has the potential to contain major new bugs. Be on the lookout and let me know if you find anything. The prior version is available in the first post so you can revert to it.

Now if an ancient civilization existed more like 300 million years ago, and happened to make all their cities along subduction zones, there might not be any trace left of them.

Hmmm, tricky. Currently you cannot transfer between small 3.5MN and array 3.5MN. I'll see what I can do.

The rocket science aspect makes it quite difficult to design spacecraft for your desired missions. But the explody animations make failure almost as fun as success. The explody part keeps you entertained while you persevere in doing the hard part. And when you finally do succeed, you are rewarded with an enormous sense of accomplishment. And rightly so. This all combines to make a game that is more addicting than crack.

This is a bit of a fallacy, for reasons explained here: http://www.projectrho.com/public_html/rocket/respectscience.php#id--"Maybe_A_Future_Scientific_Breakthrough_Will_Let_Me_Have_My_Way"

Obligatory Atomic Rockets link: FTL travel http://www.projectrho.com/public_html/rocket/fasterlight.php The "Canonical List of StarDrives" is entertaining

Oh, it already filters out any docked craft with no magazines. And any docked craft with with magazines, but of a type not shared by any other docked craft.

Actually, Captain Arbitrary discovered that for some odd reason the Kerbal physics engine uses 9.82 for g-naught. http://pa.reddit.com/r/KerbalSpaceProgram/comments/1hrah5/whats_the_best_mod_for_highefficiency_highthrust/caxaqo2

Don't forget the series of Rare-Kerbin Elements.

For now the primary ship has its name displayed. The others are "Docked Ship #1" etc. I'd like to show their names as well, but when they dock the vessel data structure melts into the other one. EndlessWaves said that a stub vessel data node is stored somewhere, but so far I have not managed to locate it. I did a part scan as he suggested, but none of the components seem to be it.

Thanks! I wanted to do something like that but had no idea how to go about it.

I've got the bomb transfer pretty much working, I think. But I have a slight problem. When you press one of the buttons, it starts transferring bombs from one ship to the other. As long as you hold the button the bombs are transferred. This is because they are what Unity calls "RepeatButtons". Unfortunately they go by so fast that even just tapping the button will send over 5 or so. It is almost impossible to send over just one, or send a specific amount over. I can replace these with Unity "Buttons". That way a tap will send over just 1 bomb. The trouble is if you want to send over 600 bombs, you have to tap the button 600 times. Other GUI frameworks have more sophisticated controls beside buttons to avoid this sort of thing. But Unity is more limited. I'm inclined to leave it with RepeatButtons, since generally one will be draining the entire tanker ship's load into the spacecraft. What do you all think?

Broadly speaking, the two main types of atmospheres are "oxidizing" and "reducing" http://en.wikipedia.org/wiki/Reducing_atmosphere

Thanks! I'll try that.

I have a kludgy way of parsing the part tree and identifying docked ships. It will probably break under some circumstances. What I do is do a depth first recursive parsing of the part tree. Two adjacent parts that contain the ModuleDockingNode module is the signal that the following branch of the tree is a docked ship. In the dialog window, I have one column for each identified docked ship. Only the first column has a name. This is because when you dock a ship to another ship, it sort of merges into one ship (the other ship becomes a branch of the active ship's part tree). And I do not know how to find the name of the ship that merged. There is one row for each type of Orion bomb magazine. The row is omitted if there are not at least two docked ships with that type of magazine, because you have to have the same type of magazine in both ships in order to transfer that type of bomb. Pressing and holding a button in the column of one of the docked ships transfers bombs of that type from the docked ship into the main ship. Bombs are (will be, haven't written this part yet) automatically and uniformly drawn from the various magazines of that type in the docked ship and evenly stored in the various magazines of the main ship. This is to keep the center of gravity of both ships in the proper place. What I haven't quite figured out is what happens when you press a button in the main ship column. Specifically: which docked ship receives the bombs? What I need is some kind of weird "radio buttons" for the ship names. Conventional radio buttons only allow one button to be active at a time. I'll need to program ones that only allow two buttons to be active at a time. Each button displays the type of bomb and the current total number of bombs on the docked ship.

thanks! I was already caching the UIDs for an unrelated reason, but it is good to know. I'm currently taking my existing magazine manager code and making all the dictionaries into lists of dictionaries, with each list entry representing a docked vessel. So I can try several strategies for sorting by vessel, but use the same data structures.

Well, adding the docking node is not too hard. The problem is that a fully loaded Orion can have around 60 magazines, each of which have to be loaded. For unrelated reasons, I've already written a "magazine manager" that keeps track of all the magazines currently in the same vessel part tree as the Orion engine (I needed it to evenly expend the bombs while the engine is running. Since an individual magazine can be several tens of tons, drawing from a single magazine will quickly move the vessel's center of gravity off the thrust axis). I've added a right-click pop up dialog for the engine to use as a user interface to transfer bombs from one docked ship to another. The only remaining piece of the puzzle I need is a way to tell which "ship" each magazine "belongs" to. I'm currently looking into parsing the parts tree and assuming that branches that start with pairs of ModuleDockingNode are separate ships. Thank you for your help.

Alas, generic resources are problematic. First off I'd need a different resource for every bomb type (seven at last count), and a way to create a new resource type for any new custom bomb type created by a user working with my plug in. Each bomb type has a unique specific impulse and thrust value. Secondly, bombs are discrete, not a fluid like liquid fuel. If each 5 kiloton bomb has a mass of 1.152 tonnes, you have to transfer in units of 1.152 tonnes, that is, as a whole number of bombs. You cannot transfer 0.74 bombs. Thirdly the bombs do not entirely fill the volume of the magazine (aka "fuel tank"). You cannot discover the maximum bomb capacity of a magazine by taking the magazine volume and dividing by bomb density. Resources were designed for fluids.

Stupid newbie here with yet another stupid newbie questions. Say you have two vessels that are docked. According to the old docs, the two vessels merge into one. Is there any way to tell which component parts used to belong to vessel Alfa and which component parts used to belong to vessel Bravo? I sort of had an idea that one could somehow identify the original root nodes and work it out by walking the trees. But I am unsure how to identify the original roots. What I am trying to do is deal with the fact that Orion nuclear pulse units do not work well with KSP's resource flow system. I want to allow two Orion ships to be able to dock and let one re-fuel the other. To do this I need to identify which ship each nuclear magazine part belongs to.

Such agonizingly slow progress! I've got it so when you right click on the engine, and select show nuke menu, the dialog appears. Eventually it will only show buttons for the types of magazine that both docked ship have in common. You will hold down the buttton for the type you want to transfer. The plug in will attempt to evenly distribute the transferred bombs between all available magazines, for balance. I will say that making windows in KSP is a major pain in the posterior.

As my grandfather used to say "I was pulling your leg, and it came off in my hand"

I'm waiting for KSP 0.21, to see if the improved ASAS fixes anything

Excellent Textures! And I love the "NY-R-4TH" on the rim! You even got the "UKAF" correct. Yes, one of my concerns is how the Orion breaks the game. Why use anything else? Of course the real world tells us why: despite the Orion's overwhelming advantages, the fact it uses radioactive nuclear explosives is a deal breaker. Public opinion is not currently modeled in KSP, though it could be indirectly simulated by making the Orion really really expensive. One of my motives in making this mod is to expose a generation of KSP players to the Orion's advantages. Just to get them thinking about it. The missions NASA could perform with that thing... Welcome to the world of programming Yes, tell me about it. 30 years of programming does not make Lernaean Hydra bugs any less annoying. It's actually other evil bugs concealed from view in the first bug's shadow. Much like turning over a rock in your back yard. In my case I was handicapped by not knowing C#, .NET, and the regrettably sparse state of the KSP API documentation (which is not the fault of the KSP Devs, the priority is getting the game done). Oops indeed. What's three orders of magnitude between friends? Reminds me of about 40 posts previously, when I was adding the "kicks-like-a-mule" code. The recoil shot the control module into the stratosphere at about Mach 15. As near as I can figure a Zubrin NSWR using 20% enriched uranium tetrabromide should have an atmosphereCurve key = 0 7000 a maxThrust = 12900 and mass = 33 The totally outrageous NSWR with 90% enriched UTB has atmosphereCurve key = 0 480000 maxThrust = 13000 and probably mass = 33

I've got an ugly suspicion that it's my old nemesis the Density problem. If you recall, that problem was causing the dancing bomb magazines. My solution was to magically suck all the mass out of the magazines and inject it into the engine. Which coincidentally is the ship part you have having problems getting parts to stick to. I hate it when program bugs start imitating the Hydra from the Greek myth of Hercules.