Jump to content

nightingale

Members
 View Profile  See their activity

  • Posts

    4,137

  • Joined

  • Last visited

 Content Type 

Everything posted by nightingale

  1. nightingale
    Could be one of two things: It is indeed a setup issue with the disableOnStateChange. I'd have to see the contract to say more - can you give me the name of it and I'll look it up in the RP-0 repository? A bug/limitation with the vessel tracking. Right now it'll keep tracking the ship that keeps the original root part of the vessel. I've been thinking about some changes to this system for 1.8.0, but haven't really looked too closely at it yet. If you built your ship "upside-down", this could be the problem. Can you still switch to the spent booster and see if all requirements are green for that one?
  2. nightingale
    Yup, that's exactly how it works. To expand, if you have define=Something, the ship that meets the conditions will get assigned the label "Something". If you have vessel=Something (in the same or a different contract), it will require the vessel to have previously been labeled as "Somedthing".
  3. nightingale
    I've updated the documentation. Hopefully it's more clear now for those who will come after.
  4. nightingale
    The other type are completed contracts, so yes, uniqueValue also tests against completed contracts. Using KSS as an example, activeUniqueValue would be, "I want this contract to be able to show up multiple times, but for different stations.", whereas uniqueValue is "I want this contract to only be completeable once per station." Another way to think of it - activeUniqueValue works like maxSimultaneous, uniqueValue works like maxCompletions.
  5. nightingale
    Haven't looked at the actual setup of those contracts, but HasCrew works for EVA Kerbals, so is probably your best bet.
  6. nightingale
    Noticed that exception and raised an issue to have it fixed, but didn't mention it as it's just a problem with the debug window (it's not even an exception with the same contract). So shouldn't be related to your issue. I'll also do some more playing around with this at home and see if I can reproduce it. Actually, if you can provide your save file I can just pull the contract's current state out of there - it might help me figure out why it's stuck.
  7. nightingale
    No problems in the log file. What happens if you re-enter the station and EVA again (please provide screenshots of the contracts+ window). What about if you switch back and forth from the EVA Kerbal to the station?
  8. nightingale
    That's incorrect - Contract Configurator never requires the vessels to be given a specific name (it will track it under the 'Soyuz-4' label, but display whatever name the player gives it).
  9. nightingale
    You'll be waiting a long time - not something I'm planning on doing.
  10. nightingale
    The REQUIREMENT shouldn't have anything to do with it. Are you able to provide a KSP.log file? I wasn't able to reproduce this one. - - - Updated - - - You want something like this: lat = @/WaypointGenerator1.Waypoints().ElementAt(0).Latitude()
  11. nightingale
    Sounds like an RSS problem, but I can't say much more without the full stack trace.
  12. nightingale
    Yup, that's a change from a while back, I now use the new module manager method for reloading contracts (which means if you do a module manager reload, it will also reload the Contract Configurator contracts). You can't get coordinates out of the SpawnVessel (but you can just reference the attributes within it). Just do something like this: DATA { type = double lat = Random() * 180 - 90 lon = Random() * 360 } And then put those coordinates in for your spawn vessel. Of course, the method above is a bit silly, because it'll generate far more coordinates near the poles. You can instead generate a waypoint using SpawnWaypoint, and use @waypoint.Latitude() and @waypoint.Longitude() to get its location. Or Yes, you can't nest behaviours like that, it won't do anything (and hopefully it'll output some warnings in the log). Aside from that, SpawnPassengers is for spawning passengers (like tourists) on the launchpad. You want to look at the CREW node in SpawnVessel. Nothing like that is supported. Raise a feature request and I'll look into it when I can.
  13. nightingale
    I found a minor bug where the timer text doesn't update (only affects the stock window, Contract Window+ is fine). In the background, the timer is still ticking down. I suspect that's the problem. Give a the dev version a try and see if that fixes the issue. - - - Updated - - - Assuming the RSS config is all correct, and the RP-0 contracts are all correct, then do a search for Eeloo in your persistence file and change it to Uranus. This assumes that the problem was a bug in the contract that someone has since fixed, and you've got something leftover in your save causing a problem.
  14. nightingale
    Looks good to me. The other approach is to use a Waypoint, but I think what you did is probably the simplest option.
  15. nightingale
    Definite no on that one, rather tricky to do.
  16. nightingale
    The first one will stop the parent parameter (orbit) from completing until the timer reaches zero. The second will start the timer after the previous sibling (orbit) completes. It becomes significant when used with the disableOnStateChange attribute - the first one allows you to specify the player hits and orbit, keeps it for the duration, and then move on to other parameter (like the ReturnHome). - - - Updated - - - New version out, with a few bug fixes. Download now! Contract Configurator 1.7.7 Fixed issues with PartTest parameter not making the "Run Test" option show up on parts to be tested (thanks Sticky32). Fixed issue with double() and other cast functions not working when casting from a non-numeric type (thanks chrisl). Fixed issue with disabled contracts not actually staying disabled (thanks DeCi & Svm420). Additional fixes to Duration reset issues (thanks chrisl). Additional error handling in string parsing for expressions.
  17. nightingale
    I have a very basic version (one contract, requires Figaro) right now. I've wanted to rework it to be a bit more generic (remove the figaro dependency), but it hasn't been a high priority. If anyone wants to work on it, I'd be happy to provide the files.
  18. nightingale
    Okay, raised [#330]. The plan is to introduce a small delay before allowing the state to get reset - that should cover off any scenarios where the states of the other parameters are still in flux. Still planning for 1.7.7 to go out tonight with this change - we'll see if I can hit that or not.
  19. nightingale
    Can you provide a link in GitHub to the actual 3/LEO contract (or paste the relevant content here)? That'll help me dig a bit deeper.
  20. nightingale
    Let's see: Remove the "define = Spaceplane", you only need/want that if you're planning on having a follow-up contract that targets this exact vessel. That'll get rid of the "Spaceplane (new)" part. You can't removing the grouping though - just because that's how it tracks all the child parameters states across vessels. For the sub-objectives of the "Take off from the runway" parameter, those are there because I try to default to giving the player as much information as possible (it's more relevant if you have stuff like an altitude or speed requirement). You can turn that off in ReachState by setting "hideChildren = true". Also, just realized you're going to have to change your ReachSpace to a ReachState. I need to document the ReachSpace better, but it's a progression based parameter that will turn true once the player reaches space for the very first time. So it's only useful in a very specific situtation (maybe I should get rid of it completely, it's so situational).
  21. nightingale
    The first way is almost 100% the way I would recommend. The completeInSequence on the very first element is redundant, but won't affect anything if you have it in. The second way uses a feature (vessel saving/tracking) that I'd always intended for inter-contract tracking rather than intra-contract tracking - ie. doing multiple contracts with one vessel. It's not wrong per se, but I think it ends up being less clear to the players than if you can do it all in one VesselParameterGroup (so I recommend that whenever possible). Also, the last two would need to be "vessel =" instead of "define =" to work properly.
  22. nightingale
    This thread's fallen into disuse, but I'm still fine with questions here or in the main thread. I'll see them either way.
  23. nightingale
  24. nightingale
    I thought there was something to get the biomes for a celestial body, but couldn't find it. Raised [#329]. I'll try to get a release out tonight or tomorrow.
  25. nightingale
    They'll keep showing up, so you don't have to worry about doing them right away. And once you do them once, they won't show up again.
×
×
  • Create New...