technogeeky

Excellent. And re: caching in RPM -- I don't buy it. First, one cache set (the one RPM would need if constantly re-centering) is just a translation of the existing cache set (modulo map size). In theory you might not need to store any additional information, but you can probably do it with an x and y offset, and/or four cutoffs. (or not: cache parts of the map that aren't currently visible in RPM, who cares) And if not that, you can just cache something else. The I plan to work quite diligently on performance upgrades this upcoming week. We're going to need it, especially as we introduce more and more overlays (for resources, for N future orbits (to check for a resonant orbit closure/non-closure), for a higher density of orbit information, etc. By far the most intimidating thing that I intend to try is to breakup the redline-drawing process so that each box in the grid is drawn independently. This way, not only will we cache the parts of the map that aren't changing -- we won't even try to update the parts of the map which could not have changed.

<-- back at work tonight. Any updates? The only bug I intend to investigate before publishing the final v6 is the bigmap-button-breaking one I mentioned. edit: I wonder why every pull request has so many commits. It's probably something I'm doing.

The problem was that I couldn't open the big map again after closing it.

DMagic: I have updated my master with the changes from above. I'd like to figure why I was having trouble opening the Big Map, but I have to go back to work. And yes, I'm using the ALCOR capsule. There are several different displays, all of different sizes. I expect that is the source of part of the problem: SCANsat expects a fixed (and certain) aspect ratio; and these RPM map instances seem to ignore this principle. Note the re-ordering of the logic in OnInitialize(): first, scanners with scanNames are dealt with (all of them, but MapTraq has is an Eyeball scanner in the part.cfg); then, MapTraq has the labels rewritten and the analyze actions/events removed; then, BTDT has the analyze events/actions removed. Until tonight...

I was not able to see any problems with the orbital tracks in ssRPM being wrong. My capsule landed exactly where the track ended: - - - Updated - - - However, I did find a problem: After opening the Big Map, and clicking trying to turn Orbits on/off while it was redrawing, I was unable to re-open the Big Map at all. I don't have exact steps to replicate, but it is more serious.

I updated my post to reflect that I figured out what you meant, and made the changes. All of the parts have appropriate VAB and Flight entries. I don't have a reference for performance in RPM, but I could look at that later. I am looking at the orbit as we speak.

DMagic: I discovered another bug. It went something like: 1. Have a partial scanned map of Kerbin. (SAR, in this case) 2. Open BigMap on Kerbin, render. 3. (Cheat) Set Orbit to 15,000 km @ Mun. 4. Without resizing map, render map. The partial scan map of Kerbin is sitting on top of the map of the Mun. Resizing the map gets rid of this bug.

Checking on these two...

The following fixes are in: * part.cfg changes for MapTraq and BTDT * re-enable lower-than-ideal-altitude penalty (also fixes blinking) * MapTraq and BTDT have been stripped of their Analyze events and actions I went with values of 0.05 for 2nd component of the part.cfgs. edit: nevermind that

As I have mentioned: I am not going to start a first post until I am confident that the release is free of serious bugs. This is for many reasons, but among them are: This will be the first Add-On Showcase release, so lots of new people will see it. I don't want to besmirch the reputation of SCANsat. This will be my first official release of any kind, so I don't want to start off with a bad reputation. There will be a new Showcase thread for the released version, and a new Dev thread for the upcoming version. This doubles the precariousness of #1 and #2. I want to make a new thread as soon as possible too; especially because this will free me to start working on my own additions to SCANsat instead of making sure the existing product works as desired.

This. Is. Correct.

Blowing up something to reduce debris huh... Like the Armageddon approach to asteroid avoidance.

The big map overlays are currently affected by no active scanners. That is what I was asking about.

#5 should be amended to say "the scanner is consuming charge (and is still scanning), but shows as off" The static does correctly come on when the electric charge hits 0.00, on more careful examination. I don't remember if the bigmap overlays were drawn when all scanners were turned off before.

I suspect this is because we've introduced an incorrect check on the status of a boolean, scanning. Can you check for me: activate/turn on any sensor on the vessel you had problems with, and see if the overlays work then (orbit icons, flags, markers, asteroids, etc) edit: in addition, the buttons for stop/starting are behaving incorrectly for me. they seem to get stuck after one use. I am testing by using an existing craft on the launchpad. edit edit: This behaviour (stop/start buttons not working "properly") seems to be related to my ship not having power. Similarly with the first thing comment. So, LameLefty: does your ship have enough electric charge? DMagic: however, there is a bug here. Steps to reproduce: 1. With some charge, start a scanner. 2. Allow the scanner to drain out the charge. (It goes blank before the static shows up; which is also incorrect) 3. While having no charge; turn off that scanner. The model will retract. 4. (Cheat): fill up your electric charge. 5. The scanner is consuming charge, but shows as off.

If I had bothered to even launch the game after my last build, I would have seen this. I'll check it out. I have had basically only an hour a day for some time to work on this. Happily, I have an extended weekend and all week next week off. So v7 should be pretty special.

Yes, I'm aware of that. It's not that I don't know how bitmasks work; it's that it doesn't need to be defined if we are using this enum as a bitmask AND I didn't know where in the scansat code we actually use 3. As for your suggestion; I don't know. Yes. If we continue to use this as a bitmask, then 4, 64, and 128 are available; so we could just take one. As for looking in the detector module -- no, that does not make sense. There is no reason to believe every kethane detector will detect every kind of kethane resource; regardless of that, you want to be able to see a map of each kind of resource regardless of the presence of such an able detector on your vessel.

Well, the one person I trust the most says the v6 version is free of major bugs! Anyone else using the v6 release and can report no major problems?

How dare you correct my face to ... my face! Fair point. The current SCANtype code is: public enum SCANtype { Nothing = 0, // no data AltimetryLoRes = 1, // low resolution altimetry (limited zoom) AltimetryHiRes = 2, // high resolution altimetry (unlimited zoom) Altimetry = 3, // both (setting) or either (testing) altimetry //Slope = 4, // slope data Biome = 8, // biome data Anomaly = 16, // anomalies (position of anomaly) AnomalyDetail = 32, // anomaly detail (name of anomaly, etc.) Everything = 255 // everything } I don't even know what the heck the Altimetry = 3 setting is for, but last time I checked 3 isn't a power of 2. There also isn't a reason I can think of that this should be restricted to 2^8, other than existing support for "everything". What I was getting at, is that you should be able to break up any part.cfg entries into multiple copies which just have each appropriate kind of scan, rather than using bitmasking. Sure, it's unnecessary duplication. And it's putting extra crap in persistent files that needn't be there. Perhaps all of this new scanning should just be in a different set of SCAN types anyway.

The eight different scanner types restriction is coming from the bitmask implementation (ie, you can use any value from 2^0 to (2^8 - 1))? If that is the case, I still haven't seen any location (except that 3rd party scanner part) where the bitmask is used as a bitmask -- and if that is the case, surely we can just claim to be able to support 255 types of scans? - - - Updated - - - Also, please report back in this thread if you are using the final v6 release and it's working and doesn't have any bugs you are aware of. I still need to know that it works for others before I make the new threads.

Everything I was able to test worked as I expected. There still might be some things not quite right with ssRPM, but it works at least. I will look at pushing down the map caching to ssRPM this week.

Once again, here are the download links for the fixed, final v6 version. DOWNLOAD SCANsat v6 (from GitHub) SCANsat v6 SOURCE (hosted by GitHub) This version, like all new versions, has a hardcoded version ("1.0.6.0", meaning SCANsat 1 version 6). Please also check out the new README. I have converted it to nice, link-filled, table-filled markdown. Please suggest fixes, changes, or additions. Unless this has any breaking changes, this freezes v6. All future features or bugfixes will be in v7 (or later). If everything is reported as good, and Mihara is able to compile against these official versions (please inform s/he to try and do so), then I will make a new thread inthe Showcase for the release version, and make a new thread in Development for us developers.

Apologies for this taking so long... my test scanner saves with ALCOR capsules all have the rotato-kraken bug, so I have to make a new spacecraft to test it. I guess.

Another day, another "final" version of V6 coming right up. I just need to clarify one issue with DMagic and then I'll re-publish the v6 release.

Ugh. There is a showstopping bug in my v6 release. While trying to make a set of screenshots, I ran into this: I got there by right clicking on the big map to zoom in, and it did something funny to the big map. I suspect that I have screwed up merges.