TauPhraim

Yes, thanks ! I thought ckan was just unzipping (potentially stripping a heading GameData at best). So does it take the first folder it finds in the zip named ModName, and ignores all the rest ?

What happens currently (with or without disableOnStageChange) is: 1) Vessel A arrives at BeAtOrigin - this completes the parameter, and locks it to complete and to Vessel A. 2) Vessel B has a hitchiker, is at Origin, but the contract is locked to Vessel A and won't accept vessel B

Yes, I think trusting the player at some point is reasonable (there are much easier ways to cheat in KSP anyway). I'd just be a bit disappointed if, with all these options and parameters, achieving something robust was not possible. You're right about the second part (if that's what you mean): the first vessel that gets at A will complete the first VPG, locking it to that vessel. Any other vessel will apparently not be considered after that. Unfortunately adding disableOnStageChange=false to the BeAtOrigin, and even to VesselParameterGroupDefine in addition, does not seem to change that.

To me it seems intentional that they don't get bonuses. They could by accident be getting them, but I don't see how they could get only half the bonuses.

Hab mechanics are relatively new to me. Could it simply be a multiplier coming from somewhere else on the vessel ?

Actually something in the code resets the efficiency to 100% whatever the bonuses, it seems. If you can open an issue, we could ask for confirmation there that it's intended, and do something about it (at least about the VAB display).

No, it's hardcoded in the lib, to 5m, which is big. (I only experienced difficult to reach parts on high gravity worlds, and it was kind of fun trying to climb or construct ladders to reach them).

It looks like it has been configured this way for a long time (looking at the changes on Tundra_275_Hab). The way I understand the hab module, it should in theory give habtime * both_bonuses (and consume resources in proportion).

Thank you for helping ! I tried the changes you proposed. With this version I can "cheat" by having a vessel with the part in orbit (A), dropping the part, then moving to the surface (B), and finally docking to a suitable part that was conveniently waiting at site B. Ideally, I'd like a vessel to be disqualified forever as soon as it loses the part. I don't know if this is possible.

I'm aiming for simply: "bring a new vessel having a hitchiker container from A (ex Kerbin Orbit) to B (ex Kerbin Surface)". I don't want the contract to complete if: a vessel without the hitchiker part completes the route the hitchiker part is dropped from the vessel before reaching B (Kerbin surface) a vessel without the part completes the route, then docks with a hitchiker part upon arrival With my current attempts using VPG, the first of these problems is happening: I can just focus on any vessel having the part, and the parameter will complete. Then using another vessel without the part, and going with it from A to B, will complete the contract. Here's the current config, if you can have a look. Don't mind the targetbody/situations, I'm overriding them in code (that part seems to work, as the correct values are shown in game).

I will try, but think I already experimented with that. Isn't Sequence supposed to do the same as having just the children with completeInSequence=true ? Thanks, will try. So VPG does not do anything by itself ? Do you think I also need to link the 2 steps in the sequence via more VPGs ? (in my testing it seems to work for A/B without VPG's define, strangely. Just not for the part parameter).

I found hacky ways (?) to manualy instanciate the parameters I want into contracts. Now I'm struggling, trying to achieve the following requirement: "bring a vessel having part X from situation A to situation B": Problems with sequence: trying to put situation A and situation B as children of a Sequence (else they can complete going from B to A, which is not desired). If I do not mention disableOnStateChange on parameters, this leads to the contract being un-completable, as going from A to B will un-complete the parameter for A If I set disableOnStateChange=true for both A and B, this leads to the possibility of going first to B then to A and get the contract completed (despite this being in a Sequence parameter) If I set disableOnStateChange=true only for A, it works as I wish. But is this the correct way, and how will this scale if I have more than 2 end points ? Problems with VesselParameterGroup: The Sequence and PartValidation are children of a root VesselParameterGroup parameter. But: If I do not mention disableOnStateChange on the PartValidation, I can go from A to B without having the part, then klaw onto a suitable part, and the contract will complete If I set disableOnStateChange=true on the PartValidation, I can load one vessel having the part to complete the parameter, then bring another vessel not having the part from A to B, and the contract will complete (despite all being in a VesselParameterGroup parameter)

I found out you can now just add: [KSPScenario(ScenarioCreationOptions.AddToAllGames,scenes)] to the scenario class, and don't need to manually register it elsewhere then.

That's what I was using, but the part about "special installations" is not descriptive enough, ex: I thought this is what happened without any special options already, so it's puzzling.

I want a "singleton that is always there in a game, and is saved/loaded when quitting/starting". So I thought ScenarioModule. The way to do this, it seems, is to : HighLogic.CurrentGame.AddProtoScenarioModule(type, scenes); However, trying to run this code in a KSPAddon with startup=before the SpaceCenter, seems to have HighLogic.CurrentGame still null. And If I do this at startup=SpaceCenter, in the initial KSC scene, the scenario module does not get created. Is there a clean solution ?

Actually I tried for a while, when writing the netkan, but could not make much sense of that part of the doc

Thanks, that was quick ! Ideally I should rename everything (especially the folder in GameData), but that would probably break existing users.

Sorry for the late reply, I had notifications turned off, somehow. @Grobluk glad you sorted it out. Github automatically offering "release" zips for new tags can be confusing in this context, but I don't think it can be deactivated. I just submitted a PR to have it on CKAN, but have no idea how long this will take. Note that it will be simply named "Explainer" unfortunately, as renaming it would have taken more time than I have at the moment.

I checked and there is only one cc.dll. Plus the code looks strange, and searching here it seems I am not the only one with the warning.

I am having the warning: Multiple assemblies with name 'ContractConfigurator' found! Looking at the code, it seems to happen as soon as there is one assembly found with the given name, so I don't know what to make of it. Is this just an error ?

Hello, Is there a way to: declare a new contract type that would never automatically be offered by the stock system ? create such contracts "manually" (programatically) ? I see one (or several) ContractSystem.GenerateContract methods, but I'm not sure what they do still have the accepted contracts visible in the contract list. And maybe count or not count in the accepted contracts limit ? Edit: I tried setting "weight = 0.0" to achieve this, but it seems that is deprecated and not working anymore. So much so that I was starting getting spammed with offers for this contract (isn't there supposed to be a limit to the number of offered contracts ?). Another idea would be to put always false requirements, but wouldn't that lead to the contracts being automatically failed, or hidden (assuming I manage to spawn/accept them manually) ?

I was bugged by this one too I think KSP just truncates the text when it's too long.

Regarding automated maintenance (ModuleAutoRepairer, when an engineer is in a workshop): it does not work during catchup (except once on initial refocus), but it should, right ? (just for confirmation). Less important, but I was thinking: the "log" for it is rather uninformative and quickly lost (lots of messages spammed on top of the screen). How about there was some facility for a persistent-ish log (not saved, but not lost if you don't read fast enough). This could be even more important for life support messages: "Jounh Kerman refuses to work" is an important thing that you wouldn't want to miss. I don't know if the future "trading" system can produce events outside of user interaction, but if so, it could benefit from that too.

On my side I have 0.5.22.0 and the file is not empty in that version. I don't know if the change is intended, or even game breaking.