Jump to content

nightingale

Members
  • Posts

    4,137
  • Joined

  • Last visited

Everything posted by nightingale

  1. Can you show me a screenshot of this? I'd like to see what contract pack it's coming from so I can track it down.
  2. There's a pull request that fixes it - you can try and grab the files from that. https://github.com/jrossignol/ContractPack-AnomalySurveyor/pull/14/files I'll be merging that and releasing a new version once I get to doing Anomaly Surveyor updates (expected sometime this month).
  3. I did notice that the contract generation isn't working as smoothly as it used to. It's on my list of things to check out.
  4. It's hard to tell exactly what's going on when you look at it from mission control. Also, the names you choose don't matter - it's picked up the vessels you've called CommSat III and IV in the first and second slot. In flight, can you focus on the vessel that *should* meet the criteria for the third slot, and show what the contract parameter pane looks like from there?
  5. Thanks for the heads up - sounds like I need to a do a bit of a review of the DMOS experiment limitations.
  6. Took a peek and this does indeed seem to be from the "Anomalous Signal Sensor" in DMOS, and you're correct that it's tied to distance from an anomaly. So I'll likely just remove this experiment from the list of valid experiments. Raised ContractConfigurator/#673.
  7. Yes, there's three related behaviours you may want to use (that all do something slightly different): UnlockTech, UnlockPart, and ExperimentalPart. The last is equivalent to what the stock part test contracts do. No, you'd have to code up a custom PartModule and custom ContractParameter to make that work. Through the DestroyVessel behaviour - but you have to know the craft that you're removing. Yes, through C# (other threads will have more specific details).
  8. This does allow for modded experiments, and sometimes they have their own restrictions coded in that can cause problems like this. However, in this case I think this is a SCANsat experiment - so I'd try that first. I don't know the name of the part, but I assume that's the @DMagic thread you were referring to.
  9. Thanks for confirming that - I had suspected an underlying stock bug, but hadn't had a chance to look yet.
  10. Yeah, this is something I noticed in 1.6.0. I'll be doing a release sometime soon to fix that.
  11. It's done (and hello @NathanKell)! Contract Configurator 1.27.1 Improved performance of WaypointGenerator's RANDOM_WAYPOINT_NEAR when the min/max distances are very close to each other. Fixed issue where too many waypoints can get generated by WaypointGenerator when count > 1. Renable backwards compatibility to KSP 1.4.5.
  12. Great, then I'll do a release right away with 1.4.5 compatibility enabled.
  13. Question - does the current release work on 1.4.5? From memory, there wasn't anything I needed to change for 1.5.x or 1.6.x compatibility, so there's a good chance that it's already backwards compatible. If yes, then I'll just do a new release and set the minimum version to 1.4.5. If not, then I can do a one-off recompiled against 1.4.5 (that way all the CKAN stuff will happen automatically).
  14. @pap1723 - I've fixed the performance problem described above for the next release.
  15. Technically, the WaypointGenerator behaviour supports that through RANDOM_WAYPOINT_NEAR. You would have to set one waypoint for the launch site (it can be hidden), and then have one generated "near" it with min/max distances set. Be careful though, because there's a known bug/limitation where it uses a stock method that only supports maxDistance (not minDistance) and just re-rolls the waypoints until it hits one that fits the bill. So there could be poor performance if you choose a very small window (or if you make minDistance = maxDistance it'll probably be an infinite loop). For sure not tested on 1.5.1, for sure not supported. Most likely does work though, just reproduce stuff on 1.6.x if you want to report bugs is all.
  16. Sorry, I can't support such old versions.
  17. It's a code thing - I've made the fix in Strategia and it should hopefully just work once it's released.
  18. Oh wow, is that still a bug? It was introduced when the RSS folk made Jupiter oblate (which I think might be an optional config? not sure). Anyway, for the next release I changed it to check the CelestialBody.hasSolidSurface flag as well - if I understand how Kopernicus works, anything that is based on Jool should have that flag set as false, so it should just work. Let me know if it's still a problem after the release.
  19. The former. It was always possible with Module Manager, but this gives another option for contract authors. With module manager the contract just wouldn't exist without MH, with this method it would still show up as a contract, it would just be disabled with a requirement stating that contract requires MH.
  20. New KSP, new release. Now with more delta-vee! Download here. Contract Configurator 1.27.0 Recompile for KSP 1.6.0 Added actual and vacuum delta-vee to ReachState. Added Expansion requirement. Added LAUNCH_SITE sub-node to WaypointGenerator behaviour. Added support for LaunchSite class in expressions. Added OtherKerbinBiomes() function to return biomes like Baikerbanur. Fixed Biome functions to correctly distinguish between KSC biomes and other collider based biomes. Fixed issue with sub-parameters sometimes showing as met when they shouldn't. Clarified error message when SpawnPassengers is omitted from a contract that requires it.
  21. Looks fine. Could be there's a bug with certain situations or something - would be good to get either a save that reproduces or repro steps.
  22. Recompiled against KSP 1.6 without any errors, so probably no issues with it. Will do a bit more testing and a new release tonight.
  23. I see your PR about this issue, so I'll merge that and get a release out soon-ish. Are you using a VesselParameterGroup? It will always display the contract from the perspective of the currently selected vessel (but potentially track it for any/all vessels in the background). In this case, giving focus back to the "contract" vessel should show the parameter as checked again. If not, the same will apply, but it won't track on a per-vessel basis (so other parameters that might depend on the NewVessel will potentially get reset. There's a lot of exceptions around the Duration and a lot of different ways to use it, so it's hard to say for sure. If you're using a VesselParameterGroup, the duration on the parameter itself is often a better/simpler choice. If you're not using a VesselParameterGroup - then I would expect it to reset when switching focus. This is sort of supported. I think @inigma did stuff like this in his GAP contracts . It would say that the next vessel you launch is the "contract vessel" (done via VesselParameter group + define). Then the other parameters would use another VesselParameterGroup with "vessel" set to lock it to the contract vessel defined in the previous step. Finally, the VesselNotDestroyed parameter is used to force the contract to fail if the vessel gets destroyed. If you want the contract not to fail - then it's really just the normal case of using a VesselParameterGroup (potentially with the NewVessel parameter).
  24. Generally Patreon is better, unless you're wanting to make a single big lump sum (see someone's analysis here). I'm happy either way though!
  25. Exactly 6 months between releases, we've almost got some sort of release cadence going! Download here. Strategia 1.7.3 Rebuild for KSP 1.5.x. Fixed active strategy text in facility right-click menu (thanks avalancha).
×
×
  • Create New...