phoenix_ca

It's under settings. You can also suppress it from opening on errors. (I had to do this. It's effectively burying the problem so I can pretend it isn't there. Bad practice, usually, but I can't fix it so...yeah.)

I'm not sure, but that might be the point. At least, I like to think it is.

I sure wish there was. I've never gotten them to work. Actually I haven't seen the point. Instead of adding extra lift each time I've tried to use them they've acted more like elevators and pitched the nose down hard. O.o

@Threadsinger: I suggest reading the wiki page to get a good grasp of how thrust is calculated for thermal rockets in KSPI. https://github.com/FractalUK/KSPInterstellar/wiki/Thermal-Rocket-Nozzle-and-Thermal-Turbojet Once you've done that you should be able to tweak the values in part files with relative ease to increase thrust provided by the reactors. Although you'll also necessarily be increasing power output too when using generators, because thermal power output is what determines thrust. Honestly a better option might be to go with B9's SABRE engines or the stock RAPIERs. They're great for SSTO flight. That said it's not all bad news. Once you hit antimatter reactors, the TWR for the 1.25m reactors (Basic) is a whopping 23.62. Upgraded some weirdness happens: TWR drops to 15.49 (which is still pretty amazing), but ISP rockets up to 8379s, compared to the 1831s of the unupgraded versions. Your other, perhaps better option, would be to use the thermal rocket nozzles, not the turbojets, and use a propellant to get significantly more thrust. If you used LFO for your VTOL, you could get a thrust from your fusion rocket nozzles of 2.7 (quite respectable, and enough to be useful), with an ISP of a whopping 3226s. @Kerbonautical: MW to GW? That's easy. It's a 1GW = 1,000MW. Mega, Giga. http://en.wikipedia.org/wiki/International_System_of_Units#Prefixes

When I think of part spam, I think of having five different versions of the same part for five different sizes. As long as the parts are mostly functionally different (I get that there are KSP limitations with parent/child node attachments), then that's not evil part spam.

That sounds kinda insane. How very kerbal of you.

When career mode actually has an economy to it, that might change with an actual pay-off for bringing the whole craft home. I already prefer to do SSTO planes for crew transfers to LKO, but that's just me wanting to use a plane for no reason at all. Though it can help with Kessler Syndrome, I suppose.

There is already a mod that makes VTOLs more stable: http://forum.kerbalspaceprogram.com/threads/67270-Throttle-Controlled-Avionics-1-3-0-23-5-%28April-6%29

Would you quit derailing this thread already? This is all pointless quibbling over things that don't even remotely matter. You want a reason why an "impulse" drive is a bad idea? Fine. It's functionally identical to the already implemented Alcubierre drive, combined with every other engine in the game. You want high thrust and the ability to steer? Okay. Put lots of plasma thrusters on and use xenon as a propellant. Done.

Okay, fair enough. I'm still proud of my hamster line though.

What does that mean? No more fairings getting pushed-out only by the base nodes and the tips staying in the way of a craft?

Not to go all Canadian on you but...that's just wrong. CANDU reactors aren't dangerous, in fact they're much, much safer than a light-water reactor. That very same section on tritium emissions you cited goes into detail about how low the regular emissions from such power plants are, and how standards for tritium amounts in water are substantially more restrictive in Canada compared to international standards. On top of that, you have the operational safety (which I stress again is laid-out in detail in the very link you posted in the sections above it). Calling a CANDU reactor dangerous is just...absurd in the extreme. Properly managed, there's far less risk of things going wrong compared to LWRs or pressurised reactors. It's like saying a hamster is a dangerous pet that could maul you to death. As for KSPI, there's the slight issue of a CANDU being put into space also being pretty absurd.

I think you're seeing things. Had I exported the background layer, it wouldn't be "slight". Edit: You're definitely seeing things. I've checked the imgur uploads, the zipped images, and the master images. All of them look perfectly fine. And it's a PNG. It doesn't have an alpha channel. O.o Well okay it does, but I don't even touch that. Photoshop even hides it as a general rule.

Those parts are slated to replace the current ones anyway, right?

Well, glad to see it's seeing more adoption. I know Biotronic is working on extending it too, so it can resize other things, like engines (YES FECKKING ENGINES).

Did I read that part of his post right? TweakScale? As in, far less part spam?

My thoughts exactly.

Made some more icons: https://db.tt/ThLBe8Qc Also uploaded them to an imgur album for viewing: http://imgur.com/a/DjO2R#0 The previews look like crap but the full versions look fine.

So, Kethane support on a lark. Wows. Now all we need is ORS support and ScanSat will be able to scan all the things.

But the problem I see there is that a single part can have multiple FNModuleResourceExtraction modules (I had the very same idea Starwasher but threw it out for the following reasons). For example, here's an excerpt from KSPI's large refinery: MODULE { name = FNModuleResourceExtraction powerConsumptionLand = 40 powerConsumptionOcean = 0.001 extractionRateLandPerTon = 0.0081300813 extractionRateOceanPerTon = 1 resourceName = LqdWater unitName = Water Extractor extractActionName = Extract Water stopActionName = Stop Water Extraction resourceManaged = True resourceToUse = Megajoules } MODULE { name = FNModuleResourceExtraction powerConsumptionLand = 30 powerConsumptionOcean = 0.1 extractionRateLandPerTon = 0.012657 extractionRateOceanPerTon = 0.01 resourceName = Ammonia unitName = Ammonia Extractor extractActionName = Extract Ammonia stopActionName = Stop Ammonia Extraction resourceManaged = True resourceToUse = Megajoules } MODULE { name = FNModuleResourceExtraction powerConsumptionLand = 40 powerConsumptionOcean = 40 extractionRateLandPerTon = 0.0008826 extractionRateOceanPerTon = 0.0008826 resourceName = Lithium unitName = Lithium Extractor extractActionName = Extract Lithium stopActionName = Stop Lithium Extraction resourceManaged = True resourceToUse = Megajoules } And it goes on from there. From what I understand, your example would find any part that has an FNModuleResourceExtraction module that also has Lithium, and then edit that part. But the edit applied with @MODULE in your example doesn't specify which of the various modules of the same name should be changed, so I assume from the examples and prior experience that it will change the first module node it finds with the name FNModuleResourceExtraction. In that case it would change the LqdWater node in the above example, and not the target Lithium one. (Or worst case MM misbehaves and applies the edit to every module.) I guess the best bet would be to try this instead, assuming it'll even work: @PART[*]:HAS[@MODULE[FNModuleResourceExtraction]] { @MODULE[FNModuleResourceExtractor:HAS[#resourceName[Lithium]] { @extractionRateLandPerTon = 0.0008826 @extractionRateOceanPerTon = 0.0008826 } } Hopefully that'd just fail instead of adding Lithium extractor module to everything. But the @ documentation is also a bit nebulous on that. If it even said just a few words like "If the node doesn't exist it won't be added" then I wouldn't be so confused. But since it doesn't, I don't make any assumptions about how @ works beyond that it will edit a node if it exists. No clue what happens if it doesn't exist.

Then you didn't look at the wiki. It was recently added there. https://github.com/FractalUK/KSPInterstellar/wiki/Alcubierre-Drive

Yeah. The problem is that the parser can't handle tabs. Spaces yes, tabs no. I just needed to turn-on soft tabs in Notepad++ so that I could make a file that's readable, as well as functional. It's a common problem in programming. I just had to remind myself that parsers suck and will break often and for illusive reasons.

Unfortunately that has a few problems. One, it'll insert resourceName, name, and the extractionRate fields in the PART array, not the MODULE array that you're trying to target. The worst part about that is that you'll end-up renaming every part that has a MODULE array with name = FNModuleResourceExtraction to "Lithium". That'll do bad things. After fiddling with it for a while though, I'm not sure if there's a way to tell MM to do exactly what you want to do in a robust manner. You may need to define each change for every part, abandoning wildcard searches and instead using the NODENAME, <index> {} format to adjust specific nodes. Unless there's a way to tell MM to only adjust a module node based on a field in it other than the name. Something like maybe: @PART[FOO]:HAS[@MODULE[FNModuleResourceExtraction]] { @MODULE[FNModuleResourceExtractionresourceName[Lithium]] { } } But I'm guessing. The # character is poorly documented on the first page and the only example use is in the @PART line, so it might not work at all. There's also no indication that :HAS will work anywhere other than in the starting @PART line so I threw that idea out too. Worst case scenario, you need to use indexes, but that comes with the annoying issue that if the config it's changing gets changed (say when a mod updates) with new nodes, it could break your patch, partially or fully. You'd have to be very aware of which configs/mods are changed and go over your patch carefully every time.

Indeed. But at least you have lots of documentation.

Kinda sorta. Even that takes a very, very, very long time, with a loooooooot of tritium. Given the 12.3 year half-life of Tritium (H-3 for reference) to He-3 (4,489.5 days), that'd give you ~0.111 units of He-3 per day for every 1,000 units of Tritium available. Well...by definition what you provided was quantitative and qualitative information. Purely quantitative info would be from say, you checking the persistence file. >.> As for the AIM...hrmmm. Those are actually good points. It still leaves pure He-3 tokamaks in a rather silly position of being practically useless. That means it's a pitfall that pretty much any newbie will fall into, because most of the info would point to the conclusion of "He-3 = more charged particles = better energy production". But that logic breaks-down in an unexpected way. It might be better to just remove the pure He-3 fuel mode from them entirely and leave it for the AIM.