• Content Count

  • Joined

  • Last visited

Community Reputation

2,818 Excellent


About severedsolo

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

9,396 profile views
  1. Pood and I hashed this out this morning. There is an edge case where Resize and Rescale could be different values and WCIG would fail hard. I've chosen to take the easy route and WCIG will just refuse to do the calculation where that occurs.
  2. @etmoonshade It's expecting an int, so passing it a float/double is making it fail. @Poodmund mentioned this to me this morning too, I'll be patching it to accept doubles shortly.
  3. Sorry, afraid not. You can add kerbals that have the same stats/name with the cheat menu, or you can just start a new game. Alternatively, you could try start a new game and copy their entries into your save from that one (remember to back your save up first) I haven't played with 1.10 yet, but apparently there was something in there about vets no longer disappearing from the roster when they are fired, they may be in your applicants.
  4. @Strych74 - not a bug per se, more a limitation of the system/design choice. I'll save you the boring technical details, but basically: anything that uses AddScience rather than the experiment system (contracts, KCT's science system, Bureaucracy itself) won't be intercepted. Because Bureaucracy also uses AddScience it's *really* easy to get stuck in an infinite loop - so it just leaves it alone. Contract science is usually a handful of points, so I'm pretty comfortable with letting it slide.
  5. Ah, much appreciated! Means I can stop doing loading order shenanigans with Bureaucracy
  6. Yup - quadrupling is still needed - the patches assume that you've got that setting on (can confirm they are correct, as use JNSQ myself)
  7. *unhelpful post is unhelpful - you've been warned* I noticed this myself yesterday while testing my Mun Lander in JNSQ. You can eliminate Persistent Rotation from your list of suspects as I don't use it. I put it down to "Frankenbuild" on my part (I'm using mods for lots of different versions for KSP which may/may not be supported in 1.9). I actually put it down to the 1.9 version of Kopernicus at the time, but haven't really had time to do a proper troubleshooting session. LGG - not expecting you to do anything with this, I'll try and make a proper reproduction case later/over the weekend and do a proper bug report if it's KRASH.
  8. As far as I know there isn't, but if you were looking for a "my first mod" project, this would be a super simple thing to code.
  9. That's fair feedback. Honestly, like I said, I didn't test existing saves at all and that post was more "This is what I think I changed" (obviously I was wrong!) I appreciate taking the time to figure it out though, I will add your instructions to the OP a little later for anyone else who comes across this issue.
  10. @Mercor 4.0 was a save breaking change. In general, if the major (first) number changes, I've made a serious change and the changelog should be read very carefully.
  11. Appreciate the attempt to help - in theory doing this is exactly the same as referencing @/targetBody1 (just tested and got same behaviour, in case it was a workaround). The DATA node shouldn't really be re-evaluated at all if it scores a "hit" - usual behaviour would be for CC to evaluate the DATA node to see if it can generate a *new* contract, rather than re-evaluating an already generated one.
  12. @nightingale - welcome back! Seeing an issue where a DATA node using CelestialBody (and possibly also due to it using SelectUnique()) is not "locking" the contracts on a successful roll and is reevaluating and withdrawing the contract instead if another body in the list of candidates can't satisfy the REQUIREMENT. Contract that reproduces the issue (used PasteBin as I'm about to hide the issue in E+ by adding another parameter to the list) Test Case: Mun has been orbited and a return from orbit has been completed, Minmus has been orbited but not returned from. Expected Behaviour: A "return from Minmus" contract should be offered and not withdrawn. Actual Behaviour: Although a "return from Minmus" contract is offered, it's withdrawn when the DATA node is re-evaluated. My suspicion is this is because the DATA node contains two candidates, Mun and Minmus - but only one of them satisfies the requirement node: You can see the Body is being switched to Mun in Mission Control as the requirement test changes to "Must not have returned from orbit of Mun" OrbitedBodies().Where(b => !b.IsHomeWorld()).SelectUnique() REQUIREMENT { name = ReturnFromOrbit type = ReturnFromOrbit targetBody = @/targetBody1 invertRequirement = true } What I believe should happen, is once a contract has successfully generated, it should be left alone (ie CC should consider offering a new contract if Mun also meets the requirements, rather than re-evaluating the Minmus one) Suspected Root Cause: The List<CelestialBody> contains two valid candidates, but only one of them satisfies the REQUIREMENT node. Presumably this will get worse as the player reaches more and more bodies, as the ratio of "good" candidates vs "bad" candidates will get slimmer and slimmer. Workarounds: Make it so the List<> can only have candidates that satisfy the requirements. Ideally of course, I'd like a "HaveReturnedFromOrbit" method for CelestialBody() but this will hide the issue, rather than fixing it. Log:
  13. Nope, it will come back if you haven't done a rendezvous, but other than that, you can safely ignore it if you want
  14. Agena is created when you perform a rendezvous. That contract needs a rework anyway, as it's possible to get it into an unworkable state if you perform a rendezvous without a docking, but the current completion path is Rendezvous two vessels > Immediately dock them. Unfortunately not, E+ reads the stock progression nodes, which can't be reset without some serious save game pruning, or starting a new game.
  15. That's a bug that's been fixed for a long time. - if it comes up again definitely report it with logs etc though. That doesn't sound like unexpected behaviour to me. A safety rating is relative. Running the maths (and assuming you haven't changed the patches) baseChanceOfFailure = 0.11 (we'll use this as initial failure, as it's Gen 1 so no generation modifiers, so I can skip part of the math) expectedLifetime = 6 (assuming it's a lifter engine) chanceOfFailure = CalculateInitialFailureRate() * (SYP.TimesRecovered / (float) expectedLifetime) 0.11 * (1/6) = 0.11 * 0.166666667 (rounded) = 0.018333333 SafetyRating is relative, safety rating 10 = 10* less likely to fail than a safety rating 1 part. Safety Rating 8 = a failure rating of about 0.022+ This is broadly in line with expectations, as test flights are supposed to iron out the kinks in a part, and a part on it's second flight is always at the top of the bathtub curve So Rating 9 is correct, but it's borderline Rating 8. As for the "failed part also got better" - OhScrap doesn't differentiate, if the vessel is launched, all parts get the buff. There is code to have a failed part do a saving roll to see if it's recovered (ie if it's not fixable, let ScrapYard drop it) - but I'm not entirely sure that's working (Trash Part is not working either according to reports I've heard)