[1.x+] Community Resource Pack

[FreeThinker]

From a purely philosophical point of view, I have to disagree with this: human beings have an amazing ability to believe stuff that simply isn't true...

Indeed, you wouldn't believe what kind of nonsense you can make people beleive. It's a genetic traith of humans which help the species survice. It's very usefull when warning children of danger. Unfortunatly it can also be abused by authority to make people believe any kind of nonse. If your not one of those people, you will wonder all the time why people can't seem to think for themselves. Edited February 26, 2015 by FreeThinker

[RoverDude]

Let me make some suggestions :

SOLIDS: For any Solid resources, a 5 unit per liter sounds fine. This includes Ore, Metal, EnrighedUranium, DepletedUranium, Aluminia, Aluminium, Actinides Substrate, Minerals and Teflon. This should keep taniwha happy.

LIQUIDS: For any (cryogenic) liquid I propose to use the 1 unit per Liter standard. Which includes LqdAmonnia, LqdDeterium, LqdPerroxide, LqdHe3, LqdHelium, LqdC02, LqdHydrogen, LqdMethan, LqdNitrogen, LqdOxygen, LqdTritium, Litium and of cource Water and WasteWater.

GASES: For any gas like ArgonGas and XenonGas (which is missing), I would like 1 unit per liter but 5 unit per liter would be possible. I would advice 1 since it's the easiest one (least amount of confusion)

Regarding LqdCO2, I noticed it is claimed by BioMass. Note it is also used as a thermal propelant in KSPI. However I noticed it uses a 4.5 units per Liter density scale.

I guess it would make sence for any organic resource but C02 is just a basic molecule. Since CO2 is also a liquid and used for NTRs, I highly suggest to put it in the 1 unit / Liter scale, otherwise I'm forced to use my own LiquidC02 version (and I don't want that)

Regarding any fantasy resources like LiquidFuel, Oxidiser, Karbonite, Karborandum or SpaceCows, I really don't care. I would suggest to keep them what they are, I think.

No objections here

Uraninite for uranium harvesting Sounds fine with me, they are very similar. Regarding consolidating Alumina and Substrate, I'm not sure if its realsitic. Aluminia is a very specific resource while Substrate is an generic abstract mixed resource like IntakeAir. It's like saying IntakeAir is the same as Nitrogen. For a large part that would be true on Kerbin, but go the another Planet/Moon and the mix would be completely different

- - - Updated - - -

Yes I was in doubt about this as well, having both Nitrogen in Gas form (from athmosphere) and Liquid Form for storage sounds fine with me. I already do this in KSPI Extended, which scoops RF Nitrogen in it's gas state from the athmosphere and converts it to Liquid Nitrogen

Good deal on Uraninite, no prob with Alumina, can even limit it to the moon pretty easily. And good deal on separation of gas v liquid. Let me know what you need in what atmospheres and I can sort the configs.

WasteHeat is currently a global heat type which is available everythere on a vessel. This effectivly allow you to put a gigantic radiator at the top of a wing and it would work as well when connected directly to the reactor. This does not seem terrible realistic, so A flow version would make more sense I guess.

A significant problem with WasteHeat instead of SystemHeat might be its diffence in quantity. KSPI Wasteheat is the result of Reactors producing GigaWatts. Do the parts you want to generate WasteHeat also generate GigaWatt? if not, any WasteHeat generated would me insignificant compared to that of KSPI.

I shall let you and Nertea sort this out

[Nertea]

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).

[FreeThinker]

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.

Agreed

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).

Well if Real Fuels already defines a resource with the same name and density (Like LqdHydrogen), Use it! As long as their are exactly the same, it realy shouldn't matter if the are defined twise or more.

All Liquids (except Water) should have the prefix Lqd

Regarding Gases I'm not sure what to do. Why does Argon have the PostFix "Gas" and other gases not? Perhaps best used the most common exiting names, like Oxygen, Hydrogen, Nitrogen, Carbodioxide

Edited February 26, 2015 by FreeThinker

[Nertea]

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

[FreeThinker]

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

Well as long as flow and density is the same and the cost is realsitic, we should use existing resources. If not, we have to define our own.

[Nertea]

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... .

Edited February 26, 2015 by Nertea

[RoverDude]

I'd be more concerned with the fuel flow rules. Maybe someone can post the differences and we can sort them... and if Nathan is still participating, maybe we can see if we can all come together, especially as we're putting the 1L fuels on the table.

[Nertea]

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.

[FreeThinker]

Exactly what is the reason we "have" STAGE_PRIORITY_FLOW ? Is there are particular reason have to use this flow type? I'm not an expert but my guess is there are good reasons why RF uses STACK_PRIORITY_SEARCH. Let's try to figure out what is ..

Edited February 26, 2015 by FreeThinker

[Nertea]

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.

[undercoveryankee]

Exactly what is the reason we "have" STAGE_PRIORITY_FLOW ? Is there are particular reason has to use this flow. I'm not an expert but my guess is there are good reasons why RF uses STACK_PRIORITY_SEARCH. Let's try to figure out what is ..

STAGE_PRIORITY_FLOW is the mode used for stock XenonGas and MonoPropellant. It draws from tanks based on how many decouplers are between them and the root part, so tanks attached to early stages of a staged rocket will generally be used first.

For resources that are likely to be found in radial tanks or used by RCS thrusters, STAGE_PRIORITY_FLOW saves on fuel lines or uses of CrossFeedEnabler. There may be some issues with generators, though - I seem to recall Karbonite having some odd issues with drills when the flow mode was set to STAGE_PRIORITY_FLOW.

[FreeThinker]

Putting them to stack flow could make ISRU quite a headache - because fuel only flows one way through fuel lines for one.

Interesting, exactly what causes this problems?

What if you used a Gas resource as an intermediate, like Hydrogen (Gas) with STAGE_PRIORITY_FLOW and convert it for storage/usage into RF LqdHydrogen. Would that solve the problem with STACK_PRIORITY_SEARCH?

[RoverDude]

The problem and why it gets weird - if you ISRU to a STACK_PRIORITY_SEARCH, you have to run REVERSE fuel lines to the converter. This is one of the main support issues I get with Karbonite converters today when they convert to LFO.

Note that you can override flow mode as part of an engine's propellant node - so unless RF is also doing ISRU, it makes more sense for the engine modifications for RF to add in a flow mode than for us to have all of our converters have to run fuel lines. I do agree with Nertea - having anything built via ISRU as a stack resource is going to be one serious headache.

Hopefully NathanKell can chime in

[NathanKell]

Apologies to all for my absence; my net was out earlier, and then when it got back, RoverDude caught me on IRC and we hashed some stuff out.

Basically, RF has two reasons for using STACK. They are:

1. Crossfeed must exist (no getting fuel magically after six steel plates, you have to actually run a fuel line there). The problems with KSP's lack of bidirectional crossfeed are mostly solved by CrossFeedEnabler, and it could be extended to make bi-directional fuel lines I'm sure.

2. Non-STACK modes have a hard clamp of 1e-5 units per physics tick. If you request less than 1e-5 units, whether you are sending or receiving, your request is summarily refused. This means that if you twitch a reaction wheel only slightly, it will not produce anything because it doesn't request enough EC and thus gets a "no EC left" response. If your antenna requests less than 0.0005 units of EC per tick, well, it thinks it's out of power because that's refused. STAGE uses the same logic as ALL_VESSEL for that.

Now, in talking with RoverDude, here's what we came up with.

1. RF will depend on CRP.

2. RF will remove, via MM, any "non-real" resources.

3. RF tank code will still implement boiloff etc.

4. Realism Overhaul will be the thing, not RF itself, that changes cost and flow mode of resources; if one does not have RO installed (like all the RF Stockalike players, who play stock career) they'll get stock-career and stock-CRP prices and flowmodes, unless RF Stockalike changes them. However, that bit will need signing off by Raptor831, since Raptor would have to add flowmode overrides to every single engine and RCS...

[Raptor831]

For RF Stockalike, I probably won't touch the costs, since I'm already scaling Stockalike engine costs to stock anyway. That said, I probably would want the flowmode to remain like it is currently in RF.

So, yeah, I'll "sign off" on updating the Stockalike portion to contain any flowmode changes needed.

[NathanKell]

The only other wrinkle, is--how are you defining gases? RF expects STP and then the pressurization is defined in the TANK definition, rather than assuming, say, Oxygen is already at 200atm. This leads to low density (and high numbers of units) but allows tanks to have different pressurizations.

[FreeThinker]

Apologies to all for my absence; my net was out earlier, and then when it got back, RoverDude caught me on IRC and we hashed some stuff out.

Basically, RF has two reasons for using STACK. They are:

1. Crossfeed must exist (no getting fuel magically after six steel plates, you have to actually run a fuel line there). The problems with KSP's lack of bidirectional crossfeed are mostly solved by CrossFeedEnabler, and it could be extended to make bi-directional fuel lines I'm sure.

2. Non-STACK modes have a hard clamp of 1e-5 units per physics tick. If you request less than 1e-5 units, whether you are sending or receiving, your request is summarily refused. This means that if you twitch a reaction wheel only slightly, it will not produce anything because it doesn't request enough EC and thus gets a "no EC left" response. If your antenna requests less than 0.0005 units of EC per tick, well, it thinks it's out of power because that's refused. STAGE uses the same logic as ALL_VESSEL for that.

Now, in talking with RoverDude, here's what we came up with.

1. RF will depend on CRP.

2. RF will remove, via MM, any "non-real" resources.

3. RF tank code will still implement boiloff etc.

4. Realism Overhaul will be the thing, not RF itself, that changes cost and flow mode of resources; if one does not have RO installed (like all the RF Stockalike players, who play stock career) they'll get stock-career and stock-CRP prices and flowmodes, unless RF Stockalike changes them. However, that bit will need signing off by Raptor831, since Raptor would have to add flowmode overrides to every single engine and RCS...

Excelent sollution!! This hierarchical structure is indeed the solution to the equation. I was afraid you didn't want to cooperate with CRP but am glad I was mistaken.

- - - Updated - - -

The only other wrinkle, is--how are you defining gases? RF expects STP and then the pressurization is defined in the TANK definition, rather than assuming, say, Oxygen is already at 200atm. This leads to low density (and high numbers of units) but allows tanks to have different pressurizations.

As far as I know this is already the case.

[FreeThinker]

2. Non-STACK modes have a hard clamp of 1e-5 units per physics tick. If you request less than 1e-5 units, whether you are sending or receiving, your request is summarily refused. This means that if you twitch a reaction wheel only slightly, it will not produce anything because it doesn't request enough EC and thus gets a "no EC left" response. If your antenna requests less than 0.0005 units of EC per tick, well, it thinks it's out of power because that's refused. STAGE uses the same logic as ALL_VESSEL for that.

Intresting. This explains some of the weird resource behavior I have encountered, where resource were not consumed unless in high timewarp

[RoverDude]

FYI Regolith takes care of that

[FreeThinker]

Hey I noticed most resources in the CRPSheet is updated to the 1unit/L , except LqdCO2. I guess it has to do with thr author of Biodome not beeing active. For the moment I suggest to add a new resource LqdCO to one of KSPI resource and leave the old LiquidCO2 alone.

One resource which is still missing is Nitrogen, it was constitudes the Majority of our athmosphere. It's currently a resource of RealFuels but KSPI uses it as well so please add it.

Anothing thing I noticed is that you made Antimatter more than708 times as heavy as it original was. Although you never going to have much of the stuff arount anytime soon, that quite heavy compaired to what it originally was.

Edited February 27, 2015 by FreeThinker

[Nertea]

Apologies to all for my absence; my net was out earlier, and then when it got back, RoverDude caught me on IRC and we hashed some stuff out.

Basically, RF has two reasons for using STACK. They are:

1. Crossfeed must exist (no getting fuel magically after six steel plates, you have to actually run a fuel line there). The problems with KSP's lack of bidirectional crossfeed are mostly solved by CrossFeedEnabler, and it could be extended to make bi-directional fuel lines I'm sure.

2. Non-STACK modes have a hard clamp of 1e-5 units per physics tick. If you request less than 1e-5 units, whether you are sending or receiving, your request is summarily refused. This means that if you twitch a reaction wheel only slightly, it will not produce anything because it doesn't request enough EC and thus gets a "no EC left" response. If your antenna requests less than 0.0005 units of EC per tick, well, it thinks it's out of power because that's refused. STAGE uses the same logic as ALL_VESSEL for that.

Now, in talking with RoverDude, here's what we came up with.

1. RF will depend on CRP.

2. RF will remove, via MM, any "non-real" resources.

3. RF tank code will still implement boiloff etc.

4. Realism Overhaul will be the thing, not RF itself, that changes cost and flow mode of resources; if one does not have RO installed (like all the RF Stockalike players, who play stock career) they'll get stock-career and stock-CRP prices and flowmodes, unless RF Stockalike changes them. However, that bit will need signing off by Raptor831, since Raptor would have to add flowmode overrides to every single engine and RCS...

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.

[RoverDude]

If the Biomass folks do not reply soon, we'll need to pull it for now, since at this point they would need to be on board with a conversion. We'll respect their mass/density for biomass however as there has been a change in their mod.

- - - Updated - - -

Also - totally open to start the theorycraft on atmospheric compositions. FreeThinker, if you want to start with what KSPI has, the rest of us can pop in as needed and tweak.

[FreeThinker]

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.

Intresting, I head something similar. Sounds like a good idea. The hard it is to store this powerfull stuff, the better. Could you provide a link to the confined cryogenic slush?

Edited February 27, 2015 by FreeThinker

[FreeThinker]

Also - totally open to start the theorycraft on atmospheric compositions. FreeThinker, if you want to start with what KSPI has, the rest of us can pop in as needed and tweak.

Alright, let me make a table

[TABLE=class: grid, width: 500]

[TR]

[TD]Resource Definition Name

[/TD]

[TD]Resource

[/TD]

[TD]remark

[/TD]

[/TR]

[TR]

[TD]EveCarbonDioxide[/TD]

[TD]Carbon Dioxide[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]EveNitrogen[/TD]

[TD]Nitrogen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]EveArgon[/TD]

[TD]ArgonGas[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]KerbinNitrogen[/TD]

[TD]Nitrogen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]KerbinOxygen[/TD]

[TD]Oxygen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]KerbinArgon[/TD]

[TD]ArgonGas[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]KerbinCarbonDioxide[/TD]

[TD]Carbon Dioxide[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]KerbinNeon[/TD]

[TD]NeonGas[/TD]

[TD]missing Gas resource![/TD]

[/TR]

[TR]

[TD]KerbinHelium[/TD]

[TD]Helium[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]KerbinMethane[/TD]

[TD]LqdMethane[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]KerbinKrypton[/TD]

[TD]KryptonGas[/TD]

[TD]missing Gas resource![/TD]

[/TR]

[TR]

[TD]KerbinHydrogen[/TD]

[TD]Hydrogen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]DunaCarbonDioxide[/TD]

[TD]CarbonDioxide[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]DunaNitrogen[/TD]

[TD]Nitrogen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]DunaArgon[/TD]

[TD]ArgonGas[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]DunaOxygen[/TD]

[TD]Oxygen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]JoolHydrogen[/TD]

[TD]Hydrogen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]JoolHelium[/TD]

[TD]Helium[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]JoolMethane[/TD]

[TD]LqdMethane[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]JoolAmmonia[/TD]

[TD]LqdAmmonia[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]JoolDeuterium[/TD]

[TD]LqdDeuterium[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]JoolHelium3[/TD]

[TD]LqdHe3[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]LaytheNitrogen[/TD]

[TD]Nitrogen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]LaytheOxygen[/TD]

[TD]Oxygen[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]LaytheArgon[/TD]

[TD]ArginGas[/TD]

[TD][/TD]

[/TR]

[TR]

[TD]LaytheCarbonDioxide[/TD]

[TD]CarbonDioxide[/TD]

[TD][/TD]

[/TR]

[/TABLE]

NeonGas and KrtptonGas should be added, they are usefull electric propellants

Regarding the Gas postfix in Names, when should they be applied and when not? For instance, why is it aplied to Argon

Say, we may also want to create a definition for the outer gas planets

Edited February 27, 2015 by FreeThinker