nightingale

Yes, but not all players in all playthroughs will go to Duna. Or Jool, or Mun, etc. It's deep enough at the end of a 3 mission chain - I didn't want them to have to do *every* anomoly before getting that one (especially since there's no way currently to see the required progression).

Why? It's the crown jewel of Anomaly Surveyor contracts - locking behind a Vall/Bop landing would make it show up in less than 1% of careers (statistic completely made up, of course ;))

Actually, it's a different exception, which means we've made progress! One more try!

I've updated the DLL (same link as above), fairly sure I've got the right fix this time. Try it, and if it doesn't work I'll take a closer look when I can actually run KSP.

@Galenmacil - I actually didn't realize that it was on selecting a waypoint that this occurs (I thought it was right when the window opens). If you right click a waypoint and do "activate navigation" do you get the issue too? What about if you do that with Waypoint Manager not installed?

The DayLength() thing was just an idea I was thinking about - it's not something that exists today. The durations are calculated based on the time settings (not sure why I chose to do it that way, I don't really like it), so you probably had it set to earth time at one point (the value won't be changed back once the contract is generated). Cancel the contract and the next one should be right. That being said, for that particular contract it doesn't make a huge difference - 2 days was a pretty arbitrary value that I selected to make sure the network is actually up and operating correctly.

It's hard to do a generic fix for this. Also, I think the resolution for this (if there is one) lies more in the contract pack that in Sigma Dimensions. Which contract packs are you referring to with the time limits? I'm guessing it's either GAP or RP-0. I ask because I'm not sure what the impacts of the time limits are (is it that it's a timed mission and the difficulty doesn't scale properly?) Generally speaking, all the durations in Contract Configurator are based on the 6 hour Kerbal day, but will display based on the game clock settings. If you want to scale those, the likely way to do it would be based on a module manager patch. One thing I could consider if the author of the contracts interested in is give a CelestialBody.DayLength() expression function which could be used to scale those types of requirements directly in the contract pack.

I raised #510 on the contract generation issue - keep an eye on that.

@severedsolo - Awesome, that's a ton of good detail. Raised #510. @brainy - From the log, it looks to be coming from the RemoteTech contract pack: [EXC 20:54:23.917] NullReferenceException: Object reference not set to an instance of an object FinePrint.Utilities.ProgressUtilities.HaveModuleTech (System.String moduleName, System.String excludeModule) FinePrint.Utilities.ProgressUtilities.HaveModuleTypeTech (System.String moduleType, System.String excludeModule) ContractConfigurator.PartModuleTypeUnlockedRequirement+<>c.<RequirementMet>b__4_0 (System.String s) System.Linq.Enumerable.All[String] (IEnumerable`1 source, System.Func`2 predicate) ContractConfigurator.PartModuleTypeUnlockedRequirement.RequirementMet (ContractConfigurator.ConfiguredContract contract) ContractConfigurator.ContractRequirement.CheckRequirement (ContractConfigurator.ConfiguredContract contract) ContractConfigurator.ContractRequirement.RequirementsMet (ContractConfigurator.ConfiguredContract contract, ContractConfigurator.ContractType contractType, IEnumerable`1 contractRequirements) Rethrow as Exception: ContractConfigurator: Exception checking requirements! UnityEngine.Debug:LogException(Exception) ContractConfigurator.LoggingUtil:LogException(Exception) ContractConfigurator.ContractRequirement:RequirementsMet(ConfiguredContract, ContractType, IEnumerable`1) ContractConfigurator.ContractType:MeetExtendedRequirements(ConfiguredContract, ContractType) ContractConfigurator.<ContractGenerator>d__26:MoveNext() ContractConfigurator.<ContractGenerator>d__25:MoveNext() ContractConfigurator.ContractPreLoader:GetNextContract(ContractPrestige, Boolean) ContractConfigurator.ContractPreLoader:GenerateContract(ConfiguredContract) ContractConfigurator.ConfiguredContract:MeetRequirements() Contracts.Contract:Generate(Type, ContractPrestige, Int32, State) Contracts.ContractSystem:GenerateContract(Int32, ContractPrestige, Type) Contracts.ContractSystem:GenerateContract(Int32&, ContractPrestige) Contracts.ContractSystem:GenerateContracts(Int32&, ContractPrestige, Int32) Contracts.ContractSystem:RefreshContracts() Contracts.<UpdateDaemon>c__Iterator81:MoveNext() [LOG 20:54:23.922] [VERBOSE] ContractConfigurator.ContractType: Didn't generate contract type RT_KerbinRelay: Failed on contract requirement check. A number of possibilities that I won't have time to investigate at the moment: Something changed in 1.1.x and I need to fix this RemoteTech compatibility issue (make sure you're on the latest version) It's a RT contract pack + RP-0 incompatibility. It could be the code above is making some assumption about parts that just isn't valid for RP-0. Raised #511, but I won't be able to dig deeper until a couple weeks from now. If updating RemoteTech doesn't fix it my only suggestion in the meantime is to uninstall the contract pack.

@MisterFister - Also, I've heard good things about Sibbell. You do a one click thing to connect it to your GitHub login, and can then get email notifications for releases on any project you've starred in GitHub.

Ah! That's actually not really a crash (which is why I specifically asked for output_log.txt/Player.log over KSP.log). No matter though. I have a pretty good idea what the problem is from looking at the code, but I'm not in a place that I can actually test it out. Could you grab the dev dll here and give it a go? I have no idea if the cause is a 1.1.2 change or a mod incompatibility, but if the fix resolves your issue I'll release it.

Nothing obvious in the log or code that would cause this - I'd recommend seeing what they say over on the RPM thread.

Could be a bug. Can you provide a log and raise a GitHub issue and I'll look at in in a couple weeks (currently out of town).

Agreed - Module Manager is practically a required dependency for Contract Configurator since most contract packs do at least some MM config.

Could just be bad luck on the contract generation. I'm starting to get some hints from other threads that there may be a need to up the availability of Contract Configurator vs. other contracts in the code (I'll look at that when I'm back from my trip). The requirements for themselves should be correct - generally speaking it's orbit the planet where the anomaly is (or scan it if you have SCANsat). Island Airfield is triggered off first launch, and I *think* that pyramids is from reaching space (might be orbit though).

@theonegalen - Also, StrategyEffects only get their OnRegister hook called if it is an active strategy, so that's usually the hook to do something/turn something on. I'd intended to do some stuff with BROKE stuff with Strategia, but I never got it done for the first release, and just haven't gotten a chance to circle back around to it.

Assuming that it's the same issue as warezcrawler, then it should be solely a NAVHud problem - but I haven't checked the follow up in that thread to see what happened. That's weird. I can't think of anything that would do that could break RPM - maybe toss a log my way and I'll take a peek.

@Keniamin - You put python on top of Contract Configurator?!? Neat! Anyway, adding an exclude option in HasCrew wouldn't be too hard - raise an issue in GitHub and I'll try to get it in the next release (not likely to be for a few weeks though).

The contract weight in the persistence file *should* be ignored for Contract Configurator, if I'm not mistaken. What I do is set it up at load time based on the contract packs (actually the number of contract group and contract type records) loaded. The formula for this is very close to what it was in 1.0.x, but modified to use the weighting system instead. You can see the source for that here. Unfortunately, the parameters that feed into that are not controllable outside of the code. It might be that I need to tweak them higher, or modify it dynamically based on the current average weight of all other contract types. What problem are you trying to solve? Is it just generally not seeing enough CC contracts, or for a specific contract type or group? For your test, how many contract_type and contract_group nodes are loaded? Where are you in the career (ie. what is the relative weight of stock contracts)? Have you made modifications to any of the contracts.cfg defaults?

Well, I have no idea how you got 4 strategies in that screenshot, but it should've been a bug that is hopefully fixed - the intention was always 1 per admin building level. The idea being that I want to make it so there is a real player decision in which strategies to pick (ie. you can't have all the strategies you want at a given time). Whether 3 is the right number or not I'm not 100% sure about. If I were to allow 4 strategies, would people want 5? The other angle I looked at was dynamically increasing the limit (having a strategy that gives + 2 strategies, for a total of 1 extra). I ended up not doing it, partially because I couldn't think of an ideal way to balance it and partially because there were technical challenges. I keep hearing about more levels of buildings in stock - but not sure if that's something we're likely to see in 1.2 or not (in which case I may revisit how the levels are done and increase the max limit).

@Madscientist16180 - If you want to specify a very specific orbit with pretty orbital markers, then use OrbitGenerator. If you just want some high level orbit parameters, then go with the Orbit parameter. @smjjames - I fixed the GAP link, but didn't see any other ones that looked wrong.

@Kerbas_ad_astra - Oh yeah, took a peek and some of those expressions are pretty nasty. When Contract Configurator is generating a contract, the minimum "step" it can do is to run a single expression in a frame. So those expressions can make it perform pretty poorly (and I'm guessing the additional planet packs are making it that much worse in this case). In general, you can break the expressions up into multiple expressions to allow it to work over several frames (look at Field Research for an example of that). There's some specific things you can do in some of your expressions too. Let's take a look at an example: targetBody1 = HomeWorld().Children().Where(b => (AllVessels().Where(v => (v.CelestialBody() == b) && (v.IsOrbiting()) && (v.Altitude() < @/maxApoapsis)).Count() < 5) ).Random() So far all moons of the homeworld, this expression will look at all vessels (which for Kerbin already means you need to look at each vessel twice). So I'd be inclined to switch this around a bit: DATA { type = List<CelestialBody> validBodies = HomeWorld().Children() } DATA { type = List<Vessel> bodyVessels = AllVessels().Where(v => @validBodies.Contains(v.CelestialBody())) orbitingVessels = @bodyVessels.Where(v => v.IsOrbiting()) validVessels = @bodyVessels.Where(v => v.Altitude() < @/maxApoapsis) } DATA { type = CelestialBody targetBody1 = @validBodies.Where(b => (@validVessels.Where(v => (v.CelestialBody() == b)).Count() < 5)).Random() } Something like that is more expensive overall, but would hopefully be less of a generation impact on the player. If there's some new expression methods/functions that you'd like for performance improvements, just let me know. Depending on how you end up doing it, something like CelestialBody.Vessels() (get all the vessels for a body) could improve what you're doing a fair bit, as reducing the number of things to look at in a Where() expression can also be a significant performance boost. I also have the ability to make methods specific to the List<Vessel>, so I could do something that allows AllVessels().WhereOrbiting(@CelestialBody). But I'm not entirely convinced that's a direction I want to go or not.

See here:

It's a different answer for landed and in Orbit. For landed, you'd use Vessel.Location() to get the vessel location - you can then either modify that by a fixed amount, or use the WaypointGenerator to create a random waypoint near that location (it can be invisible). The waypoint location can then be fed into the SpawnVessel. For orbits, it is similar, except you would use Vessel.Orbit(). There is limited expression functionality around Orbits, but it's something I've considered expanding. Right now, you'd have to take the elements you have access to and translate them into the adjusted orbital parameters. Let me know what you're looking for in this regards (either on the thread or a GitHub issue) and I can see what we can come up with here.

Is it okay without Kopernicus? You mention it causes interference, but didn't say anything about trying it without Kopernicus.