TBenz

Really? They showed several surface attachments in the the feature video.

This means we got Quadruple precision, right?

It would seem that that doesn't actually count as "proper" use of the Frisbee, as it's pretty clear the tank sizes don't support that scale of a build. The full length Frisbee should be cooling itself fine on its own, that number of radiators is definitely not required. I haven't had a chance to play with any of the more recent builds (a certain other game has swallowed all my time) but I don't remember anything else being particularly prohibitive cooling wise

Read through this and follow the troubleshooting guide. If troubleshooting doesn't work, then follow the steps for reporting an issue.

Try: @PART[fuelTankSmallFlat|fuelTankSmall|fuelTank|fuelTank_long]:BEFORE[000_ReStock] { RestockIgnore = True } MM expects an actual part name in between the square brackets. Giving it a file name (that isn't even directly related to the source parts) will just confuse it. The pipe character is interpreted as an or, so this code is telling MM to look for parts with the name "fuelTankSmallFlat" or "fuelTankSmall" or "fuelTank" or "fuelTank_long" and apply the RestockIgnore tag to them. And since those are the names of the size 1 stock tanks, the restock ignore should correctly get applied to all of them (and nothing else).

It could be added to Heat Control. Given how mediocre the stock parts are in SystemHeat already, Heat Control is all but required for FFT anyway. KSP is all about multi-part solutions. We are given a suite of modular parts that we can interconnect and combine how we want to creatively come up with solutions to the challenges of spaceflight. No other heat generator has built in radiators. And giving them to the Frisbee means that it could functionally bypass all the System Heat mechanics, which seems strange. Having a separate radiator truss part affords more flexibility to players into how they want to approach cooling not only the Frisbee, but also the other high temperature parts in FFT and beyond. I don't want to come off as being annoyingly argumentative. This is your mod and you get to design it how you want. If you don't want to separate the radiators from the engine that is totally your call. I'm just sharing my thoughts about the matter.

I would imagine this "radiator truss" part would still have a part switch that takes it out to whatever length is needed to fully cool the Frisbee. So for that use you are only looking at 2 parts, versus 1. And it could help cut down on part count on other ships with high cooling requirements. That's a 'problem' with the 6m radiator variant of the current Frisbee too.

To clarify, I meant the entire radiator and truss structure. You can make a rough approximation using the static microchannel radiators and the annular truss, but it doesn't look as good (in my opinion). Personally, I think it would be best to make the engine and the radiator truss two separate parts. It would have a couple benefits, the Frisbee would have a static max heat generation (less confusing for morons like me), the radiators would actually work like other radiators (having their own rejection values and EC use), and you could use the radiator truss for other uses. Edit: Since others are talking about the fission particles/ pellets thing, I confess to having difficultly keeping Fi P and Fi Pt straight. It would certainly help to have more clearly distinguishable names and abbreviations.

Something still seems off. At full length the Frisbee has 128 of those radiator panels, which are slightly smaller than the EF-2K and only one sided. If we ignore the size difference, we could compare them to 64 EF-2K's, which should only provide 272 MW of thermal rejection. But the Frisbee appears to actually be providing 2048 MW of thermal rejection at full length. At its current actual heat output, you would need somewhere near 1km of radiator section to sufficiently cool the Frisbee with panels comparable to the EF-2K. Which doesn't seem to be practical for KSP. As an aside, the radiators integrated into that truss are really cool (no pun intended) and it would be neat to have them as a separate part for use with other engines. Just a thought.

The Frisbee is very cool looking, but it's got heat issues. To begin with, the description in the parts menu indicates it has a 5 GW thermal output, but the system heat simulator claims the total generation for it is 2.048 GW. Interestingly, that is exactly 2^11 MW. And adding a second Frisbee will actually double the reported generation, so if there is a hard coded upper limit that is reducing the heat generation, it's per part and not vessel wide. Additionally, the built in radiators don't seem to do anything at present, which makes cooling it messy. You need 158 of the DF-8K (best of the radiators out of stock and heat control) and the DF-8K doesn't lend itself that well to bulk placement. The EF-2K's ability to place on itself could in theory be used to build out a set of massive panels that can cool the craft while looking somewhat sensible, but it has around a third of the DF-8K's cooling capability, meaning you need 3 times as many of them. 482 panels is a pretty significant part count bloat. I have yet to successfully design a vessel with sufficient cooling that doesn't kraken itself apart from the sheer part count. Edit: I did it. Had to hack gravity down to 0.01 to keep it from collapsing on the pad, and then cheated it up into orbit. When I turned on the radiators, the game turned into a slideshow (around 4 FPS). But it fires the Frisbee without overheating. It's a landmark achievement for Kerbalkind or something. Edit 2: Playing around in the editor, I can now see the total heat generation of the Frisbee dropping as I change the radiator length. I'm not sure why I failed to notice this before.

Any reason to not just give a timer based on how long it would take to discover a resource if it was there, even if it isn't actually there?

I don't believe anything in NFA itself will break, but you should make sure that any dependencies are for 1.9.1 if possible. CKAN may handle that automatically, but you could ask in the CKAN thread to double check.

There are some configurations for Restock. I don't think anything else is using this yet.

Using the Klaw is a viable solution. And you don't even need to bring the debris down with you, you can transfer crew between parts connected by the Klaw. So just send up a ship with an extra seat, attach to the debris, and transfer the crewmember over to your ship. SSPXR also has some klaw-like parts that are designed to look like crew passable tubes.

For context. Vissius had been playing with SSPXR *without this mod* and ran into the issue with the Sunrise. They posted about it in the SSPXR thread, and was directed to this mod to fix their issue. They then posted here, presumably to double-check that this is the correct mod to fix the problem, and that it would work in 1.10 with Kerbalism. As far as I am aware, it should work fine.

I believe most of the NF mod suite should work on 1.8. However, 1.10 has brought changes to the way fairings work. So the fairings in NFLV may not work properly in 1.8.

The issue @visssius is having is that numerous parts from Station Parts Expansion Redux don't have their own hatches, which this mod will fix by not letting those parts spawn for rescue missions. I don't believe Kerbalism makes any changes to the existence of hatches on stock parts, so that shouldn't interfere.

Waterfall is still a pre-release. I imagine it will make CKAN once Nertea feel it has matured enough to be called 1.0.0, it will probably be posted in Add-on Releases then as well.

What does the system heat UI say in the editor? Do you actually have sufficient radiators for your vessel according to that? What type of radiators are you using? The stock radiators have such abysmal performance that Heat Control seems almost mandatory to cool these engines without using hundreds of radiators.

If you don't mind, I am actually curious as to why.

I would assume it reports in homeworld days, so if you are playing with a stock system that should be the 0.00007611... per day. To be honest, I completely forgot Kerbin has a different day/night cycle.

The "Near Future" mod suite (specifically, Near Future Electrical) includes a series of nuclear reactors that provide high amounts of power, for the tradeoff of high mass and high heat generation. My understanding is that Kerbalism normally replaces the functionality of those reactor parts, but I haven't tried it myself and I don't know how a science only Kerbalism config would interact with those reactors.

Well, I managed to post a couple bug reports on github before I passed out in my chair. I was literally getting into bed when I saw this got released, and rushed back to my computer. Tomorrow I'll do a clean install to make sure my bugs aren't the result of my extensive modlist, and get logs if I can reproduce them in a sterile environment. Super thrilled to see this released though, will dig deeper into the testing over the weekend.

The raw ratio in the config is 0.0000000035237055479406 units a second. I had already converted by a factor of 86,400 (the number of seconds in a day) to reach 0.00030444815934206784 units a day. 0.0003 units a second results in 25.92 units a day, which is a pretty far cry from 0.0 units a day...

If I read the config correctly, the 2.5 greenhouse uses 0.0003 minerals a day. It looks like that is being rounded to "0.0 per day" on the display, but it should still very slowly consume minerals when in use. The same is probably happening with the 3.75 greenhouse.