ShotgunNinja

Thanks everybody for the feedback and the bug reports. I really appreciate that. I wrote the bugs down and will go through them one at a time in the next days. Now I will reply to some of the comments, but I will go back on others in some time. I tried to come up with a 5th ECLSS module... found nothing interesting to add. So if anybody has some ideas about other ECLSS modules I would be glad to consider them. Putting aside if the transmission rate, transmission cost or data size are unbalanced. Why you want to transmit data instead of recovering it? Because you can't or don't want the vessel to return home. You can design the mission completely differently if you have the luxury of not having to return. With the same mass then, you can go farther or do some more involved missions anyway. Why you want to analyze the sample in place, instead of recovering it? Because you are on some kind of permanent installation somewhere. That is where the lab belong, not on 'lab hopper' things (I hate those). I agree 100%, I'll test some new numbers for high-quality. I was worried about increasing mass too much, so went very conservative on it. Totally, this! Although, having your hard drives fail would suck. The thing is, you can't make redundancy here. If it fails while holding your data, you may aswell delete the probe and launch another. Backups would be an option, but... Well, I don't think it would be fun to have the one component fail which holds your mission's essence, with no real way to work around it or account for it. At first I implemented limited storage per hard-drive. The data was also stored locally in a specific hard-drive (instead now it is stored per-vessel, and the HardDrive module act just as an user interface). That didn't work too well for various reasons: there was the chance of losing data for lack of capacity when for example an EVA kerbal board or two vessels dock (losing data is not fun) the user has no way to plan around the storage capacity aspect, mostly because he doesn't have any way to see how much data it will have to store, etc... being forced to add a pod (or a probe core) to store some extra data, or even a dedicated parts (like eg: a little hard drive) is not that interesting

It's Mars that is calling us.

Version: 1.1.5-pre5 Require: KSP 1.2.1+, ModuleManager 2.7.5+ Download: github Changelog (from 1.1.5-pre4): fix: Nvidia rendering issue (for real this time! thanks to all the testers ) fix: extreme slowdown on scene changes (oops) fix: spurious signal warning messages on scene change caches are only cleared when a new savegame is loaded destroyed/recovered/terminated vessels are purged from the cache identify savegame by unique id Previous changelogs

@jo_jo_binks Press ALT+N, I'm still looking for a better way to manage that body info window.

Ok guys another try for the Nvidia issue: download this zip file, open it. There is a single file in the zip. Put that file inside Kerbalism/Shaders (replace when prompted). @SavageAngel, @nosscire, @paulbrock

This is very useful. @lordcirth I can't replicate the timewarp issue. I created a simple vessel, with a single tracking panel. Then I cheated it in orbit and run the game at max timewarp until Jeb started earing voices.

That entry in the planner originally only showed if you had an engineer on board. Could use some work. Send me the savegame please. Stopping timewarp sometimes is not enough. To go from 100000x to 1x, the game blend the speed. By the time the blending end, in-game a lot of time would have passed (eg: 20 minutes). That is why sometimes when it stop it is too late. If I do not blend the warp speed, then the vessel orbits change a bit (don't know why). It has been mentioned a few times already in the last pages. When resources are consumed in background I am effectively using the equivalent of ALL_VESSEL, that take the resources from the first container it find (usually the pod). I will try to simulate ALL_VESSEL_BALANCED instead, in a future version. This limitation was always present from the first release. Thanks a lot for the report, I have a clue what's happening. @SavageAngel, @paulbrock Ok thank you guys. I'll see what else I can try.

@AVaughan UnlinkedControl values and what they do: 'none': unmanned vessel is bricked as soon as you lose signal 'limited': the exact same control limitations as in CommNet 'Limited control' applies 'full': the vessel can be controlled, and the only consequence of loss of signal is that science data can't be transmitted

@N70 Not yet, I am working on updating the wiki. I'll give you some early documentation now: Antenna type: one of 'low_gain' or 'high_gain' cost: cost of transmission in EC/s rate: transmission rate at zero distance in Mb/s dist: distance at which rate drop to zero, in meters Comfort bonus: a string representing the bonus, valid values are: 'firm-ground', 'not-alone', 'call-home', 'panorama', 'exercise' desc: a short description to show on the part tooltip Configure This is rather complex, see how it is used in Default.cfg for now. Emitter radiation: radiation emitted (or absorbed if negative), in rad/s ec_rate: EC consumed per-second when active toggle: true if it can be activated/deactivated active: animation to play when going from disabled to enabled, and viceversa GravityRing ec_rate: EC consumed per-second when active deploy: animation to play when going from disabled to enabled, and viceversa rotate: animation to play on loop when enabled Greenhouse Too complex to describe here, see how it is used in Default.cfg and in Classic.cfg for now. Habitat volume: internal volume in m^3, if not specified it is deduced from the part bounding box surface: external surface in m^2, if not specified it is deduced from the part bounding box inflate: animation that represent inflated habitats, will be still-played from current pressure in the habitat toggle: true if it can be enabled/disabled HardDrive No options. Harvester Too many options to describe here, check Default.cfg Laboratory ec_rate: EC consumed per-second when there is an analysis going on analysis_rate: how fast the data is analyzed in Mb/s researcher: the trait of the crew required for research and their experience level, in this format: Scientist@3 PlannerController toggle: true if there should be a toggle in the VAB part ui considered: true if the part should be considered as soon as it is added to the vessel ProcessController resource: the pseudo-resource that this module will control title: short name to show on part ui desc: short description to show on part tooltip capacity: how much of the pseudo-resource is controlled by this module toggle: true if it can be enabled/disabled Reliability type: name of module associated mtbf: meat time between failures, in seconds repair: trait and experience level required for repairs, in this format: Engineer@1 redundancy: a string representing the redundancy group this component belongs to (you can use arbitrary ones) extra_cost: cost added when quality is set to high, in space-bucks extra_mass: mass added when quality is set to high, in tons Sensor type: one of 'temperature', 'radiation', 'solar_flux', 'albedo_flux', 'body_flux' pin: animation that will be set from the readings value, if specified

With this last update I think to have annihilated all bugs reported until now (that is, if the Nvidia issue is confirmed fixed). I will let this sit for a week to get other bug reports eventually. But now I'm more interested in balancing issues. In particular, I would like some feedback on these: component failures: are they too infrequent? or are your vessels plagued by them? ECLSS modules in pods: is it interesting to have them configurable? or it will be better to have all of them in all pods? data transmission: are the transmission times too short? too high? what about the EC cost? extended antennas: should I revert to assuming that they are all extended? or should I leave it configurable but default to false? ISRU: would like feedback about the chemical processes from somebody with some Mun/Duna project going on And of course anything else not in that list. That's it, have fun.

Another experimental version, maybe the last one. Still potentially unstable and unbalanced. Please report bugs and balance issues. Version: 1.1.5-pre4 Require: KSP 1.2.1+, ModuleManager 2.7.5 Download: github Changelog (from 1.1.5-pre3): fix: Nvidia rendering issue (hopefully, need confirmation from an Nvidia user) fix: avoid confirm popup getting stuck when the science dialog is closed by game events fix: do not render signal lines when Signal is disabled fix: do not render anything in space center view, irregardless of MapView.MapIsEnabled value fix: force refresh of VAB UI when quality is changed on a Reliability module fix: force refresh of VAB UI when setups change on a Configure module balance: reduced atmosphere leak rate balance: slightly increased pressure control capacity balance: 1.25m lander pod now get 2 ECLSS module slots balance: reduced processing capacity of big ISRU chemical plant Changelog (from 1.1.5-pre2): fix: missing resources in parts that are using Configure module fix: exceptions thrown by Reliability module in some circumstances Changelog (from 1.1.5-pre1): data UI show experiment body/biome/situation data recorded is now clamped to max available for that experiment situation scaled down experiment data size a bit, randomized the values hijack data from any science container, not just ModuleScienceExperiment use buffering in data transmission to avoid triggering OnScienceReceived event too much fix: combinatory explosion in Configure module symmetry handling fix: resource duplication in Configure module fix: support multiple pages in science dialog fix: analytical sunlight issue during timewarp blending fix: remove drive on PartDie, instead of PartDestroyed Changelog (from 1.1.4):

@APlayer I could prevent retracting altogheter if that is the last extended antenna... but it will require hacking ModuleAnimationGroup, that I'm currently using to control the extended state. I could even remove the requirement on antenna being extended. I kind of like it, however. Another option may be to treat all low-gains as extended even when they are not extended. Throughts?

@The-Doctor See it in this way: Nitrogen is a resource you use to improve quality of life, Ammonia instead is the fertilizer you use in greenhouses. Both are also used in ISRU processes, later on in the game.

This was possible in 1.1.4, but in the new version the Settings are parsed before MM patches are applied. It was necessary for the feature detection machinery, but I agree it is not ideal. I fail to see how this could be caused by Kerbalism. They are 5, 25 and 125 Kg respectively. You think that's too low? Seems related to the above : when docking/undocking two vessels that have varying SAS levels, the SAS levels aren't updated (they stay the same even if they shouldn't). Again, is fixed by reloading the vessel. I was not able to replicate the first problem (didn't even try the second one). Question: does this happen with Signal, or with CommNet? If the former, I don't see it happening in my case. In the latter, probably a bug in CommNet itself (as I'm just querying the connection status from CommNet, no changes on its mechanics). Oh I'll check That is intended. Provide them with pressurized habitat and it will go to 100 days. Then give them all the comforts and it will go to 1000 days. Finally provide 40 m^3 of habitable volume for each crew member, and it will go to 10000 days. Antenna need to be extended to work (can be disabled in Settings, set ExtendedAntenna to false). Yes. 2 ECLSS modules for each manned pod. The Pressure Control is not vital, but you want it in general for the quality of life bonus. Also note that these ECLSS modules can fail. So you want redundancy on long-term missions. Absolutely. I would have to check the numbers (write them some time ago...) but more or less they are good for 4 crew members. The pressure control too has ample capacity.

@mrZonke What I did was define atmospheric resources (and their abundance levels) based on this. Then I added some crustal resources: water in a specific Mun crater (with 100% chance, irregardless of game difficulty setting), water on Duna polar region (just like CRP was doing, but again with 100% change of finding it), and water on Eeloo (as a Pluto equivalent). Ore I left as in stock, and other crustal resources are of no interest at the moment. There is no need to change GameSeed.

An hotfix for the missing resources issue. This is an experimental version, potentially unstable and unbalanced. Please report bugs and balance issues. Version: 1.1.5-pre3 Require: KSP 1.2.1+, ModuleManager 2.7.5 Download: github Changelog (from 1.1.5-pre2): fix: missing resources in parts that are using Configure module fix: exceptions thrown by Reliability module in some circumstances Changelog (from 1.1.5-pre1): data UI show experiment body/biome/situation data recorded is now clamped to max available for that experiment situation scaled down experiment data size a bit, randomized the values hijack data from any science container, not just ModuleScienceExperiment use buffering in data transmission to avoid triggering OnScienceReceived event too much fix: combinatory explosion in Configure module symmetry handling fix: resource duplication in Configure module fix: support multiple pages in science dialog fix: analytical sunlight issue during timewarp blending fix: remove drive on PartDie, instead of PartDestroyed Changelog (from 1.1.4):

Ok I see the problem with the missing resources in configurable parts. Sorry about that guys, I didn't notice it on pre2 release. I'll release a fix in the next hours.

Ok, tell me if that happen again in pre2. I will try to replicate, can you confirm me that we are talking about pre2 here? There was a fix for a resource duplication issue in the Configure module (used by the wet workshops). The KER thing... maybe it is redoing calculations only when the vessel change. But technically the vessel don't change when you switch setup in a Configure module. I'll try to force it to redo the calculations. No idea, probably not. It is the same as asking if 'fuel switcher A is compatible with fuel switcher B'. From my side, I'm only changing the resources described in setups, and not the others. So if these fuel switchers do nothing to resources not mentioned by them, you could have them cohexist in the same part to some extent. But that is unlikely, as code-wise it is much easier to just wipe clean a part of all resources. Why I developed my own, instead of using the existing resource switcher modules? Because I am also switching modules. Ok I'll try to replicate this. Maybe something changed about timewarp in KSP 1.2.x. Ok I'll have a look. Ignore the engineer report. Instead click on the 'heartbeat' icon near it, you will get access to the planner. I could add it... you can also do the same with a MM patch @PART[*]:HAS[@MODULE[Reliability]]:FINAL { @MODULE[Reliability] { @mtbf *= 1.0 } } Unfortunately I can't. Some of the settings need to be known before MM start patching things. And at that point is less confusing to have all settings in one place.

@Quodios Kerman When I will release 1.1.5 I'll update the OP. I don't wat to advertize the experimental releases too much.

@The-Doctor Sorry, I am working on rewriting the wiki. Meanwhile I'll give you some details of what Science does: replace the stock data storage system with one that: add and remove science data from a vessel very fast, even when the vessel is not loaded keep track of some extra properties for each 'file' stored (example: flag a file for sending or analysis) trivially transfer data between parts transmit data over time replace the stock laboratory with one that 'analyze' non-transmissible data, instead of magically 'multiply' it tweak stock experiment situations, science rewards and data sizes (similar to 'ScienceTweaks.cfg' in previous Kerbalism versions) try to not break stock/mods experiment parts in the process In the near future, it will replace how the stock experiments collect data.

This is an experimental version, potentially unstable and unbalanced. Please report bugs and balance issues. Version: 1.1.5-pre2 Require: KSP 1.2.1+, ModuleManager 2.7.5 Download: github Changelog (from 1.1.5-pre1): data UI show experiment body/biome/situation data recorded is now clamped to max available for that experiment situation scaled down experiment data size a bit, randomized the values hijack data from any science container, not just ModuleScienceExperiment use buffering in data transmission to avoid triggering OnScienceReceived event too much fix: combinatory explosion in Configure module symmetry handling fix: resource duplication in Configure module fix: support multiple pages in science dialog fix: analytical sunlight issue during timewarp blending fix: remove drive on PartDie, instead of PartDestroyed Changelog (from 1.1.4):

I finally found the cause of this. Funny stuff... turns out PartDestroyed event is called when a vessel goes out of physical range. I was using that event to remove the drive data in case a part exploded or collided... @elpollodiablo That is very strange. KSP mods technically can only cause a crash to desktop in case of infinite recursion (or if they segfault when dereferencing a pointer). @Zuthal No, the rule framework changed in the new experimental version. Those in the OP were written against the previous specs.

Ah okay. So I am assuming a GameEvent is registered in the set of available ones when its constructor is called, and when you call FindEvent<>() it will not find it if the constructor wasn't called before. Is that correct? I'm asking these question because I wonder about the scenario when monobehaviours from mod A and B are both set to run on main menu, and ordering problems.

Any drawbacks you are aware of, if the GameEvent is initialized in the static definition? That was it is guaranteed to be initialized before first use, be it a listener or the mod that fire the event. public static EventData<Part, ProtoCrewMember> onKerbalFrozen = new EventData<Part, ProtoCrewMember>("onKerbalFrozen");

@aluc24 Ah okay, I feel better already That nasty bug has been fixed in this new version (tm).