Jump to content

Release Notes 2/24/10


OpinioNate

Recommended Posts

If this is not the appropriate place to post problems related to today's upgrade, kindly let me know.

 

There is almost a screen full of white space now between the cache description and the Additional hints. This is in both Firefox 3.5.8 and IE8. Is everyone else seeing that? What used to be in that space?

 

Thanks.

verano

Link to comment
There is almost a screen full of white space now between the cache description and the Additional hints. This is in both Firefox 3.5.8 and IE8. Is everyone else seeing that? What used to be in that space?

This was from the last update. It happens when the cache description is very short. Additional Hints only comes after "Inventory" on the right column.

 

If that is not what you mean, a screen cap or cache listing would be helpful.

Link to comment

Thanks for your kind reply. It appears that not only the Inventory, but also the bookmarks must be above the Additional Hints. I do not recall seeing this phenomenon before last night. If this is the way things are going to stay, I guess I need to make my cache descriptions longer! Why is the page set up so that the items on the right must be above the Additional hints?

 

GC1BR3V

GC1AZVY

GC1833P

 

verano

Edited by verano
Link to comment

... but still they don't have the slightest idea how to provide a page in Unicode. Great.

 

I TOTALLY AGREE!!!

No Unicode, No Modernized nor Global Geocaching.com!

(And, I don't think it's that difficult...)

 

Anyways, thanks for trying to improve the GC.com.

Very much appreciated, but would love to see more!

 

- Dr.MORO

Edited by Dr.MORO
Link to comment

Thanks for your kind reply. It appears that not only the Inventory, but also the bookmarks must be above the Additional Hints. I do not recall seeing this phenomenon before last night. If this is the way things are going to stay, I guess I need to make my cache descriptions longer! Why is the page set up so that the items on the right must be above the Additional hints?

 

GC1BR3V

GC1AZVY

GC1833P

 

verano

 

Looks to me like the BookMark lists are pushing the additional hints lower.

The Right hand table cell holds the info from Navigation to Bookmarks.

That cell and the cache Description cell are in the same row.

So having a short description with Book mark list gives the appearance of white space below description.

Long description with no book mark list gives appearance of white space on right side below Inventory.

 

From a design point of view this can be tricky as not every cache page will have the same attributes to it. Trying to ensure that the click-able Google map inserted to the right of FIND doesn't overlap or is overlapped by text could be tricky.

 

One small fix for the white space below the cache description may be to move the additional hints up one cell. But still if large bookmark list in present, white space will still appear. Especially if cache description is very short.

 

I wonder if floating div tags have been tried to design the layout of cache pages?

If so, were issues found with creating a seamless css page?

 

I haven't dug too deeply into the html of the cache pages, but these are my quick observations on the problem that you are seeing.

Link to comment
Thanks for your kind reply. It appears that not only the Inventory, but also the bookmarks must be above the Additional Hints. ... Why is the page set up so that the items on the right must be above the Additional hints?

Before the site update in January, long cache descriptions were wrapping on the right, in line with the left side of the bookmarks and inventory. This left much white space below the bookmarks. Then they changed it so the description could take up the full width of the page, which had the side-effect of dropping it below the inventory and bookmarks.

 

Perhaps some future site update will get the description to properly wrap around the inventory column.

Link to comment
14699: Timestamps on field notes getting converted multiple times, leads to incorrect log dates

Fixed and now displaying timestamps to user for casual verification

Looks like this one is fixed to "as described".

 

For testing, I used a file I created, with found time = 2010-02-24T00:01Z through 2010-02-24T23:01Z in 1 hour intervals. My time zone is PST.

 

After uploading, on Field Notes, I see the 1st 8 geocaches listed as Found on 2010-02-23, and the remaining 16 as found on 2010-02-24. This is correct for my time zone setting.

 

Next, I tried changing my time zone, AFTER uploading the field notes. The dates displayed on Field Notes changed accordingly. For example, if I change it to Beijing, the first 16 shows as 2010-02-24, and the remaining 8 shows as 2010-02-25.

 

It is important to note, however, that this is only the displayed date. When you click on "Compose Log", the date filled in is the original GMT date. So in my example, all of the logs (if unchanged) will have the dates 2010-02-24.

 

This is consistent with how moun10bike described it should work after the January update. Hopefully the next step would be to change the date in the log screen to local date.

Yep. That's exactly what I'm seeing.

 

Tried the same test but from 2010-02-23T23:00Z to 2010-02-25T00:00Z in 1 hour intervals. I included one entry from the previous day and one for the next. My time zone is EST.

 

The fieldnotes.aspx page is fixed, showing all dates in my profile's timezone.

 

The log.aspx page still needs work, showing the date using GMT.

Link to comment
The log.aspx page still needs work, showing the date using GMT.

Since you have a script that adjusts the time, seems that you would be better off running the script to convert your geocache_visits.txt time to Eastern time, and setting your time zone to GMT. That way, the displayed time and logged time would both be correct.

 

Or avoid finding any caches between midnight and 5 a.m. :lol:

Link to comment

grrrrr and a year has passed without any fixes for comments in non-english languages.

 

Groundspeak! the comments you already store in UTF8 (because when they arrive over email, they are fine), so why is it so hard to display UTF8 characters also in the cache description and comments on the website ?

 

Is USA really the only country where GC is played? Finally look at your statistics to see you are wrong!

Link to comment

Since you have a script that adjusts the time, seems that you would be better off running the script to convert your geocache_visits.txt time to Eastern time, and setting your time zone to GMT. That way, the displayed time and logged time would both be correct.

That's what I'm probably going to do. Just trying to think if there's anything else important that uses that timezone setting. I know the dates in the forum don't.

 

Or avoid finding any caches between midnight and 5 a.m. :D

:lol:

 

Ever hear of the BFL Crew? ;)

Edited by Avernar
Link to comment
Ever hear of the BFL Crew? :lol:

Not until you mentioned it. Found your name and photo on flickr after that :D

 

I'm guessing BFL = before first light? Urban dictionary has some rather unpleasant alternatives.

 

I left out a 3rd alternative - moving to Morocco. Casablanca has no GMT offset and no daylight saving time ;) Unfortunately, not too many geocaches either - only 40 in case you're wondering.

 

I don't believe the time zone is used for anything important - I accidentally left it set to New Zealand for a few months once without noticing it.

Link to comment

I'm guessing BFL = before first light? Urban dictionary has some rather unpleasant alternatives.

That's a rather good alternative meaning. It stands for (the family friendly version) Big Friggin' Light. It's a reference to all the high powered flashlights the group uses. We are very heavy into night caching. That's why I keep running into the field notes issue as I do get quite a lot after midnight.

Link to comment
how selfish. Some of us can only use the web browser provided by company IT.

How selfish. Using company time and resources to play a game :lol:

I'm one of those "corporate-mandated IE 6" users. I am blessed to have an employer who allows personal internet use, subject to certain rules including "no Firefox." Historically I've enjoyed publishing caches during my lunch hour, or while listening to a long conference call, or to clear my head in between meetings, or at the end of my work day. It helped spread my volunteer work (and the FTF opportunities) throughout the day. It kept me from getting too far behind in reviewing the new caches and responding to issues.

 

Since January the functionality of the site has been significantly impaired in IE 6. While improvements were made in hotfixes and yesterday's release, there are still many issues. Until these issues are fixed, cache owners will need to be patient because it will take me longer than before to respond. I am unable to volunteer my time as much as I'd like to. How selfish of me.

Link to comment
How long till the annoying red banner goes away? :lol:

Probably after the update that's going to happen at 11am.

 

You did notice that it's currently referring to a different update than it was yesterday, right?

I find it hard to complain about a notice regarding updates when we have been surprised by unannounced updates so often. This banner is something that everyone should notice and we should all appreciate it.

 

I could NOT agree more. Thank you for keeping us updated, it is not an inconvenience when it helps make the experience better for everyone.

Link to comment
I'm one of those "corporate-mandated IE 6" users. I am blessed to have an employer who allows personal internet use, subject to certain rules including "no Firefox."

Maybe that is part of the corporate strategy to discourage personal internet use :lol: Next month, only Lynx will be allowed for personal use.

Link to comment

Not sure if this is the right thread, but I found a possible small bug...

 

When logging my finds using Field Notes, the GC code at the top does not always display correctly, although most of the time is does. The attached jpg shows that the cache just logged should be GCYZ39, but it is really GC239BF.

 

c3f0aad6-aca5-4616-a1fd-19e625b5e92a.jpg

Link to comment

Ok maybe its been covered elsewere but it is a glitch in my opinion.. From the build pocket queries page, I attempt to run a querie of "my finds". One would think that one click would get it into the que as with the other queries. However it doent seem to go on the first click. (or the fourth or fifth for that matter.) Ok so maybe I am not allowing it to take but you would think it would atleast acknowledge the click. Dunno..

Thanks,

TC&F

Link to comment

Ok maybe its been covered elsewere but it is a glitch in my opinion.. From the build pocket queries page, I attempt to run a querie of "my finds". One would think that one click would get it into the que as with the other queries. However it doent seem to go on the first click. (or the fourth or fifth for that matter.) Ok so maybe I am not allowing it to take but you would think it would atleast acknowledge the click. Dunno..

Thanks,

TC&F

 

My understanding is that it does not gray out until the PQ actually runs. Continual clicking resets the run to the back of the queue. Click once and be patient.

Link to comment
The log.aspx page still needs work, showing the date using GMT.

Since you have a script that adjusts the time, seems that you would be better off running the script to convert your geocache_visits.txt time to Eastern time, and setting your time zone to GMT. That way, the displayed time and logged time would both be correct.

 

Or avoid finding any caches between midnight and 5 a.m. :blink:

 

Agreed (that it needs work). Ironically, by my estimation, it was fine before - presumably because it wasn't doing any 'localization' of timezone - and, consequently, I dealt with it externally, by 'correcting' the FieldNotes timestamps to accommodate this "functionality".

 

After the recent update: The 'summary' Field Notes page still shows the correct date - but when clicking through to 'compose log', the log.aspx file is populated with the GMT date (most commonly a day ahead, for my offset and normal caching hours).

 

It seems that if the site is going to 'translate' (or correct, or offset) the GMT value in the uploaded field notes file - it should do so consistently?

Link to comment
Agreed (that it needs work). Ironically, by my estimation, it was fine before - presumably because it wasn't doing any 'localization' of timezone - and, consequently, I dealt with it externally, by 'correcting' the FieldNotes timestamps to accommodate this "functionality".

Actually, it was quite a mess before the current fix. It was documented in a thread started by avernar. What happened was that it loaded, and displayed in your local time zone. Then when logging, it took this local time, treating it as GMT, and converted it to local time again. Except one of the local time is always Pacific (Seattle) time, and the other is according to your time zone setting.

 

At least now it is consistent, and I see it as the first step towards fixing the date when logging. Maybe Groundspeak needs a Tempus Lingua in addition to a Locus Lingua :blink:

Link to comment

My understanding is that it does not gray out until the PQ actually runs. Continual clicking resets the run to the back of the queue. Click once and be patient.

I don't think that clicking it again moves it to the back of the queue. I think clicking it puts it in line, re-clicking it doesn't do anything but refresh the page.

Link to comment

Glad to see some issues I'm concerned about on the list (fieldnotes date and cache page formatting stuff). Waiting for the update to go live :)

Any news about when we could expect the date format problem to be fixed too?

 

I would not expect this to be fixed in a hurry. There are a lot of issues to solve before that can happen, despite its seemingly simple solution.

Link to comment

Did a change to the PQ GPX files sneak into this update? See http://forum.delorme.com/viewtopic.php?p=147875#p147875

 

PQ from 2/26:

	<?xml version="1.0" encoding="utf-8"?>
<gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0" creator="Groundspeak Pocket Query" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.Groundspeak.com/cache/1/0/1 http://www.Groundspeak.com/cache/1/0/1/cache.xsd" xmlns="http://www.topografix.com/GPX/1/0">

 

PQ from 2/24:

	<?xml version="1.0" encoding="utf-8"?>
<gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0" creator="Groundspeak Pocket Query" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.Groundspeak.com/cache/1/0 http://www.Groundspeak.com/cache/1/0/cache.xsd" xmlns="http://www.topografix.com/GPX/1/0">

 

Note the /1/0/1 in the newer one.

Edited by dakboy
Link to comment

how selfish. Some of us can only use the web browser provided by company IT. I know I'm not the only one in that position.

Supply your own. No installation needed, just drop it in any directory you have access to (like My Documents). Fly under the radar. http://portableapps.com/apps/internet/firefox_portable

My main employer has vast amounts of very sensitive personal information on its servers, so it monitors activity closely, but it also expressly permits us to play on the Web. I know, I know. And it provides IE6 and forbids staff to run their own software. I did think about Portable Firefox and I read the rules and decided not to go there. I'm glad GS took the trouble to restore service, because I was out of options. Apart from working, I mean.

Link to comment

Did a change to the PQ GPX files sneak into this update? See http://forum.delorme.com/viewtopic.php?p=147875#p147875Note the /1/0/1 in the newer one.

I'll echo Dakboy's post. It seems the "/1/0/1" change was made awhile back but because it crippled Delorme's Cache Register it was rolled back. Even though I don't see mention of it in the release notes for Wednesday's update, it looks liked it got rolled forward again. As a consequence, Cache Register is once again broken.

Link to comment
Even though I don't see mention of it in the release notes for Wednesday's update, it looks liked it got rolled forward again. As a consequence, Cache Register is once again broken.

There is an option at the bottom of Your Manage Account Preferences page to choose the version of GPX you get. Change it back to 1.0 and you should be golden again.

 

Edit to add that option was added in January.

11424: Attributes included in GPX files.

Added ability to set version preference in user profile; default is still the original (old) version

Edited by Lil Devil
Link to comment
Even though I don't see mention of it in the release notes for Wednesday's update, it looks liked it got rolled forward again. As a consequence, Cache Register is once again broken.

There is an option at the bottom of Your Manage Account Preferences page to choose the version of GPX you get. Change it back to 1.0 and you should be golden again.

 

Edit to add that option was added in January.

11424: Attributes included in GPX files.

Added ability to set version preference in user profile; default is still the original (old) version

It seems people are having the problems Dakboy pointed out even with the preference set to 1.0

 

Edited to add: And only PQs since Wednesday's site update are affected.

Edited by Pax42
Link to comment
It seems people are having the problems Dakboy pointed out even with the preference set to 1.0

 

Edited to add: And only PQs since Wednesday's site update are affected.

Mine was requested this afternoon. My preference is 1.0.

 

<?xml version="1.0" encoding="utf-8"?>
<gpx xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="1.0" creator="Groundspeak Pocket Query" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.Groundspeak.com/cache/1/0 http://www.Groundspeak.com/cache/1/0/cache.xsd" xmlns="http://www.topografix.com/GPX/1/0">

 

Looks fine. Maybe just fixed?

 

Edit to add : that was from My Finds. Haven't done a regular PQ.

Edited by Chrysalides
Link to comment
Mine was requested this afternoon. My preference is 1.0.

Looks fine. Maybe just fixed?

Edit to add : that was from My Finds. Haven't done a regular PQ.

I think some tinkering was going on and still may be. Some folks have been seeing the 1.0 and 1.0.1 come and go depending on when their PQs were run today. Might also explain why some have been complaining of not getting PQs at all or getting them really slow. Everything's currently working for me.

Link to comment
I think some tinkering was going on and still may be. Some folks have been seeing the 1.0 and 1.0.1 come and go depending on when their PQs were run today. Might also explain why some have been complaining of not getting PQs at all or getting them really slow. Everything's currently working for me.

I think the tinkering has affected peoples personal GPX version settings. For those who have it set to 1.0, and really want it to be 1.0, you should go over to your preferences and change it temporarily to 1.0.1 (save the change). You will probably have to do it twice before it really changes (an indication that it was secretly set to 1.0.1). Then as a final step, change it back to 1.0 again. After that, re-run affected PQs -- they should be fully 1.0 compliant, not a hybrid of both versions.

Link to comment
Your support for IE6 is commendable. You really shouldn't need to do fixes for it anymore, but good on you for sticking it out for those stuck behind archaic machines.

Perhaps there is some misunderstanding here? This is not about fixing IE6; it is about fixing changes to the site that broke backwards compatibility of the site. Geocaching is a game and many users use old outdated equipment for playing it.

 

I applaud Groundspeak's efforts to be as supportive as possible of all users.

Link to comment

Any news about when we could expect the date format problem to be fixed too?

 

I would not expect this to be fixed in a hurry. There are a lot of issues to solve before that can happen, despite its seemingly simple solution.

Too bad. The date format is the major annoyance on the site. B)

Link to comment

I think some tinkering was going on and still may be. Some folks have been seeing the 1.0 and 1.0.1 come and go depending on when their PQs were run today. Might also explain why some have been complaining of not getting PQs at all or getting them really slow. Everything's currently working for me.

I set the GPX format to 1.0.1 and tried on GSAK. Attributes showed up. Very happy now B) Thanks. :)

Link to comment

Ok... I've heard of this Space Cache referenced IN the Guidelines. What's its GC code, and Where on earth is it?? :)

International Space Station (GC1BE91)

 

Makes me wonder how they came up with the coordinates. B)

 

Hmm, what about guidelines:

 

The coordinates listed on the traditional cache page are the exact location of the cache.

 

and this

 

You as the owner of the cache must visit the site and obtain the coordinates with a GPS. GPS usage is an essential element of geocaching. Therefore, although it is possible to find a cache without a GPS, the option of using accurate GPS coordinates as an integral part of the cache hunt must be demonstrated for all physical cache submissions.

 

It looks the cache is not there:

http://www.heavens-above.com/?Lat=45.95515...ed&TZ=UCTm5

 

I think this is great fun, but not for GEOcaching. Maybe for another game - "spacecaching"...

I'm really disappointed with this. No geographical location - no geocaching.

Link to comment

Ok... I've heard of this Space Cache referenced IN the Guidelines. What's its GC code, and Where on earth is it?? :rolleyes:

International Space Station (GC1BE91)

 

Makes me wonder how they came up with the coordinates. :laughing:

 

Hmm, what about guidelines:

 

The coordinates listed on the traditional cache page are the exact location of the cache.

 

and this

 

You as the owner of the cache must visit the site and obtain the coordinates with a GPS. GPS usage is an essential element of geocaching. Therefore, although it is possible to find a cache without a GPS, the option of using accurate GPS coordinates as an integral part of the cache hunt must be demonstrated for all physical cache submissions.

 

It looks the cache is not there:

http://www.heavens-above.com/?Lat=45.95515...ed&TZ=UCTm5

 

I think this is great fun, but not for GEOcaching. Maybe for another game - "spacecaching"...

I'm really disappointed with this. No geographical location - no geocaching.

 

Well, it's placed with the permission of Groundspeak, reviewed and published by Jeremy Irish himself. So I guess Groundspeak doesn't have the same concerns. (Though I would meet you halfway and say this at least should be a mystery type cache and noty a traditional.)

Link to comment

I don't see any mention in the April 1, 2010 Release Notes of a fix for the field date issue reported with the Feb 24 update, related to ticket 14699 in that update. Is there any ticket number for this issue that we can track, and any ETA for it being addressed?

 

Just curious, as this one bites me for every cache that I find after 5pm PDT and I was really hoping to see it addressed in the April 1st update.

Link to comment

I don't see any mention in the April 1, 2010 Release Notes of a fix for the field date issue reported with the Feb 24 update, related to ticket 14699 in that update. Is there any ticket number for this issue that we can track, and any ETA for it being addressed?

 

Just curious, as this one bites me for every cache that I find after 5pm PDT and I was really hoping to see it addressed in the April 1st update.

 

We had intended to get this fixed for the current release but our regular sprint was put on hold to address the performance issues and we ran out of time. It's actually a rather tough nut to crack despite its seemingly simple nature. It's on our plate for the coming month.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...