DMagic

Well, it should fix the problem, but I still don't understand why it's a problem some of the time but not all of the time. I won't get a chance to test this for a while, by Friday at the latest, but the Kopernicus fixes might totally break things if something goes wrong, so I'll need to check those before releasing anything. But most of the changes are minor, so I should have the next update ready by the weekend.

I've started putting together a list of contract packs and loosely sorting them: Google Docs My criteria right now are (there might be too much overlap for such broad categories): Progression: Early (those that focus on Kerbin-based missions, or that are explicitly labeled as early progression) and Late (those that encourage you to go to other planets) Random: Unmanned or Manned (these are missions that I consider to be somewhat similar to stock; ie based on contract difficulty they ask you to do something at a planet you have already been to or that KSP thinks is "next") Story Mode: These are guided (non-random) missions that have some type of story element to them Mod-Specific: These are things like the RemoteTech or SCANsat contracts that require another mod My thinking is that the progression-type and some random-type contracts are best suited to CCF. Mod-specific contracts don't seem like a good fit (unless they are paired with a mod that specifically addresses career mode progression), and story mode contracts might not fit well either (thoughts on this?). Right now there are several packs that seem to fit in nicely for CCF: GAP for early airplanes Maritime Missions for boats (not sure about the status of this after KSP 1.0.5) Whyren's Rover pack for rovers (with possibly another set for early rover construction; also Whyren doesn't seem to have been around for a while) severedsolo's Space Station packs (maybe Kerbin Space Station rather than Useful Space Stations, which seems to have been discontinued) CosmoBro's Base pack (which seems to have been merged with KSS) I'll need to look into the specific contracts offered to make sure they fit well and are up-to-date, but this seems like a good enough starting point. Also, does anyone know of any other non-Contract Configurator packs? So far all I have are Orbital Science, Tarsier Space Tech (these two offer more in-depth, or experiment-specific versions of the stock science contracts, mostly), and Mission Controller 2 (not sure where this one fits in). Edit: New Google Docs Spreadsheet with CCF progression categories (with a bit more fine-grained groups) and any matching contract packs.

This will be fixed in the next update. That's what I was thinking too, though I thought that the IsEnabled flag in the part module meant that it was activated. And using OnFixedUpdate was working fine the last time I tested SCANsat. In any event, I've switched to Update and FixedUpdate for the next version. I'm also working on fixing Kopernicus support and a few other minor things.

The SCANmechjeb assembly isn't an issue, it's just doing what it's supposed to do when MechJeb isn't installed. And I don't see any reason why a different store version of KSP would matter. Everything else in the logs looks fine. So the scanners work, the animations work, and the buttons work, but it isn't using power or updating the SCANsat Altitude field? That is very strange, it's like the OnUpdate method is working but OnFixedUpdate isn't. Can you check in your persistence file to see if the SCANsat modules on that vessel show IsEnabled = true? I can't see why they wouldn't be, but I don't really understand what's happening.

Does this use any KSPField's to signify some type of damage level? Like a 0-1 (or 0-100) float for damage percentage. Something like that would allow for other mods to easily grab said value from the KKS partModule and alter a part's behavior.

That's odd, does it happen on all of the experiments? Did you set the usageReqMaskExternal = 8 in all configs? That should limit EVA activation to scientists (this is handled by stock code, not me). Also, while checking this out, I discovered that I think you can require that the experiment be part of a vessel that has a control source. The usageReqMaskExternal field is a bitmask; the available options are: Never = -1, Always = 0, VesselControl = 1, CrewInVessel = 2, CrewInPart = 4, ScientistCrew = 8, So if you set the value to 9 it will require that the EVA vessel be a scientist and that the experiment part be on a vessel that has a probe core or command pod. I assume this would allow you to prevent people from trying to activate debris. If you set it to 2 or 4 I think it will allow any EVA Kerbal to activate the experiment.

Any changes needed on my end? I'll try to update my thread with the latest version tonight or tomorrow in case some one needs it. @AlbertKermin: when you're using Word just make sure to turn off the auto-reverse quotes and apostrophes, that way you won't end up with those weird characters.

@inigma: I'm not sure how qualified I am to handle anything related to part balance. I, uh..., don't really play KSP much, so I'm probably not a good judge for that kind of thing (my method for balancing science with Orbital Science is to not really try...). I could take a look at the contract packs available and try to make some sense of those, though. I mostly keep up to date with Contract Configurator (and I'm only aware of a few contract packs that don't use it) so that could be something I can handle. I think the idea is to provide standards and configs to allow for stock and mod parts to work together and maintain some semblance of balance, rather than forcing one particular set of parts. I don't think anyone said that this project should be all-inclusive, there are probably plenty of mods that don't make sense for a somewhat stock-alike career mode. If people don't want to contribute they don't have to. And if people want to have a pack included that isn't already supported they can introduce their own adjustments. The mod author doesn't have to do anything, that's what Module Manager is for.

No. SCANsat resource scanning functions irrespective of standard SCANsat scans, if one type functions properly then all types should function properly. The only way that stock M700 bugs might affect SCANsat (and again, the only way that I'm aware of for these M700 transmission bugs to occur is when using an unpatched version of ScienceAlert or RemoteTech) is when you haven't disabled stock scanning. If the stock scan hasn't been completed SCANsat can't do anything about it. If you disable stock scanning then it should work fine. Does it work at all, is it scanning and saving data? That looks like a problem with SCANsat not being properly initialized the first time it was run. The only way I know of to cause this is by using one of those mods that let you skip the space center scene and load directly to a vessel or the editor (I think substituting a quicksave file for you persistent file might also be able to cause this).

If you disable stock resource scanning (and have Module Manager installed) and use SCANsat resource scanners then whatever weird stock issues are preventing resource scans from completing shouldn't cause any problems. As far as I know the issues with the stock scanner relate to the transmission not completing (and I think this is always due to other mods breaking the transmitters) which prevents the scan from registering; and that the overlays don't work in the tracking station, which isn't really related to anything here. SCANsat scanners don't care about any of that (there is one problem that I can think of with Hyperedit - if you have never visited that planet before, and only use Hyperedit to get there, SCANsat might not register scanning, simply opening up any SCANsat map while at that planet should be enough to initialize everything). With stock scanning disabled you can scan with the M700 or the Narrow-Band scanner; there is no required scanning order.

Which behavior would that be? Did you read the SCANsat wiki to find out if such behavior is expected?

Turn off stock scanning, biome lock and the narrow-band requirement. Then carry around a narrow-band scanner for hi-res ore scans, no need for the M700 dish if you don't want it. Hi-res resource scans are saved by SCANsat the same as any other scan type.

Did you right-click on the flag? That will trigger an error.

Well, yes. But you could really use any big vessel to do that. FRAPs works for Windows, I don't think I've tried it in 10, but it should still work. The test is to show how performance varies with part count, with the new unload distances most of the run occurs with almost all of the parts, then most of them unload all at once, which isn't as useful. I haven't taken the time to go through this and figure out again how to set the unload distances to be exactly the same as pre 1.0 (I think the "beta ranges" values should be the same as before), and there is a bunch of stuff that keeps this limited to specific vessels, but it's fairly simple: using System; using System.Collections; using System.Collections.Generic; using UnityEngine; namespace CPU_Test { [KSPAddon(KSPAddon.Startup.Flight, false)] public class CPULogger : MonoBehaviour { private const string vesselName = "CPU Bunga Bunga Plane"; private const string vesselNamePlane = "CPU Bunga Bunga Plane Ship"; private Vessel mainVessel; private VesselRanges.Situation flyingRanges = new VesselRanges.Situation(200, 250, 750, 200); private VesselRanges.Situation defaultRanges = new VesselRanges.Situation(200, 250, 50, 40); private VesselRanges.Situation suborbitalRanges = new VesselRanges.Situation(200, 500, 250, 40); private VesselRanges.Situation planeRanges = new VesselRanges.Situation(2250, 22500, 25000, 200); private VesselRanges.Situation betaRanges = new VesselRanges.Situation(2250, 2500, 5000, 200); private VesselRanges.Situation betaLandedRanges = new VesselRanges.Situation(2250, 2500, 350, 200); private void Start() { if (FlightGlobals.ActiveVessel.vesselName != vesselName) Destroy(this); initialize(); } private void initialize() { print("[CPU Logger] Starting Up CPU Test Run..."); GameEvents.onNewVesselCreated.Add(vesselCreated); GameEvents.onVesselCreate.Add(vesselCreated); mainVessel = FlightGlobals.ActiveVessel; mainVessel.vesselRanges = newRanges(true); } private void OnDestroy() { GameEvents.onNewVesselCreated.Remove(vesselCreated); GameEvents.onVesselCreate.Remove(vesselCreated); } private VesselRanges newRanges(bool plane) { VesselRanges range = new VesselRanges(); VesselRanges.Situation flight = plane ? planeRanges : flyingRanges; range.flying = flight; range.subOrbital = suborbitalRanges; range.landed = defaultRanges; range.escaping = defaultRanges; range.orbit = defaultRanges; range.prelaunch = defaultRanges; range.splashed = defaultRanges; return range; } private void vesselCreated(Vessel v) { StartCoroutine(unloadRange(v)); } IEnumerator unloadRange(Vessel V) { int timer = 0; while (timer < 20) { timer++; yield return null; } if (V.vesselName == vesselNamePlane) { V.vesselRanges = newRanges(true); print("[CPU Logger] New Plane Created - Setting Plane Unload Ranges : [" + V.vesselName + "]"); } else { V.vesselRanges = newRanges(false); print("[CPU Logger] New Vessel Created - Setting Debris Unload Ranges : [" + V.vesselName + "]"); } } } }

Those aren't CapCom problems, they are issues with stock contracts not fully initializing when you accept them, you'll have to save and reload to activate them. Celestial Bodies and Vessels aren't fully loaded while in the editor, so there is a lot of potential for errors when changing contract status there. I suppose I could set CapCom to be in a passive mode while in the editor, just to let people see the offered contracts.

Basically, yes. You can read more on SCANsat and stock resource scanning on the wiki. I'm not sure why the stock resource maps aren't working in your case, SCANsat shouldn't be doing anything to affect that with your settings. It could be related to Hyperedit (which shouldn't cause problems with SCANsat).

What are your SCANsat resource settings? It might be normal behavior; and as I said a few posts up, I plan on changing the way that the resource readout works for low resolution resource scans.

It doesn't work in 1.0; changes made to how parts unload while in the atmosphere make it so the majority of the flight occurs with all of the parts still loaded. I'm waiting for 1.1 to make a new test craft and deal with the part unloading problem.

The only time that SCANsat's orbit tracks won't work is when you haven't upgraded the tracking station. The level 1 (0?) tracking station locks out necessary functions for calculating the next orbit.

I'm not really sure either, still. I haven't seen a clear answer if the intention of this is to point to a set of configs (tech tree, re-balance [both stock and mod], contracts) and say that CCF builds off of those, or if the intention is to simply say that this and that are supported by, or are compatible with, CCF. It seems to me that the tech tree is such a core component of career mode that you can't really provide any type of balance or progression without nailing that down first. Some other aspects of career mode, such as contract packs (or, from the sound of it at least, nightingale's strategy mod), make more sense to leave them as suggested or recommended. It's easier to point to contract packs that focus or different types of craft, or that encourage exploration and progression in a certain way and just say that they are supported, without greatly affecting other aspects of career mode.

That's normal; see the RPM controls below, the controls for the ALCOR panels can be found on the first post, and the GitHub readme.

Do you have it set to alter active contracts? Did you adjust the science return for the (part?) test contract, or the test parameter, or both? It should be working correctly, I'm not aware of any problems, other than some weirdness that can happen if you repeatedly toggle the alter active contracts option on and off while changing values. If you keep having problems can you send me your log files (KSP.log, or output_log.txt)?

1. Is 64 experience level 5? The number on the left is how much experience you have, which doesn't stop growing after reaching level five. 2. The values after each entry represent the amount of experience for that entry, so you get 13 experience for planting a flag on Duna (this represents the total amount of Duna experience, not just the amount for planting a flag). 3. Same as 2. Note that these entries are generated with stock code, not by me (also note that this stock system rounds each value to the nearest whole number, so the actual amount might be higher or lower). The entries under career log should be exactly the same as what you would see in the astronaut complex. The flight log entries use the same system, they just represent the things you've done in the current flight (so you won't necessarily get the amount of experience listed for each entry). The way that the experience system works is that there is a max amount for each planet, which you can achieve only by planting a flag on the surface (which is a system that I hate...). When the flight log says Orbit around Duna = 8 (or whatever the amount is) that means you'll get 8 experience from Duna if you return to home at that point. If you plant a flag you'll get 13 experience from Duna; the values don't add up, you don't get 6 from a fly-by + 8 from orbit + 10 from landing, etc... You just get the highest value. And yes, you can disable either or both tooltips using the config file as you have described above (and if you disable the experience tooltip the stars won't show up in science or sandbox mode, where everyone starts at level 5).

Yep. Also, the sensor pods have a very high impact tolerance, you can get away with ejecting one while landing in most cases, as long as it lands before you get out of physics range (2.5km in vacuum, 22km in atmosphere). Though if you don't want to really go crazy you should fix the error in the hammer and sensor pod config files so that they can be used repeatedly (set rerunnable = True).

Old versions aren't supported. Screenshots? This sounds like the RemoteTech/ScienceAlert issue with resource scanner and science lab data transmissions. Does stock scanning work at all? Try it with default SCANsat resource settings or without SCANsat at all. This: And you can try disabling the Narrow-Band Scanner Requirement for now. I have plans for adding a simplified resource concentration cutoff adjustment to the planetary overlay window (something similar to the stock system, but without that confusion generating system of using different percentage scales for the cutoff...) and for adjusting how the tooltip and resource readouts work without a Narrow-Band scanner;I just haven't gotten around to it.