• Content count

  • Joined

  • Last visited

Community Reputation

56 Excellent

About TauPhraim

  • Rank
  1. If you accept inaccurate results regarding the external factors, just launch the vehicle and check the numbers on the launchpad. It sure would be more convenient to have that in-VAB, but currently I estimate the convenience/work ratio not big enough, sorry.
  2. Also you have to get much closer to see the tube specific buttons appear, than for Disassemble.
  3. I gave it some thoughts. But there are a number of missing things in-VAB compared to in-flight (planetary bonuses, surrounding vessels, ground resources concentrations ...) that would both make implementing this a bit bothersome, and render the results not so useful.
  4. They do research as in, contributing to increasing MKS bonuses for planets they reside on. And collecting science via MKS parts that offer a "Check Kolony Rewards" button. But they don't work in stock science labs.
  5. It should be, I just checked the code. Are you sure you had "Local Warehouse" enabled on the EU tanks ?
  6. With this new version, (where I generate a random ID for each contract instance to keep vessel groups separate), I am now having issues with PartValidation: On contract generation/acceptation, the parameters are displayed correctly: "Vessel having part X" + "At least 1". But as soon as I focus on a vessel, even one without the part, the PartValidation parameters all complete. Also the "At least 1" line disappears, but I don't know if this is a consequence of the parameter completion, or the cause of the problem. Exceptionally, the "At least 1" line will remain, and the contract work as intended. But this is very rare, and seems random.
  7. No, you have to make sure Fert(G) us displayed after the =>, AND click on the button. The converter name on top should then show "Fert(G)"
  8. Let me rephrase it without confusing arrows "Fertilizer (M) => Fertilizer (G)" switches converter #1 from converting minerals into fertilizer, to converting gypsum into fertilizer. In the VAB: to get the one you want, click until the desired one is displayed on top. In situ, each change will cost you material kits etc, so you want to use the next/previous buttons, so that the change button directly does "whatever => desired_converter". Sorry if it's not clear. Please post a screenshot in this case, and I'll try to use real names/examples.
  9. This bug will be fixed in the next release. It should only happen if you don't have USI-LS installed. In such case, greenhouse and habitat are useless anyway, so you can just not click on that. This means the part has 3 configurable converter "slots", and the buttons are for configuring them (Ex: "switch converter #1 from minerals->fertilizer to gypsum->fertilizer").
  10. There is a bug (also with some of the classes). A fix is coming. Actually, currently the random button gives you a male, male gives you a female, and female gives you a random. That's for portraits though, but the first name of the kerbal is apparently always random (with or without the fix). If we pretend, after several thousand hours passed with them, to understand Kerbal culture enough to distinguish female and male first names, then indeed this randomness is problematic. Please log a github issue if you confirm that, as a fix would be slightly more complicated.
  11. I tried a new version, abandonning the idea of fixing the last problem (assuming that when you accept the contract, the first vessel that you manage to get to the origin conditions is the one you implicitely choose for the contract). With that, I now have a problem when having several instances of the contract (with different vessels and origin/destination). It seems objectives complete for the wrong vessel (I can detail a case when a contract unexpectedly completes). I think this comes from the "define" identifier being the same, as it works across contracts according to the doc. Do I need to generate a random identifier for each accepted contract instance ? If so, can I use the Random() expression ? (it seems to generate integers).
  12. After confirmation with RD: it's intentional that hab modules don't get the regular bonuses from MksModule (like geology*botany etc). hab is benefiting from a slightly different dedicated system: the kolonization bonus ("rep boost") is used, only once (not squared), and adds to the multiplier of the whole vessel. Ex (I think): if your kolonization is 120%, and you hab multiplier would be x3, you get x3.2 multiplier instead For #1 we'll probably do something so that the MksModule aspect does not show up in VAB, when it does not apply like here For #2 I could give a shot at including Hab in MksExplainer, but the calculations are extremely complicated, this might take some time
  13. Yes, thanks ! I thought ckan was just unzipping (potentially stripping a heading GameData at best). So does it take the first folder it finds in the zip named ModName, and ignores all the rest ?
  14. What happens currently (with or without disableOnStageChange) is: 1) Vessel A arrives at BeAtOrigin - this completes the parameter, and locks it to complete and to Vessel A. 2) Vessel B has a hitchiker, is at Origin, but the contract is locked to Vessel A and won't accept vessel B
  15. Yes, I think trusting the player at some point is reasonable (there are much easier ways to cheat in KSP anyway). I'd just be a bit disappointed if, with all these options and parameters, achieving something robust was not possible. You're right about the second part (if that's what you mean): the first vessel that gets at A will complete the first VPG, locking it to that vessel. Any other vessel will apparently not be considered after that. Unfortunately adding disableOnStageChange=false to the BeAtOrigin, and even to VesselParameterGroupDefine in addition, does not seem to change that.