[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[leops1984]

Can you set an action group for analyzing data in the VAB? And if so does it work?

Yes, I can set an action group with the Analyze Data command. Yes, it works.

[Mecripp]

Think this will fix the toolbar icon

ACTIVE_TEXTURE_MANAGER_CONFIG

{

folder = SCANsat

enabled = true

OVERRIDES

{

SCANsat/SCANsat_Icon

SCANsat/SCANsat_Map_Icon

SCANsat/SCANsat_SmallMap_Icon

{

compress = true

mipmaps = false

scale = 1

max_size = 0

make_not_readable = true

}

}

}

[DMagic]

I think I've found the problem, at least one aspect of the problem...

If you were using a previous version of SCANsat and you had an active vessel with the low res scanner turned off then the analyze button would be disabled and has no way to be re-enabled once you moved to the new version. This should be easy to fix.

But, that shouldn't cause new vessels to also lack the analyze button.

Edit: I fixed the problem with existing vessels, it should theoretically make new vessels work properly too if they are also having this issue. I sent you a PM with the link, if it works I'll push the fix to TG.

Edited May 12, 2014 by DMagic

[leops1984]

I think I've found the problem, at least one aspect of the problem...

If you were using a previous version of SCANsat and you had an active vessel with the low res scanner turned off then the analyze button would be disabled and has no way to be re-enabled once you moved to the new version. This should be easy to fix.

But, that shouldn't cause new vessels to also lack the analyze button.

Edit: I fixed the problem with existing vessels, it should theoretically make new vessels work properly too if they are also having this issue. I sent you a PM with the link, if it works I'll push the fix to TG.

Thanks - I'm about to head off to sleep (past midnight in my part of the world). Will let you know by this time tomorrow if the fix worked.

[technogeeky]

On the RPM subject, it turns out that you don't have to rebuild all three plugins every time(at least with my setup). Apparently, any given RPM codebase spits the same version numbers out regardless of which plugins you build it with, the problem's just that the 'release' source spits out a different build ID from the official pre-built release.

So you can build all three *once*, and then only have to do do the <X>RPM for whichever one changes as long as you use the same RPM code.

To change RPM versions you'd have to do all three again, though. Isn't this whole thing wonderfully terrible?

My understanding is that, right now, as of v6, the version numbers are:

[TABLE=class: grid, width: 500]

[TR]

[TD]Name[/TD]

[TD]Version Format[/TD]

[TD](Example) Version[/TD]

[/TR]

[TR]

[TD]MechJeb (Release)[/TD]

[TD]v.v.v.0[/TD]

[TD]2.2.1.0[/TD]

[/TR]

[TR]

[TD]MechJeb (Dev)[/TD]

[TD]v.v.v.b[/TD]

[TD]2.2.1.244[/TD]

[/TR]

[TR]

[TD]RPM[/TD]

[TD]v.v.x.y **[/TD]

[TD]0.16.???.???[/TD]

[/TR]

[TR]

[TD]MechJebRPM[/TD]

[TD]0.0.0.0[/TD]

[TD]0.0.0.0[/TD]

[/TR]

[TR]

[TD]SCANsatRPM[/TD]

[TD]0.0.0.0[/TD]

[TD]0.0.0.0[/TD]

[/TR]

[TR]

[TD]SCANsat[/TD]

[TD]v.v.v.v[/TD]

[TD]1.0.6.0[/TD]

[/TR]

[/TABLE]

where:

• v is a manually entered digit
  
• b is the build ID, generated by the Jenkins build process
  
• x and y are generated by the IDE at compile time
  
• ??? just means I did not bother to look it up
  

[**]: In the AssemblyInfo.cs file, this would would look like: "v.v.*" or "v.v.*.*" where v are integers. As of now, RPM is the only one using compile-time-generated version numbers (SCANsat used to do this, and so did MechJeb a long time ago perhaps?)

So, if you build RPM yourself, you will make a DLL with a version number whose first and second components you can predict, but whose third and fourth components you can not.

[technogeeky]

Ugh. There is a showstopping bug in my v6 release.

While trying to make a set of screenshots, I ran into this:

I got there by right clicking on the big map to zoom in, and it did something funny to the big map. I suspect that I have screwed up merges.

Edited May 12, 2014 by technogeeky

[DMagic]

Arghh, I see the problem now, it's the same thing that was happening to me while testing the Kethane grid. The zoom map uses the same methods as the big map, so it breaks the height map array.

I think I can fix it, I'm testing a solution now.

Edit: Should work now after my last pull, but probably warrants a bit of testing. The only end-user change is that you can't open the zoom map while the big map is still re-building (right-clicking on the map won't do anything).

Edited May 12, 2014 by DMagic

[kiwiak]

I may be interested in doing line-style ground track on the big map too, since having on the order of ten thousand dots to represent several orbits is quite taxing.

That woudl be good, these dotted lines are sometimes hard to read.

By the way, another idea, showing ground track on third one orbit after current, fourth one etc, player woudl be able to enter specific number. Right now we see only current and next.

[Psawhn]

Psawhn (who made the ideal altitude calculator) figures that you can replicate the correct swath width of the Kethane hexes by simply using an FOV (or was it swath width?) of 2.25. Or maybe a shade less, to handle the case where you are scanning between two Kethane grids.

Swath width of 2.25, not FOV. A constant field of view will cause an increase in swath width with increasing altitude, but Kethane scanners only scan the cell directly underneath them, which are 2.25 degrees of longitude wide at the equator.

Funnily enough, an orbit with exactly 2.25 swath width and 0% sidelap shouldn't have any scanning between two Kethane grid, because of the exactness. But the calculator isn't set up to give you that (a new program with an analytical solution would be needed), and close enough is close enough anyway, so I never mind having a few missed vertical strips in my Kethane maps.

Nice job with the release of SCANsat v6, guys! I'm looking forward to playing with it in my games!

Edited May 12, 2014 by Psawhn

[technogeeky]

Another day, another "final" version of V6 coming right up. I just need to clarify one issue with DMagic and then I'll re-publish the v6 release.

[technogeeky]

Apologies for this taking so long... my test scanner saves with ALCOR capsules all have the rotato-kraken bug, so I have to make a new spacecraft to test it. I guess.

[technogeeky]

Once again, here are the download links for the fixed, final v6 version.

DOWNLOAD SCANsat v6 (from GitHub)

SCANsat v6 SOURCE (hosted by GitHub)

This version, like all new versions, has a hardcoded version ("1.0.6.0", meaning SCANsat 1 version 6).

Please also check out the new README. I have converted it to nice, link-filled, table-filled markdown. Please suggest fixes, changes, or additions.

Unless this has any breaking changes, this freezes v6. All future features or bugfixes will be in v7 (or later).

If everything is reported as good, and Mihara is able to compile against these official versions (please inform s/he to try and do so), then I will make a new thread inthe Showcase for the release version, and make a new thread in Development for us developers.

[technogeeky]

Everything I was able to test worked as I expected. There still might be some things not quite right with ssRPM, but it works at least.

I will look at pushing down the map caching to ssRPM this week.

[phoenix_ca]

So, Kethane support on a lark. Wows. Now all we need is ORS support and ScanSat will be able to scan all the things.

[DMagic]

So, Kethane support on a lark. Wows. Now all we need is ORS support and ScanSat will be able to scan all the things.

Does anyone know how many resources use the Kethane grid? Or how many use ORS?

SCANsat is limited to eight different scanner types, there are currently five (the mapTraq is type 0 and so doesn't count towards this limit), but I think the biome and anomaly type can be combined and the BTDT type can be dropped entirely. I can see no scenario where anyone would need background scanning for the BTDT, and it doesn't give science the way the other scanners do, so I think it would be better to create a different module specifically for that part. That leaves three default SCANsat scanner types.

With room for only five more types I'm not sure how feasible it is to add support for more than the standard resources. Those would be Kethane, the Interstellar resources (maybe?, I haven't looked into these specifically) and maybe Ore.

Increasing the number of available scanner types is not trivial and might cause issues with the amount of data that needs to be stored in the persistent file. I'm also not sure how feasible it is to switch which scanner types are available based on the resources mods that the user has installed. By that I mean that it might be necessary to explicitly support certain resource types (support for Kethane, but not Ore, for instance).

I looked into ORS briefly. From what I can gather the scanner works by checking your vessel's current position, mapping that position onto a specific pixel on the resource texture, and checking that pixel for the presence of the specified resource. It should be no problem to adapt SCANsat to handle background scanning and map overlays for these types of resources. But again, there could be problems if there are too many types of ORS resources.

There are also massive dependency issues with all of this. I'm not sure how to get around this problem other than by basically recreating large sections of the SCANsat code in a different .dll that can be optionally installed. And this would probably run into the same kinds of problems that RPM does when any of the other mods update.

So don't expect anything to come of this soon. It's obviously possible to include support for scanning other resource types, but the actual implementation has many issues that need to be worked out.

[Mecripp]

@Dmagic, I know this mods add's a hand full of thinks to scan and use's the Kethane plugin http://forum.kerbalspaceprogram.com/threads/79588-0-23-5-Modular-Kolonization-System-%280-16-3%29-2014-05-12

But the you have http://forum.kerbalspaceprogram.com/threads/43839-0-23-5-KSP-Interstellar-%28Toolbar-Integration-New-Models-New-Tech%29-Version-0-11 which think it use's ORS for all it's resorce.

[Starstrider42]

SCANsat is limited to eight different scanner types, there are currently five (the mapTraq is type 0 and so doesn't count towards this limit), but I think the biome and anomaly type can be combined and the BTDT type can be dropped entirely. I can see no scenario where anyone would need background scanning for the BTDT, and it doesn't give science the way the other scanners do, so I think it would be better to create a different module specifically for that part. That leaves three default SCANsat scanner types.

I have to disagree. Biome and anomaly scanning are fundamentally different, and one might want to make a part that does one but not the other. So those should be kept separate.

Second the idea of making BTDT a fundamentally different component, though. The way it works right now is a bit unintuitive.

[technogeeky]

The eight different scanner types restriction is coming from the bitmask implementation (ie, you can use any value from 2^0 to (2^8 - 1))? If that is the case, I still haven't seen any location (except that 3rd party scanner part) where the bitmask is used as a bitmask -- and if that is the case, surely we can just claim to be able to support 255 types of scans?

- - - Updated - - -

Also, please report back in this thread if you are using the final v6 release and it's working and doesn't have any bugs you are aware of. I still need to know that it works for others before I make the new threads.

[Starstrider42]

The eight different scanner types restriction is coming from the bitmask implementation (ie, you can use any value from 2^0 to (2^8 - 1))? If that is the case, I still haven't seen any location (except that 3rd party scanner part) where the bitmask is used as a bitmask -- and if that is the case, surely we can just claim to be able to support 255 types of scans?

What about the stock biome scanner? 24 == 16 | 8

MODULE
{
	name = SCANsat
	sensorType = 24
	fov = 4
	min_alt = 5000
	max_alt = 500000
	best_alt = 250000
	power = 1.5
	scanName = multispectral scan
	animationName = Multi_Antenna
}

[technogeeky]

What about the stock biome scanner? 24 == 16 | 8

MODULE
{
    name = SCANsat
    sensorType = 24
    fov = 4
    min_alt = 5000
    max_alt = 500000
    best_alt = 250000
    power = 1.5
    scanName = multispectral scan
    animationName = Multi_Antenna
}

How dare you correct my face to ... my face!

Fair point.

The current SCANtype code is:

        public enum SCANtype
        {
            Nothing = 0,         // no data
            AltimetryLoRes = 1, // low resolution altimetry (limited zoom)
            AltimetryHiRes = 2, // high resolution altimetry (unlimited zoom)
            Altimetry = 3,     // both (setting) or either (testing) altimetry
            //Slope = 4,        // slope data
            Biome = 8,        // biome data
            Anomaly = 16,        // anomalies (position of anomaly)
            AnomalyDetail = 32,    // anomaly detail (name of anomaly, etc.)
            Everything = 255    // everything
        }

I don't even know what the heck the Altimetry = 3 setting is for, but last time I checked 3 isn't a power of 2.

There also isn't a reason I can think of that this should be restricted to 2^8, other than existing support for "everything".

What I was getting at, is that you should be able to break up any part.cfg entries into multiple copies which just have each appropriate kind of scan, rather than using bitmasking. Sure, it's unnecessary duplication. And it's putting extra crap in persistent files that needn't be there.

Perhaps all of this new scanning should just be in a different set of SCAN types anyway.

[DMagic]

I don't even know what the heck the Altimetry = 3 setting is for, but last time I checked 3 isn't a power of 2.

I didn't consider using it as just a byte rather than a bitmask, but you're probably right, it should allow for plenty of different types.

The scanType of 3 is used internally for generating maps, basically it is just a way to check if the specified location has been scanned by any type of altimeter before going on to determine which type and assigning the proper terrain height value and color. I don't see any reason why it can't be modified to check either type separately rather than using the current method. Checking a small array twice is definitely not the performance-limiting step of generating the big map.

Using a separate type-enumeration might be the simplest method. I think dependency issues will require recreating a lot of this code anyway, so it might make sense to create a different scanner type for other mods and make that one not use a bitmask, while the standard scanner type could remain unchanged.

Multiple modules for combined scanner types is another possibility. I figured out most of the issues with keeping things from getting too messy when I made my Universal Storage science parts with two experiments on the same part. They each have two science modules and two of my version of the environmental sensor module (that controls the readout for each part and the fancy animations).

Edited May 13, 2014 by DMagic

[DMagic]

I checked out the latest release on my regular, full installation of KSP. I put a bunch of vessels in orbit (without cheating!) with different sensors at difference altitudes. I checked scanning for all of the different sensors, everything seems to be working, both for regular scanning and background scanning. All of my attempts to break the big map failed, so that's a good sign.

I also did some brief testing without Toolbar and that was working fine.

There are a handful of very minor issues and one slightly less minor issue that I found. All of which, I think, can wait for another major update to fix.

The MapTraq has a non-functional "analyze data" action group available in the VAB, and the BTDT has both the action group and the right-click event for "analyze data", all of these should be removed. The commented out lines in SCANcontroller (437-439) that change the fov calculation also make it so the blinking orange/green light never goes away, at least I think that's what's happening. It doesn't affect scanning though. Also, I'm not sure if anyone really cares about this, but the MapTraq and BTDT are kind-of sunken into the part they connect to.

The line in their part.cfg file should be: node_attach = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 0, currently it's: node_attach = 0.0, 0.1, 0.0, 0.0, -1.0, 0.0, 0 (flip the sign on the second value).

The less-easy to fix problem is that when the big map overwrites low resolution altimetry data with high resolution data it only changes the color. The blockiness of the low resolution data remains until you rebuild the big map cache (just change the size a little bit). This isn't a big deal, it's easy enough to rebuild the cache and it's probably not all that common to scan with a low resolution scanner, then do it with a high resolution scanner in such quick succession. I also discovered that the big map cache is persistent through vessel and scene changes, which is nice.

Also, I would hold off on adding caching to SCANsatRPM. It's resetting the map size every time the map rebuilds, so a cache wouldn't do anything but take up space in memory. I'm not entirely sure how it decides what size to set the map, so I don't know if this can be worked around easily. I'll try to test it out with RPM at some point and see if I can't get it to tell me what size it's setting the map at.

Otherwise I think it's fine, everything seems to be working correctly.

[diomedea]

Does anyone know how many resources use the Kethane grid? Or how many use ORS?

I see nobody yet provided info about the above question.

I am using info from my install of the Kethane (v.0.8.5) and Interstellar mod (v.0.11, ORS comes with the latter). The current total of mappable resources tied to those mods is 6.

Kethane by itself defines the resources Kethane and KIntakeAir, but only Kethane is geo-localized (therefore to be mapped).

As previously said, Kethane allows its mapping to be used for Extraplanetary Launchpads, at the current version 4.1.2 EL defines one geo-localized resource (Ore) and two more non localized (Metal, RocketParts).

InterStellar currently has 4 different geo-localized resources: Uranium, Thorium, Water, Alumina, the ones that may be found on land. It also defines the following atmospheric and oceanic resources (not localized):

UF4, Ammonia, LqWater, Lithium, Argon, LqMethane, Deuterium, Helium-3

However, my understanding is ORS is meant to standardize other resources, in future.

[phoenix_ca]

Modular Kolonization System adds to Kethane: Minerals, Ore, Substrate, and Water. However, RoverDude has talked about adding support for ORS. (MKS is the only reason I have Kethane installed. If he switched to ORS, or added it as an option, I'd dump it entirely. Then again my reason for that is how painful it is to map for kethane.)

[Starstrider42]

I believe Kethane also has its own water expansion, separate from MKS.