DMagic

It's hard to do much to ScienceData that differs much from how standard data is generated. A lot of it is handled internally by R&D so, it can be tricky to try things like manually adjusting the amount of science you get for certain data. For the Science Subject values check this old thread, aside from the broken formatting I think everything is still valid: The tricky one is Scientific Value; it handles the science point decay from repeated experiments. Also, regarding the ScienceUtil class, be aware that the KSC biomes work differently. You'll need to check to see if the Vessel.landedAt string is empty, if it isn't the Vessel.GetLandedAtString() string will give you the proper KSC biome name.

Looks like they weren't exaggerating about the crooked landing. It looks like it slid around on the deck quite a bit, too, the landing seemed to be well centered, but it's at the edge coming into port.

@Bishop149 Does the KSPedia entry above clear up the seismic hammer issue? I'll look into the second point, those double experiment parts are a little weird. @the1visionary Do you have log files from when this happens? That definitely isn't normal. @Nithos Do you have log files? Moving the files around won't work. Do the other parts work normally?

@Elouda Let me know if it works. That's the only thing that I know of right now that would interrupt the contract loading process. I think @Tarheel1999's problem might be stemming from something else that I might not be able to do anything about. @tomf An Unassigned list is probably doable. @Torgo You can already assign a contract to multiple missions. Just click on the little mission checklist button and select any mission. You can also remove a contract from any mission with this list.

@kcs123 Do you mean for SCANsat? Like this:

The full KSPedia entry: For some reason I was thinking this would be relatively short, maybe five or six pages, instead it came out at 19 pages...

I'm not sure that you can unpack the .asset files with Unity. You can try Unity Assets Explorer, but I've had difficulty using it with Unity 5, it never seems to be able to open the larger asset files. If you want to access the texture in-game you can try grabbing the texture by name and doing whatever you want with it. Try printing out every texture's name if you don't know which one you want, they usually have names that make sense. You can draw the texture on-screen if you want to make sure. This is what CapCom does to access the Mission Control texture atlas, just don't do this more than once per KSP session... Texture original = null; foreach (Texture2D t in Resources.FindObjectsOfTypeAll<Texture2D>()) { if (t.name == "SpriteAtlasTexture-MissionControl (Group 0)-1024x1024-fmt5") { original = t; break; } } If you want to edit that texture you'll need to make it writable: Texture2D missionControlTexture = new Texture2D(original.width, original.height); var rt = RenderTexture.GetTemporary(original.width, original.height, , RenderTextureFormat.ARGB32, RenderTextureReadWrite.sRGB, 1); Graphics.Blit(original, rt); RenderTexture.active = rt; missionControlTexture.ReadPixels(new Rect(, , original.width, original.height), , ); RenderTexture.active = null; RenderTexture.ReleaseTemporary(rt); rt = null; original = null; missionControlTexture.Apply();

@Kerbart @5thHorseman If KSP were some kind of content-creation public-service utility then teaching users how to make HTML content might be worthwhile, but it isn't. KSPedia is an internal tool for adding info to the game. Since it uses standard Unity UI objects and asset bundles it makes it relatively trivial to take entries that anyone makes and incorporate those into that game. Any step-by-step tutorial using unfamiliar software will look daunting. But coming up with clear and concise writing, appropriate images, and making sure that it's understandable to people who don't already know all of the information you are trying to convey is far more difficult and time consuming that learning how to make pages (which you'll only have to learn once). As to the original point, yes it would be easy to edit KSPedia text content because, wait for it... they use Unity UI objects. You can point DebugStuff at KSPedia page and see the breakdown of all the Text objects. Squad's entries use less than helpful naming schemes (Text001, Text002, etc...), so it would be tedious for a mod to go in and edit the content of those objects. But it would be fairly straightforward for Squad to tag certain Text objects as being tied to in-game settings, celestial body parameters, or anything else. Adding buttons to KSPedia pages is another possibility, I'm not sure why anyone would want that, but someone probably has a good reason. It would be a lot more trouble than editing Text objects, but I don't see any reason why it wouldn't be possible.

As I said in the GitHub issue, PortraitStats never writes to the config file. The only time it will change is when you manually make the change in the file, which is not something that's likely to happen more than once or twice. Or you can just make a MM patch to change the settings and not worry about it.

@sp1989 I think I know what causes this, SCANsat has a strange way of dealing with the science results pages. @Sarxis Did you check the SCANsat wiki? It has a lot of information about stock scanning and more information than the KSPedia entry on SCANsat resource scanning. @cantab SCANsat doesn't store any info on planetary terrain, only scanning coverage.

@Doghead13 You could, but that still wouldn't be accurate, there are further complications beyond a simple altitude check. But the real point is that you would have to constantly check this (or at least constantly when splashed down or landed), whereas the standard science situations trigger an event whenever they are changed; stock KSP does all of the constant checking for us. And really, for the bathymetry experiment, you are talking about six possible data sets for stock KSP planets. I don't think it's worth the trouble regardless of how complex it would be. Also, @Z-Key Aerospace it's no longer necessary to check the sitMask and bioMask fields for my experiments anymore. All of the experiments have their proper values set in the regular Experiment Definition nodes. Those two values are now only used internally when I want different behavior.

It uses the Unity UI. Which is nice for a Unity game, that uses the Unity UI for everything else. It's easy to create an entry with just a few minutes of tinkering in Unity (coming up with the content is what really takes time), and it's easy for KSP to draw these entries on-screen. I'm not sure why incorporating some completely different system would be any easier.

@JPLRepo Code's a mess; I'll get to it eventually though.

@Alshain Do you mean overlaying the map onto the planet in map view? Like This:

I discovered another useful little habit to follow when creating entries with lots of text. Every time you add a Text object you need to select the font, size, and color, and set the position and any hierarchy information. Instead of doing this you can simply save little Text object snippets as .prefab files. Just setup a Text object, then drag it into your project window to save it as a prefab; drag that back into a Panel to add it to your project. I added this information to the first post, too.

In other news; here are five new pages for the KSPedia entry, they go over some of the non-standard experiments, Universal Storage parts and interaction with other mods: @drhay53 XScience, or anything else that looks at biomes and science situations just reads the standard data. Each planet has a biome map which you can get the list of biomes from. Orbital Science ignores that for some experiments, instead looking at something else (depth underwater, latitude, some internal asteroid composition properties, etc...) to decide what tag to append to the end of the science subject id. There isn't really any good way to build a list of all possible "biomes" of this type without just manually adding them. If you want to know the current biome tag for a specific part, at a specific location, that's easy, but trying to find all possible tags at any time is not so easy.

I think that might be referring to Custom Biomestm, as in, the mod custom biomes, or Kopernicus, which both just add standard biomes. When science experiments use biomes they just append a biome name to the end of the science result id, there is nothing specifying that the tag has to be a proper biome name. So when my experiments use non-standard biomes, what they are really doing is just appending whatever tag I want at the end of the science id. The underwater and recon experiments work like this, but so do all of the asteroid results and anomaly scanner. So the only real way to handle those is to manually tell XScience which tags I'm using.

@drhay53 Outside of just manually handling each special case I'm not sure that there is anything that can be done to get something like Xscience to recognize the correct biome and situation values. It's not quite the same as something like Automated Science Sampler, which just has to figure out what the current situation and biome is.

The first four pages of the KSPedia entry, these cover the asteroid experiments: Let me know if anyone has suggestions or notices errors. Note that some of the content shown here doesn't apply to the current version, as there have been a few minor tweaks. I have at least another 10 pages planned, covering the basics (including some kind of table regarding the situations and biomes for each experiment), the non-standard experiments, and contracts.

@Sandworm Are you looking at the SIGINT.cfg file? That is for the old version, the 2.5m inline part. The nosecone version is in the electronics node, the new 1.25m inline version is in the miniaturization node. As for the accuracy of the dish, I might worry about that more if someone could find actual, concrete information about any of these satellites, or even just more than one source for all of the diagrams. All we know for sure is that the design of these satellites have grown significantly over that past 50 or so years, they are enormous, there are a lot of them, and they tend to use whatever is the biggest launcher at the time. There were several classified shuttle missions that supposedly dropped these off (and used the same type of booster as the Galileo probe to get into GSO), and more recently they seem to have made up most of the Delta IV Heavy launches (along with a few KH-11 telescopes). Given how open the NRO has been about their telescopes (they put a KH-9 on public display for one day a few years ago) it seems a little bit surprising that almost nothing has been released about the signals intelligence programs. As one of your pictures demonstrates, the basic technology behind really big satellite dishes doesn't seem to be a secret, it is used in communications and radar science satellites.

@Syndic Huh? The name is the same it has always been.

@AG5BPilot Just force those contracts to complete using the Alt+F12 Contracts menu.

@blu3wolf Yes, pretty much. Though I added a transmitter module to it later on, since it seemed silly to have such a big dish that couldn't transmit at all; it does use quite a bit of power. The real thing supposedly needs a two relatively big solar arrays for power, but I have no idea how much power those would actually provide:

Version 1.3 is out; get it on Space Dock. This version makes some changes to the reconnaissance instruments introduced in version 1.2. The inline SIGINT dish has now been reduced to a 1.25m part (with a ~50m dish) and a new 2.5m part has been added. This part fits onto the end of a vessel and acts as a nosecone. It includes shrouds that can be manually jettisoned, activated through staging, or activated by deploying the dish. The old part is still included, but can't be researched or added to new vessels. There has also been a change to how the experiments for the recon instruments works. The SIGINT dishes share the same experiment and the two recon telescope experiments have been combined into a new experiment. The smaller instrument for each experiment is only able to collect 50% of the total science, regardless of how many samples you collect. If there is 100 science to be collected from Duna's northern hemisphere for the recon telescopes, then the small instrument will be able to collect 50 science if the sample is returned, and 25 science if it is transmitted (the part has a 50% transmission level); the big instrument will be able to collect the full 100 science if the sample is returned. The same applies to the two SIGINT dishes (but both transmit at 100%). There are also some changes to asteroid science. The asteroid spectral types now conform to those used by Custom Asteroids (there are five now, instead of nine) and it will pull the asteroid type data from Custom Asteroids if it is installed. A few bugs with the TweakScale configs have been fixed and the new science experiment function has been implemented; smaller experiments cost more. A few bugs in the API were also fixed.

OnGUI is like Start or Update, it's one of those Unity MonoBehaviour methods. It handles all of the legacy GUI drawing. Basically, anything in the GUI classes can only be run in OnGUI.