Epiphanic

That's incredibly well-thought out. Just wanted to give a suggestion to a potential future feature. Thank you.

I'll try my best to explain what I mean. Radiation doesn't stay forever. It eventually "breaks down". Half-life is the length of time it takes for something to halve from its original value. As an example, let's say Kerbal Health's radiation had a half-life of 1 year. If Jebediah had 16,000 bananas of radiation, he would have 8,000 bananas after one year, 4,000 bananas after two, 2,000 after three, etc. Assuming, of course, that he doesn't receive any additional radiation in the meantime. As far as how to implement it, it could be updated continually (like the current marginal health mechanic) or possibly something that is only triggered when a certain condition is met (e.g. unassigned at the KSC). I don't know very much programming so I'm not sure which method would be easier to implement or if it's something worth doing at all. I certainly don't want to make the radiation mechanic useless (it can already be simply turned off), but I do think it might be worth thinking about having a way for Kerbals to "recover" from radiation over time. Wikipedia article

I've been playing with Kerbal Health recently and would like to make a few suggestions for your consideration: Would it be possible to add trait icons on the health overview menu? On the right-click menu for parts that have health recuperation abilities it says "Toggle Health Module" (or something to that effect). Could that be changed show the status? Something like "Health Module: On/Off" on the right-click menu. If you choose to provide a way to reduce accumulated radiation in the future, I suggest a half-life mechanic. I've been quite happy playing with Kerbal Health in my current save in its current form so, no big deal if you can't or don't want to add those features.

@karamazovnew For what it's worth, @severedsolo has a part failure mod that is specifically designed to take advantage ScrapYard. Perhaps that has the features you're looking for. I hope I'm not out of line suggesting an alternate mod in a different mod's thread, but I just thought I'd suggest something that might work that already exists.

I'm not sure if the "wage" system is working properly. When I hire workers on the BARIS window on the Astronaut Center, the worker section reflects my new payroll. (by $100/worker -- as it should). However when those workers are "employed" during vehicle integration, the payroll summary goes to zero. A similar thing happens with Astronauts. If they are available for a mission, their wage is reflected, however if they are on a mission ("employed"), the payroll summary goes to zero. I also didn't notice my funds going down at all when the pay period switches. Although the default pay period is 12 days, I edited the Constants.cfg file to be 1 day. As far as I could tell no funds were deducted for wages at any time. The pay period summary also doesn't reflect the edited Constants.cfg for the new DaysPerPayroll value.

Thanks. They are level 0. I didn't know that Kerbal wages scaled with experience level.

I recently gave this mod a look and noticed a small bug (or graphical error). I had unassigned Kerbals costing $1000/month but the GUI predicted expenses line said $500/month. If I changed that particular slider in the settings menu the predicted expense line would update to exactly half of whatever the value was set at. I'm not sure if this is simply a graphical error or if the wrong amount is being deducted.

@jlcarneiro You can disable Kerbalism's science module by editing the settings.cfg file (set "science = false"). This will bring back the stock messages and allow [x] Science! and IndicatorLights to work as expected. This should result in using the stock science system rather than Kerbalism's vision for science. As I understand it, since Kerbalism's science module uses a new storage container (the hard drive) to store experimental data, mods like [x] Science! and IndicatorLights are "looking" in the wrong place so they don't get triggered.

Yes that's how it work now. I believe there's a small bug regarding this feature. I tried some quick missions with the science module turned off (Science = false in settings.cfg). The stock science dialog still doesn't come up. They run fine ([x] Science displays normal behavior), but the "Review Data" option in the right-click menu doesn't work. The button appears and then disappears once you click on it with no other window appearing.

@AVaughan : I figured that was the case with [x] Science. Thanks for clarifying.

I'm currently using the Dev Release build and there may be something wrong. When I go to the Astronaut Complex (in a vessel or EVA) the game recognizes the biome as Administration rather than Astronaut Complex.

I think there's an interesting (but unintended) interaction with Kerbalism and [x] Science!. When I run a Crew Report (or any other kind of experiment) it runs fine and is automatically put into the "solid state drive" in the command pod. (At least that's how I understand Kerbalism to work. It's a neat feature, by the way, as it minimizes the "data dance" to get store multiple variations of the same base experiment.) I think because it's being stored in this hard drive feature, [x] Science! doesn't realize it's actually been run if it hasn't been recovered/transmitted. It's not a major issue, but something I think is worth mentioning. Earlier in this thread other posters mentioned something about massive science multipliers. In my latest mission (a basic KSC rover collecting goo/temperature readings for the Field Research Contract mod), when I recovered the vessel I I recieved over 150 science points. I think it should've been mabye 20 or so (I failed to get a screenshot -- apologies for that omission). In previous missions where I just did crew reports science yields upon recovery were fine. I'm currently using the pre-6 build for Kerbalism.

Maybe a flag or a house?

No worries. You didn't come across as harsh. I just wanted to share my thoughts on trying your mod out. As the creator/maintainer you get final say to what gets put in or not.

Fair enough. I'd still make the argument that adding a storage bin shouldn't make the MK1 Command Pod cost about 5x as much. And at that point we're just arguing about what's a reasonable line to draw. I'm not sure why the original mod made the decision to price it that way (and I certainly don't expect you to change it), but I thought it was a bit much. For now, I'll just pretend that there was already a utility cupboard in all the pods and the Kerbals decided to just throw their junk in them in case they'd be useful. I just thought I'd share my simple config in case others felt the same way I did. If in a later version of this mod you make my personal adjustments superfluous, great! Thanks for all your hard work.

As I understand it, the scope of the mod adds the possibility of part failures and breakdowns with the introduction of a new resource (Spare Parts) to remedy those failures and breakdowns. I don't understand why the base cost of parts (no Spare Parts added) has to be different. I haven't changed anything with respect to the specifications of Spare Parts or any other defaults. If there's a gameplay rationale for why this mod should change the base costs, I'm interested to hear it.

After some trial and error I threw together a Module Manager config to bring the prices of command pods back to stock levels if no Spare Parts are loaded. The adjustments are based on the default price of Spare Parts in the in Dang It! and the total storage capacity of the command pod. Because the price changes are hard-coded, changing the storage capacity or price per spare part would mess it up. If others have a better way of doing it, I'd be interested to know. I'd figure I'd share it in case others want it. // Config to bring command pods back to stock base price for Dang It! // @PART[*]:HAS[#CrewCapacity[1]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 2520 } @PART[*]:HAS[#CrewCapacity[2]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 5040 } @PART[*]:HAS[#CrewCapacity[3]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 7560 } @PART[*]:HAS[#CrewCapacity[4]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 10080 } @PART[*]:HAS[#CrewCapacity[5]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 12600 } @PART[*]:HAS[#CrewCapacity[6]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 15120 } @PART[*]:HAS[#CrewCapacity[7]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 17640 } @PART[*]:HAS[#CrewCapacity[8]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 20160 } @PART[Mk1FuselageStructural]:FOR[DangIt]:AFTER[DangIt] { @cost -= 7560 } // Add to all cargoe bays @PART[*]:HAS[@MODULE[ModuleCargoBay],!MODULE[ModuleProceduralFairing],~name[RadialBay]]:FOR[DangIt]:AFTER[DangIt] { @cost -= 7560 }

Thanks for your help. I downloaded the mod and it appears to be working as intended.

Part prices are still way too high for my liking and (MK1 Pod is over $10,000 with no spare parts added). Personally, I'd like the parts that can hold spare parts (i.e. command pods) to be the same price as stock when they are empty and increase in price as you add the spare parts resource. I haven't been able to figure out how to edit the SpareParts.cfg file to achieve that.

I do not have CRP installed. Would I need that to make this Resource Definition config file?

I just downloaded Dang It! to try it out and it changed the MK1 Command Pod's cost to $15,000 (up from $600). I looked around the Module Manager configs and didn't see anything that would adjust it so much. The SpareParts.cfg only increases the cost by $3,150 (if I understand it correctly). There also doesn't seem to be a tweakable slider when you right-click on the command pod to adjust the number of spare parts. It's obviously a small fix by editing the Module Manager configs, but I'm still trying to figure out what to edit.

This is a pretty neat mod. I'm playing around with the templates to get a feel for it and I have a question. Do the variable names in [square] or <carrot> brackets have to be one of those "special variables" (engineType, vesselType, etc.) or can they be anything?

What suit pack is that? Those are sweet.

Has anyone gotten Kerbal Renamer to work with 1.2? I downloaded the zip file from the github and placed the resulting "KerbalRenamer" folder (the one with the .dll and .cfg files) in the GameData folder. I understand if this would need to be updated or recompiled for 1.2, I'm just curious to see if anyone has had success.

I noticed a potential error in calculation for Basic Orbit. I was in orbit around Kerbin with a apoapsis of 100(ish) km and a periapsis of 75(ish) km. The Semi-Major Axis measurement was listed as 700(ish) km. I would expect it to be nearly 90 km, no? Edit: Upon further reflection, I think I'm incorrect. I forgot to add Kerbin's radius to my apoapsis and periapsis altitude. That would explain the discrepancy. Space math is hard.