CacheStats minor problem at start of new year

[+abcdmCachers]

I found a little bug in CacheStats today. Just wanted to let CacheStats users know that on Jan. 1 your projected number of cache finds for 2007 will be way off (I mean waaaay off - it will take quite a new year's resolution and superhero stamina if you want to meet the projected value). But as soon as you generate a gpx file that has at least one cache find for 2007, the calculation will correct itself. Or you can download an update that has the fix for the problem here:

http://www.logicweave.com/cachestats.html

(Just need to download and install, previous version will automatically be uninstalled).

 

A few other minor problems have been fixed since the initial release of 2.0 in November:

- New goal values not shown in HTML export until program was exited and restarted

- World map checkbox didn't stay checked

- GC10C has no D/T values (!) causing CacheStats to choke. Not sure if there are any others like this one.

- Nova Scotia and Czech Republic not filled in on maps

 

If you're not familiar with CacheStats yet, it's a program that calculates statistics based on your my-finds pocket query. Click above to learn more.

[+FlygURL]

I downloaded it today. I like the enhancements a lot.

 

I think that I found a problem - while I found a cache yesterday, I did my logging on gc.com after midnight. My log shows in gc.com as being 12/30, but cachestats shows it to be 12/31.

 

Also, I have a question about the sequence of caches cachestats interprets. I did three caches yesterday. The second one was a milestone and chosen for that reason. However, cachestat interprets another to be that milestone. How do I correct that?

[+The Cheeseheads]

- GC10C has no D/T values (!) causing CacheStats to choke. Not sure if there are any others like this one.

I've come across this problem as well with my app. It looks like the first bundle of caches that Jeremy entered in when GC.com first launched didn't all have D/T values set, and for some, the GPX file contains 0 or -1 where the values should be.

 

So yes, there are many more. (Maybe 70 or so?)

[+abcdmCachers]

I think that I found a problem - while I found a cache yesterday, I did my logging on gc.com after midnight. My log shows in gc.com as being 12/30, but cachestats shows it to be 12/31.

The time of day that you logged shouldn't matter, only the date that you select when entering the log. But I don't know why it would show 12/30 in gc.com and 12/31 in cachestats. Presumably it contains 12/31 in the gpx file, so maybe gc.com pocket query generator extracts the dates differently? Feel free to send me your gpx file via the email address on logicweave.com and I can take a look to see if I can figure out what's going on.

 

Also, I have a question about the sequence of caches cachestats interprets. I did three caches yesterday. The second one was a milestone and chosen for that reason. However, cachestat interprets another to be that milestone. How do I correct that?

CacheStats orders caches first by find date, then by the order of caches logged on that date if there is more than 1. So if you logged your finds in a different order than you found them, you'll have a discrepancy. CacheStats lets you correct this: select the milestone, click on the "Make correction" button, then select the correct cache for that milestone. The correction will be saved in the CacheStats data file, so you should only have to do this once.

[+Maingray]

Woh, missed the November update. great extra stuff, changes are just what I wanted!

[+J10fly]

New version looks awesome! Just changed my profile with the new info! Thanks!

 

Jayman11