Jump to content

nightingale

Members
  • Posts

    4,137
  • Joined

  • Last visited

Everything posted by nightingale

  1. There's a couple changes that I've made to get it to compile, just haven't had a chance to test it all out with the new CBK. Should get that done within the next couple days.
  2. @linuxgurugamer - The answer is - it depends. There's lots of different ways to do that type of thing. One method is to use two VesselParamterGroups (one with a define and the second with a vessel attribute). This can get clunky though, so my preferred method is to just be careful with use of the completeInSequence and disableOnStateChange attributes in a single VesselParameterGroup. Something like this (pseudo-config): VesselParameterGroup { HasCrew = 0 (or HasCrewCapacity) ReachState => ORBIT (disableOnStateChange = true) ReturnHome (completeInSequence = true) } You may of course have other parameters needed to define the particular mission you had in mind.
  3. @linuxgurugamer - That looks like it's working correctly. Get any vessel to orbit, then bring it back home is exactly what the parameters say.
  4. @severedsolo - Raised #602 for the Contract Configurator side, as I agree with you. As to the stock Exploration contracts, they don't set any weights because they are non-cancellable/declinable. So the player isn't able to make a choice of which body to take with Exploration contracts. Still, I could see an argument for increasing the weights regardless (as the player can just ignore the contract, so there is still minimal ability to choose).
  5. Hard to tell from that log, but it doesn't look like any of the RemoteTech contract pack config is actually installed (but the version file seems to be there). This looks like one for @severedsolo (maybe - I can't easily tell from just the name alone): ContractConfigurator.PartValidationFactory: CONTRACT_TYPE 'BaseSelfSufficiency', PARAMETER 'Self-Sufficiency' of type 'PartValidation': Error parsing part ArgumentException: 'USILS_Greenhouse' is not a valid Part. at ContractConfigurator.ExpressionParser.PartParser.ParseIdentifier (ContractConfigurator.ExpressionParser.Token token) [0x00000] in <filename unknown>:0 at ContractConfigurator.ExpressionParser.ExpressionParser`1[T].ParseVarOrIdentifier (ContractConfigurator.ExpressionParser.Token token) [0x00000] in <filename unknown>:0 at ContractConfigurator.ExpressionParser.ExpressionParser`1[AvailablePart].ParseSimpleStatement[AvailablePart] () [0x00000] in <filename unknown>:0 Rethrow as Exception: Error parsing statement. Error occurred near '*': USILS_Greenhouse ................* <-- HERE
  6. Nothing planned. It's an interesting idea, but might work better through plain contracts. In general though, I think the ISRU mechanic works better as something to enable in-mission refuelling than as a specific goal. Personally, I'm waiting for the Mining and Processing mod to become a thing.
  7. @Sol Invictus - You get number #600. @Sundering - You get number #601.
  8. Not at a computer, so I apologise for the lack of specifics. If I remember correctly, that particular event is for the game settings, so it won't get fired when starting a new game, but it will when changing difficulty settings in-game. Really depends what you're trying to accomplish, but there may be better options: - OnSave/OnLoad logic in your parameter class. - if what you're trying to do is tied to a specific field, make it a property and add the logic in the set method. - do "first time" instantiation logic in a scenario module instead
  9. @silvan78 - there's nothing that Waypoint Manager adds that helps make this any easier (the waypoint stuff is all stock, even more so with KerbNet allowing custom waypoints in 1.2). So your best bet would be requesting the feature in RPM.
  10. @Skalou - that is something that is not currently possible.
  11. @Sol Invictus & @Yemo - Ah, I thought this was about disabling contracts via the difficulty settings. Yes, WorldFirst is gone, RecordTrack has been gone for a while (I think) and ExploreBody is now ExplorationContract. The wiki has been updated.
  12. Could be because Exploration is special in stock or could be a bug in how Contract Configurator saves those settings. Post up a save file and I'll take a look.
  13. Right, I've figured out another way to do things, which means this should no longer occur. Props to everyone who did get their mods updated though (it's still a good idea - someone else could come along and do the same thing).
  14. New release here with lots of good stuff! Got a new workaround for the "toolbar" issue in place - other mods no longer need to change their code for compatibility (although it's still a good idea). Kerbal Konstructs support is also back in this release. Contract Configurator 1.21.0 Found new workaround for GetExportedTypes reflection issue (the "toolbar" issue). Added NextUnreachedBody() and NextUnreachedBodies() methods. Added Part.MassDry() and Part.MassWet() methods. Added CelestialBody.CanHaveSynchronousOrbit() method. Recompile Kerbal Konstructs integration. Fixed contract window text not updating for dynamic text (duration timers, etc.).
  15. Better option would be to ask @RoverDude to use :FOR[Karibou] in his configs (he already has MM configs, so it doesn't introduce a Module Manager dependency on his end that doesn't already exist). That will allow other mods to use :NEEDS[Karibou]. Or better yet - submit a pull request with that change. I know @sarbian has rejected doing subdirectories in the past (with good reason, the directory hierarchies in some mods get very deep, and there's a lot of exceptional stuff like "PluginData" that would need to be specifically excluded). EDIT: Missed that the original issue has to do with Firespitter + Resources. I'm less familiar with how that's set up, but could still be hypothetically fixed by using an appropriate FOR[xxx] somewhere.
  16. Yup, this is a case where the vessel assignment isn't really necessary in the contract and just makes it more complicated for the player. So not a bug (from a Contract Configurator standpoint).
  17. @WarpSpider74 - It's a bit of a weird edge case, but I think it's just the way the contract is written - not something I can change.
  18. @Gilph - This looks to be the same issue as the duration timer in the Tourism contract. Working on a fix for the next release.
  19. @seanth - Unfortunately, the answer to both those questions is no.
  20. Probably this one that will be the one you want to get rid of. AssemblyLoader: Loading assembly at F:\Kerbal Space Program 1.2\GameData\RealPlume-Stock\ContractConfigurator\ContractConfigurator.dll
  21. @Sudragon - There's tons and tons of errors in that log, so it's safe to say you have problems with mods that don't work in 1.2. For Contract Configurator, you have at least two copies installed, which is causing it to fail to load. I'd suggest starting with a clean install here, and adding 1.2 supported mods back in from there.
×
×
  • Create New...