Jump to content

nightingale

Members
 View Profile  See their activity

  • Posts

    4,137

  • Joined

  • Last visited

 Content Type 

Everything posted by nightingale

  1. nightingale
    See [#420]. This functionality was actually introduced by KSP 1.0.5 - I just haven't exposed it through Contract Configurator yet. Can't really help there - the game doesn't track that.
  2. nightingale
    My recommendation is to base it off of the player's progression - that way even if your contract pack is installed in an existing save they will get offered contracts that are logical to where they are at. Also, same thing for if they skip a contract (maybe because it didn't get offered to them).
  3. nightingale
    First off, this: CONTRACT_COMPLETED_SUCCESS { type = List<CelestialBody> @/localPlanetFlybys = @/localPlanetFlybys.Add(@/unmannedMissionPlanet) $planetFlybys = @/localPlanetFlybys } Will not do what you want - you can't put expressions like that on the left hand side. What you probably want is: CONTRACT_COMPLETED_SUCCESS { type = List<CelestialBody> $planetFlybys = @/localPlanetFlybys.Add(@/unmannedMissionPlanet) } ... but that won't work either, for the following reasons: List.Add isn't actually adding it when the input list is empty. I've fixed that in the dev version. Lists aren't actually supported in the global variables. They're not explicitly not supported (which is why you don't get a nice clean error), but I'll need to write a bunch of code to make it work. Raise an enhancement request and I'll try to get it for you in 1.9.4
  4. nightingale
    See the Data Node documentation - there is an attribute called requiredValue on DATA nodes that defaults to true. Because $planetsFlybys is null, it stops the contract from generating. If you need it to still generate, then set requiredValue to false.
  5. nightingale
    Hard to say, the answer is complex. The number of files is not terribly relevant (I'd expect 100 contracts in 1 file to perform pretty much the same as 100 contract in 100 files). Less contracts is probably better, even if those contracts have complex expressions in them. So I guess I would say it will reduce the load on CC and KSP - but I don't know if I would say that the difference would be significant/noticeable.
  6. nightingale
    CONTRACT_TYPE { name = FirstUnmanned @STGUnmannedMissions:UnmannedMissionPlanet Flyby ... } Expressions are not supported in the contract type name.
  7. nightingale
    Nothing looks particularly bad there - toss up a full contract with a log into GitHub and I'll dig into this one.
  8. nightingale
    Same as before (sometime last week it came up, I think) - the data-type determination for $global variables is very limited. In this case, to hit it over the face with the type, you could try this: DATA { type = List<CelestialBody> impactedPlanets = $impactedPlanets } REQUIREMENT { name = Expression_3 type = Expression expression = @/impactedPlanets.Contains(@STGUnmannedMissions:UnmannedMissionPlanet) }
  9. nightingale
    The contract type name must be a static and globally unique string. No expressions allowed. Looks like what you need is an enhancement to CompleteContract where you could say something like: REQUIREMENT { type = CompleteContract contractType = FirstImpact_UnmannedMissionPlanet targetBody = @targetBody } Of course, that actually doesn't work well, because what ends up happening is the contract generator would pick a body and then fail the contract requirement (and end up very rarely generate a contract. So better would be: @targetBody = AllBodies.Where(cb => cb.ContractCompleteForBody(FirstImpact_Unmanned)).Random() If that's the way you'd like to go, raise an enhancement request.
  10. nightingale
    I know the stock contracts for recovery have a lot of smarts (it looks at planet radius, atmosphere depth and the highest peak), so you're set there. For Contract Configurator stuff... I'd just trust to the authors as Contract Configurator should give them the tools they need to avoid hard-coding altitudes and such.
  11. nightingale
    You've actually asked a really tricky question. I would actually be very careful about this, as a lot of contract packs already have fairly good support in generic fashion for rescale mods and planet packs with new planets. So trying to add on to that yourself could throw things off or break them completely. Anyway, I'll answer your questions and then give you my personal suggestion on where to go. Let's start with stock, because the stock/Contract Configurator answers are completely different: Stock - Pretty much all the *easy* customizability options are what exists in GameData/Squad/Contracts/Contracts.cfg. Most revolve around weights for different types of things and rewards - I didn't see anything in there for size/distance/altitude related stuff. The hard customizability would be changing anything that's saved in the persistence file for any of the ContractParameters (some may be public members, but most likely aren't). Contract Configurator - See Parameters. There's a lot. And you likely can't change a lot of it via module manager due to Contract Configurator's expression langugage - I could do something like "altitude = @targetBody.Radius() / 2.0" - which isn't module managerable, but already suppports the resizing. Anyway, that being said, what I'd recommend is to apply a scaling factor to the celestial body's mutliplier. All contract rewards and science stuff gets that multiplier applied to it. You can also play with the global funds/reputation/science multipliers (stuff like HighLogic.CurrentGame.Parameters.Career.FundsGainMultiplier) if you want to decouple them a little bit. That way you could figure out a method to get scaled contract funds based on the scaling of planets. Or if you don't support per-planet scaling, then maybe you can do just the career parameter based scaling.
  12. nightingale
    Each part has a category in its config file. It's the same as the categories the parts are grouped into in the VAB/SPH.
  13. nightingale
    Raise a GitHub issue and we'll see what we can come up with. I'm thinking if we average over 5-10 frames we can eliminate silly stuff like that.
  14. nightingale
    Yup, I'll definitely take a pull request for that one. Note that if possible, it would need to be via reflection.
  15. nightingale
    There's actually a specific parameter for that for RT. Nothing for AntennaRange, and not planned (nothing against it, just not terribly interesting in doing any more mod-specific parameters with the current workload i already have).
  16. nightingale
    No idea (my guess is yes), but if you edit the last post in a thread it'll show the thread as unread to people following it (and I follow all my own threads). Tourism will get a quick update in the next week or two, so I'll pick this up then - raised [#20]. Really shouldn't be Strategia related, but anything's possible.
  17. nightingale
    Antennas don't have range in stock - which mod are you looking at? (unless that's something new?)
  18. nightingale
    Okay, the contracts without parameters is pretty serious, so new release to fix both those issues (I'd missed a couple contracts for the duplicates). Download here. ContractPack-FieldResearch 1.1.4 Fixed contracts without any parameters (thanks smjjames). Fixed near-duplicate geological and climate contracts (thanks smjjames).
  19. nightingale
    1.9.3 had a major issue that affected tourism - retry it with 1.9.3.1 and let me know if you're still having issues. I took a look at the asteroid contract, and the checks for it seemed correct at a glance.
  20. nightingale
    Fixed some major problems with 1.9.3. Download the update now! Contract Configurator 1.9.3.1 Fixed MAJOR issue introduced in 1.9.3 that broke Tourism Plus (thanks Ryusho). Fixed ReachState not working with timers (thanks SoTOP).
  21. nightingale
    Should work that way if you put it in the VPG. I'll try to get to it in the next week... but a PR would help. I'll look into both of these and see if I can get a fix out ASAP.
  22. nightingale
    Forgot to put that in the log - duplicate prevention should be working again now, yes.
  23. nightingale
    New release of Field Research introduced the Strategia integration (so if you've installed the module manager config, make sure you remove that before updating).
  24. nightingale
    New maintenance release, just some minor fixes here and there. Download now! ContractPack-FieldResearch 1.1.3 Strategia integration. SCANsat support - bodies need a biome scan before Field Research contracts are offered (thanks severedsolo). Rewrote some contracts using the ITERATOR functionality to reduce complexity. Improvements to Scientist contracts.
  25. nightingale
    New release with lots of bug fixes. Download now! Contract Configurator 1.9.3 Added VesselParameterGroup.hideVesselName. General improvements to behaviour of parameters with in-sequence completion (thanks inigma). Improved reliability of RemoteTech parameters. Fixed issue with some expressions being parsed twice in the Expression behaviour (thanks linuxgurugamer). Fixed problem with Duration timer contracts not working when used as a child parameter (thanks TrooperCooper & NathanKell). Fixed issue that caused disabled stock contracts to re-enable themselves on occasion (thanks Rokker). Fixed supposedly removed Kerbals going MIA (thanks inigma). Fixed major issue with RemoveKerbal (thanks inigma). Fixed issue with Sequence parameter not always firing (thanks Steven Mading). Fixed issue where CollectScience wouldn't correctly check that it needed to be completed in sequence (thanks linuxgurugamer). Fixed failWhenUnmet to actually fail contracts (thanks inigma). Fixed issue with biomes with spaces in their names in CollectScience (like "Ice Caps").
×
×
  • Create New...