DMagic

It's in Kerbal Space Program/KSP_Data/output.log

Thanks for this. I'll be adding contracts to my own mod soon and I'll make to sure to post here if I learn anything useful. It would be great if this could be stickied (or maybe moved to the plugin forum and stickied) like the science experiment thread is.

I'm not really sure about the specifics, but I know that this is a common problem when copying the KSP or the Unity default GUIStyles. You can try looking at TriggerAu's GUI framework to see if the methods there for creating new GUISkins helps: https://github.com/TriggerAu/KSPPluginFramework/blob/master/KSPPluginFramework/SkinsLibrary.cs

That definitely looks like a problem, though it's hard to say for sure what's causing it without the full output.log file. You can try deleting, re-downloading and re-installing SCANsat v6.1, maybe something is corrupted. You can also try this out on a clean installation of KSP with only toolbar and SCANsat. Also, if you updated from an older version you must fully delete the old SCANsat folder. Simply overwriting the existing SCANsat folder with the new copy won't work and will leave multiple copies of several files.

Well the icons are there and look ok. If clicking on them doesn't do anything check the debug log (alt + F2) to see if it shows any "null reference exception" entries, or submit your output.log (in the KSP_Data folder) here.

Yes, the old reaction wheels all had 20 torque, including the big one, and the mass values made little sense. Now they are: - Inline Reaction Wheel - 8 torque, 0.12 tons, 600 Funds - Inline Advanced Stabilizer - 15 torque, 0.1 tons, 1200 Funds - Advanced SAS Module, Large - 30 torque, 0.2 tons, 2100 Funds So it looks like they are differentiating the IRS and IAS based on cost, weight and torque now, which is a big improvement from before. The 2.5m reaction wheel is a lot stronger too, which should be helpful.

Pictures or log files? It's hard to say what the issue is without more information. It sounds like there could be a problem with the toolbar.

You would only need it in one mod if everyone used that mod, but that isn't the case. If a dozen or so popular mods add this, then it will cover most of the user base. Having multiple copies of the plugin installed does nothing but add a few milliseconds during the initial loading, so it's not as if this will create some performance issue if someone has fifteen copies installed. And it's only 'tricking' people into using it if they can't read or comprehend a few simple sentences.

I did some more testing; I do see some improvement going from 0.23.5 to 0.24 on the lower end, with possibly a small boost from x64; the improvement is more noticeable at less CPU dependent stages, so there could be some graphics related performance boost here. You can see that the desktop shows no really significant change either way. The x64 results on the desktop were collected using my CPU logging plugin, for whatever reason KSP x64 wouldn't start with FRAPS open, even though it worked just fine on the mobile computer. The CPU logger required an update; you can get it here if anyone is interested: http://www./download/ccddbv8t1oupijt/CPUDatabaseLog_v1.1.zip I didn't run into any catastrophic problems caused by the x64 decoupler issues, in most cases I lost a few SRBs after they were decoupled, but they didn't affect the main rocket, so I think the existing file is fine.

This worked fine for me on a clean x64 install. But your log files cutoff just after the anomaly sensor prints to it (it prints out the exact distance and direction to the nearest anomaly whenever you push the collect data button), so it does seem like it's causing something bad to happen. It does have to go through a bit of math whenever you try to collect data, but it seems like it's getting through all of that if it prints out the information in the debug log. Did you notice if the on-screen message appears after pushing the collect button? It should say something like "Anomalous signal detected approximately 0.5km away to the southeast, get closer for a better signal." in that regular green KSP font. That on-screen message is the last part of that method, and if it's getting through that method there isn't anything afterwards that should cause any problems, at least there isn't anything that really any different from what all of the other parts are doing. I thought this meant removing the entire outer and side walls like the other parts. I see what you mean now though. I'll probably rework my parts a bit to make them attach directly to the side walls where appropriate in the next release. I assume that animation is just a scaling thing like the other mesh toggles (it would be great if the real mesh animations would work), I can probably just activate that automatically from my end without any problems.

There are eight parts included that are already placed inside of the US science bays, as in, they can't be separated from them; these require module manager to use (so does Universal Storage, so this shouldn't be a problem) and they exist as entirely separate parts from the regular, non-US science parts. If you want to attach my regular parts in an empty US science bay they should work ok, I've never actually tried that though. Pictures would help if you're still having problems.

I haven't done any testing in x64, but there's no particular reason why they shouldn't work. If you can isolate anything in particular let me know. The module manager method for handling US parts screws this up a little, since they will revert to unresearchable and be invisible in the VAB after reloading the database in game. That's kind-of nifty. I could always use more surface based parts. Thanks.

There was several weeks of this discussion in the old thread before the changeover. Currently the status of ownership is addressed in several places including: the first post here, license information found in the source code and in the GitHub repository, and as the first section of a very extensive readme file found on GitHub and included in the release package. I believe the plan is to do away with the MapTraq entirely. I'm not convinced that there is any worthwhile reason to keep it around. There isn't any particular need to have SCANsat dependent on a part for background scanning and map access. So the plugin can be altered work without it. It's already there.

I think you want to set guiActive = false and active = true. guiActive is what controls whether the button is visible when you right-click on it while controlling the vessel with the part on it. active is just the global activation setting (I think), so unless you're setting active = true somewhere else, which it looks like you might be doing, then this should be true. And also, you should only need one KSPEvent for both EVA activation and standard activation. The externalToEVAOnly just means that only an EVA Kerbal can activate the KSPEvent while the part is not on your current vessel, it doesn't prevent you from using the regular right-click mechanism. So in that case you would want to set guiActive, guiActiveUnfocused, and externalToEVAOnly = true. This should give you a one method KSPEvent to control the function both while on the active vessel and while EVA.

Update() is called by any Unity Monobehaviour class once every frame. OnUpdate() is a KSP thing that is called by part modules once every frame, but only if the part is activated; this is usually by staging or by forcing activation in your OnStart() method. I've never tried this with KSPFields in a part module. You might have to manually load the confignode in your OnLoad() method, bot not using the default ConfigNode. public override void OnLoad(ConfigNode node) { foreach (ConfigNode part_node in GameDatabase.Instance.GetConfigNodes("Part")) { if (part_node.GetValue("name") == "your_part_name") { ConfigNode[] body_node = part_node.GetNodes("BODY") ...Do something with body_nodes... } } } This would be for non-nested nodes, just BODY{} nodes within your part.cfg file, but you can just go down the chain of nodes if you want to nest them within the module node. As far as I know any config node (which should include the PART{} that part.cfg files use) is added to GameDatabase, so you should be able to access it there. You could, alternatively, just stash your settings in a different config file, instead of adding it to the part.cfg file, the loading method would be the same. As for saving anything in those nodes, I'm not so sure, but it sounds like that's not what you're trying to do.

A quick check on a clean installation of the x64 version shows everything working OK. There could be some problems with other mods, and/or some compatibility issues.

My plan was to have this pulsing, blinking, bulge of goo flowing through those tubes, but I could never get it to look right, so I settled for the glowing tubes instead. I did some initial balancing of part costs. My thinking was to basically match the cost of stock parts, but to add a cost penalty based on potential science gain. So the telescope and imaging platform, which both have 100% transmission and support biome reports from low orbit, are a bit more expensive than the comparable parts (I think I should actually increase their cost a lot more). Whereas the parts that require a bit more work, or have lower potential are somewhat cheaper. The solar particle collector, for example, has a very low transmission rate (you get a big boost from the lab processing though), only allows for four sample to be collected, and doesn't support biomes, so it's a bit cheaper. The Universal Storage parts are all quite a bit heavier than their standard counterparts. This helps offset the fact that you can easily add so many of them (eight US Science Jr's are easy to fit, whereas eight regular parts take up a huge amount of space), I also reduced the cost a little bit for these. Let me know about cost balancing; I'll try to update soon with further balancing changes and, I hope, some contracts.

the KSP.log file in the main folder, and/or the output.log file in the KSP_Data folder. I haven't done any testing on x64. But Technogeeky has been running it on the Linux x64 build forever, so theoretically there shouldn't be any problems, but you never know.

SCANsat has been updated and will probably break the SCANsat integration here, though the changes should make it simpler and maybe cheaper to implement. Both versions use the same method for external SCANsat coverage checking, so it should be a simple enough fix.

SCANsat has been updated with RPM support incorporated into the main file. Everything seems to be OK to me, but post in the SCANsat threads if any specific issues come up. Make sure to delete any old copies of SCANsatRPM. Also note that the Module Manager config included with SCANsat in the folder: 'GameData/SCANsat/MM configs/' is required for RPM and adds a MapTraq module to all parts with an IVA.

SCANsat v6.1 has been released on GitHub. - Update for KSP v 0.24 - Folder structure significantly changed; you must delete any old SCANsat installations - SCANsatRPM integrated into standard SCANsat - You must delete any SCANsatRPM folders; do not install SCANsatRPM from any source - ModStatistics Added - Some minor bug fixes - SCANsat flag added - Initial part cost balancing The only significant changes here are the folder structure and the inclusion of the SCANsatRPM code into the SCANsat code. Delete any old SCANsat installations to ensure proper installation of this update. Delete any SCANsatRPM folders and files; don't install this file from any source. ModStatistics has been added as well; see here for more information: http://forum.kerbalspaceprogram.com/threads/81764

Update released for KSP v 0.24 on GitHub. - Updated for KSP v 0.24 - Folder structure significantly changed; you must delete any old SCANsat installations - SCANsatRPM integrated into standard SCANsat -You must delete any SCANsatRPM folders; do not install SCANsatRPM from any source - Updated to support Kethane 0.8.8 - Modular Kolonization Module Manager configs removed; these are handled on the MKS side now. - Many internal changes, mostly non user-side - ModStatistics updated to 1.0.3 There are lots of folder structure changes, including the removal of SCANsatRPM. Just delete the entire SCANsat and SCANsatRPM folders when installing this. SCANsatRPM is no longer required for RasterPropMonitor compatibility, delete all copies of the SCANsatRPM.dll file and don't install others from any source. There are a lot of internal changes, everything seems to be working ok, but let me know if anything weird happens. Significantly, the backup cache for the old style of persistent map storage has been removed. I haven't seen any problems with the new style so this should be ok, but be aware of this if you are updating from SCANsat v6 or from before release candidate 2 for SCANsat v7; you may want to make a backup of your existing persistent file.

I totally forgot about running this, I'll try to get some results up with 0.24 and with 32- vs 64-bit comparisons on two different computers. Edit: I'll update more later, but preliminary runs show a minor increase in performance. There also appear to be some changes to fuel flow or fuel consumption in some engines; this leads to some tricky staging, but I think it still works OK. The x64 version might have some issues with staging because of decoupler problems, but I didn't run into any catastrophic problems, so it might be OK.

I had a quick look today. It shouldn't be any trouble to get my plugin working the way I described in the next few days. Some methods might need be customized to get them working exactly as intended, but that shouldn't be a problem.

New versions of SCANsat with the internalized SCANsatRPM should come out tomorrow. I just asked Ramon directly about using the Mechjeb code, so I don't think there's anything else that really needs to be taken care of right away before releasing it.