DMagic

I'm not aware of any kind of formula to figure out these values, they all seem to be hand coded for each planet/situation. It's easy enough to figure them out in-game (vessel.mainBody.scienceValues.landedDataValue, etc...), and with some more complicated code you could probably make the game spit out every value for each planet/situation/biome. But otherwise the wiki or existing results are probably all you can go by. Your method probably works well enough though. It's my own that I've been using for my replacement science part module. I just noticed one other problem (and the "the" thing might not be an issue if I'm correct about how the names work, but I can't check that now), the KSC results give another variation on the title, they just show "something scan from LaunchPad" or runway or KSC. It should be easy enough to fix that though. I'll try to check for the proper results for in space high and upper atmosphere with biomes too.

This is what shows up in the title bar of the experiment results page. There are a few combinations that I'm not sure of, but I think I have found the proper format for most available results. They differ based on whether or not the biome is relevant (the "b" string in the code below). The text for each situation below is just added on after the experiment title from the sciencedefs file. I'm fairly sure that the non-biome titles are correct below, but I think the in space high and the upper atmosphere results with biomes might not be correct. It may not matter though, I imagine that the "id" string is the only one that must be correct for the results to show up. Edit: Looking at this I see the only sticking point is the "the" in front of Mun. Every other planet/moon lacks the article, so I guess I need to stick that in instead of just "from Mun Highlands". public string situationCleanup(ExperimentSituations expSit, string { if (b == "") { switch (expSit) { case ExperimentSituations.SrfLanded: return " from " + vessel.mainBody.name + "'s surface"; case ExperimentSituations.SrfSplashed: return " from " + vessel.mainBody.name + "'s oceans"; case ExperimentSituations.FlyingLow: return " while flying at " + vessel.mainBody.name; case ExperimentSituations.FlyingHigh: return " from " + vessel.mainBody.name + "'s upper atmosphere"; case ExperimentSituations.InSpaceLow: return " while in space near " + vessel.mainBody.name; default: return " while in space high over " + vessel.mainBody.name; } } else { switch (expSit) { case ExperimentSituations.SrfLanded: return " from " + vessel.mainBody.name + "'s " + b; case ExperimentSituations.SrfSplashed: return " from " + vessel.mainBody.name + "'s " + b; case ExperimentSituations.FlyingLow: return " while flying over " + vessel.mainBody.name + "'s " + b; case ExperimentSituations.FlyingHigh: return " from the upper atmosphere over " + vessel.mainBody.name + "'s " + b; case ExperimentSituations.InSpaceLow: return " from space just above " + vessel.mainBody.name + "'s " + b; default: return " while in space high over " + vessel.mainBody.name + "'s " + b; } } } Yep, and the cap is just the value from the sciencedefs file multiplied by the sbv, so it's easy to figure out one value from the other.

You also need to make sure you set all of the scv values to 1. This is the decaying, experiment scientific value that reduces the amount of science gained for repeat experiments. Only that and the sci values should be changed.

I'm guessing that the reverse would be the better option. Though either way is probably very difficult to do correctly and not screw up your persistent file in the process.

I have yet to actually see anyone do any asteroid science in any of the videos, but from what I've heard from several scattered places science can be done on an asteroid at each planet. So my guess is that asteroids are one or two extra experimental situations (probably asteroid grabbed and asteroid near, or something like that) that can be done around any planet/moon. Since they aren't actually planets (they don't have SOI's, it sounds like they are vessels not CelestialBodies, they don't have gravity etc...) it seems unlikely that they would be treated as such by the science system. Treating them as planets would require lots of changes to how science reports are generated and my guess is that they would go for the simpler method of adding on a few experimental situations and a few vessel situations to go along with them. I'll be interested to see how it works though. Especially considering that the scenario described above would break my own mod, though it should be easy to fix.

Using transform.InverseTransformPoint("root transform position") should give you the root part's position relative to your part's position. I imagine you can flip that around to get your part's position relative to the root part's. There might also be some more direct way of doing it, I've never had to find the reverse like that.

If you want to know more about all the in-depth, make-your-head-spin details about n-body physics in KSP just check the thread in the add-on development forum. If you want to know why Squad will never actually include something like this, just scroll down to the bottom of the first post and see if you can make sense if the orbital paths shown there.

That may be, but a date (I'm guessing they wouldn't announce a date more than 1 or 2 days in advance) has a whole lot more substance than SoonTM.

Is there any reason for not using Visual Studio (or some similar non-windows program)? The object browser is immensely helpful when trying to track down what does what. At the very least in will tell you what methods and variables are available in each class. Generally the names are self-explanatory so you just need to search for something that sounds like what you need. And if you're searching for differences between versions you could load up references to old KSP versions and check the relevant classes. The available code is not always clear, but I think sifting through object browser and checking others' source code are the only real options when it comes to figuring out how things work (and obviously google for things not necessarily KSP specific).

Does it always run OnSave/OnLoad, even when you are first launching from inside the VAB/SPH? I've never really checked, but I'm assuming it does. I had some issues with the both OnSave and OnLoad being called every time you load, it was screwing up some confignodes. Just using debug printout I saw that OnSave was always being called after OnLoad, usually separated by quite a bit of other entries. I didn't pay attention to OnStart, but I'm fairly sure it was always being called before OnSave. So maybe, if you only need to run something once, you could do it in OnUpdate, and put a bool check on the code. Set the bool to true in OnSave (which should be happening long after everything else), then set it to false after everything in OnUpdate runs. Would that work, or would that cause issues later on with OnSave when you're actually saving? Or maybe set the bool to true in the KSPAddon OnStart.

Did anyone demonstrate how science collection works with asteroids? I watched several of the videos, but didn't see anything.

It's possible to extract the models from the game through various methods, but actually doing anything besides playing around with them yourself is probably not advisable.

There are several unused tech tree nodes in stock KSP. Experimental Science is one of them, so there shouldn't be any problems getting it to show up as long as the prerequisites have all been researched.

The only problem I've had with Unity 4.3 was when I tried setting up emissive animations. KSP simply wouldn't accept them. I don't know if there's a way to work around that, but for now I would recommend sticking with 4.2.2. Even if 4.3 works for most things, or you can find workarounds, it's not officially supported by KSP. It would be nice though, if the latest supported version was listed somewhere prominent, maybe in the part tools thread.

A simplified explanation of what Interstellar's model looks like can be found on the wikipedia page. I suspect the basic form of the model I'm using isn't terribly different, it just has a ton of empirically determined constants that give a lot of variability to the results; both versions should give you a magnetosphere that looks something like a flattened sphere, but the WMM values won't be so evenly distributed. As far as I can tell the Interstellar model doesn't go beyond the dipole model (except for lots of scaling for different planets). Accounting for the effects of the solar wind adds a bit of complexity, but it gives a result that resembles a real magnetosphere, at least a little bit.

I checked the archives with PlanetFactory, I see what you mean now. It doesn't look like something that can be easily fixed, at least not from our end. But science reports should still work properly, you just can't review them in the archives. In the meantime I've been tweaking my magnetic field model to get it to show some semi-plausible results for Kerbin's magnetosphere. The model I'm using is the World Magnetic Model, which is used to simulate the Earth's magnetic field near the surface for calibrating compasses, and navigation. It isn't meant to give accurate readings of the magnetosphere (it treats the Earth like a dipole magnetic, basically a giant bar magnet), but I think it can still be useful. It provides a lot of non-random variation and it's relatively simple to tweak the input values so that I can produce a rough approximation of how the real magnetosphere behaves. Actual magnetosphere simulations exist, but they are more complicated and much more computationally expensive, and, most importantly, there doesn't seem to by any version that can be so easily adapted for my needs. The WMM software has no noticeable effect on performance, but if there are issues it can be turned off in the .cfg file (or retract the magnetometer). I can also change the code so that it runs only a few times per second instead of once every frame as it's doing now. Primarily I'm using a stretched out, off-center torus to scale my altitude readings so that I can get a strong magnetic field stretched out far away on the night side of Kerbin and a very stubby field on the day side. Unfortunately this requires using a lot of empirically determined values, like the length of a Kerbin solar day, the point on Kerbin where the sun is directly overhead at the beginning of each solar day, and a lot of altitude variations. This means that it's not so easy to adapt this to other planets, I'll have to determine those values for each one. I made the torus with a bunch of semi-educated modifications on the basic torus equation to produce a shape that looks like this. The front half has been removed to give you a better idea of how it looks. Imagine Kerbin at the origin. The magnetic field readout roughly follows the shape of that torus around Kerbin (ie the field strength drops off quickly outside of that shape) and the input values for the magnetic field model that I'm using are shifted so that the stubby end of the field always points toward the sun. Of course it would be nice to actually do something with all of these fancy simulations, but that will come later. For now I want to get the simulation running properly around Kerbin before even moving on to other planets.

I propose that "diarrhoeic" be the word of the day, even if the forum doesn't think it's a real word. But I agree, I'm not too worried about balance at this point, though if you really want to you could just delete some of the stock science parts, maybe the seismometer thing and the accelerometer, some of those have really high science values. And I'm always interested in new part ideas, I can't promise I'll ever get to them, but I'm open to suggestions. I have several already, which I don't know when or if I'll get to, but there's no rush. Speaking of new part ideas, take a look at this and tell me it's not the most Kerbal telescope design ever conceived. Check out the video to get the full effect: http://www.jpl.nasa.gov/video/?id=1284

That's weird, I just tried this with something I'm working on and it seems to work fine. [KSPField(isPersistant = true)] //guiActive = false, guiName = "Bt" public string Bt; //Running in OnUpdate() double uTime = Planetarium.GetUniversalTime(); Bt = uTime.ToString(); I tried this with and without the guiActive and guiName fields included and it worked fine with both. Under my part in the persistent file it included: Bt = 44093.4754801721 I don't see why starting with a double and converting it to a string would produce different results from starting directly with a string. I also tried adding + " seconds" to the end of the line and it also works. Edit: Ignore all that, I see you're talking about the .craft file, not the persistent file.

The single quotes, I believe, are used for single characters, while the doubles are for strings, so I guess it only considers the unicode key as a character. I tried that method, and a few others for trying to insert the symbol as a character, but none worked in the right-click menu. After looking at Squad's parts I realized none of them have special characters in that menu either, so I'm guessing they're using some font or style that doesn't allow it. I guess I can just use "Deg" for now as I'm really using the right-click menu as a place-holder for now.

No, not really. The planets that it works on are hard-coded into the .dll. It wouldn't be much trouble to change that, but I wouldn't call it quick or simple.

The power usage idea is actually something I had overlooked before, even though it makes a lot of sense. I've since added it to some of my own parts, though I still haven't decided how forgiving I should be about what happens when you run out of the resource.

I'm not really sure what the policy is. The rules post that I linked to says that you have to somehow notify players that you are accessing anything online, but they don't say anything about actually sending data. I'm actually trying specifically to avoid that. I don't really like the idea of save scumming and I don't want to encourage it (I know that there are lots of legitimate uses for multiple saves, too). There are a few mods out there that do basically that. I found this one: http://forum.kerbalspaceprogram.com/threads/51901-0-23-Multiple-Saves-DA-v016, but I think I've seen others somewhere too.

It should be easily possible, but it is against Squad's addon rules to write or alter files outside of the KSP directory: http://forum.kerbalspaceprogram.com/threads/7529-Plugin-Posting-Rules-And-Official-Documentation. Even exposing such an option through the Settings.cfg file would probably be a bad idea. Changing it yourself wouldn't be too much trouble. You just need to replace the second "activeDirectory" line with the full path of your desired destination, then recompile it. File.Copy(Path.Combine(activeDirectory, "persistent.sfs"), Path.Combine(activeDirectory, replaceBackup), true);

You just need to run some code when you exit the VAB/SPH right? Is there a GameEvent that will work for this? Maybe GameEvents.onGameSceneLoadRequested; add a check to see if you're still in the editor if you don't want it work anywhere else. Or will that have the same problem as your OnDestroy issue? Edit: Another question. Does anyone know how, or if it's possible, to get the degree symbol (°) to show in the right click menu? Using a KSPField I can get it to show a string, and update that string, but all of my attempts to add the degree symbol fail. I have tried directly adding it to the string with alt+0176 or alt+248, I have also tried using the UTF-8 hex code \0xB0, and other variations on that. Everything displays only a blank spot in the end, there are no errors and the rest of the string is fine, just nothing is displayed where the symbol is supposed to be. I am compiling with UTF-8. Edit 2: Directly adding the symbol to a string works fine for writing to the debug window, the hex code doesn't though. So it seems this is an issue with the right-click menu specifically.

I didn't check that, I'll see what I can find out. In the mean time, what do we have here? It's going to take some work to get that returning values the way I want it to, but it's a start.