technogeeky

This is a general issue with the upgrade to 0.23.5, I think. I don't think it's related to SCANsat in any way. I don't know if there is actually a fix, though. - - - Updated - - - edit: I'm a dirty, dirty liar who doesn't know what he's talking about! SHAME!

RPM adds glass cockpits generally.

1. There is no reason to believe this could would take up a lot of CPU time or memory. 2. This is a perfect example of something that could actually use threading (since it only needs to know a few, very minimal bits of information which are static modulo the state of the game -- that is, planet information, etc). In which case, you would be using currently unused CPU time, and you would only need to worry about memory usage. Either way, it could be written in C# and the same code could be presented as a dll for in-game use, and an executable for out-of-game use. It would also be a fine candidate for a web application.

There are also a few tools which run arbitrary Octave/Matlab code online in the browser. In that case, all one would need to do is wrap up all the functions that were split into files back into one file, and put the data in that file too. But I would prefer rewriting it in C#. Also, Psawhn: Earlier you asked if SCANsat uses a camera or something like that to scan the surface -- no, it does not. The camera bit (RemoteView) is just for the BTDT sensor.

Psawhn: Yes, I am aware they are incorrect. I was still deciding what to do about it. I don't even remember the state I left MapSatAltitude.m in. I currently think I should modify MapSatAltitude.m to use the same calculation that SCANsat uses internally. Namely, fov *= (current altitude/ideal altitude) if you are below the ideal altitude; and also fov *= max(1,sqrt(kerbin radius/mainbody radius)). This first factor is a penalty, the second factor is a bonus if the body is smaller than Kerbin. Yes, I think this is precisely where the discrepancies come from; I just was focused on getting SCANsat released first.

You can use any official or unofficial sensor you like, as long as you activate the sensor then SCANsat should operate normally. The Orbit button will show you where your orbit descends to the surface, but only after you do your de-orbit burn. A near future version of SCANsat should have support for the MechJeb landing reticle and the rover target reticle.

I modified the ssRPM file, and the only change is for resetMap. The next version of SCANsat and ssRPM will reference MechJeb to get landing target information and rover target information; but we'll cross that bridge when we get to it. RPM, ssRPM, and mjRPM all have no declaration of assembly version -- which implies that they are set to 0.0.0.0 and behave as hard coded. There is some other file 'sharedassemblyversion' in the git repo which does have a stated version (0.17.*) -- which will indeed change every time it's built, but I don't know what it's used for. Are you one of those users who wants to build his add-ons himself? Or are you doing this because it used to be necessary to get things to work? Yes. In my mind, either SCANsat's internal hardcoding of the aspect ratio of the map OR RPM/ssRPM's use of maps which do not have said aspect ratio is a bug. I don't know which I think is more incorrect yet.

On iPad so sorry for mistakes As of the latest mechjeb build and the latest scansat build, there will be no more versioning problems. Everyone had agreed to hardcode their versions to workaround. You need to use the included ssrpm or build it from scansat source. Reset map should be called with a 1 in the second argument Anyway please just delete your scansat and ssrpm folders (save any exported pngs) and use the new ones

This issue is solved as of the latest releases of both MechJeb and SCANsat. Both projects are now committed to hardcoding their assembly version (even for dev releases), and the ssRPM and mjRPM helpers are both hardcoded to 0.0.0.0.

We at S.C.A.N. encourage all forms of worship and deism, except those which interfere in the sciences of scanning and navigation. We also take cash, checks, money orders, wire transfers, and blood (or not blood) diamonds.

Yes. Tonight, I have on my list: create dev thread for v7r0 create link from this thread to dev thread, and vice versa create FAQs section for this thread add all TODOs from TODO.txt into GitHub issues, and delete TODO.txt add any other non TODO.txt wants into GitHub issues Also, my current plan (just out of circumstance) is to reserve odd-numbered versions for development, and keep even-numbered versions for releases. So the next one to get released in here will be v8.0. Everything in v7.0 will be for development and new features, and any bugfixes or changes that should be backported from v7.0 will end up in v6.1. Or something like that. Maybe I'll do the odd/even split on the last digit, so 6.0 is release, 6.1 is dev, 6.2 is next release. Either way, the version numbering in the assembly will be the same until either: the next release version we introduce backwards-incompatible changes Also, my current plan is to replace the MapTraq scanner (and maybe BTDT) with something nicer by the next release. But instead of replacing it, I will deprecate the existing scanner, and remove it two releases from now.

We should have other mods start sponsoring competitions for models/textures they need (but can't do themselves). In addition to the weeks when we just have interesting new ones.

I will take these into consideration.

Agreed. I think I'll also convert the output to github flavored markdown, so I can make nice formatted tables instead of space-delimited nonsense.

DMagic got to you first; but he's right -- there hasn't been any changes to scanning mechanics, and you certainly shouldn't need to be adjusting your inclination every orbit. Putting a spacecraft into very-polar orbit (87 to 93 degrees) will eventually scan everything, assuming the planetary body is rotating. But eventually will take a long time. There are ideal orbits that have lower inclination and will scan much faster. My current way to attack a full planetary scan with a single spacecraft would be to inject into orbit in a polar orbit (89 or 88 degrees), and map both poles. Then, I would go down to an ideal orbit (using the ideal calculator, in my signature) and get the rest. - - - Updated - - - Yes. This is intended and for the sake of realism.

I hope to have this done for v7. I have one standing offer for modelling work, so I can ask for it.

I def. would not use my code to publish tables yet; it does not yet take into account the lower-than-ideal FOV penalty that SCANsat applies. I intended to fix/publish this week.

The only thing that is necessary to use RPM, to my knowledge, is to have the latest version (0.16) installed. Then, as long as your Kerbal Space Program\GameData folder has the relevant folders like so: ... JSI ... SCANsat SCANsatRPM ... Then it should work. RasterPropMonitor expects SCANsatRPM version 0.0.0.0 (which it is), and the included SCANsatRPM expects SCANsat version 1.0.6.0 (which it is). If you are still having problems, please (carefully, with backups) delete JSI, SCANsat, and SCANsatRPM and try again. RPM support is important to us at SCAN, so we want to make sure it is working right.

I know that some countries restrict access to GitHub (which is insane and horrible, but whatever). Can you access KSPforge? What other sensible location can I put the binary so you can get it sooner?

Please put spoiler tags around totally completed maps. I see now that my first post has the same thing exposed on one of the Big Map animations, which was a mistake on my part.

FYI: There is also the Ideal Altitude Calculator which is much more detailed and complete (see my signature) -- though one would have to use the software themselves right now, since I haven't published all of the altitude tables. But I expect in the next few versions (v7 or v8) will such information (ideal altitudes, orbital resonance identification, and projection of all of the orbits needed to complete the map) in SCANsat itself. - - - Updated - - - I'll make it more apparent. I have run out of space in the header bar, so I don't know where I will include it. But I will find a way.

You can't change the small map to show biomes. It either shows high resolution or low resolution altimetry, depending on the scanner.

I don't know. I expect to add new parts in V7, and possibly change MapTraq and BTDT models and textures. Yes, in v7. It's in development already.

No, it does not.

Oops. The most permissive license in SCANsat is the BSDv2 one, which is on the original code. The compressor is listed as GPLv3 in the license.txt file. So I have changed the first post to say it's BSDv2.