technogeeky

The downloads are fixed. They are on github. I will update the first post links in a few minutes.

The (old) latest versions on GitHub have been modified to be in spec. ModStats was removed, and the ORS includes a license.

This must be a rendering/layout bug, because there is nothing (other than the title) in the window. I am not sure if it's fixed in the next release or not. I will try and investigate, but I can't promise anything.

Removed...

1. It always will (I won't be revising the distribution for an old version). 2. The only non-anonymous part of the ModStatistics data collection was the fact that it communicated directly: that is, your (public facing) IP address. There is no realistic way to subvert this (unless you route data through something like tor). And this IP adddress is *the only* potentially identifying data (that is, the actual information transmitted contained no identifying information). So by the definition you appear to be using, 'gather data anonymously' is an impossible task (it is an empty set). If you want all data collection of all kinds to stop, you should say that instead if what you said.

While I helped write part of those rules (specifically 4a), SCANsat does not do anything against the rules and it won't be going anywhere. So his comment still does not make sense. ModStatistics is already removed from the git HEAD of SCANsat (and from the jenkins builds); so if that was the reasoning, it is no longer valid.

I think there might be something else going on. It's a little hard to think about with that image. I'll have to look at the map generation code carefully anyway. Can you send me instructions/code so I can look at this scene myself? The primary issue with SCANsatRPM code (whose code I have barely looked at at all) is that the aspect ratio is assumed of the map is assumed in SCANsat proper to be fixed (2:1?). Not only do the IVA screens not have this aspect ratio, but they have several different aspect ratios (in ALCOR, for instance). Also: I'm about to release the v8/v9 series of SCANsat; so this is moot -- but you are posting SCANsat 7.0 material in the release thread. And, in fact, SCANsatRPM code was integrated into SCANsat with the version you have. I highly doubt this is causing the behavior you are seeing, though -- primarily because we changed so little when we brought it in. As for the rectangular -> spherical projection, that seems like perhaps you are doing something incorrectly? Again, I'd like to look at what you're playing around with.

Thanks for the Rep. I apologize for the delay. It's one of those things where you know you are distributing bad information, and you want to stop that before you make even one more table. Please let me know how your scanning journey goes.

OK. As one might see, I have now produced all of the tables for all of the planets. These occupy the 1st, 2nd, 3rd, 4th, and a few other posts on the front page (it all fits on the front page!). All tables and albums are up-to-date, with the 5 scanner types supported.

As an example of the new output, see this link. I actually don't trust the error values that much; but as you can see, we now have too MUCH space.

I was attempting to add another textual output format (csv-github) (csv, but formatted in a way that it looks nice on GitHub), and I was tracing back the EQx. As far as I can tell, I have either been labelling things wrong, or I have introduced a bug. Looking at some specific table, like this one for example: It's clear that the UEQx is produced by orbitRatN(minalti). And that the EQx is produced by orbitRatD(minalti). The same is true for every text file format. A cursory search for orbitRatN reveals that the only uses of it are: the initial assignment and the text table outputs. (ie, it is not used in any calculation, ever) A similar search for orbitRatD reveals that it's used very often, including in other columns of the text table output (sidelap) This leads me to conclude that: The column UEQx should be removed. The column EQx should be renamed UEQx and kept. TL;DR: I will make these changes to all output formats and push the result to github. If I'm wrong (or I am breaking someone else's parser) please let me know. In all tables, FOV is calculated as: [B]dispfov = 2 * (hFOV_at_altitude(altii) * 180 / pi);[/B] Altii is the index of the zone of altitude under investigation, for example hFOV_at_altitude(1) is the lowest altitude zone. i = 1; for thisAlt = alts if (thisAlt < S.AltitudeIdeal) thisFOV = min(([B]S.FOV [/B]* (thisAlt / S.AltitudeIdeal) * sqrt(surfscale)),[B]20[/B]); hFOV_at_altitude(i) = ( thisFOV / 2) / 180 * pi; else thisFOV = min(([B]S.FOV[/B] * sqrt(surfscale)),[B]20[/B]); hFOV_at_altitude(i) = (thisFOV / 2) / 180 * pi; end; i=i+1; end; I'm more than a little confused at this (and I wrote it!) I know that the 20 in question is in degrees; and it comes from the arbitrary cutoff in SCANsat code. The rest of the code is mirrored from the section of code just above there. (I understand the following paragraph will annoy you; bear with me): The original MapSatAltitude code as I found it was written in terms of "halfFOV". SCANsat was not. So when I input the values from SCANsat (into the scanners file), I entered what SCANsat said under FOV (ie, this is S.FOV), and then cut that value in half to make S.HalfFOV (never actually used anywhere in code. shrug). In conclusion, if there is a halving of FOV it is that SCANsat itself reports halfFOVs instead of FOVs. TL;DR: halp? I guess I can just multiply everything in MapSatAltitude by 2; and since we do not report FOV anywhere in the SCANsat UI (other than implictly, through the maps we make), nobody except those who read the SCANsat part configs will be wiser about it. Please someone tell me what to do here. In conclusion, ladies and jellyspoons; I think I will remove the following columns as they are not only incorrect; indeed, they are orders of magnitude incorrect. For instance: ScanTimeError might be incorrect. For the above examples, it suggests 1.2 minutes. That is probably not right; but it's in the same order of magnitude as the correct answer. SwathWidth, ResolutionDeg, and ResolutionMeter are all out by orders of magnitude. TL;DR: I am going to remove the columns: UEQx, SwathWidth, ResolutionDeg, ResolutionMeter (or their equivalents in other tables) because they are either meaningless or totally incorrect. And I will rename EQx to UEQx, which means Unique Equatorial Crossings. As for the other information: I totally agree. The idea that these tables have accurate information

Indeed. That is why I was very, very careful (and spent a whole day) writing my imgur album upload script. I did not want to break any existing image albums when I added the two new scanners. And yes; I def. should put the stuff in the first page/post. I will do that later. Thanks.

I apologize for the delayed response. I have been doing several KSP-related projects at once, and this one fell back a little bit. However, due to the upcoming release of SCANsat v8, I have a renewed interest. I have not completely merged all of the Matlab-related suggestions yet; but I fixed a few more bugs: See this link for the commit. I'm happy to report that, with this commit, I can finally build all plots and tables for all scanners without any errors: on Gilly on Minmus on Jool on Moho on Eve on Kerbin on Mun on Duna on Ike on Dres on Laythe on Vall on Tylo on Bop on Pol on Earth on Moon on Eeloo Notice that some plot labels used to be incorrect (the wrong color or label was associated to the wrong plot). This is corrected. I also have some scripting that allows me to automatically re-upload all images to SCAN's paid imgur account. I can't share yet, because it uses secret keys and such; but I will share it with them stripped. I intend to put the tables *in* the SCANsat thread, along with the imgur albums (which should automatically update; because I am submitting them via a script)

Oops! Sorry about that, and for the delay.

This is probably a bug. Please submit a screenshot or two, and your KSP.log.