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.

No. 1. Asteroids are Vessels and not mainBody-ies. (and this SCANsat will not even recognize them) 2. Asteroids do not contain anything that SCANsat regards as scannable: no anomalies, no terrain height map, and no biome map. We may, in the far future, introduce something for SCANsat to do with asteroids, but we don't even have any such plans yet.

It happens to be that we at S.C.A.N. voted to exclude ModStatistics from future releases. However, I am very skeptical that it is ModStatistics that is crashing your game (and doubly skeptical that it is effing up your EVAs).

I'm working on this as we speak. I'm building it in a *very* robust and general way, so it's taking a while. But it will be worth the wait.

I have extracted what I consider to be the relevant information from your output_log.log: > cat output_log.txt | grep -i SCANsat | uniq -c | tail -n 22 1 JSISCANsatRPM: Active on page 0 9 [SCANsatRPM] SCANsat module not attached to this IVA, check for Module Manager problems and make sure the RPMMapTraq.cfg file is in the SCANsat/MMconfigs folder 1 SCANsat Controller: Loading 2 known vessels 1 SCANsat Controller: Loading map for Sun 1 SCANsat Controller: Loading map for Kerbin 1 SCANsat Controller: Loading map for Mun 1 SCANsat Controller: Loading map for Minmus 1 SCANsat Controller: Loading map for Moho 1 SCANsat Controller: Loading map for Eve 1 SCANsat Controller: Loading map for Duna 1 SCANsat Controller: Loading map for Ike 1 SCANsat Controller: Loading map for Jool 1 SCANsat Controller: Loading map for Laythe 1 SCANsat Controller: Loading map for Vall 1 SCANsat Controller: Loading map for Bop 1 SCANsat Controller: Loading map for Tylo 1 SCANsat Controller: Loading map for Gilly 1 SCANsat Controller: Loading map for Pol 1 SCANsat Controller: Loading map for Dres 1 SCANsat Controller: Loading map for Eeloo 1 JSISCANsatRPM: Active on page 14 1 (0x0000000048413EAE) (Mono JIT code): (filename not available): SCANsat.JSISCANsatRPM:OnUpdate () + 0x13e (0000000048413D70 0000000048413FF0) [0000000003DC4D48 - Unity Root Domain] + 0x0 and the stack trace ========== OUTPUTING STACK TRACE ================== (0x0000000103E10004) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x0000000048413EAE) (Mono JIT code): (filename not available): SCANsat.JSISCANsatRPM:OnUpdate () + 0x13e (0000000048413D70 0000000048413FF0) [0000000003DC4D48 - Unity Root Domain] + 0x0 (0x00000000484024DA) (Mono JIT code): (filename not available): InternalProp:OnUpdate () + 0x8a (0000000048402450 00000000484025D8) [0000000003DC4D48 - Unity Root Domain] + 0x0 (0x00000000484023F1) (Mono JIT code): (filename not available): InternalModel:OnUpdate () + 0x51 (00000000484023A0 0000000048402420) [0000000003DC4D48 - Unity Root Domain] + 0x0 (0x000000004840236B) (Mono JIT code): (filename not available): Part:InternalOnUpdate () + 0x5b (0000000048402310 0000000048402375) [0000000003DC4D48 - Unity Root Domain] + 0x0 (0x000000004846A325) (Mono JIT code): (filename not available): Part:Update () + 0x145 (000000004846A1E0 000000004846A32F) [0000000003DC4D48 - Unity Root Domain] + 0x0 (0x00000000042572DB) (Mono JIT code): (filename not available): (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr) + 0x6b (0000000004257270 000000000425734A) [0000000003DC4D48 - Unity Root Domain] + 0x0 (0x000007FED76136CA) (mono): (filename not available): mono_set_defaults + 0x2b8e (0x00000000FFFFFFFF) ((module-name not available)): (filename not available): (function-name not available) + 0x0 (0x0000000003DC4D48) ((module-name not available)): (filename not available): (function-name not available) + 0x0 ========== END OF STACKTRACE ===========

There are a lot of demands in this debate from people who don't write mods at all. Or perhaps they don't write software at all. All programs, from the simplest to the most complex, have dependencies. Not being able to include dependencies is detrimental to everyone: the users have a much higher barrier to use (deciding if they have all of the deps., installed in the exact right location (due to KSPAddon system, in this case), with the right versions). The mod authors then suffer because their work is harder to use. They also suffer because they have to provide technical support to people who may not understand what they are doing wrong. Your demand of mods not installing mods is untenable and naive.

I've updated the first post to reflect the changes.

That's pretty much it. If you want to scan for any resources (ORS, Kethane, Interstellar, etc) then you'll want v7. I would use v7 anyway, as it will be updated more frequently.

Did I miss them? I thought I covered everything. edit: Checking a post on page 4, both Duna and Ike seem to be there. It may be easier to go directly to our imgur gallery.

I think he means the new, native (non-Blizzy) toolbar.

The 0.24 update includes different versions of libmono.dll and also includes 64-bit versions of them. The current ones distributed with ksp-devtools are incompatible with the 0.24 executables. Also, if you're on Linux (like me), you'll want to compile a 64-bit version of load-fork.so. I have made some of these changes, but I never actually built libmono.dll myself. I'll have to go through that process. It seems to involve grabbing a more recent version of Unity's fork of mono, a newer version of mono-tools, and building them. The other outstanding problem I have identified is that MonoDevelop 5 (5.1 actually) doesn't seem to behave the same with regard to the Listen step of the debugger. The result of pressing either Connect or Listen is the same -- it goes straight to Application Output, and it never pops up a dialogue that indicates it's waiting for the process to connect. Any help in either of these two directions would be greatly appreciated.