DMagic

Are you looking for something that already exists or to create your own? I think the resource system random seed might work for you. ResourceScenario.Instance.gameSettings.Seed You can ask Roverdude, but I think that value is independent of anything else and persists throughout a save file.

It's not terribly complicated. The orbit class has a method that returns your position along the current orbit at a given time. So if you want to draw orbit lines for the previous and following orbit (or any other timescale) you just ask for the vessel's position at time intervals before and after the current time, then connect the dots with some kind of line drawing, or just leave them as dots like SCANsat does. There are a few complications, like accounting for the planet's rotation, checking if the orbit at a given time is under the surface, projecting the position onto an actual map, etc... but it's actually less difficult than it sounds.

My Universal Storage science parts use this config: MODEL { model = UniversalStorage/Parts/US_1M110_Wedge_ScienceBay/model } MODEL { model = DMagicOrbitalScience/UniversalStorage/USScope/modelScope parent = UniversalStorage/Parts/US_1M110_Wedge_ScienceBay/model rotation = 0, 180, 0 texture = Scope_DIFF, DMagicOrbitalScience/ProbeScience/Scope/Scope_DIFF texture = Scope_NRM, DMagicOrbitalScience/ProbeScience/Scope/Scope_NRM } They will continue to load just fine without US installed. They are missing the exterior mesh (and they don't work because the plugin assumes that the mesh and its animations are present), but they will get loaded and can be used in the editor. I set them as unresearchable and their editor category as none by default and use MM to activate them. But this way they won't necessarily break existing vessels if you delete US (or more realistically if you move US to the wrong place or delete the US science bay part only). Edit: Yep, here is half of my US telescope:

I figured it would have a better home here, where it won't get so easily lost in the release forum. I keep thinking that someday I'll make a more robust version of this. Something with an in-game editor that allows for save-specific settings, similar to my contract rewards modifier. It would probably be very easy to make, I could just recycle most of that addon to create it; or maybe I can try it with the new UI system, it would be good to figure out how to make something a bit more complex. I've never been a fan of config file editing to make changes, it's so much easier to handle it in-game.

I'm guessing that water uses the same transparency shader as the parts do. I'm hoping that Unity 5 brings some improved transparent shaders as the current selection is pretty bad and has lots of weird issues. 1.0.5 and 1.0.6 were both deleted from Kerbal Stuff; they were bad.

Trying again...

And version 1.0.6 is out...

It looks like it just isn't checking if the key is actually in the dictionary before accessing it. It's always a good idea to check if something is in the dictionary before accessing it, adding it, or deleting it. These dictionary key errors pop up all of the time when that doesn't happen. Why the dictionary doesn't have that key is another matter. Since you'll probably have to reject contracts after they are generated you'll need to figure out the target planet for each one; this can be rather nasty. There is no Celestial Body field in the base contract class, and every type handles it differently. I've been using this ugly looking thing to assign celestial body targets to each contract. When it fails, and with all addon contracts, the only real option is to check the contract title for the body's name. Most of the time it works well enough, but there aren't clear ways of determining the target planet for some contract types.

Apparently it was some kind of staging order mix up. They are supposed to be back to normal by Tuesday. http://www.nasa.gov/nh/new-horizons-plans-july-7-return-to-normal-science-operations

The [thread=80369]main release[/thread] has been updated to SCANsat v14. It fixes a few minor bugs from the last release here, but is otherwise the same.

Version 1.0.5 is out; get it on Kerbal Stuff. It fixes some issues caused by deploying parts in the editor, adds support for SCANsat version 14 resource scanning, has a few contract reward changes (mostly increased the magnetic field final reward values), and has a temporary fix for exploding Universal Storage parts. I just increased the maximum temperature, which probably isn't the best way to go about it. But the parts seem to survive a bit better, and should be ok if you put them behind a heat shield during reentry. I take my wedge properties from Universal Storage parts, so if they come up with a better way of handling it I'll switch to that method.

SCANsat version 14.0 is out; get it on Kerbal Stuff. The resource scanning system has received a major overhaul. Options are available to replace most of the stock surface scanning mechanisms. The available resource scanning options can be changed in the new resource settings window. Planetary resource, terrain and biome overlays can now be generated and are controlled by the new overlay window. There are a number of other changes and bug fixes; see the GitHub documentation and the first post for the complete change log and more details. A few examples are shown below. Partially scanned resource overlay (the grey background intensity can be adjusted, along with map quality settings): Terrain overlays (tooltips can be turned off): Modified zoom map use in place of the stock resource map (the terrain map is slightly lower quality than standard SCANsat maps, but much faster to generate): Scanning ground tracks (the overlay doesn't automatically update as this suggests, it would be too slow): Various planetary overlay examples:

There is no dependency on Ven's Stock Revamp, that's just how Module Manager configs work. If the stock transfer line isn't in the utilities part tab, or the in the advFuelSystems tech node (or logistics if using the Community Tech Tree) then something else is going wrong and I'll need to see full log files, not excerpts. Pictures would help.

It only happens when you are only showing tracks for the active vessel, the default state, right? It's just a simple matter of not checking if it's the right body. I'll fix that.

Version 13.4 is out; get it on GitHub. It fixes several bugs with the last version, including the distorted zoom maps near the poles, parts with multiple SCANsat resource abundance display modules, scanning continuing without power, duplicate map grid lines at the space center, and several others. See the first post for a complete change log. It also adds ground track indicators for either the current vessel or all vessels in orbit around the current planet, because why not? These can be adjusted or disabled from the settings window. These also highlight one of SCANsat's long-standing issues, that it doesn't take latitude into account when calculating scanning swath width. Because of this the scanning range narrows at higher altitudes; this is made obvious by the constant width ground track indicators. I'll try to address this for the next version, but it will probably require changes that will break any existing "ideal orbit" calculations.

You mean the parts that the Compound Part is attached to? CompoundPartModule.compoundPart.parent; Should give you the parent part of the start point, which would be the part that it is attached to. CompoundPartModule.compoundPart.target; Will give you the target part, where the end point as attached. The fuel line and strut both inherit from the CompoundPartModule class, so you should be able to get to that value easily.

I'm trying to find all parts with a certain module that has a certain value, then add my own module. It works fine when the part has only one of the module, but when it has more than one I can only get results for the first module. @PART[*]:HAS[@MODULE[ModuleResourceScanner]:HAS[#ResourceName[Minerals],#ScannerType[0]]]:FOR[SCANsat]:NEEDS[CommunityResourcePack] { MODULE { name = SCANresourceDisplay sensorType = 32768 ResourceName = Minerals } } This will find all parts with the Minerals scanner and add my own module just fine. But when a part has multiple ModuleResourceScanner modules (like the MKS_Antenna) it only catches the first instance. So when I try to check for all of the following: @PART[*]:HAS[@MODULE[ModuleResourceScanner]:HAS[#ResourceName[MetallicOre],#ScannerType[0]]]:FOR[SCANsat]:NEEDS[CommunityResourcePack] { MODULE { name = SCANresourceDisplay sensorType = 128 ResourceName = MetallicOre } } @PART[*]:HAS[@MODULE[ModuleResourceScanner]:HAS[#ResourceName[Minerals],#ScannerType[0]]]:FOR[SCANsat]:NEEDS[CommunityResourcePack] { MODULE { name = SCANresourceDisplay sensorType = 32768 ResourceName = Minerals } } @PART[*]:HAS[@MODULE[ModuleResourceScanner]:HAS[#ResourceName[Substrate],#ScannerType[0]]]:FOR[SCANsat]:NEEDS[CommunityResourcePack] { MODULE { name = SCANresourceDisplay sensorType = 65536 ResourceName = Substrate } } @PART[*]:HAS[@MODULE[ModuleResourceScanner]:HAS[#ResourceName[Uraninite],#ScannerType[0]]]:FOR[SCANsat]:NEEDS[CommunityResourcePack] { MODULE { name = SCANresourceDisplay sensorType = 1024 ResourceName = Uraninite } } @PART[*]:HAS[@MODULE[ModuleResourceScanner]:HAS[#ResourceName[Water],#ScannerType[0]]]:FOR[SCANsat]:NEEDS[CommunityResourcePack] { MODULE { name = SCANresourceDisplay sensorType = 8192 ResourceName = Water } } It only find the Minerals scanner, the first in the MKS_Antenna config. Is there some way of searching all modules of the same name in a config? Preferably without specifying the index, if I have to do that then it makes more sense to just target specific parts. I've tried using * as an index wild card in several different ways, but I'm not even sure if that works for HAS blocks, or at all. Alternatively, is there some way to search through each instance of the ModuleResourceScanner module in a part, copy the ResourceName field, and apply that to my own module, adding multiple copies of my module if needed? I can specify the sensorType value in code, so all I really need to do is find all modules with ScannerType = 0 (these are surface resource scanners) and add my own module with the same resource name to that part. @PART[*]:HAS[@MODULE[ModuleResourceScanner]:HAS[#ScannerType[0]]]:FOR[SCANsat]:NEEDS[CommunityResourcePack] { @MODULE[ModuleResourceScanner],* { ResourceName = <copy this> } MODULE { name = SCANresourceDisplay ResourceName = <paste here> } .... Repeat As Needed }

I found it. Thanks for pointing this out, I don't use the grid lines much so I guess I somehow never noticed it. I sort of understand why it was happening, but I have no idea why it only affected the space center map. In any event, the next release will have a fix for it.

I'm not entirely sure what this means, but there was an issue with older versions of Science Alert that prevented data transmission from SCANsat parts. Possible yes, but it's not that simple. I don't want to have some kind of instant scan mechanic like the way stock resources work, so visual mapping would work the same way as standard SCANsat mapping. I'm thinking of having a few levels of detail for each planet with new scanning parts for each (and also assume that crewed capsules have some kind of visual band scanner). I'm also thinking this is something that work better as a standalone addon for SCANsat, rather than adding more options and complications for the base addon. Either way, it's not something that's likely to happen very soon.

Excellent, thanks for the help. Some combination and modifications of the above seems to work. Vector3d center = v.transform.position; Vector3d up = body.GetSurfaceNVector(lat, lon); Vector3d srfCenter = body.position + height * up; Vector3d VelFor = Vector3.ProjectOnPlane(v.srf_velocity, up).normalized; Vector3d vesselPerp = Vector3d.Cross(VelFor, up).normalized; Vector3d left = srfCenter + width * vesselPerp; Vector3d right = srfCenter - width * vesselPerp; Then I just draw a triangle with center, left, and right as the three points.

Does the grid move with the map? Does it appear by the big map in the flight scene? Does it go away when you turn off the grid overlay? I don't see any specific errors with SCANsat. There are quite a few FAR errors, along with scattered NRE's from various other sources. But I don't know why anything would cause the grid lines to be drawn twice like that.

I have a fun vector question. Does anyone know how to draw a line perpendicular to the direction of travel on the surface of a planet with a given width (doesn't have to actually map the surface, just two points) and its center directly below the vessel. So in an equatorial orbit the line would have be drawn straight north/south, and in a polar orbit would be drawn east/west. Or more to the point, how to calculate the Vector3d end points of said line. I can get the position under the vessel with: body.GetSurfaceNVector(lat, lon); I can think of maybe figuring out a way of converting the width to modifiers for the lat/lon based on vessel inclination (some geometry to give lat/lon +/- values). Then using the same function to get the position at those coordinates. I think calculating new coordinates that way would end up with the line flipping directions at some point, though I might be wrong. Is there some better way of handling it? I don't think they do. Asteroids generate some log spam when they are created, so you can probably just watch for that to make sure.

That will return the distance from the center of the body, if you care. You'll need to subtract the radius if you want the distance from the surface, and if you need really accurate numbers you'll need to get the terrain height.

I've been thinking about this, or something like it, for SCANsat, or more likely as a SCANsat addon. Basically it would be a few more scanning parts for the visual range coupled with some kind of blurring overlay for each planet (that could then have other SCANsat overlays drawn on top of it). Some kind of default settings would be provided for each planet (full view of Kerbin, full view of the Mun's near side, a partially blurred view of Minmus, etc...) to allow for custom starting conditions. To that end, does this mod have any kind of public API? Something that would allow for a very simple, external method of saying, Duna has been discovered, Moho has not been discovered, etc... That kind of information could be useful for setting the visibility state of each planet.

OnGUI isn't going anywhere and doesn't have anything to do with KSP. The most that might be said is that the RenderingManager might not accept legacy Unity GUI Windows anymore, though I doubt it. But in any case you can always just use OnGUI directly and handle hiding/showing your UI manually. And yes KSP can use the new UI system right now. The latest version of KSP (from 1.0 up) uses Unity 4.6, which includes the new UI system. There might be some additional functions added in Unity 5, but the bulk of the change was in 4.6. That said, creating a UI that has the standard KSP look would be difficult right now. You would have to create all of the UI assets yourself. Mu said that we would be able to use all of the KSP style assets in the new UI system (the font styling and color, the button images, sliders, etc...) so you might not want to deal with the new system until KSP 1.1 comes out. Whether you should use the new system is mostly a matter of how complex your UI is, and whether it's meant to be displayed all of the time. Every UI element (buttons, labels, sliders, textures, etc...) produces multiple draw calls when using GUILayout, and elements can be drawn even if they are off screen or hidden in a scroll menu (try putting 1000 labels in a scroll menu that only shows 10 at a time, KSP will slow to a crawl). Manually positioning things with GUI can alleviate some of the problems, but it's a lot of trouble and doesn't help that much in most cases. But if your UI is only really meant as a configuration window, or something not meant to be shown a lot then those performance issues aren't really a big deal. Something like Contracts Window +, which is designed to be shown all of the time and can display a huge number of elements, is something that could really benefit from using a more efficient UI system. Which is why I'll probably end up spending a lot of time porting it over.