technogeeky

Now that SCANsat releases all have included maps, can we make an entry for SCANsat with the flag logo (somehow, it's going to be hard to do it) and include it with PartCatalog? Thanks

It's not usable? It should be usable. It may not be pretty in terms of GUI, but it should work fine.

There was quite a bit of warning in the old SCANsat thread. I had been posting in it for about a month, indicating that I was working on an updated release. After about 2 months total of being unable to contact damny through multiple avenues, I went ahead and forked the project (as the first post says, in the header bar). Now, the current team is me (technogeeky) and DMagic. We have been the authors of this fork for about a month or so.

Such a note was added the very moment that ModStatistics was added to the release version. It's the second line of the post.

First post updated before you asked me. Huzzah!

I have updated the first post to reflect the changes DMagic made. Thanks as always, DMagic. I have changed the folder structure to represent the fact that SCANsatRPM is no longer needed.

We have not released a 0.24 version yet, no. This doesn't mean that the existing version won't work, however.

I've updated the first post: please note this update reflects DMagic's update from several (12) days ago. Sorry for the delay.

It records static when you are low on power (or are about to be low, during a time warp); or when you use a scanner on a place that doesn't have that resource to scan (ie, Moho doesn't have a biome). In this case, it's probably the latter.

The reason that both DMagic and I agreed with adding ModStatistics in the first place is because it only takes a few minutes to review the source code for it (it's all in one file; and the data gathering only consists of one function). We both indepdendently reviewed the code and agreed that it was safe and not spying on anybody. As far as I understand, the only private information that can be gleaned from the submission of the report is that the act of submission will connect to a remote server; and in doing so you must reveal your IP. However; any mod which connects to any remove server will do the same (and several do; for instance, to check for updates). However, Majiir made it clear to us that he's not even recording the IPs. The section of the relevant function is here. Calling this spyware or nastyware is either propaganda or nonsense. Several data points which would help developers but would also carry a risk of de-anonymizing the results have already been considered and rejected. It's anonymous. It collects only a tiny bit of information about what .dll files your game is using, and when crashes are happening. If you don't like it, you can delete it or opt out -- no functionality to you will be lost.

I have edited the first post to issue the standard warning about ModStatistics.

It's not for you, it's for us. It has the potential to tell us which mods are conflicting with us, and which are not.

Updated first post to reflect 7.0rc2.4 release.

And, to be even more clear, I have updated the GameData locations: GameData Folder Structure [TABLE=class: cms_table, width: 800] [TR] [TD] GameData 000_Toolbar\... ... JSI\...\RasterPropMonitor.dll ... MechJeb2\... MechJeb2RPM\MechJeb2RPM.dll ... SCANsat\SCANsat.dll SCANsatRPM\SCANsatRPM.dll ... ModuleManager.2.x.x.dll [/TD] [TD] [REQUIRED] SCANsat.dll from us [*][RECOMMENDED] 000_Toolbar from blizzy78's Toolbar [*][REQUIRED for SCANsat in IVA]* JSI from Mihara's RasterPropMonitor SCANsatRPM.dll from us [*][REQUIRED for MechJeb in IVA]** MechJeb2 from r4m0n/sarbian's MechJeb mj2RPM from Mihara's RasterPropMonitor [*][OPTIONAL]†from sarbian's ModuleManager [/TD] [/TR] [/TABLE] [*] required for SCANsat in IVA glass cockpit, but otherwise optional. SCANsatRPM will not be loaded if it is not needed, so it is safe to install in either case. SCANsatRPM must be installed exactly in GameData\SCANsatRPM. This is required because of the alphabetical, depth-first search nature of Squad's plugin loader. [**] required for MechJeb in IVA glass cockpit. Currently, SCANsat does not interact with MechJeb but this may change in the future. [†] optional; required for adding SCANsat functionality to existing parts/pods/vessels/etc.

I don't know why they would conflict, but I think I have seen logs with error messages from TAC before. Can you please upload your full log somewhere, and paste or PM me the link?

I am trying to understand what might be going on here. I think I may need you to upload your entire log somewhere and PM me the link. A search with the error message: AssemblyLoader: Exception loading 'SCANsatRPM': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. reveals some similar problems from last year with MechJebRPM, and Mihara of RPM fame telling a user to check to make sure only one RasterPropMonitor.dll is found anywhere inside GameData. While you're at it, please check to make sure that there is only one SCANsatRPM.dll found anywhere in GameData. I think I can infer that the reason that JSISCANsatRPM and MapMarkupLine are the only things mentioned is that they are the only classes exported by SCANsatRPM.dll. I suspect you must have two copies of one of these DLLs somewhere. A complete log (uploaded to some file sharing service) and/or a complete listing of the contents of your GameData directory would help. edit: looking at the documentation for GetTypes(...), it seems like the only time it throws an exception is when an assembly is unavailable at the time GetTypes(...) is called. This further points to either duplicate DLLs or misplaced DLLs.

Can you verify the correct placement of the DLLs: GameData Folder Structure [TABLE=class: cms_table, width: 800] [TR] [TD] GameData 000_Toolbar\ ... JSI\ ... MechJeb2\ MechJeb2RPM\ ... SCANsat\ SCANsatRPM\ ... ModuleManager.2.x.x.dll [/TD] [TD] [RECOMMENDED] 000_Toolbar from blizzy78's Toolbar [*][REQUIRED for SCANsat in IVA]* JSI from Mihara's RasterPropMonitor SCANsatRPM from us [*][REQUIRED for MechJeb in IVA]** MechJeb2 from r4m0n/sarbian's MechJeb mj2RPM from Mihara's RasterPropMonitor [*][OPTIONAL]†from sarbian's ModuleManager [/TD] [/TR] [/TABLE]

The first post has been updated to reflect the v7.0rc2.3 release.

This bug is fixed in the dev release. Basically, the minimum allowable window size isn't small enough (and/or the buttons don't have the right depth). I just made it so you can't make the Big map that small, in the dev release. WORKAROUND: Simply go to Settings -> Reset all Window Positions. I think it resets sizes too.

If you are following this structure, then SCANsatRPM should work: GameData Folder Structure [TABLE=class: cms_table, width: 800] [TR] [TD] GameData 000_Toolbar\ ... JSI\ ... MechJeb2\ MechJeb2RPM\ ... SCANsat\ SCANsatRPM\ ... ModuleManager.2.x.x.dll [/TD] [TD] [RECOMMENDED] 000_Toolbar from blizzy78's Toolbar [*][REQUIRED for SCANsat in IVA]* JSI from Mihara's RasterPropMonitor SCANsatRPM from us [*][REQUIRED for MechJeb in IVA]** MechJeb2 from r4m0n/sarbian's MechJeb mj2RPM from Mihara's RasterPropMonitor [*][OPTIONAL]†from sarbian's ModuleManager [/TD] [/TR] [/TABLE]

If a map resize (click the [//] button and move it a little) fixes this; then it is simply the big map cache bug. If it does not fix it, then it's another bug. Please let us know.

The resize bug is fixed in v7.0. This line and this line were changed in an attempt to make it impossible to have the // button overlap. But these are not yet included in master, and hence are not in the released version.

I haven't tried this route, so I don't know yet. Is at least one scanner (and/or MapTraq) turned on? I don't even think that is required for RPM.

I'm not aware of anything we've done that would break it. What altitude are you scanning at? What color(s) are the "LO" label on the Small Map? If it is solid orange, then your altitude is too high.

I'll double check, but I think the effective FOV numbers are "correct" (in the sense they match what SCANsat is doing). The nominal FOVs for those scanners are 5, 4, and 2, respectively. There is an (arbitrary) maximum cutoff of 20 degrees total, which is again reproduced. Me too. But until I switch SCANsat to tell the user any of these values during scanning, I'm just going to stick with the nomenclature that's there. Once I have a good handle on the relationship between the two, I'll switch over to be correct. I didn't actually even think about checking that, though obviously it should be easy to do. I suspect they are dependent on the scan-lines-per or whatever parameter that is currently 200, which is legacy and wrong. I have a chicken-and-the-egg problem with the hFOV (notice it's only used once). hFOV_at_altitude is what I should be using where hFOV is used (again, per SCANsat design, not real life) -- but the maximum altitude *could* be determined by maxSwathWidthAlt, which would change the indexes of hFOV_at_altitude. Yes, on the next run I will probably remove the last two columns (resolution in degrees, resolution in meters). I wanted to get the Kethane scanners working, and I started editing/commenting your Kethane code; but I got bored and moved back to SCANsat. I want to get Kethane done so I can bribe Kethane users to try out SCANsat when they look up what altitude to scan at. I think SAR is arbitrarily high. I don't know about RADAR. I don't know about biome, but that makes sense. Damn. I was hoping you would know. I assumed it was number of total number of equatorial crossings, but that didn't seem correct.