Nertea

Small detail + basic colorization pass.

Cool. I'll try to find some time to test in the next 24 hours.

Want to draft up some cfgs for the distributions (I'll do it myself, but my time is limited these days)? I want to do ingame tests on this before we decide for sure.

Gotta say, I am hugely pleased at how the smelter turned out. Piston moves, emissives glow ingame too!

I am quite possibly the person on the forums most aware of that ;).

Sweet, that's a much better way of doing it. I'm going to implement this in my NFT spreadsheet for the future. Another interesting fact is that the Dawn produces something like 41 MW of thrust power for... 9 EC/s? So if you assume 1 EC = 1 KJ, well, that's some magic there. If you go the other way and calculate EC value from thrust, you get 1 EC/s ~ 4.5 MW, without taking efficiency into account. Those are some crazy solar panels :P.

I probably shouldn't have thrown that 80 in there, that's how I'm calibrating FFT engines. If you compare the jet power to the heat given by the cfg for stock engines, you'll find that they're something like 98% efficient. That's mortgage likely to produce good results.

Thanks for pointing this out. Engines can individually be set to consume fuel via any flow method, I can make sure that these engines are set to obey similar staging rules as LFO engines.

Eh, not hugely on my critical to-fix list... I'll think about fixing it sometime though. It looks like a NFConstruction adapter plus surface radiators, radial batteries and tiny hydrogen tanks.

The drag cubes that I'm using are the ones copied from the fuselage sections and appear to perform just fine normally. We're looking at some problem in the interaction between the cargo bay modules and occlusion which I have not been able to reliably track yet. They are more efficient than the RAPIER is, as I recall.

That would be fairly inconsistent with the density of LF and specific impulse of LFO engines.

There's 2 approaches I've used. Part of the final balance for my suite will involve a hard look at these numbers (I have a huge spreadsheet). 1) Calculate the EC usage in kW of the engine (only works for ion engines obviously). Get the system efficiency and multiply by the inverse that to get the waste heat. Convert to cfg values. 2) Calculate the jet power of the engine (P = 0.5*Ve*Fthrust). Determine the heat efficiency of a comparable RL engine (for example 80%), and work backward to find the total power of the engine. Total power - jet power = waste heat... convert to cfg values.

That's cool. Can we proceed with that approach then? Redo all atmospheric concentrations to the 0.001 to 100 range, where 100 = highest possible abundance for that resource?

How would you go about applying an exponential approach to this bit?

It's pretty silly. The way the math works out though is basically saying that ignoring the generation factor, a heatProduction of 1 means "I raise my temperature 1K per second" (so including the generation factor, 0.03K per second). That means that in theory, you can look at that number and say "the Ant engine increases its temperature by 0.3 K per second", so balancing-wise, it's fairly easy how long an engine can run at in isolation without blowing up. Yet this is moot, generally, because no engine functions in isolation...

I only included the definitions from the CRP cfgs, which only define LqdHydrogen in Jool atmo and as an exoatmospheric resource. If you want to add a bunch more definitions that's of course not included in the sheet. Plus, I'm going to heavily push that Alternate approach up there. I think it's cleaner.

So, I got this info from NathanKell a while ago, it's what I use to set my engine heat production values. It might be out of date though. Engine Heat Production in kW = heatProduction * partSpecificHeatCapacity * heatProductionMultiplier * partMass * throttleSetting where partSpecificHeatCapacity is typically 800, and heatProductionMultiplier is typically 0.03. edit: tried applying that to your numbers with the Ant's 0.02 t mass and it doesn't quite work... gets roughly 2x what you have there (4kW).

So here's an editable sheet, with values taken from the current CRP. I have used the minimum and maximum values for all distributions here to capture the whole range. Some observations that jump out: There's 3 pretty clear scaling factors that can make all values right: 1.0, 100,000 and 100,000,000 Some values have a large range that feels like it could be compressed. Namely Xe and LqdHe3. Compressing Xe down to 0.001/0.01 seems like it could be reasonable with a resassignment of what planets are useable. It's scaling factor would then be 1.0 Compressing LqdHe3's minimum could also allow it to work in the 100,000 range This would leave us with two clear factors of 100,000 and 1.0. The 'exotic' number pretty clearly only applies to exoatmospheric and super-rare He3 so it minimizes player confusion. I have noticed that exoatmospheric definitions for antimatter and atmospheric definitions for LqdDeuterium (probably specifically for Jool) are missing, by the way. We should add these. Completely Random Alternate Idea What if... each "abundance" was refactored merely to mean relative abundance, in terms of extractive potential? So all resources have an atmospheric abundance range of 0.001 to 100%. This gives a full set of 6 sigfigs of abundance variation without venturing into strange >100% territory, which might be confusing to the player. It would then be up to the part module to (using the efficiency parameter) define the actual extraction rate. Example: Scanning for LqdHe3 on Jool shows an "abundance" of 100% (maximum value that can be mined anywhere) Scanning for LqdHe3 on Kerbin shows an "abundance" of 0.001% (absolute minimum value that can be mined anywhere) The part extractor has an efficiency of 0.0004 (example), so the efficiency scales the mining to a realistic number value. I added a third table in the spreadsheet to show what that would look like. There is still compression of ranges required in this one, but it is less arbitrary. The more I think about this, the more I like it, provides the necessary info (relative concentrations) and easily shows where an planet has a "better" atmo than another.

Okay, sounds good initially, but let's not rush into this. Last time we made modifications to the distributions we didn't test them fully, and this resulted in this mess in the first place. I'm going to put together a shared google sheet on this and we'll work it out over the next week. Stand by.

I'll add this in the next build, whenever that is. Probably after the latest CRP argument is over and changes get finalized. I examined this. You have a bunch of NFE-unrelated NREs in there... seems like there may be some problems with your install.

Nah, I don't like TweakScale, but it's easy to add yourself. So first off, there is a need for the boxes you've marked as "extra" for the complete encapsulation of the cargo. I also don't see these weird colliders in my install with sarbian's tool, or in Unity, or anything. There might be some issue that I would want to look into as a result of that, but at any rate, it's not the problem. The drag cubes are not currently being generated by the colliders, they are being generated by the fuselage pieces of equivalent size and overwritten.

I'm fairly certain that you're incorrect about the size of the minimum value. Let's take the definition of LqdHe3 for example (one of the smallest numbers) PLANETARY_RESOURCE { ResourceName = LqdHe3 ResourceType = 2 PlanetName = Kerbin Distribution { PresenceChance = 100 MinAbundance = 0.00000000072 MaxAbundance = 0.00000000072 Variance = 0 Dispersal = 1 } } 100% chance of existence in any save on kerbin with those exact parameters. When I query the ResourceMap with the appropriately formatted request object, the LqdHe3 abundance is returned as 0.0. Other, higher numbers work fine. There certainly is a minimum useful value, and it's lower than the default ModuleResourceScanner will show, but it's there. And by the way, worshiping at the altar of realism does not help anyone's case. -edit: Trial and error testing the ResourceMap query seems to point to the minimum queryable indeed being 0.001. Care to share your method for getting smaller values? KSPI-E's code is labyrinthine and I can't spare an hour or two to dig.

Is it too much to ask for a solution that doesn't involve another plugin dependency (and thus maintenance and bugfixing thereof) and can be accomplished using the system provided to us?

Based on the BATSE instruments on the Compton Gamma Ray Observatory. I'm not hugely happy with it, but it has some nice spec maps that show up well ingame. I threw the scoop ingame to test its looks, I'm pretty happy with it. Will probably start texturing now.

So I believe I need to have some comprehensive changes to the distributions of atmospheric resources. It's all very nice to put "real" numbers in the config files and all, but my recent testing has essentially shown that abundances below 0.001 do not show up as harvestable in the game at all. This means that things like this beautiful distribution: GLOBAL_RESOURCE { ResourceName = XenonGas ResourceType = 2 Distribution { PresenceChance = 50 MinAbundance = 0.00000005 MaxAbundance = 0.0000005 Variance = 5 } } ...functionally means 0 abundance everywhere. Feel free to confirm this if you like. So there has to be a key improvement in this for atmospheric harvesting to be useable at all. Namely, all resources have to have atmospheric abundances above 0.001. My proposal is that the entire set of resources contained in CRP that are extractable from the atmosphere be recalibrated so that the "lowest' abundance becomes 0.001. This will necessitate a compression of the range of available values. For example, the tiny abundance of LqdHe3 (0.00000000072) becomes 0.001. We then recalibrate the other values so that the relative abundances are preserved. The obvious counterargument to this is that it might make some resources too abundant. That's pretty easy to fix... apply the efficiency parameter properly to this and it'll reduce the effective extraction rate.It's important to note that this also only affects people who use the stock atmo resource system. I don't know who that is beyond me and @RoverDude in Karbonite. These people should chime in. Important note: I haven't tested this with exoatmospheric resources so far, but I expect the same behaviour.