DMagic

The Community KSPedia Collection Now that user-made KSPedia entries are possible, we can add anything from mod descriptions, to Delta-V maps, to in-depth tutorials. The forums are full of helpful information that could be converted into KSPedia pages. The only downside is that we might end up with dozens of KSPedia additions, all scattered in different topics and all adding to the length of the KSPedia table of contents. Instead we can collect all of the additions here, whether in the form of individual links, or a single entry that compiles contributions from different people. So if people want to, they can send me completed KSPedia prefab files (and any images you have used for the page) and I can make an entry. I’m thinking the first page could just be a list of contents and authors. Then for the rest I can clean up entries if they need it, so that everything is consistent. To get started see the KSPedia tutorial thread: If you want to make your own entry, just post a link and I will put them here. If you want to contribute to the collection just pm with the files and any other information. We'll have to work out licensing details if people start contributing to a single entry. Here are a few entries that others have made so far; these can be downloaded and placed anywhere in the GameData folder (the files have a .ksp extension): Planet science and extra info wiki, version 2, by @jandcando: https://www.dropbox.com/s/lks5si1m0x8o9e6/PlanetWiki_v2.zip?dl=0 Stock Delta-V Map, by @AlexSheFF: https://yadi.sk/d/Fatb7e0xs5jhg (Delta-V map by @swashlebucky and @Kowgan) Stock + OPM Delta-V Map, by @AlexSheFF: https://yadi.sk/d/1oNfcMcVsDKPs (Delta-V Map by @swashlebucky and @Misucat) Scrollable Stock Delta-V Map, by @jandcando: https://www.dropbox.com/s/z3p6kjrgj6zt55n/deltavmap.ksp?dl=0 (Delta-V map by @Kowgan) A list of mods that implement KSPedia can be found below (some may be in progress, or not available yet):

@Poodmund Are you using a single large image per page? When I was making pages that contained multiple images the file size was much larger. With SCANsat I have 17 pages, all of them with a single, panel-sized image (plus the blueprint background, the file size for which is around 20kb), and it comes out to 3.8MB. The image files range from less than 500kb to around 2MB; all of them are .png files. If your images have little to no transparent space they might come out a bit bigger, but I think there are several stock pages with skybox backgrounds, and all but one Squad KSPedia files come out at less than 150kb (I don't know what the deal is with the single 1.5MB page for science transmission). Also, all of my prefab files and images are on the SCANsat GitHub repo.

Is there any reason to assume this kind of perfect fuel crossfeed, where the center stack is receiving 100% of its fuel from the side boosters? Isn't there some alternative scenario where, when the side boosters run out of fuel the center stack is at 50%, or 75% fuel? There must be some balance between the benefits of not having to continue carrying all of that dry mass, and the relatively low TWR of only a single stack. A curve showing the TWR vs. fuel level might help here.

@Tossy64 The hi-res scan contracts will only rarely be generated for the Kerbin system. They are only offered as two or three star contracts, and the three star contracts aren't offered for anything in the Kerbin system. @Lucky Spacer They should be offered as long as you have less than 70% of a planet scanned. There is also no real progression built in; a scan contract of Kerbin is not required for a scan contract of Duna to be offered. I'm not sure if duplicate contracts will ever be offered. If the first one failed for some reason, you might not get another. That said, if you have vessels just disappearing, then SCANsat contracts are the least of your problems. You can check the ScanSatOfficial contract type in the Contract Configurator window to see if it shows some problem. But I'm not aware of any reason why contracts would stop showing up, other than just having too many different types. Maybe this pack needs to have some weighting attached to it. @Enceos I saw that, I'll add it to the next version. Thanks.

@Enceos That's a mock-up? It's easy to envision a system like this, but very tricky to actually implement. I've seen this idea come up several times, and I spent a lot of time trying to come up with something that would work. It will take someone a lot smarter than me to make something that I would consider worthwhile. The obvious first thing to try is to use the overlay maps like the resource system does. SCANsat uses these extensively for all of its overlays and you can see that they work well. But when applied to actual visible maps there are several problems. The overlays are fully lit: Unlike the standard map, all sides of the planet are fully lit up; there are no shadows. This obviously doesn't work. There are probably ways of mucking around with the shaders to make the overlay use shadows, but that leads to the next problem. All of the other overlays, the stock resource map, SCANsat overlays (but not the stock biome maps, I think) use that same layer: When you apply a texture to the resource overlay map it replaces whatever was there before. So if someone wants to view a resource overlay you would have to intercept that texture, then layer it on top of your fuzzy visible map texture. The overlay does nothing to hide the normal map: The normal map for most planets actual gives a lot of detail. Even if you add an opaque low-resolution visible map, the high-resolution normal map makes things look surprisingly similar to the regular map. So the resource overlay has lots of problems, why not just go down to the visible map texture itself? We can easily get to the Scaled Body renderer and access its properties. From there it's not hard to get both the visible map ("_MainMap") and the normal map ("_BumpMap"). We can just get rid of the normal map, and that makes things look a lot fuzzier. With the visible map we can generate a low-resolution map that actually matches the regular map (instead of doing something silly, like including dozens of pre-generated map textures) using TextureScale. To do this, though, we first have to go through the somewhat tedious process of making the unreadable texture that we get from the renderer into a readable object. This involves swapping around several textures and can lead to memory problems, which we'll get to later. In the end we can take the regular planet map and convert it into a low-resolution, fuzzy texture, with no detail from the normal map. It actually looks really good, like what you expect from distant images of other planets. And if you want to go a step further it's easy to convert the fuzzy color map into a black and white map. (I would love to show pictures of all of this; I'm pretty sure I got a lot of them, but they seem to have all been lost in the shuffle of changing drives, deleting unused data, and KSP updates...) There are some cases where the planet doesn't actually have a color map, like Kerbin, just a black and white texture that gets converted into the map we see through the shader. Through lots of fiddling we can get from the black and white map to the regular map, but it all tends to behave very strange. So if all we wanted was a full replacement of the high-resolution map with a fuzzy, low-resolution map, on a single planet, this might work. But to get to what that mock-up is showing means we would have to combine the high-resolution map with our fuzzy map. This means we have to juggle multiple, possibly very large, textures, and keep using those to update the texture that we actually see. Normal maps are tricky, too. They don't behave as well when re-scaled, and if you introduce sharp transitions (from a blank texture to the high-resolution texture, say along a mountain range) it looks very ugly, like a deep canyon or wall just formed. Now take all of that and figure that you need to apply it to possibly two or three celestial bodies at the same time. You can't be looking at a fuzzy Ike map, while Duna looks perfectly clear in the background. All of this adds up to severe memory and performance issues. Juggling six or so large textures (possibly 2, 4, or 8k, at 8, 32, or 130MB or RAM per texture) can get really nasty. Making those textures readable, and updating them is also a big drag on memory and the CPU. I can imagine a way where making the actual low-resolution map isn't necessary, where you just apply some type of randomizer to the colors on the high-resolution map, but you would still have to keep a readable copy of that map around, and you would still have to deal with the normal map. So replacing the regular map with a low-resolution texture is fairly easy. But doing anything other than an instant-scan type of thing, where the entire planet is revealed as soon as you scan it, is a lot trickier. I certainly wouldn't add a feature like that to SCANsat, and I don't think it's a very interesting mechanism by itself.

Contract Parser is used by CapCom and Contracts Window +. It is still in the process of being labeled as compatible with KSP 1.1.2, so CKAN might misbehave when trying to install either of those two. I'm not sure what it would have to do with this though; just uncheck CapCom and Contracts Window + for now.

@PortableGoogle As well you shouldn't. There are technical reasons for why accepting or canceling contracts while in the editor is a bad idea, so those functions are disabled.

Wait more than three hours before complaining about CKAN.

@dlrk Do you mean the seismic hammer is just lying on, or attached to, the ground? I don't think it will work. The seismic pods can be placed on the ground by a Kerbal, though you will have to make sure to activate them. But the seismic hammer probably won't be in the right position for it to work. I updated Space Dock and CKAN to mark this as 1.1.2 compatible. Let me know if anyone finds any new problems.

Version 16.1 is out; get it on Space Dock. It is updated for KSP 1.1.2, adds a feature that will allow for Kerbalism support, and fixes an issue that prevented the windows from being opened after exiting the Mission Control building.

Version 2.2 is out; get it on Space Dock. It is updated for KSP 1.1.2 and fixes some issues with keyboard shortcuts; there are now two options, to disable all shortcuts, or only the accept and decline/cancel shortcuts, and the keys don't work when the window is not open now.

Version 6.3 is out; get it on Space Dock. It is updated for KSP 1.1.2 and re-implements the replace stock toolbar function.

I haven't really tested it, but I think it should work fine in 1.1.2. If it does I'll update Space Dock and CKAN.

@Mechtech What version of KSP is this? The lab seems to be working fine for me. @rasta013 The long range makes sense. I might lower the transmission power a bit, I think it's at 55 now, so maybe 45 or 40.

There isn't a list. Just the Body.BiomeMap.Attributes array for each planet. Also, the KSC building biomes don't show up there. I'm not really sure how to get all of those, except for through Vessel.GetLandedAtString(vessel.landedAt), which will only tell you the specific KSC biome that you are in for that vessel.

@PortableGoogle

I'm starting to think that it's worth creating a KSPedia creation made up of other people's contributions like this. So that, rather than having a bunch of one or two page entries we can have a single entry, or just a couple, with lots of sub-categories and pages. The tutorials forum is filled with stuff that could make great KSPedia additions. I'll see about making a new thread to collect all of the KSPedia entries and maybe start some kind of unified collection.

There are two simple ways of getting the biome for a location: string biome = ScienceUtil.GetExperimentBiome(body, lat, long); //Returns the biome name CBAttributeMapSO.MapAttribute biomeAtt = body.BiomeMap.GetAtt(lat, long) //(Coordinates in radians) Returns the attribute The attribute can be used to get the name, associated color, or the unused biome value (which I think is supposed to be some kind of science multiplier, but stock science methods don't use it).

@rasta013 Longer range makes sense, and you can alter the data transmission levels for Antenna Range too if you want, I was just thinking intuitively a big dish seems like it should require more power but send data faster/in bigger packets. Also, I'll include any configs that people can agree on in the next version.

@KnotaiG Whoops. It should only happen when the mouse happens to be over the position where the CapCom window was. For now the best option might be to just change the keyboard shortcut to something else. I'll fix it in the next update, and provide a toggle to turn off all keyboard shortcuts.

Version 1.2.4 is out; get it on Space Dock. It fixes some issues with EVA scientist resets, lab data, asteroid experiments, contract waypoints, and reduces the total amount of science available from asteroids for each experiment. It also adds a transmitter module to the SIGINT dish; it has fast transmission rates, but uses lots of power; Antenna Range and Remote Tech configs are not included. Search tags have been added for all parts, they are mostly the same as the stock science tags. And a public API has been added for better compatibility with other mods.

@KocLobster The DTMagnetometer comes from somethings else, KSPI I think. @jhultgre That's strange, it looks like something is wrong with the magnetometer experiment. Can you check to see if the magnetometer actually works? And can you provide log files? You might still be able to complete the contract as is, just do the tow RPWS experiments and see if the parent parameter completes. If it doesn't you can finish everything else then use the Contracts Tab in the Alt+F12 menu to force the contract to be completed.

Version 2.3 is out; get it on Space Dock. It is updated for KSP 1.1.1 and fixes an issue that prevented the window from being used when opened immediately after loading a game.

@SpaceTiger An Orbital Science update should be released tomorrow. I just need to sort out some transmitter issues.

@mafkaas300 It looks like they changed how asteroid colliders work. They now seem to share the same collider layer as regular parts, meaning I'll have to update and that the two sensors will need a clear line-of-sight between each other, with only the asteroid between. Before they could ignore any other parts that got in the way, which made things a lot simpler.