Nertea

That is indeed easier than rearrangement, I'll see how that looks.

Part balance between mods is irrelevant here. As RoverDude pointed out, KSPI-E patches either itself or other mods to suit its balance, because it is its own balance target. Therefore trying to enforce KSPI balance in resource collection is really strange, because you'll have to mess with it anyways if you want to have interop. And please, answer my question - how does it hurt KSPI balance if I, in another mod that is not designed to work with KSPI (none of my mods are), have a resource collection system for a CRP resource that is used in both mods? Let's examine scenarios: 1) SomeMod He3 is mineable on the moon using a custom part The distribution of He3 is relevant. The distribution of ChargedParticleDust is irrelevant because there is no part to mine it. There is no interoperability problem 2) KSPI-E ChargedParticleDust is mineable on the moon using a custom part ChargedParticleDust is converted to He3 The distribution of He3 is irrelevant because there is no part to mine it There is no interoperability problem 3) KSPI-E plus SomeMod ChargedParticleDust and He3 are mineable on the moon using two custom parts The distribution of He3 is relevant. The distribution of ChargedParticleDust is relevant. There is an interoperability problem These 3 scenarios apply to any resource, not just He3. There is only a conflict in scenario 3 because both mods provide their own extraction parts and detection parts. The scenario 3 conflict is also irrelevant, because in that case, you already have to patch KSPI-E or SomeMod as their balance likely differs in other, more critical ways. The only thing we need to agree on is resource distributions in the case that: Both mods have the resource Both mods mine the resource in an identical fashion In all other cases it's not relevant what either person wants to do with the resource. You can have ChargedParticleDust and He3Gas all over the place if you like, it won't affect me unless I explicitly use that resource. Likewise, I can have LqdHe3 wherever I want, because unless you explicitly provide a part to mine LqdHe3, your players won't be able to mine LqdHe3! Proposed Way Forward @FreeThinker, List all the KSPI resource production chains that involve the following resources: XenonGas ArgonGas LqdHydrogen LqdHe3 LqdTritium LqdDeuterium Antimatter By production chain I mean something like ChargedParticleDust -> He3 -> LqdHe3. Then we can see what "source" resources need actual distributions. For my purposes, all those listed resources above need distributions. Then we can see exactly where we overlap and focus our discussion productively on what to do.

@FreeThinker: I'd rather you post the proposed PR's for these resources here so I can have a look first. It'll be easier to collaborate until a final decision is made.

This doesn't work for me. What you are asking is that you and others define gameplay for my mod. Which isn't great. There's no reason why mods can't have separate gathering methods that do not conflict at all. In fact, this already exists (for example, I strongly suspect you aren't using my atmospheric separator parts to extract noble gases). If I have a part that extracts He3 from an atmosphere, you just don't need to have that part, then your player will not be able to extract it. All I need is the resource distribution defined. This doesn't stop you from having a complex, KSPI-specific system to do whatever you want :). However on the contrary, if you don't want to define resource distributions to work together, that does stop me from getting what I want in terms of gameplay. Which results in me doing things that I'd rather not, like adding my own distributions inside my own mods, which makes the point of CRP moot.

I'll check those, but those damn lines sometimes don't go where I want :P. No support until officially updated.

Yeah... well I'm not 100% sure what you're arguing here. The "more stuff could be relevant" isn't really... relevant given the scope of what I intend to use only four specific CRP resources (Antimatter, LqdHe3, LqdTritium, LqdDeuterium) for. If you want to start providing additional distributions for other resources or even new resources, that's great, but I don't particularly care - I'm sure that you, with your particular scope of your mod, will do a great job. I'm just interested in where we overlap, which is on those 4 resources :P.

Intermediate resource is off the table for me, I'm not interested in making a production chain. Would it not work to just give an extractor a very low efficiency? 0.01 concentration with 0.01 efficiency should produce, for example, a rate of 0.0001, and that's really all you're going for with low concentration is a low rate, right? And we are sure that the rounded concentrations are not just a UI thing? @RoverDude, thoughts? Atmospheric occurrence is low, but production is constant. Yeah, I'm talking about in space. Great!

I've noted Deuterium as an oceanic resource only on Kerbin . Let me break down my assumptions for the others He3: It's actually more common than Xenon, believe it or not. Would just be harder to fractionally distill. Similar situation for Venus (Eve proxy), which is where that occurs. Tritium The primary mechanism for tritium formation naturally is cosmic ray bombardment of N2. Any atmosphere that contains a lot of N2 is going to have traces of tritium in it. Balance-wise, here's the thing. You only extract these materials if you provide an extraction method, so don't provide an extraction method for that in KSPI. Problem solved. Other people are then free to use the stock system to do extraction, and if they install that mod with KSPI, they need to understand that relationship (or you can kill my extraction part with MM).

I have made a start on iconography, some are good, some are bad. You can follow the progress on the CTT 3.0 Gliffy (takes a while to load). Notice you can now mouse over the tech icons to see what mods contribute... I'm going to solicit lists for this, then I'll populate them. I hope that this will reduce the "what mods contribute to what node" questions. I don't usually make things randomly for other mods. You'll be free to re-use whatever I make for CTT as per the license. There will probs be some propellers for the subsonic propulsion nodes.

This is a good point, I'll mention that I'm only listing things for parts that I intend to develop. Other people might chime in for such uses, so that's good. I also haven't properly educated myself on the specification for crustal resources yet.

Ok, I'm going to assume everything is totally fine then Proposed fixed-location atmospheric/exoatmospheric resource distributions: XenonGas Kerbin: very low atmospheric concentration Duna: very low atmospheric concentration Jool: medium concentration Laythe: ? ArgonGas Kerbin: low atmospheric concentration Duna: low atmospheric concentration Jool: medium atmospheric concentration Eve: low atmospheric concentration Laythe: ? Helium-3 Kerbin: extremely low atmospheric concentration Jool: medium atmospheric concentration Eve: extremely low atmospheric concentration Deuterium Kerbin: medium water concentration Jool: low atmospheric concentration Laythe: medium water concentation Everywhere in space at extremely low concentrations Tritium (I'm more or less assuming that any atmosphere that contains a decent amount N2 can have infrequent production from cosmic rays) Kerbin: extremely low atmospheric concentration Jool: extremely low atmospheric concentration Duna: extremely low atmospheric concentration Antimatter Jool: low space concentrations Kerbin: very low space concentrations Laythe: very low space concentrations Hydrogen: Everywhere in space at extremely low concentrations Proposed cost alterations Tritium -> 18.0f/unit He3 -> 52.5f/unit If nobody has any problems I'll make a PR in the next week.

I have a number of changes to propose for a 1.2-era update. Since I don't really own any of these definitions besides ArgonGas, these are merely proposals. 1. Regularize the distribution of certain resources Authoritatively define some key Atmospheric Resources, ie. on which planets they are guaranteed to be present. ArgonGas [NFT]: define presence on stock planet atmospheres XenonGas [stock]: define presence on stock planet atmospheres Tritium [KSPI]: define presence on stock planet atmospheres and oceans Deuterium [KSPI]: define presence on stock planet atmospheres and oceans He3 [KSPI]: define presence in stock planet atmospheres, space, oceans and regolith Antimatter [KSPI]: define presence in stock planet space The primary justification for this is to make things more predictable on certain planets so they can be used as refuelling targets reliably. I would still have randomness of abundance so some discovery is required. If this goes through I'd like to open a discussion on what we would put where by default. I do not anticipate huge problems with messing with the distribution of these resources, because as far as I know, KSPI still mostly uses ORS to do extraction of resources. These stock distributions would therefore exist alongside the KSPI distributions without conflict. Please comment on this @FreeThinker, if you have any objections. 2. Propose alterations to the cost of a few resources I'd also like to open a discussion on the cost of fusion fuel resources. CRP (and KSPI) defines the He3 cost as 525f/unit and the Tritium cost as 188f/unit. This is possibly too much. For reference, Deuterium is defined as 0.256f/unit and standard LH2 is 0.03675f/unit. I recognize that this is a realism thing and that these costs would represent current costs. However.... This starts to create problems when balancing engines and such. If I have a D-T engine with a +50% performance benefit over D-D, the fuel cost goes up 1000x. The cost certainly outweighs the benefit, and without providing a ridiculous benefit, that creates a balance issue that cannot easily be solved. The 'canonical' reason for this is to encourage off-planet mining, and that's cool, but kinda makes hash of mods that don't want to deal heavily with that. I'd like to propose some reduction in the scaling perhaps by 10x. With He3 at 50f/unit and T3 at 10f/unit, the cost penalty for the above scenario (D-T) is only a 50x cost increase or a (D-He3) 250x cost increase. This still strongly incentivizes off-planet extraction but doesn't make it prohibitive to launch with these. Again, feel free to comment here, particularly @FreeThinker but anyone else too :P.

The CC-BY-NC-SA license that is used by NFE allows whatever you like to be done by anyone as long as the license terms are expected. Better yet, a second mod using MM to do what you want! That being said, super explody nuclear reactors will never happen in any version of NFE developed by me.

It's that major-KSP-release time of year again, so let's talk about CTT 3.0. Here's what I have planned: Node art for all nodes (finally! and the reason for the major version bump) Calling people who are good at icon concepting! If I don't get ideas, you're just going to get silly things like trefoils with +, ++, +++ etc :P. Several new techs (names might be subject to change, locations are more or less final) Experimental Radiators (Heat, T12) High Power Electrical Systems (Electrics, T11) Experimental Electrical Systems (Electrics, T12) Experimental Physics (Science, T12) Nothing major, but particularly, @FreeThinker, confirm this is what you want :).

Made a quick model yesterday that seemed like it went very well!

Typically an install issue. Follow the instructions in the readme.txt. The RPM support is old and should be deprecated. Maintaining it is a bunch of work that I don't want to do. I eagerly accept contributions for fixing it. No idea why bits of the IVA are missing form some angles. Very frustrating to me, some people also see this, but I don't in my game! I will look into it post 1.2

So uh, how was the performance with that? :P. Just like a stock system, the basic system is simplistic. There is an undocumented, untested module called RadioactiveConstantSource which does more or less what it says on the can. There's also an undocumented, untested parameter in RadioactiveEngine called EmissionDecayRate and EmissionMinimum which are supposed to specify the rate at which emission decays and the minimum emission from an activated engine. Looking at the code it's not fully implemented but I'll make sure to include that in the next build. Incidentally, the next build will probably be the last 1.1.3 build as I start targeting the 1.2 experimentals.

Yeah it's a balance for sure. That'd be why I'm not touching it yet Ah I see. Yes that would decrease the amount of 'casting needed. However, you'd still need to do complex updating in a few cases, ie individual kerbals on EVA. I'm going to implement the simplified method first then move on to the more complex implementation if need be. Ah. Reminds me of the stuff with the Ymir in Seveneves, if you've read that :P. I was just thinking of something that caused virtual surface contamination via biome-like maps. I came up with some crazy simple math model on the bus and knocked it out in Python at work I was way overthinking it :P. Visualizing this will be fiddly, but I have some ideas on that front too. I've noticed that attenuation seems a bit strong sometimes. I have done some excel math to test things in simple situations so they seem to match up, but nothing hugely complex. It might be true, to some extent, because KSP objects are so dense (if that is the case, we can arbitrarily reduce the standard attenuation constant), but it could also point to some problems. I'll have to do some testing to be more sure. If you make a ship (simple as possible, please) that has something that looks odd going on, please send me a log and the craft, I'll try to manually calculate the attenuation paths. The small exposure numbers are going to get a time-shift - below 1 mSv/s or something they'll change to minutes, then hours, then days.

I think integration itself is simple, but producing an interesting gameplay experience is not. I dislike having random events with very painful consequences, but I think that there's room for something interesting here! Maybe there's a basic solar weather randomizer (deterministically driven with the KSP game seed) that produces infrequent semi-random events. Let's say there's a solar observatory part or something, and using that part brings up a prediction of solar weather for the next 60 days. Then you might create some interesting gameplay from that, build a solar observatory to get data, plan missions accordingly. Plus there are many reasons to have a storm shelter, like having a place to hide sensitive crew during a burn, or during a radiation belt transit :). That's what I describe in the first option. It could be rather computationally expensive, because in the case of one ship things are ok. The list of events to listen to is low. In the case of more than one ship, the list of events is potentially quite high... consider how frequently the geometry between two nearby ships changes. With something like an absolute minimum of 16 rays needing to be cast per sink (and realistically in the 48-96 level), that would get very unpleasant fast. To do this I probably need to (at minimum) get a major optimization done, which is to exclude crew-containing parts that do not contain crew from the simulation. That will drastically improve the performance for many ships, particularly those that decorate with a lot of hitchikers or other usually uncrewed crewed parts. I considered contamination too! Probably not something I'm interested in doing, but really wouldn't be that hard to keep a database of all "contamination points" that is added to when you do something horrid with 100t of nuclear waste. Merely check whether you're close to one of those and work from there. My reluctance to do too much collaboration comes more from time constraints than other things. When my activity is very peak-based, I don't want to commit really to joint projects and I particularly don't want to spend a large amount of effort ensuring that everything stays exactly compatible. It can be quite frustrating. Will probably talk to him at some point though :).

Sweet! So I've been doing a bunch of thinking about ambient radiation modeling, and I will now share my thoughts. Essentially, there are four main natural sources of radiation that make up the ambient situation. I have to deal with them all to some extent. We have Solar (primarily coronal mass ejections) Galactic cosmic rays Planetary radiation belts Surface radiation Solar: Let’s begin by not modelling solar. It’s mostly CME based, which requires a simulation of solar weather, which doesn't seem hugely interesting, or does it! I could have a readout, with a graph, activated by a part, which would give you a nice prediction... that'd be pretty cool. Let's table it though, it would be very complex. GCRs: Ambient radiation from GCRs is more or less an omnidirectional increase in radiation flux, attenuated by the local planetary magnetic field. Anywhere in the universe, your exposure to cosmic rays is primarily a factor of your magnetic field and the amount of the sky that is not occluded by a gigantic massive planet. To work out the complete solution you would essentially have to raycast outwards from the part in all directions with a decently high angular density, attenuate those rays through the parts, and from that figure out the total exposure of the crew pod. Additionally, scale the total flux by the strength of the planet’s magnetic field at that point. Essentially... If (Sv/s) = I0 (Sv/s) * tau* sum(rayIf)/nRays If = dose at part surface I0 = GCR mean dose, as from MSL (say 300 mSV/year) rayIf = final attenuation of ray once propagated (0-1) nRays = number of rays cast tau = attenuation scalar of magnetic field at vessel distance This would allow full simulation of using parts to attenuate GCRs. It’s conceptually doable but adds a bunch of computations. Every time a vessel is changed or moves relative to another set of parts, the ray burst has to be recalculated for accurate simulation, which could be quite lag-inducing (though conceptually you could spread this out over a few frames and optimize it a bit). Not ideal. I believe that a simpler model is to have each part work out the approximate visible size of the local celestial body and use that to scale the total flux from cosmic rays, as that is the main driver of cosmic ray exposure (attenuating GCRs sucks without a lot of mass). Additionally, scale the total flux by the strength of the planet’s magnetic field. This would be kinda... If (Sv/s) = I0 (Sv/s) * ((4*pi) - Psr (steradians) )/ 4*pi * tau (scalar) I0 = GCR mean dose, from MSL (say 300 mSV/year) If = dose at part surface Psr = size of planet in steradians at vessel distance tau = attenuation scalar of magnetic field at vessel distance This is computationally simple so that’s great. The problem with this solution is that of course it does not take into account parts of any kind. This means that you have to rely purely on the crew pod’s shielding and the planet’s magnetic field. Another approximation might be calculating the "real" sky visibility from a part, but then that would not take into account the ray path through parts, which means it's pretty much inaccurate too. I’m leaning towards the second option, mainly because i’m already heavy on raycasts for the point simulation and want to save that power. Surface radiation: This can be bundled with GCR simulation pretty easily using the inverse of the second method, it’s easily possible to calculate the fraction of the sky that is “planet” and use that to scale the total radiation. Local radiation could easily be sampled on a per-biome basis (eve’s seas could be radioactive, for example). Seems pretty straightforward. If (Sv/s) = I0 (Sv/s) * ( Psr (steradians) )/ 4*pi I0 = dose when surrounded by the radioactive surface material If = dose at part surface Psr = size of planet in steradians at vessel distance Radiation belts (and magnetic fields) This one is in the same vein as GCR. If you’re in the radiation belt, it can be assumed that the incoming radiation is omnidirectional. This can therefore piggyback off whatever GCR model is being used. The issue is how to model the seed value for the strength of the radiation belt. Typically the radiation belts are weirdly shaped depending on the magnetic field distribution of a planet (Kerbalism has good examples). What’s the value in semi-accurately shaping the magnetic fields versus modeling them with a altitude based curve? A curve can be sampled easily which makes it pretty simple. Arbitrary shapes are harder to evaluate and visualize, but could make for some interesting gameplay. Thoughts?

Here is a new build. It should fix... all? most? of the bugs reported so far, notably the ray overlay disappearing if the ship is moving and the UI detonating sometimes. It still does not fix the overlay not being set up properly when a vessel loads in the VAB. Bugs fixes: Fixed rendering of overlay rays in non-static situations Fixed UI overflow with very small dose rates Fixed overlay info windows being shown in the map view Added placeholder Geiger Counter (thermometer) science part, which can track current and total radiation doses (resettable) Added placeholder Storm Cellar part, which has 85% radiation shielding but roughly 3x the mass of a standard hitchhiker

It's awkward to tune that collision radius so that stuff mounted on the nodes and stuff mounted on the surface is not occluded, but stuff mounted in the bay is. I'll have to take another pass at it sometime.

I'm pretty sure this is something to do with connecting the rays to the ship. I thought I was doing this correctly, but this wouldn't be the first time a KSP API field does something completely different than described :P. I need the actual log, guessing what part I might need doesn't help - that chunk is completely nominal :). As the dimensions of the shadow shield are parameters of the model I don't want to do that. The separate shadow shield part could become tweakable though. As for Kerbalism compatibility, I've hopefully made the database easy to understand, so anyone can build off it somewhat easily. I will be building my own model for ambient radiation as well, but I want to lock down this first, it's much harder . Thanks for the craft file, this helped me determine that there was a UI overflow when drawing a part with very low, but not zero dose rate, so that will be fixed soon.

That's... Really weird and didn't show up at all in testing. Can you send me a log too? And more or less what you were doing to get it to there? In the second picture at least it looks like all the lines are right but just drawn at the wrong location. Huh. Well I'll look into it when I get home.

Pretty nice! Is there any noticeable performance hit? That contains exactly one of the four things I asked for in bug reports above.