Nertea

I'm currently on vacation, so I can't do much... But just so you all know, most of the costs in that sheet are not done or good.

^ What he said. We've made quite a few concessions for KSPI, and created conventions as a result. It seems strange to throw that away.

For me, it would be a case of functional differentiation. There's no particular reason to differentiate between those two fuels - we don't have a nuclear reactor core simulator in KSP. I prefer just one more general resource because it can be quite abstract, I can say, use it for a solid core, gas core or even a microfission fuel without creating different resources and different tankages. If you want both, I'd like to keep EnrichedUranium anyways.

I am open to either using the density of uranium oxide (UO2) at 10970 kg/m^3 (the current one in the sheet) or uranium carbide (UC) at 13630 kg/m3 for those two fuels. Both are qualfied solid core (or pebble bed) reactor fuels both for power and thermal rocket applications, though UC may be a better choice for NTRs (was used in late KIWIs). Though, like I said, either works .

Antimatter.. FreeThinker proposes keeping Fractal's original definition of 1 unit = 1 mg. In gaseous form with 1L units, 1 unit =~ 90 mg In slush form with 1L units, 1 unit =~ 70 g (about the density of LH2)

Well, we went through all this grief getting all the resources to 1L/unit. It would be a shame to start making exceptions now.

Hey, I don't know if you got this working with the stock modules - I never did to my satisfaction (UI issues as you mention). I ended up writing my own solar panel module to handle multiple suncatcher transforms - feel free to use it if you want.

No need to get agitated dude. I asked for input on some resources and you left it out of commentaries, so I was understandably seeking clarification. You still haven't told me whether you want to define antimatter as a gas or liquid/slush. Yeah, I think it's the same. I've consolidated it as UO2. I added Fluorine, and moved those gasses into the gas section (their densities were already gases).

I don't see Actincides in that list. Are they gone? So now we have these: Actincides [same as UF4??] DepU235Rods DepletedFuel [same as UF4??] DepletedUranium [corrected to UO2 density] EnrichedUranium [corrected to UO2 density] Plutonium238 [corrected to proper density] TH4 [corrected to proper density] U235Rods UF4 [corrected to proper density] UraniumNitride [good already density] RF folk, do you mind unifying with me on DepletedUranium (U235Rods) and EnrichedUranium (DepU235Rods)? I think I use the same proxy as you (uranium oxide rods).

Yeah, I do really wonder what they are doing exactly. We shall see what they end up with and maybe I can use it, maybe I can't.

Soo... densities? Input on costs?

I deprecated LqdPeroxide, it'll be replaced by CO2. Also removed all the Biomass resources and normalized CO2 density. Could use some input (KSPI people) on the cost of He3 and Antimatter, as well as whether you guys want Antimatter as a gas or a slush. In addition, there may be some things to decide about nuclear resources. We have all sorts right now... from NFT, RF and KSPI. U235Rods DepU235Rods EnrichedUranium DepletedUranium Plutonium238 Actincides Some consolidation seems possible here. Additionally I thought KSPI had some crazy thorium stuff, not sure if it should be in here. My input is that EnrichedUranium and DepletedUranium are enough for me, they adequately represent everything I need to represent.

Yeah I asked earlier whether that was the case and didn't get an answer. edit- D2O would be a moderator and I would abstract it for a heavy water reactor as part of the mass.

I've added all of the RF resources to the working document and corrected many densities. I'll try to start working on costs (note that I'll be referencing the LF price to the price of kerosene to generate CRP costs). In the meantime, if you all could have a look and see if any forms/intermediaries are missing, or if there's anything you're thinking of adding in the future, might as well stick it in.

I'm not going to comment on the atmo resources, but it's desirable to better the user experience to not have half a billion resources clogging up a resource intake. C. This causes no problems, the only issues is ensuring that tank volumes are correct . I would say that there's no point in including different phased versions of resources in the project at all - only the stored version should be defined. If you're scooping hydrogen out from the air, it's going to be stored as LH, not gaseous. I'm unclear on the actual utility of storing intermediaries (scoop Oxygen, liquify to LiquidOxygen makes my eye twitch)

Something in a Robert Forward theoretical paper. Can't find the link at work, seems. Think I got directed to it off of AtomicRockets though. It's not going to change the difficulty of storing it, if you're currently using gaseous confinement it's a Penning trap (leaky electrostatic) that needs a lot of power. Cryomagentic would just change the requirements to cooling and magnets. ArgonGas has the suffix because... a) KSPI Argon had a screwed up density and I didn't want to conflict. XenonGas was a thing. I've added all the RF resource to that WIP spreadsheet. I'm trying to compile who uses what from my limited knowledge, so let me know if yall use one of the resources and you're not in that users column.

That seems pretty good. Gas pressures should indeed be at STP, it's probably the simplest solution. One question then - by your post, it seems logical to say that CRP should be a complete master list and try to include as many resources as possible (or at least, all the RF ones and all the possible ones that CRP now manages). Edit - I changed antimatter that way because I was reading some papers on antiproton storage which suggested the best way to store it would be as a magnetically confined cryogenic slush. It can go the other way if you want.

Indeed! I much like the radiators. Basically SystemHeat radiators hijack the Solar Panel module, so you build them as you would a solar panel (there are a few tutorials around), but aim the sun transform parallel to the radiator, instead of perpendicular to it. All done!

RF uses STACK_PRIORITY_SEARCH for realism's sake - you have to get crossfeed from tanks to engines (via CF-enabled parts, fuel lines or the CFEnabler plugin) for fuel flow. STAGE_PRIORITY_FLOW is what stock monopropellant and XenonGas use, it works similar to ALL_VESSEL but attempts to preserve staging order instead of draining all tanks at once. Abstraction of low-pressure simple piping I suppose. I am strongly against using STACK_PRIORITY_SEARCH as a standard for CRP. I had it for LH2 in NFT for a while and the response wasn't great... All the fancy KSPI resources are currently ALL_VESSEL as well (probably mostly because STAGE_PRIORITY_FLOW didn't exist when they were defined). Putting them to stack flow could make ISRU quite a headache - because fuel only flows one way through fuel lines for one.

Very nice! I hadn't checked up on your progress in a while and saw this rebranding.

The conflicting resources are LqdHydrogen, LqdMethane, LqdAmmonia and LqdOxygen as far as I can tell. RealFuels is all STACK_PRIORITY_SEARCH for these. Currently we have STAGE_PRIORITY_FLOW for these. The main difference is needing a fuel line vs not needing one.

The issue is that RF cost and flow mode are both realistic, but if you put that in a system that is designed to supplement stock resources, those numbers will produce costs that are far too low to be compatible with LF/O/Xe/MP. The only overlaps with RF look like LqdHydrogen, LqdMethane, LqdAmmonia and LqdOxygen, btw. EDIT: oh, and maybe HTP depending on how you're defining the KSPI Peroxide... .

Density isn't the only parameter though, as I mentioned the cost and flow mode are going to vary as well.

It may be best to just keep WasteHeat and SystemHeat separate. The power generation systems are so massively different in function and magnitude between KSPI and NFT that it almost makes sense to have two, in a similar vein to Megajoules and ElectricCharge. So the prevailing opinion is to keep the stock resources in 5 L/unit (untouched) and make everything we can 1 L/unit, OK. There are other considerations now: Names: What are the resource names? A decision here needs to take into account RealFuels resource names and thus what Nathan posted earlier. If we use the same names, there's potential conflicts in costs and flow modes.... Costs: What are the costs of the resources based on? Needs to take into account names, because RF costs won't exactly match up well with stock costs. Flow modes: I had a look at the RealFuels flowmodes. Again, I'm not 100% sure that we want to go exactly this route (all stack search).

No arguments there at all, that's the perennial problem, which could be elegantly solved if Squad decided to define volume properly! My idea of the goal of CRP is that it provides a standardized framework for mods that does not change stock mechanics and vaguely ensures that different argon tanks work together, etc. There's no such effort required for RealFuels based mods, because RF chooses real values that are essentially pre-standardized. As to the options: 1. This is probably the best compromise and it what I'd like to push for. As long as mod makers are diligent in defining module resource properties as MM-targetable parameters instead of hardcoding them, it makes it relatively easy to write patches that convert one set of fuel standards to the other. It's really not horribly difficult to ensure that CRP resources aren't conflicting with RF (there's lots of way to abbreviate liquid hydrogen, for example). This was in fact the reason that I named some of my own custom resources the way I did (LiquidHydrogen vs RF LH2). 2. A viable backup, but it leaves mods that want to support both (which I generally do) in potential trouble. 3. I don't think this is viable. For one, RF should stay RF and not adopt stock KSP's unit madness if it can be avoided at all. Conversely, adapting RF for CRP immediately means that simple compatability with stock is off the table, which is not something I want.