nightingale

Yup, as Nori said, that's not easy. Another hack that might be good enough is to disallow any vessel with any Oxidizer on board (HasResource).

I posted a response here on your original thread.

Doesn't look like there's any major issue for Contract Configurator here. I see: A minor New Horizons compatibility issue in Field Research that prevents one contract from working (fixing that for the next release). Some errors that should be warnings (it's just an issue with the output with some backwards compatibility stuff in Contract Configurator 1.7.x). Some old old issues in the Advanced Progression contract pack with a few of its contracts. I'd recommend focusing on the other issues that OWK mentioned - I suspect it's one of those that is actually causing your tracking station issues.

The .zip file starts with a GamData folder - merge that into your KSP/GameData folder. The end result should be GameData/ContractPacks/RemoteTech/<stuff>

Part of the problem is that the contract can stay "stuck" in the preloader for a while - which is why you're seeing a contract under a vessel name that was later changed. Raised [#310] to at least partially address that. The only other thing that can be done is to add an expression requirement to your contracts that checks the targetVessel is a Station and has the right crew capacity - that way it'll get rechecked before being offered. It's a little bit redundant, but it's the only way I can think of to 100% close the hole.

AssemblyInformationalVersion is the ideal one. Anything else is gravy. This is what I set in Contract Configurator: [assembly: AssemblyVersion("1.0")] [assembly: AssemblyFileVersion("1.7.2")] [assembly: AssemblyInformationalVersion("1.7.2")] [assembly: KSPAssembly("ContractConfigurator", 1, 0)]

Confirmed I'm seeing the issue as well - I'll work at getting this into the next release. Raised [#309].

So the AtmosphereFromGround object that was tied to the Atmosphere GameObject is NOT the same object that I get when I use your method linked above, which was the problem. I did a dump of the info on the AFG object your method found, and it's also on a GameObject called Atmosphere, with the same components (Transform, MeshFilter, MeshRenderer, AtmosphereFromGround). This bugs me to no end. Anyway, it worked, so thank you both very much for your assistance here! - - - Updated - - - Okay, I figured out why I was having so much trouble originally (and Thomas P made reference to it if I had been thinking clearer about the implications). I was messing around on the preFab object, long after the Jool CelestialBody had been instantiated. Which is why I had so much trouble and the only thing that seemed to give me results was doing very destructive things like altering the shared mesh (I was also wondering why altering the localized copy of the mesh via the mesh property hadn't work). So it all makes sense now, thanks again.

Could be that it's just plain broken, I'll do a quick test tonight. Those other buildings don't do an actual scene change, so makes sense that it would stay the same for those.

Nope, Contract Configurator won't help, unless you're looking at changing time limits for contracts in the various contract packs (although most of them don't set limits, I believe). What you're looking for is DMagic's Contract Reward Modifier. It has a slider for duration, and you can set it differently per contract type.

Contract Configurator adds the NoRandomContractMentality (example usage here) for that very purpose. It's 99% effective (I've occasionally seen a contract slip through the cracks, I think if KSP doesn't find an appropriate agent it'll fall back to randomly picking one).

Shouldn't be a major problem for completed contracts - Contract Configurator will output a warning message in the log that it can't load them, but that can be safely ignored. Active contracts will get auto-cancelled with a message in the notification area and offered contracts will silently disappear.

From reading the SO page you linked to, the Specific Version is only for the compile time check (so if I am project DependentOnBROKE which depends on BROKE, and BROKE changes version, it'll affect whether it refuses to compile without me updating the version in the properties). At run-time it will always look for the version of BROKE that matches what DependentOnBROKE was compiled against. The same SO page talks about getting around this with the App.config - which when building a mod DLL isn't something we can play with (as far as I'm aware). I don't know enough of the details about what happens on load of .NET assemblies. If it loads an assembly with a class that implements BROKE.IFundingModifier before BROKE is loaded, I have no idea if it will be a problem. It may be that it won't cause a problem unless said class gets instantiated before BROKE is loaded, which wouldn't happen. Either way, the answer will come out when you test it. 100% agree - which is why I still set the AssemblyFileVersion and AssemblyInformationalVersion to something sane. Oh, and feel free to have a look at my version check code - I use it for doing version checks against a number of different mods that all capture the version number differently (SCANsat, RemoteTech, ModuleManager), so it tries a number of different ways to get a version. Obviously if you're just using it for checking against BROKE you can just use the appropriate check from there. That assumption is definitely correct - works the same way for Contract Configurator stuff (ie. the internal CC_RemoteTech that has the RemoteTech code, but has no MonoBehaviours).

It's supposed to stay toggled! Just skimmed over the code (don't have KSP access right now), and everything looked good. Could you provide some more details? Is it both the stock contract types and Contract Configurator groups that it is not working for? If you save on the space center scene and reload immediately, does it reset then? Can you provide a log (and save file too) covering the change from one scene to another when it gets reset?

Thanks! I swear I'd tried all those things (at least individually) without luck, but it worked. Unfortunately, there's still the white atmospheric "halo" doing it this way, so I still seem to be missing one critical piece.

Alright, didn't seem to have any luck there. The other possibility would be that I dismissed the atmosphere stuff too quickly - I assumed that destroying the gameObject actually got rid of everything... but I suppose that it could be leaving some shader behind somewhere that is still getting executed? Not really too familiar with how unity destruction works - I just assumed it'll take care of everything in the hierarchy, but I guess if the Squad code isn't setting it up properly.... Alright, enough for tonight - I'll play around with this some more tomorrow evening... any advice in the meantime is appreciated.

DLL dependencies suck in KSP (but I don't have a better suggestion, as any other method than the interface would be way uglier). Keeping that in mind though, there's a couple things you may want to do differently in your AssemblyInfo.cs: I always leave the AssemblyVersion alone at 1.0. Otherwise if you change it, it forces someone who compiled against you DLL to recompile. In other words, every time you release, you break everyone else's DLLs, which is obviously bad. [assembly: AssemblyVersion("1.0")] I set this to the same thing as AssemblyFileVersion. There was a good reason (DMagic told me to), but I can't remember what the reason was. I think it made code for checking a version easier/better/more reliable. [assembly: AssemblyInformationalVersion("1.7.2")] This will allow others to do a KSPAssemblyDependency() on you, which means you don't have to do silly things with the alphabetical load order and name your mod aaa_BROKE. Again, don't touch the version, because there's a bug in KSP where the version number comparisons are done wrong (see #3995). [assembly: KSPAssembly("ContractConfigurator", 1, 0)]

I may have to take you up on this, I don't seem to be getting anywhere. I've tried poking at the AtmosphereFromGround component, at first I would get some nasty NullRef exceptions for every method I call (extremely suspiciously, the mainCamera, sunLight and planet fields were all null. Was able to set those and hit the code that updates the shaders, but not real luck on getting rid of the white halo. So I started to suspect that I must still be barking up the wrong tree, and nuked the Atmosphere GameObject via Destroy. Halo still present. So any thoughts on where I may need to look? Here's a dump of Jool's components from PSystemBody down: PSystemBody component: PSystemBody (UnityEngine.Transform) PSystemBody component: PSystemBody (PSystemBody) PSystemBody component: Jool (UnityEngine.Transform) PSystemBody component: Jool (CelestialBody) PSystemBody component: Jool (PResource) PSystemBody component: Jool (OrbitDriver) PSystemBody component: Jool (OrbitRenderer) celestialBody component: Jool (UnityEngine.Transform) celestialBody component: Jool (CelestialBody) celestialBody component: Jool (PResource) celestialBody component: Jool (OrbitDriver) celestialBody component: Jool (OrbitRenderer) scaledVersion component: Jool (UnityEngine.Transform) scaledVersion component: Jool (UnityEngine.MeshFilter) scaledVersion component: Jool (UnityEngine.MeshRenderer) scaledVersion component: Jool (UnityEngine.SphereCollider) scaledVersion component: Jool (ScaledSpaceFader) scaledVersion component: Jool (MaterialSetDirection) scaledVersion component: Atmosphere (UnityEngine.Transform) scaledVersion component: Atmosphere (UnityEngine.MeshFilter) scaledVersion component: Atmosphere (UnityEngine.MeshRenderer) scaledVersion component: Atmosphere (AtmosphereFromGround) Looking over that list, I think I'm going to take a closer look at the ScaledSpaceFader... that's about the only thing left that I haven't messed around with yet.

Only way to say for sure is to see a log file. Anomaly Surveyor contracts start showing up pretty quickly (after the first launch you'll get the Island Airfield). You could also be getting bad RNG luck. Have you tried cancelling offered contracts to see what else shows up?

Heh, I had already looked at that code file and tried some stuff from it to no avail. But now that I know that's where I should focus my efforts hopefully I'll have more success.

Testing out some ideas for a new contract pack, and one thing I want to do requires me to play the planetary scale a little bit. Note that this wouldn't be a Kopernicus thing, as the scaling is dependent on an event. Also, what I'm doing is far far simpler (in theory) than Kopernicus - just a simple rescale of a body without a PQS. Anyway, after much trial and error, I've gotten my 50% rescale test working for everything but the atmosphere. I was hoping someone can get me the last mile: Before: After: I know that the general issue is that the atmosphere background isn't being scaled, but I can't seem to figure out what is needed to set the scale for that. Any assistance is appreciated. Here's my test code: private void DoRescale() { Debug.Log("doing Jool Rescale"); PSystemBody psbJool = PSystemManager.Instance.systemPrefab.rootBody.children.Where(psb => psb.celestialBody.name == "Jool").First(); // This works MeshFilter joolMeshFilter = psbJool.scaledVersion.GetComponent<MeshFilter>(); ScaleMesh(joolMeshFilter.sharedMesh); // This does nothing MeshFilter atmoMeshFilter = psbJool.scaledVersion.GetComponentsInChildren<MeshFilter>(true).Where(mr => mr.name == "Atmosphere").First(); ScaleMesh(atmoMeshFilter.sharedMesh); } private void ScaleMesh(Mesh mesh) { Vector3[] oldVertices = mesh.vertices; Vector3[] newVertices = new Vector3[oldVertices.Count()]; for (int i = 0; i < oldVertices.Count(); i++) { newVertices[i] = oldVertices[i] * 0.5f; } mesh.vertices = newVertices; } I've also played around with the AtmosphereFromGround class a bunch to no avail, as well as changing the Atmosphere transform.

A couple new items to report on: New contract pack from WhiteCat106! The Maritime Mission Pack has above and undersea contracts intended for use with Fengist's Maritime Pack. SCANsat Lite is no more... it's been integrated directly into SCANsat! Good job, severedsolo.

Looks like a bug in CosmoBro's config to me - CrewRotation is specified when I think it should be BaseCrewRotation.

It's doable, but not something I've ever attempted. Fengeist is probably the expert in on/under water adventures. - - - Updated - - - Essentially when any one of the agent graphics fails loading, it'll take down the whole subsystem with it. No agencies means no contracts.

Everything looks fine from a Module Manager perspective, but you're on 0.2.1 of Base Construction and CosmoBro has released 0.2.2. Update that, and if there's still issues please follow up with a new log file on the Base Construction thread.