voidheart

Hi all. I'm using Stock resource scanning for the first time in conjunction with UKS and I'm running into a problem I haven't seen described elsewhere. When I "Perform Orbital Survey" I don't get any complaints, and my antenna dutifully transmits without running out of electricity. However, nothing else happens. I can't access the resource overlays (no data), the SCANsat big map doesn't show any resource information, and SCANsat status window showing the LAT, LON and current altitude all says NO DATA for all resources. I've jumped across to a Satellite with a Planetary Survey Camera and it's UI still complains that an Orbital Survey needs to be done. I'm not sure, but I get the impression I'm supposed to see a "Orbital Survey Complete" message after my antenna stops sending. I can repeat the scan as many times as I like, without any change. I'm using a M700 at 150 km (at 90 degrees inclination) above Kerbin. I see references to requiring a narrow band scanner, but my understanding is this is just for high resolution scans. When I turn the scansat overlays for Biome etc they all work great. I'm using a few mods, but not Science Alert. My version of SCANsat is v14.7. can anyone point out a silly mistake I'm making, or can you suggest further information I might be able to provide? Thanks for any help.

Same here, I'm wondering if the recent OKS/MKS releases have any implication on MCM? (guess I'll find out )

I think I might have found a bug here with the Sequence parameter type. I tried your suggestion and a thousand other things to make sequence respect a disableOnStateChange=true but couldn't do it. The parameter would always complete and then uncomplete when the condition became false. I switched to SequenceNode and my problems immediately went away. Here is my demonstration contract. To be clear, the potential bug is that disableOnStateChange behaviours don't work in Sequence parameter types. (Posted here for someone to spot something silly before I raise a bug) CONTRACT_TYPE { name = SequenceTest title = Test How to make sequence requirements work description = test 8 notes = test synopsis = test completedMessage = test prestige = Trivial targetBody = Kerbin rewardScience = 0.0 rewardReputation = 5.0 rewardFunds = 10000.0 failureReputation = 5.0 failureFunds = 10000.0 advanceFunds = 5000.0 weight = 10.0 // Doesn't work. ReachState1 becomes uncomplete after being completed PARAMETER { name = LaunchAndPullSequence type = Sequence PARAMETER { name = ReachState1 type = ReachState maxAltitude = 100 disableOnStateChange = true } PARAMETER { name = ReachState2 type = ReachState minAltitude = 500 } } // Works fine (first/ReachState1 stays completed) // // PARAMETER // { // name = first // type = SequenceNode // // disableOnStateChange = true // // PARAMETER // { // name = ReachState1 // type = ReachState // // maxAltitude = 100 // } // } // // PARAMETER // { // name = second // type = SequenceNode // // PARAMETER // { // name = ReachState2 // type = ReachState // // minAltitude = 500 // } // } }

Looks great and I am about to give it a try. Any chance of seeing this on CKAN?

Thanks for the fast and extensive feedback. I'll give it a try when I get I get a chance (need to get some regular KSP hours in right now). I will also review the documentation to see if there are tweaks which would have prevented my confusion. I hope you don't mind but I've already used the edit feature of the pages to make a tweak. If you don't object I'll continue to do that when I notice something. Not at all

I'm building a contract pack called Better Parts Testing It lives on Github at https://github.com/bendavieshe3/ksp-cc-better-parts-testing On my very first contract though, I have a bit of problem. It is a parachute contract where the user is expected to launch a vessel, attain a minimum altitude (20,000 m), and then let the vessel descend until a sensible testing point (2000-6000m). Unfortunately the initial altitude requirement is uncompleted when the vessel descends below 20,000 m. I've been trying to use disableOnStateChange in different places and with different values without success. See the contract below. Any ideas? Thanks for any help // Better Parts Testing parachute contract // For use with Kerbal Space Program (https://kerbalspaceprogram.com/) // And Contract Configurator (http://forum.kerbalspaceprogram.com/threads/101604) // Github https://github.com/bendavieshe3/ksp-cc-better-parts-testing/ CONTRACT_TYPE { name = SimpleParachuteTestingContract title = Test Basic Parachute Operation description = It is no surprise that what goes up frequently comes down. When it does it tends to explode. We believe fitting vessels with a parachute is one excellent way to prevent this. We need someone to test this theory. This, of course, is where you come in. notes = Parachutes are a relatively inexpensive way to decelerate vessels attempting landings on bodies with atmospheres, including Kerbin. Parachutes can be deployed directly or via the staging system. It is generally not a good idea to deploy parachutes too early. synopsis = Launch a vessel to the minimum height and land it safely on Kerbin using a parachute completedMessage = Congratulations! You've learnt basic parachute usage! // Contract min/max expiry in days. // minExpiry = 7.0 // maxExpiry = 30.0 // Contract deadline in days. Default is no deadline. deadline = 30 cancellable = true declinable = true prestige = Trivial targetBody = Kerbin maxCompletions = 1 maxSimultaneous = 1 // Contract rewards // TODO: Find multiplier reference rewardScience = 0.0 rewardReputation = 5.0 rewardFunds = 10000.0 failureReputation = 5.0 failureFunds = 10000.0 advanceFunds = 5000.0 // TODO: Change back to 1.0 after testing weight = 10.0 PARAMETER { name = LaunchAndPullSequence type = SequenceNode // The title to display // Default: Complete the following in order //title = // Vessel should first reach at least 20K meters PARAMETER { name = ReachGoodAlt type = ReachState minAltitude = 20000 } PARAMETER { name = TestAtTheParachuteAtTheRightTime type = All title = Test the parachute 2000-6000 meters above sea level // Vessel should be at reasonable altitude and speed PARAMETER { name = ReachGoodAlt type = ReachState minSpeed = 100 maxSpeed = 450 minAltitude = 2000 maxAltitude = 6000 situation = FLYING disableOnStateChange = true } // Vessel should have the Parachute tested PARAMETER { name = ParachuteTest type = PartTest // TODO: See if this can be generalised part = parachuteSingle disableOnStateChange = false notes = Test the parachute through the staging system } } PARAMETER { name = Touchdown type = LandOnBody } } REQUIREMENT { name = FirstLaunch type = FirstLaunch } }

I see some lines like this in the log: [ERR 11:23:51.003] ContractConfigurator.ContractConfigurator.HasPartFactory: HasPart is obsolete as of ContractConfigurator 0.5.0, please use PartValidation instead. HasPart will be removed in a future release. Is there any chance of adding the specific contract name or file to this sort of error? With multiple contracts and multiple contract packs tracking down this sort of error to the contract (which might come from somewhere else) might get a bit old

Yes.. there will be questions

Wow, that is a great example of a multi-part contract using the same vessels - its really helpful. Maybe with a bit of cleanup it would be a good addition to the documentation as an example? (unless I have missed something similiar there already )

Actually there is an obvious if slightly brittle way to do this, just add a part requirement from the mod.

I might chuck something up on Github then Do we need a Work in Progress list then? Something perhaps maintained on the second or third post of the thread? I can see a lot of people coming up with similiar ideas and not knowing others are working on the same stuff. The more collaboration around the packs the fewer higher quality ones we will have, the less user confusion etc etc. Random question - I don't think there is any generic way to make a contract mod specific, is there? Regardless of whether deep support is offered, I can think of instances were within a contract pack you might want to offer a specific contract only if the user has or has not got a specific mod installed. Just wondering

Right. Everything makes some sense now Thanks for your reply. Hopefully the two contract-packs can be combined (or have known, different flavours) so users don't end up making a Coke/Pepsi choice. I am really interested in ContractConfigurator and am fooling around with a few potential packs of my own, but my time is limited (mostly by my desire to play KSP in the time I do have). I wonder if there is any interest among others in helping me out (so the question is, should I share early or wait until I have something beta-ish?). The contract packs I'm working on: 1) Into the Black - Extra Progression Contracts beyond LKO 2) Better Parts Testing - Parts Testing Contracts that actually teach you how to use the Parts (and Play KSP) It might be a better use of my time to contribute to other's contract packs though, so we'll see. Last night for example I was really wanting just to fix some of the deprecation warnings on the other SCANsat pack to reduce the noise in the logs. I'm also interested in more specific mod themed contracts to help demonstrate how to use the mod. There are a lot of mods that might otherwise be installed and not fully exercised or explored.

Hi, Can anyone tell me (or point me to something describing) how to use the 'Interstage' parts? What are they for? I assume I can place cargo in them (like the petal adapter?) or are they more like inline fairings? I'm not sure how I should be placing them (they always want to overlap parts above above and below), how I should be attaching the payload or how it behave when working properly. Any information would be great!

Firstly thank you for authoring the SCANsat missions. I'm a bit confused about your current release. Or rather what is the current release of this package. I guess your github above is authoritative (and I can see recent activity) but my view of CKAN* has seriously confused me. I'm not sure if you see something different in the GUI version of CKAN but when I run a search for SCANsat I see this: ContractConfigurator-ContractPack-SCANsat ContractConfigurator-SCANsat SCANsat I had 'ContractConfigurator-SCANsat' installed, which reported itself as 1.0.2. It was in what I think was the old location, \gamedata\cc_contracts. I just installed 'ContractConfigurator-ContractPack-SCANsat', which reports itself as 0.4.0, which seems to be in the new (common) location of /gamedata/ContractPacks. Moreover it seems it to use the newer parameters (and even mulit-spectral scans etc - yay) BUT has different file names (like 'MonLoRes.cfg' instead of 'ScanMun.cfg' as in your GitHub.) None the less, it definitely seems to be your mod (you are identified at the top of each file). Could you help me out and let me know which is the most current? - The 1.0.3 version from Github? - The 'ContractConfigurator-SCANsat' @ v1.0.2 on CKAN? - The ContractConfigurator-ContractPack-SCANsat' @ v0.4.0 on CKAN? This is also a PSA that the situation is bound to be a bit confusing for others too, and they might not see any updates you push using CKAN. * My view of CKAN is through the command line client - latest and updated just now. Thanks again for your work PS. I feel bad getting support for your Contract Pack on the Configurator thread, maybe start a new one (or point me to it )

Sorry, looks like this is fixed now. It reads 'Above 70,000 m'. Thanks for the reply!