[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[DMagic]

If I update from the latest damny version to the techno/magic version will I lose my currently scanned maps?

Also looking at the changelog, is there a whole lot of difference? My V5 is working fine (afaik) on 0.23.5 Am I going to notice any changes?

If you are worried about losing map data, or anything else, just make a backup of your save folder, which everyone should probably be doing anyway.

All of the mapping information is stored in your persistent file as a string of compressed gibberish, so as long as you keep a backup of that file your mapping data should always be there. If you're careful you can even copy the data from one persistent file to another.

You mean in the README.txt? Or in the small map? Or both? Either way, OK.

I believe this is referring to putting the min, max and ideal (if you don't change how that works) into the parts' VAB descriptions. Though I think it might be a better idea to put this into the extra info tab (the right-click window in the VAB), that way it will always match the values from the .cfg files.

The only aspects of ISA that I believe are worth discussing are the variable scanning resolution and maybe some kind of info tab for each planet (ideal orbits maybe?). While I think there are benefits to SCANsat's method of simply increasing the scan width up to a point, I also really like the way that ISA start giving more sporadic data at higher altitudes.

Maybe some combination of the two would be good. For instance, the scan width could increase, with 100% coverage, up to the ideal altitude. Above that the scan width could continue to increase (but within reason, not greater than 180^o like I think ISA could sometimes do) up to the max altitude.

I'm not sure if implementing something like that would be possible without changing the way SCANsat registers a scanning pass. But it might be, I haven't really thought about it.

Edited May 4, 2014 by DMagic

[Rioliki]

I believe this is referring to putting the min, max and ideal (if you don't change how that works) into the parts' VAB descriptions. Though I think it might be a better idea to put this into the extra info tab (the right-click window in the VAB), that way it will always match the values from the .cfg files.

Exactly.

*This message is too short*

[technogeeky]

Among other things, I'm bringing all of the GameData files (MapTraq, Resources (science defs.) Scanner 1, Scanner 2, Scanner 8, Scanner 32) into the solution (and also into git).

While looking at the part.cfg files for SCANsat (to add scanning altitude descriptions, as was requested and I think nice), I noticed that Scanners 1,2, and 8 all have multiple definitions for attachRules. And they don't match.

It's always a battle between [1,1,0,0,1] and [1,1,1,1,0]. I would guess that the latter wins. Which one (if either of these) should it be?

[technogeeky]

I think I just had a good idea. We can solve many of these problems and make the game more realistic easily by doing just one thing:

Make the: minimum, maximum, and ideal altitude tweakables (with sensible bounds).

This is exactly what one would do (in a loose and generic sense) in real life. You would have a general satellite design that you would make for some orbit around some planetary body (or Lagrange point). And you would decide what kind of orbit you determine to be 'ideal' (the one you choose to put it in, silly) , and then you would adjust the general design accordingly.

1. This would let users know what the altitude limitations are.

2. This would let them set their own ideal (the sweet spot configuration chosen by the user); but penalize them for putting it closer (or further away, if it's appropriate)

3. This would make each sensor need to be slightly tailored for each planetary body you wish to scan. This means you will want to scan the Mun (or Gilly, or whatever) with slightly different configurations than with Kerbin.

4. The specific configuration could be used to determine the power usage (higher ideal and/or max might require more power (inverse square falloff?)).

5. There are some other advantages I thought of, but forget now...

Anyway, I think generically this is already supported (since the .dll reads these values from the part.cfg files) -- except that I'd have to add tweak ability or whatever.

edit: I was looking for GetInfo.

Edited May 5, 2014 by technogeeky

[DMagic]

While looking at the part.cfg files for SCANsat (to add scanning altitude descriptions, as was requested and I think nice), I noticed that Scanners 1,2, and 8 all have multiple definitions for attachRules. And they don't match.

It's always a battle between [1,1,0,0,1] and [1,1,1,1,0]. I would guess that the latter wins. Which one (if either of these) should it be?

I never noticed that. They should all be [0,1,0,0,0]; that is, you should only be able to attach them to the surface of other parts (provided those parts allow surface attachment).

The "node_stack_bottom" and "node_stack_top" lines should be removed, they should all only have "node_attach".

There are a few other issues in the .cfg file too, the masses should probably be tweaked a bit, the bigger scanners are should probably be heavier.

I suppose "cost" and "entrycost" don't really matter now, but at some point those will presumably become important.

And the low-res altimetry scanner needs a "scanName".

Edited May 5, 2014 by DMagic

[technogeeky]

Here are some screenshots of my first attempts to add the relevant information to the editor (right click for extra information) window:

edit: I delete this album because it was easier than deleting the images in it.

Someone else please approve this choice as sensible (or not), and let me know. I expect to include this in the mythical v6rc3.

Edited May 5, 2014 by technogeeky

[technogeeky]

I never noticed that. They should all be [0,1,0,0,0]; that is, you should only be able to attach them to the surface of other parts (provided those parts allow surface attachment).

The "node_stack_bottom" and "node_stack_top" lines should be removed, they should all only have "node_attach".

There are a few other issues in the .cfg file too, the masses should probably be tweaked a bit, the bigger scanners are should probably be heavier.

I suppose "cost" and "entrycost" don't really matter now, but at some point those will presumably become important.

And the low-res altimetry scanner needs a "scanName".

I have before, and I again tonight glanced at your generalized science mod thing. Should I convert these part config files to use it? If the answer is yes, should I do it now (high priority) or later?

I'm sorry I haven't had time to pay anywhere near similar levels of attention to your mods (though I used the **** out of your science experiments to farm precious data in both of my careers so far).

[Starstrider42]

Here are some screenshots of my first attempts to add the relevant information to the editor (right click for extra information) window:

http://imgur.com/a/d7jeZ

Someone else please approve this choice as sensible (or not), and let me know. I expect to include this in the mythical v6rc3.

Well, the MapTraq readout looks a little goofy, but I like the overall layout.

One suggestion: you might consider omitting the "best altitude" line where best = minimum, since it basically amounts to disabling altitude scaling. That would probably make it clearer for users who aren't familiar with the exact definition of "best", too.

[technogeeky]

Well, the MapTraq readout looks a little goofy, but I like the overall layout.

One suggestion: you might consider omitting the "best altitude" line where best = minimum, since it basically amounts to disabling altitude scaling. That would probably make it clearer for users who aren't familiar with the exact definition of "best", too.

Yeah. I think actually the ideal situation is to report the *effective* FOV (if possible) for each of the three altitudes. That way they can see, at-a-glance, that there is a boost above best, and a penalty below best.

But I certainly agree with your suggestion and will implement it.

And yes, the MapTraq scanner is looking more and more like it should be removed/deprecated/MM inserted into all pods.

[DMagic]

I have before, and I again tonight glanced at your generalized science mod thing. Should I convert these part config files to use it? If the answer is yes, should I do it now (high priority) or later?

Using my module would probably require too much work to fit all of SCANsat's requirements to really make it worthwhile.

There are a number of issues with the SCANsat part module though (thanks for reorganizing that), some of which I think can be cleaned up right away, like saving and transmitting science data. There are also a lot of things running in OnUpdate that probably don't need to be: the KSPEvent initializations (there is after all, an OnInitialization method), and a few other things, some of which might need to be more carefully looked at. I'll try to go through some of it tomorrow.

I'm sorry I haven't had time to pay anywhere near similar levels of attention to your mods (though I used the **** out of your science experiments to farm precious data in both of my careers so far).

I haven't really done anything since I released the update last week. But today I started coming up with better methods to do asteroid science. At first I was disappointed when I saw that Squad didn't really do anything for asteroid experiments. Now I'm glad though, as it gives me a completely blank slate to come up with my own designs.

Well, the MapTraq readout looks a little goofy, but I like the overall layout.

One suggestion: you might consider omitting the "best altitude" line where best = minimum, since it basically amounts to disabling altitude scaling. That would probably make it clearer for users who aren't familiar with the exact definition of "best", too.

Yeah, you can also probably add a check to see if any of the values are greater than zero before adding them to the string. But otherwise I think it's ok.

[technogeeky]

Using my module would probably require too much work to fit all of SCANsat's requirements to really make it worthwhile.

There are a number of issues with the SCANsat part module though (thanks for reorganizing that), some of which I think can be cleaned up right away, like saving and transmitting science data. There are also a lot of things running in OnUpdate that probably don't need to be: the KSPEvent initializations (there is after all, an OnInitialization method), and a few other things, some of which might need to be more carefully looked at. I'll try to go through some of it tomorrow.

I haven't really done anything since I released the update last week. But today I started coming up with better methods to do asteroid science. At first I was disappointed when I saw that Squad didn't really do anything for asteroid experiments. Now I'm glad though, as it gives me a completely blank slate to come up with my own designs.

Yeah, you can also probably add a check to see if any of the values are greater than zero before adding them to the string. But otherwise I think it's ok.

I had already implemented that (or something similar: check that the values are != 0, and compare best/min) before you posted.

Great minds think alike for nearly trivial things

Javascript is disabled. View full album

[technogeeky]

OK. I have pushed all of my changes into my master/v6.

This includes a bunch of (trivial) reorganization and re-ordering of methods to suit categorization.

Unfortunately, it also includes me running two custom commands (in a shell, no less). I am certain these will not work in DOS, so please beware. If there is an equivalent DOS command and you want to do it that way in general, let me know.

I think the line endings should all be Windows style now (yay!)

I also have the assets inside the project (and the github repo) -- except the part.cfgs are end in .ignore, to be ignored by the game.

I have made all the appropriate changes to the part.cfg files. I have not made any gameplay-affecting changes.

And I'm done for the night. As usual, not much done, but it's something.

edit:

And I've changed the multispectral scanner to be easily clickable.

Edited May 5, 2014 by technogeeky

[technogeeky]

Hey guys, I made a 1.25 meter scanner to stick on top of your rockets that looks a bit more realistic than the stock parts. I have it set up to do three different scan types but you can change that if you want in the config file. Just download and copy the rar contents to your GameData folder.

Here's a pic of it in Blender:

http://i.imgur.com/IQruKhK.png

And here's a pic of it in game:

http://i.imgur.com/Z6gIwTT.png

Download Here

Assuming everything checks out, are you OK with me including this sensor into the SCANsat package?

[Virtualgenius]

I use the calypso all the time its my favorite all in one scanner

[Mecripp]

I only have 2 parts for scansat thats the SCAN RADAR Altimetry Sensor and calypso and maptraq MM on my command parts.

[technogeeky]

I only have 2 parts for scansat thats the SCAN RADAR Altimetry Sensor and calypso and maptraq MM on my command parts.

Can you point me to Maptraq MM? I assume you mean that small cell-phone looking thing.

[Mecripp]

Can you point me to Maptraq MM? I assume you mean that small cell-phone looking thing.

Sorry MM is ModuleManager cfg file to add it to what ever there are some so, I just click on command pods or probe core and there will be open map there.

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[sCANsat]]:Final

{

MODULE

{

name = SCANsat

sensorType = 0

fov = 0

min_alt = 0

max_alt = 0

best_alt = 0

power = 0.05

}

}

If thats what your asking there was 1 that looked like alittle TV somewhere in the post.

EDIT but if you was looking for new parts here was some.

And the download for them http://www./download/7c6nrgngsjmypss/SCANsatALTv0.11.zip

Edit here was the post about them http://forum.kerbalspaceprogram.com/threads/55832-PLUGIN-PARTS-0-23-SCANsat-terrain-mapping?p=766120&viewfull=1#post766120

EDIT - And DMagic made a Altimetry sensor for putting on rovers.

Edited May 5, 2014 by Mecripp2

[Virtualgenius]

I like that little GPS thing its very handy makes a great handheld if you put KAS grab in the config also there is this little fellow from milkshakefiend who did most of the original models

[LameLefty]

For some reason, the latest SCANsat package that technogeeky put together has stopped working with RPM for me ... version 5 worked, complete with incorrect map icons at all, but v6rc isn't. Either I get an error for no satellite connection, or else I get a completely black screen "map" that never updates. I can still access the maps from external views but not on the IVA displays.

Any ideas for a quick, easy error I may have missed?

[Mecripp]

For some reason, the latest SCANsat package that technogeeky put together has stopped working with RPM for me ... version 5 worked, complete with incorrect map icons at all, but v6rc isn't. Either I get an error for no satellite connection, or else I get a completely black screen "map" that never updates. I can still access the maps from external views but not on the IVA displays.

Any ideas for a quick, easy error I may have missed?

Did you replace both folder ? SCANsat and SCANsatRPM.

[LameLefty]

Did you replace both folder ? SCANsat and SCANsatRPM.

Yep, sure did.

Well, time to roll back to v5 and see if I can get it functional again, then try to narrow down what might be conflicting.

[technogeeky]

For some reason, the latest SCANsat package that technogeeky put together has stopped working with RPM for me ... version 5 worked, complete with incorrect map icons at all, but v6rc isn't. Either I get an error for no satellite connection, or else I get a completely black screen "map" that never updates. I can still access the maps from external views but not on the IVA displays.

Any ideas for a quick, easy error I may have missed?

Note: I do not expect this comment to help your situation, but perhaps it will help us devs figure out how to stop this version mismatch nonsense.

I don't see where this compilation-target mismatching is happening. The (primary) source code of SCANsat and SCANsatRPM do not have version numbers encoded them. However, the assembly file of SCANsat does:

// The assembly version has the format "{Major}.{Minor}.{Build}.{Revision}". 
// The form "{Major}.{Minor}.*" will automatically update the build and revision, 
// and "{Major}.{Minor}.{Build}.*" will update just the revision. 
[assembly: AssemblyVersion ("1.0.*")]

The assembly file of SCANsatRPM does not even declare an AssemblyVersion:

using System.Reflection;
using System.Runtime.CompilerServices;

// Information about this assembly is defined by the following attributes.
// Change them to the values specific to your project.
[assembly: AssemblyTitle("SCANsatRPM")]
[assembly: AssemblyDescription ("RasterPropMonitor / SCANsat interface plugin for Kerbal Space Program")]

The assembly info for MechJebRPM:

using System.Reflection;
using System.Runtime.CompilerServices;


// Information about this assembly is defined by the following attributes.
// Change them to the values specific to your project.
[assembly: AssemblyTitle("MechJebRPM")]
[assembly: AssemblyDescription("RasterPropMonitor / MechJeb2 interface plugin for Kerbal Space Program")]

And lastly, the assembly for RPM itself is similarly terse:

using System.Reflection;
using System.Runtime.CompilerServices;


// Information about this assembly is defined by the following attributes.
// Change them to the values specific to your project.
[assembly: AssemblyTitle ("RasterPropMonitor")]
[assembly: AssemblyDescription ("RasterPropMonitor plugin for Kerbal Space Program")]

I suspect this is an intentional decision on Mihara's part (to remove all of the version declaration).

The assembly file for MechJeb is more complicated, but it appears as they are doing what I thought might be a good (bad) idea.

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;


// General Information about an assembly is controlled through the following 
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("MuMechLib")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Multiversal Mechatronics")]
[assembly: AssemblyProduct("MuMechLib")]
[assembly: AssemblyCopyright("Copyright © Multiversal Mechatronics 2014")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]


// Setting ComVisible to false makes the types in this assembly not visible 
// to COM components.  If you need to access a type in this assembly from 
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]


// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("a903d9fe-4604-47b8-b9d9-95728538f769")]


// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("2.2.1.0")]
[assembly: AssemblyFileVersion("2.2.1.0")]

I say good/bad, because the good is it might allow us to make builds which work better -- but bad, because we have to remember to update the hard coded versions.

If the issue of this not working is actually because C# / Unity / Mono / whatever is checking hash values of various .dll files, then we're probably never going to get around this kind of dependency hell (unless, I suppose, we do whatever the Toolbar guys are doing and write a wrapper).

[LameLefty]

For some reason, the latest SCANsat package that technogeeky put together has stopped working with RPM for me ... version 5 worked, complete with incorrect map icons at all, but v6rc isn't. Either I get an error for no satellite connection, or else I get a completely black screen "map" that never updates. I can still access the maps from external views but not on the IVA displays.

Any ideas for a quick, easy error I may have missed?

Bad form to quote myself but I've found the problem:

A user named OrbitalDebris has been updating RPM.dll and SCANsatRPM.dll to keep them in synch with the dev builds of MechJeb as sarbian releases them. Unfortunately, doing so breaks RPM integration with the v6rc version of SCANsat.

[Mecripp]

That was bad, Don't think OrbitalDebris recompile worked too good took all my RPM's out of my pods by could still use the toolbar to bring up the SCANsat map which was good.

Edited May 5, 2014 by Mecripp2

[LameLefty]

This might be a dum question but did you mix match the *.dll, As install v6rc version of SCANsat and his SCANsatRPM.dll or OrbitalDebris SCANsatRPM.dll and MechJeb2RPM the 2nd should have worked but can't mix the *.dll install v6rc with OrbitalDebris SCANsatRPM.dll and MechJeb2RPM and his MechJeb2.dll should work.

Not really sure what you're asking; it's hard to parse without periods and sentences.

The issue appears to be that, in order to keep RPM working with the dev builds of MJ, it's necessary to recompile BOTH MechJeb2RPM.dll as well as the core RasterPropMonitor.dll. Once the core RPM file is updated, it breaks SCANsat integration with RPM, though SCANsat itself continues to work just fine.