DMagic

The other problem is that there is no need for experiment definitions to be in a file called ScienceDefs.cfg (in fact, you could put part definitions, experiments, resources, etc... all in one big config file if you wanted to) so just searching for , or changing, that name won't not help. A better way to verify that this is actually the problem is to either post your output.log file (found in the KSP_Data folder) or check your logs to see if you're getting a duplicate key dictionary error (this happens while KSP is first loading, so it happens to quickly to easily see it in-game). You can also open the Alt+F2 debug log when you activate an experiment and check to see if the orange "No experiment with X name found" warning appears. Either of those should confirm that duplicate experiment definitions are to blame here. If you want to verify that the anomaly scanner is working and to see its various visual cues, put a small rover on the launch pad with an anomaly scanner on it. When you activate it the standard spinning dish will pop up along with the camera module (the picture on the first post of this thread shows this at the island airfield). The cameras will point directly at the nearest anomaly (though it only rotates in one dimension, so this works best if you mount the scanner on top of a rover body, or something equivalent), which in this case will be the KSC anomaly, the center of which is located about 30m below a point midway between the VAB and the launchpad. If you try to collect data you'll be a little too far away, so an on-screen message will tell you which direction to go, the exact distance and directions will be printed in the debug menu. If you get within 250m of the center of the anomaly the green lights will start flashing and you can collect data. The cameras pop-up whenever you are within 10km distance to the anomaly (though it varies with your height above or below it), so you can use them as an indication of distance when the anomaly is too far away to see. The on-screen message will appear when you try to collect data within 30km of the anomaly (this also varies with height); both of these give a pretty good indication of where the anomaly is, even if it is buried underground or too small to see. If there is something really wrong, like the anomaly is somehow at the center of the planet, the anomaly scanner will never get close enough to work, and SCANsat also shouldn't work. That's good to know, well... good for me to know. I'll add some debug outputs and more safeties to catch anything weird happening when science collection occurs; this won't fix anything, but it will give a better indication of exactly what is wrong, and there is some slight, but very real danger that null science data could be passed through the system with catastrophic (and hilarious) results.

Yep, my [thread=80220]celestial body science parameter modifier[/thread] can be used to adjust this. I have a big warning on the thread about it affecting contract rewards though, since a few people discovered the hard way that this happens.

That looks good. Is there any reason not to include this in the SCANsat folder, I think I've seen other people include them outside of ATM, which would be preferable to me.

KSPI resources are already defined in the SCANsat resource config. It's only a matter of whether they are defined as ORSX planetary resources and that they have properly linked resource maps. If anyone has the Active Texture Management (or any other relevant texture mod) configs to prevent the toolbar icons from being re-sized could you post it here? I want to include it to prevent this problem, but don't care to figure it out right now.

Did this only happen when using ScienceAlert to collect data, or does it also happen when using the right-click menu? And does it happen all of the time, or just this time? ScienceAlert is basically just deciding when an experiment should be collected; once it thinks you should collect something it gives you the button, which just runs through mostly the same thing as what my code does. The only thing I can think of is that something is being activated when it shouldn't be. Were you actually splashed down in Kerbin's ocean when this happened? It's possible that something else is going wrong here. You weren't connected to or very near to an asteroid when this happened by any chance? That could have affected things. I'll look through it and at least make things fail a little more gracefully when something like this happens. Were you able to actually see the anomaly, or use the Anomaly Scanner? And did you check the Alt+F2 debug log to see what it was saying. The last time I checked the Minmus anomaly was on the surface, not floating like it used to be, so it should be visible if you get close enough.

But are the coordinates wrong because of something fundamental SCANsat is doing wrong, or because its periapsis prediction is wrong? Is the periapsis for the two programs showing up over the same physical location on the planet, but giving two different sets of coordinates, or is the periapsis in a different position? And does anything different happen when using a rectangular vs a different SCANsat map projection?

SCANsat[v7.0] release candidate 5 is now available on GitHub This is a final release for version 7 barring any new bugs. ORSX support is included for the latest preview versions of USI mods. - Updated for KSP 0.24.2 - Updated for Kethane v0.9 - OpenResourceSystem no longer supported - KSPI may still be supported depending on how the resource maps and definitions turn out - Added support for ORSX - ORSX dll not included; support is through reflection - Will support any ORSX planetary resource with a defined SCANsat sensor - SCANsat resource sensors now defined through a separate config file - Located in SCANsat/resources folder - SCANsat sensor type, and resource overlay colors can be defined here - Colors are defined by RGB values in the 0-1 range - Sensor types should not be changed by users - Improved Multi-Spectral scanner - Improved clickability - More efficient model; 60% reduction in triangle count - .version file included; KSP-AVC or mini-AVC not included - Probably some other stuff that I've forgotten about

So this is concerning the Periapsis or Apoapsis that SCANsat is giving you on its orbital projection overlay right? I think I see what Arrowstar means about not taking into account a body's initial rotation, but I'll have to look into it. I've never actually looked at how SCANsat calculates anything to do with the orbital overlay. At some point it needs to be replaced as it's a performance hog, and, apparently, doesn't quite work right. SCANsatRPM actually uses a different method for the orbit prediction, most of which was taken directly from MechJeb, so I'm curious if the orbit projections from IVA SCANsat maps match up right, or if MechJeb matches Mission Architect. The notation is more of a style convention thing. On Earth longitude is typically given as -180 to 180o, but on other planets it's usually just 0-360 (the East or West part is determined by the direction of the planet's rotation). And KSP gives all sorts of values when you ask for longitude, so if you aren't clamping the results it gives you then you can end up with values greater than +- 360. It makes it simpler to treat everything the same in KSP, so longitude is always displayed as -180 to 1800.

That's true that .net works like that, but there is no way to directly link a part module to an actual assembly in the part.cfg file. You just put a part module name in the config node and KSP assigns the first part module of that name. You could have two addons, with two different namespaces, defining a part module with the same name. That would cause serious problems, which is why most people append some mod-specific prefix to the names of their part modules.

I don't believe this is how part modules work. They use the method found from the first assembly loaded to define them, that would be the un-numbered version of OpenResourceSystem.dll. This is how I understand it from your own post in the ORS thread and from my own experience. In any case everyone was linking to the correct version of ORS, v1.2 or v1.2.1, since, for some reason, everyone stopped distributing the un-numbered version. So any duplicate key exceptions caused after the update to ORS 1.3 could not have been caused by improper linking.

I actually tested this once, and it is possible, it's just completely unrealistic to do it without cheating. Your altitude has to be incredibly low to scan the sun, you can't even timewarp below the 800km necessary for the SAR to work, and the DeltaV requirement to get that far down is absurd. There is also nothing to map, you'll just get static for all three map types, but you can still get science from it.

Version 2 is almost ready and will come with a number of updates. There are a few more things to fix, but otherwise it's almost there. These screenshots were taken running KSP at 1600 * 900 (with KSP windowed on a 1080P screen), you might need to open the images in a new tab and zoom in to see them clearly. The two new icons on the bottom row control the size options displayed above. The font icon increases the font size for most of the text by 1. The window re-size icon increases the font size by 2, increases the window width, and increases the size of all of the texture elements. This gives you a range of four possible font sizes; a font can be toggled between, say, 11 - 12 in the small window, or 13 - 14 in the big window. This makes a pretty big difference. It's difficult to change the font size too much without changing everything else, so the increased window and texture sizes help accommodate the biggest font sizes. The textures have all been remade from scratch, they are more uniform in style and size and behave better when re-sized. You can also see the new title bar above each contract. The expiration date is always displayed, so there is no need for the intermediate width window anymore. The difficulty is also displayed along with the note and show/hide icons. The new pin icon allows you to move a contract to the top of the list and ignore any sorting options. Pinned contracts are added in order, so the first one to be pinned will always stay at the top until you un-pin it. The pinned state, along with the collapsed state (whether or not it shows the parameters) is saved now, so you won't have to reset everything when you load or change scenes. There is also a button that appears when a contract is completed allowing you to remove it whenever you want, though they will still be automatically removed when you load a new scene. And it also works in the SPH now, too.

I've always been curious about the VAB slow-down, it does get very bad with really high part counts. Can you send me the results, either here or in a PM? The improvement in the x64 is interesting; it seems that some people can around a 10% increase while others see no real improvement, I wonder why it's so variable. I've seen it on a low-end computer, but not on a higher-end one, but you see a pretty big difference here. It's also worth noting that the average FPS line gets less useful above 60FPS. If you look at the frametime results you see that the framerate is all over the place, so you probably wouldn't see as much of an improvement as you might expect if you are using a 120Hz monitor (though I've never actually tested this).

Anomalies are still screwed up. There is at least one issue that I'm certain needs to fixed, and possible a few others. For now I would suggest first saving and loading when you are directly, or nearly-directly above the anomaly. You can also try to land by the anomaly (this one is almost straight north of the KSC and is hard to see unless you get very close, unless it got buried at some point) to verify that it is actually there and that the anomaly scanner works, which uses a different method than the other instruments. Obviously you can't get the in-space results while in the atmosphere, but you could just manually complete the contract in the Alt+F12 menu if those are the only parameters holding you back. You have to use my parts to complete the asteroid contracts. For the stock experiments that means using the Universal Storage versions. If you don't have US installed these experiments should not be asked for, though they might get assigned if you had US installed at some point but removed it later. This is noted in the Asteroid Survey contract notes, but unfortunately these notes are only visible in the mission control center, they can't be viewed in the stock contract window (this is in contrast to parameter notes, which can be viewed in the stock window using the little blue "notes" button). You can however, use my [thread=91034]Contracts Window + addon[/thread] which will show these notes, and allow you to preview the correct part while in the VAB (the SPH doesn't work yet because I'm dumb). The distance for non-grappled asteroid experiments is 2km.

Any specific reason why this, this, and this weren't implemented? The first two fix fairly critical bugs that can make the game unplayable in some cases, the third just makes things vastly simpler for accessing through reflection. Also, is there anywhere where the source is available online? All I see is older versions on GitHub and Bitbucket; I'd rather not have to resort to ILSpy to get to the source. Edit: nevermind, I just noticed how recently it was updated here.

Does part.mass take into account the masslessness of physics-disabled parts? You might have to account for that manually.

So says you. If poking around to find out how things worked were considered a violation of the EULA then basically all addons would be in violation. This thread would certainly not be stickied along with the other thread dedicated primarily to explaining what Squad's code actually does. So it seems reasonable to assume that users telling other users how the code works is considered acceptable.

Regardless of what happens with the other types of resources it's planetary resources that are the most common cause of critical errors in ORS. The first thing that should be done, and already has been done (WaveFunctionP's development branch already contains a number of fixes to ORS and should probably be the starting point for any further development), is to fix the loading mechanism for planetary resources to prevent the game becoming unplayable when someone uses multiple copies of the same resource (and someone will always do this, regardless of how careful you are about distribution). The CRP already nicely handles the issue of multiple mods distributing the same resources in different packages, so I don't see any reason not to continue using that going forward.

You need to tell Unity what animation it's supposed to be playing by creating an instance of the animation class. Is that lowercase animation in your example supposed to be an instance of Animation? Because those methods aren't static, so it wouldn't work or compile otherwise. A common way of initializing the Animation instance is something like this: Animation anim; private void Start() { anim = part.FindModelAnimators(Scene)[0]; } [KSPEvent(...)] public void play() { anim.Play(Scene); }

Version 0.8.5.1 released: Kerbal Stuff All existing DMagic Orbital Science contracts will be removed upon updating from v0.8.4 or before; no cancellation penalties apply; other mods will not be affected Updating from v0.8.5 will not reset contracts This version fixes three bugs, most importantly that addressed in this post above. This Null Reference Error is caused by a vessel being somehow deleted (missing parts from the GameData folder being the simplest method to cause this) while registered to a magnetic survey contract. This non-existent vessel cannot supply a Guid value and thus throws the error seen above causing all sorts of terrible things to happen. This release fixes that. It also makes any survey contract (orbital, surface, or biological) parameter able to complete by returning science results to Kerbin, regardless of their science value. Transmitted science results still require that there be a minimum amount of science gained from experiment, but returned science no longer has this requirement. This should address any edge cases like those mentioned in this post, and avoids generally frustrating results caused by taking the time to return a vessel to Kerbin only to get the "not enough science message". It also has what should be a more reliable method for resetting DMagic contracts upon upgrading; again, note that upgrading from v0.8.5 will not reset contracts. See the first post for the full change log. That giant update warning will be standard in all of my release posts from here on. Anyone asking about contracts resetting (unless it happens when they aren't supposed to, in which case please tell me) will simply be directed to that warning again.

A setting for larger fonts is definitely a good idea. I will probably want something that resizes the not just font size, but also texture elements and the window itself. This is something I'll need to play around with to get right (increasing the font size by something like 1.5X, but the window and textures by only 1.2X, or something like that), so it probably won't happen any time soon. I'll try to get to this by the time 0.25 is released though.

The full output_log.txt would blow up the forum's character limit about 10 times over, unfortunately, so the only way to post the whole thing is through download links.

I was referring to naming the next version 1.3 instead of 1.2.2 or something like that. I just realized that it doesn't really matter though. When using reflection to get a method it's only the namespace that matters, and that is always OpenResourceSystem, regardless of what the actual file is called. I think this has always been the idea; point any hard-links at the numbered versions, and only update the non-numbered version, because it should be the first one to load. So if your plugin folder comes before ORS (obviously not a problem for something like SCANsat or USI, but if someone put it the community resource pack folder it would be loaded first) it might be problematic to include a different copy of the plugin in that folder.

For low and high concentrations. What those concentrations are is arbitrary, but having two colors allows you to lerp between the two of them creating a better looking overlay so you can see at a glance where the higher concentrations are.

I submitted another pull request with some optional fields for resource colors and a hidden flag. Resources default to not-hidden, so nothing needs to be changed unless you have a special case like Karborundum that you don't want to show up on overlays. This doesn't specifically affect anything in ORS (though it could be used to adjust ORS scanners' behavior), it's just being used by SCANsat as a flag to ignore certain resources. There are also options for low and high color values, so that resource creators can specify what colors they want for their resources on overlays; there are default values for these too (hello hot pink ). They need to be entered as 0-1 float RGB values. lowColor = 1, 0.8, 0.2 highColor = 1, 0.4, 0 Those are yellow and orange colors that I've been using to test Karbonite. They can have different values for each planet (the same goes for the hidden flag, as with any other ORS resource parameter). To get these values from the more common 0-255 range just divide each value by 255. The highColor value is 255, 102, 0 in standard format; divide each by 255 and you get 1, 0.4, 0. It's probably best not to include a fourth, alpha channel value. Whenever you do update ORS I would ask that you name it OpenResourceSystem_1_3_0.dll, following the naming convention that's been used in the past, and make sure the assembly version is 1.3.0.0. I'll probably be updating SCANsat soon, and I have it set to check for this specific version of ORS ( it doesn't really matter if this isn't updated before SCANsat, ORS overlays won't work, but everything else will be fine). My other suggestion here is that this should probably have a new thread. And that ORS should have its own repo, not be part of Interstellar.