DMagic

I finally got around to figuring out exactly what all of the "value" fields are in the persistent file. Each contract's final entry (before anything custom added in the save method) is the "value =" string, with a 12 comma delineated entries. From left to right these are: (I think the time fields are doubles and the rewards are floats) 1: Time in seconds until an offered contract expires 2: Time in seconds of a contract's duration after it is accepted 3: Funds: Advance payment 4: Funds: Completion payment 5: Funds: Penalty amount 6: Science: Completion reward 7: Reputation: Completion reward 8: Reputation: Penalty amount 9: Universal Time: Time in seconds when an offered contract will expire 10: Universal Time: Time in seconds when the contract was accepted 11: Universal Time: Time in seconds when an accepted contract will end 12: Universal Time: Time in seconds when a contract was failed/expired (I don't think this triggers for successful completion) And the contract parameters: 1: Funds: Completion payment 2: Funds: Penalty amount 3: Science: Completion reward 4: Reputation: Completion reward 5: Reputation: Penalty amount The last few entries on the contract's value line are particularly useful if you are testing something and don't want to reset or start a new contract. You can just edit the time values and continue on with the same contract.

I guess you'd have to pass variables up and down from contract parameter, to the contract, then back down to the next parameter. If you want to block someone from using the same vessel for parameters one and two you could have a null vessel in the parent contract. Then set that vessel whenever the firsts parameter finishes. Then have the the second parameter check the parent contract's vessel property. If the contract's vessel is null then the second parameter can't complete, if the current vessel is the same as the contract's vessel then the second parameter can't complete, only when the vessel is not null, and different from the first could the contract complete. You would just have to make sure to save and load all of this information so it doesn't get lost.

Thanks Donziboy2. It looks like a small, but noticeable increase going from x86 to x64, though the biggest difference comes later on when you're already at very high frame rates. EVE knocks performance down a bit, but again, it's mostly at the high end where you are already above 60 FPS.

Great, let me know about color choices. Sometime I'd like to get some kind of color selection built into the SCANsat ORS resources, preferably through some kind of config file. I think handling the same way that Kethane resources do would work well, just taking an "empty" color and a "full" color and lerping between them based on concentration. It's an area of active discussion right now. We'll be turning this dev build into version 8 and releasing that soon in the main thread, so if anything happens it will happen then.

This was essentially how ISA worked, it just saved the map as a texture, and as such it was a huge memory hog. That's the trade-off, you can swallow 100's of MB of RAM, or you can have this slow method that's fairly light on RAM. I have some ideas for improvements, but haven't really worked on SCANsat recently.

Do you know how you're actually going to implement this? If these models are PQSCity objects they'll be detectable as anomalies, which would be really cool.

That's very cool Nertea. The terrain height data from SCANsat is stored in a cache, but isn't directly accessible from outside assemblies. There's no real reason for that though, and it would be simple to make that (it's just a big 3D float array) public, or publicly readable. There is already a very easily accessible public method for checking if an area has been scanned (it was added to make for easier integration with Science Alert through reflection); adding another would be no problem. The bigger problems are that SCANsat's caching is kind-of crap, I'm certain there are much better ways to do it and it will probably change at some point. And that terrain height calculations are very slow when done in such large amounts. I'm not sure what kind of resolution you would need to get a good looking terrain overlay in the map view; it could be a problem if it requires something very high resolution.

Yeah, the tech tree placement is always subject to revision, I'll think about moving these combined experiments around a little. The specific issues Teeton was detailing are, as far as I know, standard behavior for Science Library. But yes, the changes I made will prevent my experiments from showing up or being deployed in Science Library.

Do you mean this module: http://forum.kerbalspaceprogram.com/threads/65364? There is no reason why it couldn't be included with Karbonite.

This isn't an error, it's a message telling you that ModuleResourceConverter wasn't compiled properly. If ModuleResourceConverter wasn't compiled using .NET 3.5 it could cause problems in KSP, removing ModStats won't do anything but hide this message.

I haven't heard any complaints; it should work fine.

I was curious about the multipliers used for setting rewards and penalties for contracts so I just printed out results from each body with all values set at 1. If you set a Celestial Body in the methods for this (setFunds, setScience, etc...) it multiplies whatever number you put in a by a certain value. I don't know if these numbers are stored somewhere like the science multipliers, that would be nice for people who want to reduce rewards. Edit: Actually, they are affected by contract prestige too. Those values are: Prestige: Trivial Significant Exceptional Sun: 4 5 6 Kerbin: 1 1 2 Mun: 2 2 3 Minmus: 2 3 4 Moho: 7 9 10 Eve: 5 6 8 Duna: 5 6 8 Ike: 5 6 8 Jool: 6 8 9 Laythe: 8 10 12 Vall: 8 10 12 Bop: 8 10 12 Tylo: 8 10 12 Gilly: 6 8 9 Pol: 8 10 12 Dres: 6 8 9 Eeloo: 10 12 15

It works fine for me. Any more specifics? If you toggle the US parts on and off repeatedly and rapidly it can sometimes screw up the animations, but otherwise it should always play both the magnetometer and the science bay animations.

I think the principal problem with biomes is that there is no stock method for determining which biome you are in. This encourages tedious click spamming, dropping in and out of timewarp, and, worst of all, getting in and out to check EVA reports. I think SCANsat in combination with Science Alert provides the ideal solution to this, but that's not stock, and until there is a stock solution to this biomes will continue to be problematic.

Renaming any of the Squad or mod folders is a very bad idea. Many of these mods, even parts-only mods, require that the files be in a specific folder. Renaming or moving the folders will break these mods or prevent parts from loading. There are mods available that help organize the VAB part list, if that's what you mean by being confused about which parts are stock. Using those is a much better option than renaming folders.

I've been working on several contract types for the next update. All of these contracts are only given in limited numbers, preventing contract spam, and all of them require that you at least reach Kerbin space before being generated. When a contract asks for a specific experiment it also checks if the part associated with that experiment is actually available, so no impossible contracts will be generated. There is a config file with settings that allow you to modify the amount of Funds given (and taken in case of failure), the amount of science returned, and the amount of reputation earned. This config file also contains a list of all the science experiments. Each experiment has several values associated with it that are used in assigning different contract types. All of my experiments (except the anomaly scanner, which requires special treatment) and all of the non-Kerbal (this is an unmanned-focused mod after all) stock experiments have been added. Any standard science experiment could be added so long as the proper format is followed. Contract descriptions are also included in this config file, allowing for easy creation of more; they make sense too. The simplest type of contract is just an extension of the regular science contracts. Instead of asking for any science from a particular body these will ask for a specific experiment in a specific location, and biome in some cases. These contracts are selected based on the currently available science parts and your progression through career mode. These contracts aren't repeatable and they are only given for experiments that still have remaining science to collect, ie. they won't ask you to conduct an experiment with only 1 or 2 remaining science points to recover, so it is possible to finish all of them. There are also several survey types of contracts. These contracts ask you to perform a number of experiments from a given location. There are four of these type: orbital surveys, ground surveys, biological activity surveys, and asteroid surveys. These contracts select experiments of the appropriate type from categorized lists and assign a target planet for you to study. Planets are selected based on the contract prestige (the number of stars) and your progression through career mode. Only untracked asteroids can be selected for asteroid surveys. These don't actually consider the amount of science remaining for any given experiment, but since they are only given in limited numbers I don't think that's too much of a problem. I also might reduce the science gain from contract completion based on how much science the experiments actually recover. I'm currently working on anomaly contracts. These will focus heavily on the Anomalous Signal Scanner, obviously, but I also want to incorporate other experiments. The back-end for all of these contracts is fairly similar, so adding different types isn't all that complicated. I have a few other ideas in mind and I hope to have this update out by this weekend with a few other fixes included as well.

I've had a few reports of partModules not being applied to parts with an IVA the way they are supposed to be. I'm fairly certain this is due to the module manager config and load order issues. Normally this just throws an error and prevents saving of SCANsat map data from IVA screens, but a few people have seen crashes that seem to be caused by this. I think you're right that using partModules for persistence storage when the partModule isn't actually integral to the part is a bad idea. I intend to transfer all of this storage over to the SCANsat scenario module and hopefully get around this whole problem.

Download SCANsat from this thread, download MKS from that thread, use the parts included with the mods, follow the example for ORS scanning found on the first page here. If RovedDude doesn't include the config in the Karbonite download then I'll include it here, but I would really prefer that ORS developers handle the scanner modules on their end.

Are you rebuilding the Kethane grid database from the settings menu? Unfortunately there is really no simple way to automatically transfer SCANsat data back to Kethane without creating even more performance issues. On top of that the Kethane grid display won't update with the SCANsat data even after rebuilding its database; with multiple Kethane resources you can just switch which type is being displayed to get it to reset, but with just Kethane you have to re-load, or switch vessels, or something along those lines to get the grid to reset. This will all need better documentation and demonstrations before the main version gets updated.

You don't need anything from this thread unless you intend to create your own ORS-dependent mod. Everything that you need will be distributed with mods using ORS.

SCANsatKethane is very sensitive to changes in the Kethane assembly; if it doesn't fail to load entirely (which is the case here) it runs an explicit check on Kethane's version number and stops if it doesn't match the hard-coded acceptable version number. This doesn't affect the base SCANsat program, it just means that the Kethane overlays won't work. Yes, you need the appropriate scanner part and Module Manager to attache the SCANsat module to that part. The scanning parts are included in the various resource mods.

I've been thinking about this and have re-written most of the code to allow for much more flexible usage of adding experiments to contracts. I've created a one line method that handles all of the science contract parameter generation. You just run it, then check if the parameter it returned is null, if it is then something failed a check (the experiment part hasn't been researched, the science has already been collected, etc...), and if it isn't null then you can add it to the contract's list of parameters. I've been adding several overloads to the parameter generator. You can generate a fully random experiment, or you can specify a planet, an experimental situation, a biome, or an experiment. This allows for the option of say, generating one random parameter, then generating a second with the same planet and biome as the first. If you want to incorporate any properties of the parameters into the contract description, title, rewards amount, etc... then you can easily access them; you just have to save and load the relevant parts if they are needed. So my thinking is that this could be used to sort-of replace or upgrade the stock "explore planet x" contracts, where they ask you to orbit, land, and collect science from both locations. Instead of that generic contract you could generate one or two experiments for a specific biome or location (on the surface for example) then generate way points for those locations. I'm not actually sure how to go about generating way points for a given biome on a planet, but's that's something that can be figured out. The problems I described before about tracking where exactly your experiment was collected still apply, but I don't think that really matters. It would theoretically be possible to ask for experiments from one biome with way points at one location with that biome. You could then collect science data from one area with that biome, then go to the way point in another area with that biome; the contract would still complete, but who cares. There is little functional difference between collecting the science where you are supposed to and going to the trouble of visiting two locations just to trick the system (except that the later is a whole lot more trouble), so I think it would work well enough. I suppose the only real reason for doing this might be to use different vessels to complete each segment of the contract, but that still seems like it would generally be more trouble than doing it as intended.

Use the dev version of SCANsat: http://forum.kerbalspaceprogram.com/threads/80661 You mean the tech node has been researched and purchased in the R&D center but it's not showing up in the VAB? Does it show up in the VAB with the message about not being researched, or does it not show up at all. If the part has been researched in the R&D center this could be caused by having duplicate copies of the part installed in your GameData folder. Make sure you fully deleted the old SCANsat folder if you were updating from an earlier version.

Everyone who has encountered this bug has command pods that aren't loading the SCANsat module for whatever reason. I have no idea why this is still breaking things, and I can't replicate it. It only seems to happen on x64, and I haven't seen consistent behavior in exactly how it is crashing. But I can at least use a more reliable Module Manager config to make sure that the SCANsat module gets added to all parts where it is needed. Can anyone see any issues with this? It should be adding it to everything that has an IVA associated with it and only when RPM is present. It seems to work in some quick tests, so hopefully it at least prevents SCANsatRPM from getting to whatever point it is that causes problems. @PART[*]:HAS[@INTERNAL[*]]:FOR[SCANsat]:NEEDS[RasterPropMonitor] { MODULE { name = SCANsat sensorType = 0 fov = 0 min_alt = 0 max_alt = 0 best_alt = 0 scanName = Eyeball Scan power = 0.05 } } I don't think this is an RPM issue, at least not directly.

Karbonite scanning works fine in SCANsat. Just attach the module manager config I posted earlier to whatever part you're using to scan and it will work like any other ORS-type scanner part.