Jump to content

nightingale

Members
 View Profile  See their activity

  • Posts

    4,137

  • Joined

  • Last visited

 Content Type 

Everything posted by nightingale

  1. nightingale
    Looks okay to me (Edit: I swear it's accidental that Gene's agreeing with me in the screenshot...): Expiration is when an offered contract will no longer be available to be taken. Deadline is how long you have to complete an active contract. All the ones in the RemoteTech contract pack have a deadline of "Never". If you still do want to mess around with it, check out the Contract Configurator wiki, specifically the CONTRACT_TYPE node. Here's the attributes related to contract expiry/deadline:
  2. nightingale
    Let's see, with lazy counting including whitespace, comments, etc.... 102. Actual statement count is probably more like 4 or 5 dozen. Supposed to, let me know if there's issues anywhere and I may have to up the lines of code by 3 or 4...
  3. nightingale
    If only that were true.... It was *surprisingly* difficult to get this to look right.
  4. nightingale
    Need the full log file please. What those errors mean is that the RemoteTech integration code failed to load for some reason - the error for that should've been further up in the log. I see you're on Contract Configurator 0.5.2, but can you confirm your RemoteTech version for me? - - - Updated - - - Nevermind the logs - the latest 1.6 build of RemoteTech broke it again. - - - Updated - - - Found the issue - they changed some namespaces. I can't fix it without breaking support for 1.5.2, which is their current stable release. Until further notice, Contract Configurator doesn't work with pre-release RemoteTech - I'll release the fix once their 1.6 branch gets officially released as stable.
  5. nightingale
    It's up on CKAN now too.
  6. nightingale
    Wider Contracts App is obsolete, as it has been integrated into Contract Configurator. Description This mod takes the stock contracts app and super sizes it, increasing its width by 60% (and doubling its default height). Before After Download CKAN: In CKAN, Select and download the mod "Wider Contracts App" GitHub: Download here Source The full source is available on GitHub. Change Log FAQ Q: That's nice, but 60% isn't enough. A: Kerbal scientists are hard at work at an 80% bigger contracts app, but are running into issues as they start getting close to theoretical atomic contracts app limits. Q: No, really - I want it bigger. A: Have no fear! We plan on releasing different flavours of Contracts App resizing mods for all tastes. Look out for releases of Wider Contracts App 6.4x and Wider Contracts App 10x. It's entirely possible we're thinking of a different mod though. Q: Fine, just make it configurable. A: I'm considering it. Perhaps for Wider Contracts App Pro? Testimonials "Since deploying Wider Contracts App, I've seen a 50% increase in the number of mission commanders actually caring about their mission objectives. What's that? Oh, never mind... Jeb's on the roof again instead of on his way to Minmus..." Gene Kerman - Mission Controller "You did WHAT with the funds we gave you to upgrade the launch pad?!?" Mortimer Kerman - Finances Guy "Who are you? How did you get in here? Do you even work here? Wernher!! Help!!!" Linus Kerman - Intern "Kerbal is awesome!" * Elon Musk - CEO, SpaceX * It is assumed that Mr. Musk was referring directly to Wider Contracts App when he made this comment. License Wider Contracts App is licensed under CC-BY-NC-SA-4.0 Like what you see? Consider donating to the coffee fund! It will not go directly to supporting this or other mods under my care, but it may keep my motivation up!
  7. nightingale
    Contract Configurator 0.5.2 is out with a quick fix to a RemoteTech issue that affects the contract pack. Download it now! Contract Configurator 0.5.2 - Fixed issue with HasAntenna using ActiveTarget (was breaking the RemoteTech contract pack). Huge thanks to Bluemoon for pointing this one out. - - - Updated - - - Let me check out the spawned kerbal disappearing - that wasn't expected. The expiration time I knew about, but it's so low priority I never even raised it on GitHub. Now it's there, so at least I won't forget about it. That is awesome!! I actually read through that whole thread when I first started Contract Configurator, but forgot you'd posted that. It'll make my life much easier when I document it.
  8. nightingale
    Ah, when I finally got a chance to look at this, I see it's broken. I'd changed how some stuff works and never when back and verified this contract. Basically the Target: Kerbin and Target: Active Vessel are mutually exclusive and are not supposed to show up in the same parameter. It should only be Active Vessel. Contract Configurator 0.5.2 is up and fixes this issue. Thanks so much for brining this one up, be sure to let me know in the thread if you have further issues.
  9. nightingale
    Good stuff, nice to see there's people out there spreading the good word!
  10. nightingale
    Thanks, I was aware of it, but hadn't formally documented anything. Note that the prestige values are also applying a multiplier, so that a Kerbin trivial contract has a 1.0 multiplier. Basically, the way I tend to look at it is to just let the multipliers take care of it. In other words if you have two contracts that are effectively the same other than the target body, then just use the same funds/science/rep values. Or at least... use as a starting point. Jool has something like a 9.0 multiplier, which can really mess up your rep numbers.
  11. nightingale
    It sounds like you're new to RemoteTech - try checking out their Tutorials page.
  12. nightingale
    Cool! I'll put in a fix for that one.
  13. nightingale
    Version 0.5.1 is out, with fixes to work with the upcoming RemoteTech 1.6. Download it now! Contract Configurator 0.5.1 Fixed to work with RemoteTech 1.6 Hide text for fake Parameters related to OrbitGenerator in mission control on active contracts. Removed ':' from the Duration parameter default text.
  14. nightingale
    I tried it last night, and I can guarantee that it will break it! But the fix was easy and is already done. I just need to release it, which will be part of Contract Configurator 0.5.1 - you can expect that this weekend sometime, unless Peppie23 throws a curve ball and releases it before me (in which case it'll still be this weekend, but I'll be scambling to unbreak everything). Correct - but the real question is why? Completing the early contracts is not a dependency for getting the later ones offered, if that's what you were thinking. Although I just realized... Public Service Announcement: If you are installing this on an existing save with RemoteTech, the contracts will work - but the coverage system will need about two minutes either in flight or in the tracking station to fully initialize. Until then it will assume 0% coverage of all bodies - which means that the contracts offered may not be the ones you expected. New saves are not affected.
  15. nightingale
    The ": Incomplete" part is appended by the contract system, and I have no control over it. The pre-fine print stock contracts had a tendency to follow a <condition>: <value> (example "Alt: 1000m to 2000m"). I've tried to follow that convention in Contract Configurator, but you can override the title completely in 95% of parameters. Recently I've tried to be better in newer parameters (such as Duration) about giving the ability to set the text for different parts, to preserve the "count-down" logic, (which in my opinion in necessary to give the player the right feedback). Anyway, for the duration one... let me think about it. It may look a little cleaner without the ':', and if someone wants it they can type it into their text.
  16. nightingale
    Hey DMagic, I've got a couple bugs/requests for you. Head over to this post in the Contract Configurator thread for the background. When a parameter has no title (I assume the check is for null/empty), the stock contracts app does not display that parameter OR any of its child parameters. I rely on this behaviour to secret away and hide a parameter that needs to be there to display the orbits, but may not be desirable as an actual contract parameter. Would it be possible to do the same logic in Contracts Window + to be consistent with stock? In the stock app, when a parameter with child parameters is completed, it stops displaying the child parameters. To be honest the behaviour is annoying, but since I have to assume users are potentially using the stock app, I have many cases where I change the parameter title to show some details from the children when it's complete (so the user can still see it). This results in it getting displayed twice in Contracts Window +. So again - could Contracts Window + be changed to behave like stock (not because I like the behaviour, but for consistency). Thanks!
  17. nightingale
    Ah, gotcha. So there's a couple things here: There's logic to do a search and replace to hide the text in the mission window. It seems to work when the contract is available, but breaks when the contract is active. Bug, should hopefully be easy. The stock app hides any parameter where the text is empty, as well as hiding all child parameters underneath that. It also hides child parameters when the parent completes (which is another story). The Contracts Window+ window obviously doesn't do these things. My preference is to get the behaviour of Contracts Window+ changed to match stock. I'll throw this up in DMagic's thread and see where it goes.
  18. nightingale
    double.MaxValue, or in normal person speak, 1.7976931348623157E+308. Actually, it's more like sum(<all loaded contracts's weights>) must be less than double.MaxValue. Either way - pretty big. The weight is compared against all other ContractConfigurator contracts. So what you're setting is the relative priority. If you have two contracts, one with a weight of 100, another with the default of 1, then it's roughtly a 99% chance that the one with a weight of 100 is chosen when selecting a new contract to be offered. Do something like this if you have a contract that MUST be offered, but you should then do something like set maxSimultaneous or MaxCompletions so it can't show up many times. Similarly, if you want a rare contract that the player should snap up if they ever see it, you can do a weight of 0.1 or 0.01. Of course I could then come along and give my contract a weight of 10000, which means it'll pretty much always get chosen over yours. The best you can do is assume most contracts have a weight of 1, and then think in terms of how many times more (or less) likely you want it to be for your contract to show up.
  19. nightingale
    When you say that it does indeed have it once accept in the game - do you mean in the contract window (stock or otherwise, but please specify) or in the persistence file? Because of the way the orbit system works, the only way to get the orbit lines to render properly is to have a stock ReachSpecificOrbit parameter in the contract. Because I want to separate the behaviour and the parameter, I generate one as part of the behaviour, but wrap it in an special "AlwayTrue" parameter - which is always completed and invisible (at least, supposed to be). If you choose to have a ReachSpecificOrbit parameter in your contract, I actually create a different one under the hood that mirrors the parameter that was added for rendering. TD;DR: It's complicated under the hood and there could be bugs, but what you want to do is supposed to be supported. Actually a nice feature would be to do away with ReachSpecificOrbit and add support to "reading" the orbit into a HasOrbit parameter. It's not trivial though, so although I'll put it on the roadmap, there's no promises.
  20. nightingale
    Correct - it's meant to support vessel tracking *across* contracts (it's just a bonus that it supports it within contracts). So once the vessel is associated with that name, it's associated with it forever. Now, if you have another contract with "define = Same Name As Before", then it will actually associate a new vessel with that name (there can only be one vessel associated to a name, but a vessel can be associated to many names/tags) - but only once the vessel meets the VesselParameterGroup parameter. So if the old one is still out there, there's a possibility *it* could meet the ReturnHome parameter (or whatever it ends up being). So there's lots of little things to think about, but it could still work with name reuse. But safest is just to use unique names as in your example.
  21. nightingale
    To meet inner planets you can launch one satellite in Kerbin orbit and point it at Duna. To meet Mun coverage you need something that will cover the far side of the Mun. Which means getting 1-3 satellites in Mun orbit (or near Mun orbit). Higher dv requirement, and either multiple satellites or very clever design. But there may be some cases that the rewards need balancing - so I'm open to this type of feedback.
  22. nightingale
    disableOnStateChange = true should work for this, unless I somehow broke it in 0.5.0. A quick review of the code looks good - but I won't be able to test myself this until the evening. I thought I saw an issue with it - but it was because I thought you'd want it on the destination=Kerbin bit too. But you'd need to come back to return home anyway, so that part doesn't need to be locked down. I'll play with this when I can, see if there's a bug. - - - Updated - - - I need to document this part better. The "defined" name and the player-chosen name are independent. define= means "the vessel that meets this parameter shall internally be known under this tag" (I really should've used the term tag). name= mean "This parameter can only be met by the vessel that was previously tagged with this name".
  23. nightingale
    EDIT: as a troubleshooting step, I tried using disableonstatechange = true , but it hasn't helped. PARAMETER { name = ReachSituation2 type = ReachSituation situation = ORBITING disableOnStateChange = true } Still uncompletes after de-orbit burn Hmmm.... the best way to do it without any issues that I can come up with would be using the new vessel tracking feature: PARAMETER { name = Sequence type = Sequence title = Reach orbit of Kerbin and come back home PARAMETER { name = VesselParameterGroup2 type = VesselParameterGroup define = Kerbin Orbiter PARAMETER { name = HasCrew2 type = HasCrew trait = Pilot minCrew = 1 } PARAMETER { name = ReachSituation2 type = ReachSituation situation = ORBITING } PARAMETER { name = ReachDestination2 type = ReachDestination targetBody = Kerbin } } PARAMETER { name = VesselParameterGroup3 type = VesselParameterGroup vessel = Kerbin Orbiter PARAMETER { name = ReturnHome1 type = ReturnHome } } } Every other option I could think of seems to leave some gap or another (ie. reach orbit with vessel x, but "return home" with vessel y).
  24. nightingale
    Very much supported by Contract Configurator, and very much implemented in this contract pack. Here's a very brief summary of the pre-requisites for a contract to show up: Initial relay - <70% coverage of Kerbin OR does not yet have an antenna pointed at active vessel Mun/Minus - >70% coverage of Kerbin AND <70% coverage of Mun/Minmus Inner Systems Sat - <20% coverage of [Moho & Eve & Duna] Outer Systems Sat - <20% coverage of [Jool & Dres & Eeloo] Everything Sat - <20% coverage of [Moho OR Eve OR Duna OR Jool OR Dres OR Eeloo] Specific Planet Relay - 20-70% coverage of that planet (ie. have a dish with range pointed at it) Specific Moon Relay - 70-100% coverage of the parent body, 0-70% coverage of that moon Jool Relay - 20-70% coverage of anything in the Jool system. In additional, you need the appropriate tech unlocked (probe cores + power) as well as an appropriate dish (ie. you can't get a Jool contract without a giga range dish).
  25. nightingale
    Good point - the link now goes to the Contract Configurator thread.
×
×
  • Create New...