ShotgunNinja

Unfortunately if I include DX11 shaders, the Unity editor bork when creating the asset bundle, and also include DX11_9 shaders. These in turn don't have support for 'point-sprites' stuff I'm doing in the shaders code, and somehow get selected on some particular GPUs, resulting in the players with these GPUs having no radiation field rendering. I found out the hard way. You will have to switch back to DX9/OpenGL, or live with the pink... The airlock dynamics we were talking about. To do it proper, support for multiple separed habitats would be necessary (even if one is just a tiny one meant to be a simple airlock).

Crap, no that's a mistake. I've released a new version 1.2.2 with the hotfix. Thanks for letting me know - fix: remove stock antenna from probe cores

New version 1.2.1 released: - new ECLSS component: Waste Compressor, compress Waste into Shielding - new ECLSS component: Monoprop Fuel Cell, burn Monoprop and has Water+Nitrogen by-products - atmosphere is breathable on all bodies containing oxygen, when pressure is above 25 kPA - proper experience bonus calculation in stock converters and harvesters (@Gotmachine) - MOLE solar panels support in planner and background simulation (@Gotmachine) - support patches for SXT & HGR, improved patches for VSR & HabTech, and more (@Eberkain) - support patch for OrbitalTug (@PiezPiedPie) - fix: cache stop updating after planting flag (#50, #52, #75) - fix: exception in main loop when space weather is disabled (#78) - fix: exception in planner analysis when comfort modifier is used in a process (#79) - fix: greenhouse harvest ready message spam - fix: missing configure setup descriptions in some cases

I found the issue with control loss and flags. Flags are vessel, and apparently they have vesselID = 0. The vessel cache is a FIFO one, the oldest entry is removed and recomputed. The code that checked the oldest entry had a special meaning for vesselID = 0. So as soon as a flag became the oldest entry in the cache, the whole cache stopped recomputing. This was evident after EVAing a vessel without antenna. Before the EVA, the vessel cache entry was controllable (because manned). When it went outside, the vessel cache was updated to uncontrollable (because unmanned and no antenna). After planting the flag, the cache stopped being update shortly afterward. Then on re-entering the vessel, it still figured as uncontrollable according to the cache, leading to control loss. Special thanks to @blakemw for providing me with a test case, and to Bob Kerman for landing on the mun a hundred times.

@John Nowak This is rather complex, and I just woke up, so please bear with me. Suppose it was possible to split a vessel into multiple habitats, even if only an 'airlock' and a 'main' one. Now all habitat properties have to be valid and defined for each one of them. This is not possible with the stock resource system, as you would effectively have multiple 'sub-vessels'. The next logical step would be to throw away the pseudo-resources in habitat, and implement the same in a more complex way instead. That would be possible, but it would also be a less flexible system. How much less flexible? I'll make an example: you can create a 'waste compressor' that produce shielding, using a stock module resource converter or equivalent, right now. This kind of thing would not be possible anymore if I go this route. Another solution would be to implement 'sub-vessel resources'. The resource cache system could be extended in such direction. However, what about anything that doesn't use it, like for example non-kerbalism modules in loaded vessels? Those will be unaware of the sub-vessels. That's why I didn't dwelve futher in this matter at the time the pressurization was introduced. Instead, I went around these issues with some minor tweaks: the habitat part 'lock/unlock' was renamed to 'enable/disable' there is only a single habitat in the vessel at all time, composed of all enabled habitat parts transfering crew inside a disabled habitat will automatically enable it you can't disable an habitat where some crew is inside it

That was my reasoning. Essentially I went for 1 kerbin day = 1 earth day, and kerbal = human. I could rescale rules automatically from day-lenght. However, all process/module would have to be rescaled as well. There will be subtle changes in balance too, for example EC consumption reduced to 25% against unchanged solar panels, etc. Is probably best to write a new profile for RSS. There is a small list in the OP, but most mods should work without issues. Some aren't simulated in backround (like KSP-IE), but otherwise work.

It doesn't, that's probably the issue. In default profile each kerbal eat 1.77 Kg of food every 6h. Irregardless of your KSP day-length setting. Also everywhere the UI is telling you 'days', it mean 6h or 24h depending on your KSP day-length setting. So in your example: crew of 1, consume 1.77 Kg every 6h pod has 27 Kg with 6h day-length setting, the estimate say 15.25 'days' left (it mean: 91.52 hours) with 24h day-length setting the estimate say 3.81 'days' left (it mean: 91.52 hours)

@eberkain I'm using NASA estimates for a human.

There is no scaling of the rates in code, rather they are specified in the configs. In there you can do some scaling using MM-fu. For example I scale the ECLSS rates using crew capacity. Multiple profiles can coexists, but only the one selected in Settings.cfg is used. @podbaydoor Yeah, sorry about that You could also switch setup in the configure window, that should re-setup the right amount of resource in theory.

@JadeOfMaar That is nice The Harvester module can do atmospheric harvesting, when 'type' is set to 2 (the valid values are the same as in the stock harvester). You can have multiple switchable harvesters (each one for a specific resource) in a single part by using the Configure module (that look messy to use at first, but it grows on you). You can see an example of how this is used here, where a configurable atmospheric harvester is added to the stock atmospheric sensor part.

@JadeOfMaar Absolutely interested. What parts do you have in mind, and how can I help you? I would suggest not to worry about it, and make them for the default profile first (I just found out that non-trivial interaction between Kerbalism + TAC are fundamentally broken beyond hope of fixing). You mean code-wise, or something that could be made with new processes? I'm adding a couple new ones in next version: a WasteCompressor that produce Shielding, and a MonopropFuelCell. They are already on github here. I've also received a WasteIncinerator process as a contribution, that maybe will end up in the ISRU chemical plants.

Note: I understand the thread is old, I'm posting this anyway not to discuss with the previous posters (probably most gone by now), but to leave a link to source code that may be useful to those that ends up in this thread because interested in these issues. 3 years later, all 3 of these features have been implemented in the resource cache system of this mod. The relevant source code is here, and is in the public domain. 'Batch resource requests': the OP clearly understood the issue here. When inputs and outputs are inter-dependent, the problem is essentially of an information-loss nature: the inter-dependency information need to be preserved and taken into account when executing the 'requests'. This is solved in the code linked, by preserving information in recipes. 'Storage-independent resolution': another great insight by the OP. This is solved in the code linked by allowing pure-inputs and pure-outputs recipes to overflow/underflow the resource capacity, while the inter-dependent recipes are instead executed using an iterative algorithm, that is very simple and fundamentally agnostic of the orders in which recipes are executed. 'Offline resource flow': This is also accomplished in the code linked. Producers and consumers in unloaded vessels are simulated, resulting in a set of recipes that is then feed into the resource cache system. The state of all resources is then synchronized back into the vessel proto structures. The process is atomic, and performed at an arbitrary frequency.

Mmm, I was thinking more about it. Probably, given that TAC does its own 'post-facto' simulation, it is showing to you the Water level including all its own things. These things, Kerbalism can't be aware of, nor they result among the vessel resources when it is unloaded, because TAC simulation is fundamentally different from my own. So, what this mean at the end of the day? That if Kerbalism and TAC share some resources (like Water in this example), you are going to have problems bigger than wrong estimates.

@John Nowak Originally the pressurization was meant to include that. Entering/exiting would have required the pressure to be equal, so that you would had to move to an 'airlock habitat', isolate it from the rest of the vessel, equalize its atmosphere with the outside, then eva out. Likewise to eva in, the opposite process. From the exterior it would also been possible to 'vent' the whole vessel, to enter in uncontrolled ones (a similar valve is present on the ISS). On simple vessels (like, a moon lander) where there was a single habitat part, the only solution would have been to vent it before going on EVA, then re-pressurize it from scratch after the EVA. It wasn't implemented due to: time contrains (I was developing a lot of other things), unclear how to manage 'isolation' between habitat parts, and general lack of airlock parts.

Some time ago I did a preliminary design for a celestial body weather system. Here are the notes I took at the time, maybe they can be useful to the discussion. Take these with some reserve, as nothing mentioned was ever actually implemented, not even in experimental form.

They are trying to open up revenue streams: localization open new markets, DLC extract more from already exhausted markets. This is a 'money grab' (what else businesses do?), but there is nothing inherently evil in it.

You can go into Settings.cfg, and set UnlinkedControl to limited. That will allow you some partial control of the vessel when there is no connection, akin of some kind of poor man flight computer. The limitations in that case are exactly the same as the ones in stock CommNet 'limited control mode'.

Ah ok, thanks for clarifying. I think the issue is that the greenhouse inputs and outputs are not mass conserving (could be wrong, I'll check later). I can see Bill (or is Bob? I can't never remember) the engineer rigging it up, before the inevitable unplanned conflagration. But honestly, I wanted to represent this kind of 'on-the-field ingenuity' in emergency situations (I read 'the martian' before the last big update). I didn't manage to come up with any appropriate representation of it, the nearest thing being the fact that Configure setups can be re-configured in flight if specified in the module, but that is not really used in current incarnation. I like this very much. Will be in next version. Possible. Asteroid-related stuff is perhaps the least tested, for logistical reasons. I'll check it.

Exactly my throughs. It would be nice if human-readable IDs ids are allowed (like, #mymod-ui-whatever). If that turn out to not be the case, we could avoid duplicate IDs by choosing a random number from a very big space (like, 128bit). However then I'm not sure that I really want to deal with code containing these unintelligible numbers.

@Crimeo Sorry somehow missed your post before... I'll check the numbers, maybe there is some error there. That make sense. To be fair there was a reason I didn't made the greenhouse consume CO2, but I don't remember why right now. I'll try to sneak this in the first savegame-breaking update available and see how it goes. The waste processor should produce Ammonia, not Nitrogen! Can you double check this? I understand. But what would be the purpose of carring monoprop + a dedicated ISRU chemical plant, instead of carring directly more nitrogen + hydrogen. One vessel may have spare monoprop, that happen often. But they will most definitely lack the dedicated ISRU plant anyway once the nitrogen (or hydrogen) deficit for the mission became apparent.

I'm going to re-implement the space weather mechanic. The idea is to replace the current CME symbolic event with a simple solar wind model. Technical details are here for those interested.

@Neoph Not at the moment. I'll see if it can be implemented. @smckamey19 The max transmission range on a vessel doesn't increase if you put more antennas on it (let's say, two high-gain ones). But the transmission rate does increase (along with EC cost of transmission), because you can use multiple antennas at once to transmit the data. So it can be useful. Also they can fail, if you have Reliability enabled, and you should decide if having some redundancy is proper for the mission at hand.

@JadeOfMaar By 'non-chemical processes' I mean things like the Waste Processor, or the Greenhouse lamps (maybe). If I go the fully automatic 'ec consumed -> heat produced' way, that could be technically possible to implement both for my own processes (the converter-like things in the rule framework) and in general for all things consuming EC (perhaps using some of the new KSP events added recently), I fear there will be issues along the way that will be a pain to deal with (the NF ion engines you mention are a great example).

I've started a discussion about the implementation of a new thermal control mechanic here on github, reproduced below for convenience of those interested in partecipating on its design. This issue outline the details of the new thermal control (TC) mechanics to introduce in the near future. Comments and suggestions are welcomed. The objective is to model approximately heat, and to force the user into taking engineering decisions and compromises similar to those done in reality on the matter of thermal control on spacecrafts. Technically, it will be implemented on top of current infrastructure to minimize work and potential bugs, and will be exposed to the user by extension of the current Rule Framework capabilities. While thermal control, in reality, is not an exclusive of manned habitats (every device and instrument has its own operative temperature range to be maintained), for simplicity only the crew and its survival temperature range is taken into account. This avoid a total redesign of the rule framework, that is way beyond the time and attention budget allocated for this new mechanic. You know those radiators that are barely used only if you go to the inner solar system, or if you deal with the stock ISRU? I'm talking about these things: We are going to make these useful. How it works The habitat system is extended so that every habitat part would have capacity to store Heat, a special non-visible mass-less resource, in function of the volume of its internal space. This is similar to what happen right now with the Atmosphere and WasteAtmosphere resources. The Heat resource would then be generated by: crew members any process that consume EC any chemical process that is exothermic a dedicate Heater ECLSS module incoming solar/albedo flux, in proportion of half the vessel external surface and consumed by: vessel radiative flux, in proportion of the vessel external surface any chemical process that is endothermic radiators The internal habitat temperature will then be determined from the Heat level (that being the Heat amount versus capacity) over the set of enabled habitat parts. Modifiers changes The old temperature modifier is removed, and new ones added: incoming_flux: the sum of solar flux, albedo flux from nearest body, and radiative cooling flux from nearest body, expressed in W/m^2 half_surface: like the current surface modifier (that represent the sum of external surface of all enabled habitat parts), but multiplied by 0.5, expressed in m^2 cooling_need: a value in [0,1] range, that is 1 when internal habitat temperature is above survival range, and that rapidly approach 0 as the internal habitat temperature approach the survival range heating_need: a value in [0,1] range, that is 1 when internal habitat temperature is below survival range, and that rapidly approach 0 as the internal habitat temperature approach the survival range crew_count: the number of current crew members on the vessel Rules changes The climatization rule is replaced by two new rules: freezing and burning. Both of them are resource-less rules, that will use the respective cooling_need and heating_need modifiers so that, when internal habitat temperature is above/below the survival range, they will degenerate (up until death) and when the internal habitat temperature is inside the survival range, they will recover (as degeneration will be zero in that case). Processes changes Some new processes are added: Process Consume Produce Modifiers IncomingFlux Heat incoming_flux, half_surface OutgoingFlux Heat surface Metabolism Heat crew_count Heater EC Heat heating_need, _Heater Radiator Heat cooling_need, _Radiator In every other 'non-chemical' process where EC is consumed, Heat will be generated. This is not made automatic (albeit it could) to allow greater flexibility. All chemical reaction processes, instead, will either produce or consume Heat in relation of them being endothermic or exothermic in nature. A new 'heater' ProcessController module, and relative Configure setup, will be added to manned pods. Stock radiator modules will be removed without mercy, and replaced with 'radiator' ProcessControllers instead. Planner changes A new panel is added, to convey informations about Heat generation and consumption, according to the body/situation/sunlight environment as specified in the planner ui, and the simulation of rules and processes for the vessel in the editor. Monitor changes The telemetry panel in monitor will show the internal atmosphere temperature, as determined by the level of Heat stored.

@babale There should be no issue with any custom tech tree, as long as it is a super-set of the stock tech tree. Because parts and setups are unlocked by stock technologies. 1) Water use the same definition as in CRP, so it is the same resource. Ammonia on the other hand isn't defined in CRP at all (it use LqdAmmonia instead). So I guess you will get both Ammonia and LqdAmmonia in your game. I added Ammonia instead of using LqdAmmonia myself, to comply with my own convention that resources have to be defined at STP, and that the different matter-states of a substance don't have to be represented using different resources, but rather by manipulation of the storage properties of the containers storing them. I think these are reasonable conventions. Many CRP resources follow the same conventions, but not all of them. 2) I never used KSP-I, but I guess that anything that doesn't require MegaJoules directly can work with other EC producers. 3) The stock resource harvester module is supported, in the sense that I simulate it ad-hoc when the vessel is not loaded. Any mod using that module will work coherently with the rest of the background resource simulation. So if the two mods mentioned are using ModuleResourceHarvester, you should be good.