nightingale

They do not. The Message behaviour is an unobtrusive way to notify them (or at least it would be if I had a setting to allow it to trigger on contract accept like some others do). If that's what you want, raise a GitHub request. Another option is the DialogBox behaviour, but that would be highly obtrusive. Third, if you want it to show up using the "green text" that sometimes appears on screen for a couple seconds, I could add that either as a new behaviour or as a variant of the Message behaviour. If you want this one, again raise a GitHub request.

Just because it's possible in stock contracts, doesn't mean that it's implemented in Contract Configurator. This one doesn't look like it has ideal coverage, but there's a couple ways to get something along these lines: HasResource with ElectricCharge > 0. Not quite power generation, but depending on what you're trying to do this may be good enough. PartValidation with a check for ModuleGenerator. You'll probably also need a second one under an Any with a check for ModuleDeployableSolarPanel. The ideal solution would be similar to the PartModuleTypeUnlocked requirement (I would just add that to the PartValidation). If this is something you need, raise a GitHub request, and I'll get it into the next release.

Yup, that would do it. You can also change the id in the ContractVesselTracker scenario module in the save file.

(0° 38' 24" S, 279° 13' 59" E, the second closest to KSC) I'm thinking that if they're all fixed and above ground now, then the completed message doesn't make a lot of sense.. But then, I haven't actually checked them all yet.. I checked that one on 1.0.4 and it was definitely underground (for me at least). What terrain detail setting are you using? Can you think of other mods you're running that might make changes to the PQS system? Kerbinside or Kopernicus come to mind, not sure if they would be the cause of it being different for you. I someone mentioned something similar for the third one in the contract too (the floating one). It floats for me, but it didn't for them. 5thHorseman just visited the MSL one on Duna, and for him that one was completely underground (for me it pokes up properly). All in all, it's *really* annoying how inconsistent it is depending on terrain detail settings (at a minimum).

Yeah, in Contract Configurator when an undock event happens for a defined vessel, I have to make a decision which of the two vessels to keep tracking. In the situation where the two vessels completed them as one vessel (ie. it's not the case where a vessel got defined, and then docked to something else), I have no way of knowing which is the "right" choice, so I go with the one that kept the ID from before the undock (which is typically the one with the root part). There's nothing I can easily do to solve this in CC. Best bet is to have the contract do a check for vesselType = Rover, although KSP may decide to automatically make your lander a rover before you touch down, or the player may not know/understand they need to change the vessel type of the vessel (too many people don't really read the contract parameters). To make it even worse, the UI for changing a vessel type is horribly unintuitive (double click name in info panel of map view, or right click a random probe core and hit rename).

CelestialBody.GetWorldSurfacePosition() just does some fairly simple trigonometry, it doesn't use the PQS system at all (but you need to provide an altitude). If the collider is loaded at the given latitude/longitude, then you could use it to raycast straight down from a specific altitude that is above the max terrain height and get the terrain height at the given position that way. However - this is what I was warning you about - I doubt that colliders are loaded for very far from the active vessel. Tens of kilometers is probably fine, but I suspect if you try to do this hundreds of km away it'll just return no hit (or maybe a default hit at sea level? haven't really looked into planetary colliders much). Yikes. There has got to be a better way to move a vessel that's on rails. Looking at the persistence file, the stuff that I see that would need to be changed on a teleport are lat, lon, alt, nrm (normal vector for vessel's "up"), rot (quaternion for the vessel's rotation) and ORBIT. All of these are calculated in my code for SpawnVessel. Some are done directly in the config node before writing it though - those one you'll have to figure out how to get them to change in the protovessel if they are needed for what you are doing.

One could say the same about rep! That being said I agree that post count just doesn't seem to be as interesting a metric. I'm a geek when it comes to this kind of statistics though. There's far more interesting metrics to look at. Ratio of rep to post count, ratio of rep to how long a user has been on the forum. Ooooh, and then there's stuff you can plot or make infographics out of. Number of members for various countries. New members per day vs. KSP update release dates. And don't even get me started on how interesting it would be to have statistics from the game itself. How many people play career vs. science vs. sandbox? How long does a game last on average? What mods do people have installed? What parts are the most/least used? I know a lot of people get kinda freaked out about data collection & privacy (which is a legit concern), but if done correctly (anonymized and aggregated) it can give a developer a lot of useful info on what changes need to be made in their game.

From the linked article: And that is why I scratch the game development itch with modding. The fact that "getting people to work for free" is even a consideration is astounding. No, I'll stay with my current job that puts food on the table, thank you very much.

Since you can sort the member list by post count as well as rep count, I imagine it'd be pretty trivial to modify magico's program to do a post count extract.

Right - which is why I recommended it in a coroutine with a per-invocation time limit as in my example.

Looks like we're solving different problems, and to be honest I'm not sure which one is the one that WhiteCat is looking to have solved. I assumed he is looking for navigation on a global scale (ie. get from point A to point B halfway across the globe). I also assumed that it needed to work when not focused on the vessel in question. Under those restrictions, I don't imagine the raycasting would work (I have no idea how/when the colliders for the celestial body are loaded, but assume they're only loaded for a fairly localized area around the active vessel. And totally agree with you - the calls into PQS are a massive performance hit - but I don't see any better options if the restrictions above are correct. So WhiteCat - if indeed you need localized navigation, then the solution stupid_chris provided is far better than mine.

Have a look at the BiomeTracker class in Contract Configurator. It's used in the science subsystem to come up with a rough estimate of what proportion of a given biome is water by sampling points. It samples a 2048 x 4096 array of points, and completes in the background within a minute or two on my machine (to give you an idea of the slowness of this method). In my case I just store the aggregated value (biome + the ratio of it that is water). double lonRads = Math.PI * longitude / 180.0; double latRads = Math.PI * latitude / 180.0; double cosLon = Math.Cos(lonRads); double sinLon = Math.Sin(lonRads); double cosLat = Math.Cos(latRads); double sinLat = Math.Sin(latRads); Vector3d radialVector = new Vector3d(cosLat * cosLon, sinLat, cosLat * sinLon); double height = body.pqsController.GetSurfaceHeight(radialVector) - body.pqsController.radius; There's also a CelestialBody.GetSurfaceNVector(lat, lon) method that is a bit easier coding-wise - can't remember why I didn't use it in the BiomeTracker code, this might've been slightly less expensive. Or it was because I had the numbers in (u, v) coordinates, so it was easier to just do it manually. I'm thinking that if you use this in combination with an A* pathfinding algorithm (only checking for whether a point is water when you examine it) you'll get reasonable enough performance (although I'm 100% sure you'll have to do it as a coroutine). You'll probably also need some added smarts to increase the search resolution when you hit a "wall" - otherwise you'll by trying out too many points and performance will suffer, or you won't be at a detailed enough resolution to find the rivers/inlets. EDIT: Oh and when I say it takes a couple minutes, that is in a coroutine that is limited to 0.01 seconds per invocation - that way it falls beneath the player's notice in terms of the performance hit.

Hmm... I feel I need to provide a link to Anomaly Surveyor. Contracts for visiting all the Easter eggs, plus one very big bonus Easter egg introduced by the contract pack itself.

Just have to pop in to say that I absolutely love the reflective visor in TextureReplacer. Also, teaser for what I'm working on (new contract pack): Val sees dead people...

I can't say too much more without seeing what contract packs you have installed. A log file, screenshot of the Contract Configurator debug menu (alt-f10) or listing of your GameData/ and GameData/ContractPacks directory.

Contract Configurator doesn't remove any contracts - but gives the ability to remove contracts. It's probably a specific contract pack that is giving you grief (perhaps the Advanced Progression one?).

Correct. I missed that the first time I looked at this one. EDIT: Also, the Duration won't be optional in this set-up, but I don't think there is a way to have it optional without going back to the VesselParameterGroup (as we discussed a few pages back ) - - - Updated - - - The first one is wrong, the second right. You can still add the ExcludeAll. EDIT: To expand on this, you have it reversed (the List<> should feed into the single value). Basically exactly what you have in the second one.

The expression behaviour changes that allow you to have any type (introduced in 1.7.x) will help you here. I'm thinking something like this: // Track the bodies that this contract has been completed for BEHAVIOUR { type = Expression // The CONTRACT_COMPLETED_SUCCESS node gets executed when the // contract is completed successfully. CONTRACT_COMPLETED_SUCCESS { type = List<CelestialBody> DummyList = [ @/targetBody ] NoriContractCompletedBody = $DummyList.Concat($NoriContractCompletedBody) } } // Add in an exclusion for anything where there contract has already been completed DATA { type = CelestialBody activeUniqueValue = true validTarget = AllBodies().Where(cb => cb.SemiMajorAxis() < @/smamax && cb.SemiMajorAxis() > @/smamin && cb.IsPlanet() && cb.HaveReached() && cb.HaveLandedOn() == false && cb.IsHomeWorld() == false).[COLOR=#ff0000]ExcludeAll($NoriContractCompletedBody).[/COLOR]Random() } I haven't tested the above, so it may not work. The reason I do stuff in a bit of a weird way is due to some parser limitations. If it hasn't initialized $NoriContractCompletedBody, it won't know what type it is, which means doing $NoriContractCompletedBody.Something() won't parse. There's a chance the way I did it above won't work either... but this way probably has the best odds. Oh and a quick tip - if you seperate the validTarget into two (ie. break out a List<CelestialBody> called validTargets), you'll be able to see its list of bodies in the debug window - might help you in testing/debugging.

I check subscribed threads frequently (and I have a lot of subscriptions).

I may have to go and document up some stuff around the Duration, as the recommended way to do this has changed (NathanKell came up with some more issues that needed a fix). So the recommendation for what you're trying to do would look like this: PARAMETER { name = Orbit type = VesselParameterGroup title = Orbit @targetBody PARAMETER { name = NewVessel type = NewVessel } PARAMETER { name = HasCrew type = HasCrew minCrew = 1 } PARAMETER { name = Orbit type = Orbit minPeA = @targetBody.AtmosphereAltitude() * 1.1 PARAMETER { name = Duration type = Duration duration = 1d preWaitText = Orbiting for a day will provide us with some valuable data. waitingText = One more day should do. completionText = Excellent, this will be very helpful. rewardFunds = 6250 / @targetBody.Multiplier() rewardScience = 2 / @targetBody.Multiplier() } } PARAMETER { name = ReturnHome type = ReturnHome completeInSequence = true } }

There isn't a simple answer, as it depends how the contract pack does its progression logic. If it does it by contracts (you have to do contract A to get contract , then you can clear all your completed contracts through the alt-f12 debug menu. If it uses any other mechanism (KSP internal progress tracking, "state" variables), then you need to do some save hackery, and you'd need to understand what the contract pack in question is doing to do it right.

Oh, I see... that would make it easier for the players to do transfers to moons, too.

Should be possible. ReachState supports a biome, so that covers a contract parameter for things like "Landed at the Mun's Highlands". You can get a list of biomes for a CelestialBody using the Biomes() method (eg. @targetBody.Biomes()). There's no way to tell which biomes a player has visited, aside from which biomes they've done science in. That gets a bit more complicated, but you can have a look at Field Research, it should have lots of examples that are pretty close to what you want.

I doubt there's anything that can be done by Sigma for the contract issue. The intention for those contracts was never to have them available for a barycenter (which wasn't even a thing in KSP when they were written). So I think I can do a few checks in Contract Configurator to make it work better with Sigma Binary (raised #317). First, can you confirm that a typical binary system will look like this (sounds like it from the descriptions)? [COLOR=#333333][FONT=Consolas]Sun [/FONT][/COLOR] \- DunaIke |- Duna \- Ike So what I'll do is eliminate anything that has a radius less than say 5m from the lists of celestial bodies that Contract Configurator uses. I'll also need to do some magic to decide what to define as a "Planet" vs. "Moon" for the children of the barycenter. I'll probably just make the most massive one the planet, and everything else a moon (although I can probably support co-planetary systems too). Oh, and for RemoteTech specifically - it has an occlusion check. So it is most likely considering Duna as occluding DunaIke. So there's no way to get coverage no matter what you do.

The question is sort of vague, I'd recommend reading the wiki and asking more specific questions. In general, there is some stuff you can do around biomes, mostly around science. Doll the answer is most likely yes. Other stuff that isn't there might be easy to add - all depends on what you're trying to do.