HxRoamer

Thank you so much - that is exactly what I was looking for.

I was thinking more about the functions available and calling syntax but not really applicable to this thread.

Many thanks for your explanation. Perhaps one day I will get to understand a bit about lua. I assume there must be a Wherigo library somewhere but I can't find it.

Hi Charlenni: Many thanks for your prompt assistance. I had managed to get the lua file into an editor but frankly it didn't mean too much to me particularly as all the strings need decoding. I have created a tiny cartridge in Urwigo with a single zone and a single On Entry event. I used the Urwigo builder to display three dialogs. The first displayed CurrentZone.Name, the second CurrentZone.Description and finally CurrentZone.Inventory Count. The event code is: function Zone1:OnEnter() _bnqDm = _DUs("\040\059\003\117\071") _Urwigo.OldDialog{ { Text = _G[_bnqDm].Name }, { Text = _G[_bnqDm].Description }, { Text = tostring(#_bnqDm.Inventory) } } end This will produce the runtime error. However if I remove the final InventoryCount dialog then the other two work perfectly. I tried removing the 'tostring' function and '#' sign but I couldn't re-load the lua into Urwigo to test it out. Kind regards Robert

Another Newbie with a problem! Does anyone know why using 'CurrentZone.InventoryCount' causes a Lua runtime error? It reports "Attempt to get length of field 'inventory' (a nil value)". As I move into a zone I simply want to display the zone's name and the number of items in that zone's inventory. There is no problem if I display just the name. There are no errors detected in the Urwigo builder. Any help would be appreciated Regards Robert

All well this morning using the GSAK api.

Same problem. Hope it is a one-off issue that can be quickly fixed. I am more concerned by the appalling response when logging at weekends. It now takes as long to log the finds as it take to go out and find them.

In response to luvvinbird. If I had to rely on my 650 we wouldn't have found anything like as many caches as we have. Why? When compared to my wife's Garmin 62s it is inaccurate and sluggish. I would say that on 95% of our finds the 62s goes straight to the cache whilst the 650 is anything from 30 to 60 feet away. If you wait long enough the error will reduce but by that time my wife has signed the log and is on her way to the next. It is rare that I have a day's caching without having to remove the batteries because the unit has locked up. Screen sensitivity can also be a problem. I have programmed the user button to lock the screen as otherwise the very fact that it is banging against your body will cause it to do all sorts of odd things. Even with the screen locked it can suddenly re-configure itself, for example change or turn off a dashboard which may have happened to looneybin. If it is cold and you are wearing gloves you need to increase the sensitivity. However if it then starts to rain the screen is useless. Give Garmin their due, they have exchanged the unit twice free of charge but all three units have exhibited exactly the same faults. The 650 does of course have its good points. It is easy to scroll the map and enter data, for example next stage coordinates, and flip between applications, but if I had to have just one device for geocaching it would be the 62s.

Problem solved!! Each of the pages that were causing problems contained a link, amongst others, within the text to GC459XV. However I made an error and pasted a link to GC459XV's edit page "http://www.geocaching.com/hide/report.aspx?guid=" rather than the cache page itself "http://www.geocaching.com/seek/cache_details.aspx?guid=". I can understand my error causing me problems when I test the links (which is how I have now discovered it) but I do not understand why the error affected the "Edit Listing" button. Many thanks palmetto for your reply. At least my problem is resolved, but I am curious as to how an error in user code could cause this to happen.

I am currently inputting details for a new series of caches. When I need to edit some of the data I have been using the "Edit Listing" button alongside the "Submit For Review" button at the top of the page. All went well until I noticed that pressing the button took me to the edit screen for a different cache! For example view GC45F87, press "Edit Listing" and it loads GC459XV. I have now found at least two more caches that behave in the same way, always loading the same GC459XV. I had successfully edited all these caches a few times before the problem cropped up. Thankfully the "Edit Listing" link in the Navigation box on the right works correctly. Running Windows 7 Pro and get same behaviour using IE9 and Chrome.

24 hours later and response is even worse than last night - continually getting "Cache not Published". Really hope that the problems can be resolved before the weekend. Totally unsatisfactory at the moment.

Here I am on a Wednesday evening trying to log my finds. Taking at least 45 seconds to get a response and then more often than not is says "Casche is Unpublished" - can't be, I have found it. I can accespt that the traffic is very high at a weekend (though the system should be able to cope with it) but I find it hard to understand why it is so slow mid-week. I think there was an update last night. Could this have made things worse? This terrible response is taking much of the fun out of geocaching. Please Groundspeak get it fixed once and for all.

Here I am again one month after my last post and once again I am having to wait minutes for pages to download. This is not acceptable. Two things spring to mind. Firstly, when the system is busy premium members should get priority over non-premium members. Secondly, geocaching is growing at an almost exponential rate. You only have to look at the number of caches being published (and thanks to our volunteer reviewers for all their hard work). I assume that the number of premium members is growing at a similar rate - hence Groundspeaks revenue is growing at a similar rate. How about investing in additional computer capacity? It is getting to the point that we dread getting home after an enjoyable day's caching for fear as to how long it is going to take to log our finds. Come on Groundspeak - please do something about it.

Sorry for not responding last night nkroy. It was getting late in the UK so after posting this message I turned off my computer and went to bed. All back to normal this morning. I hope that GS will urgently address this problem, particularly at weekends.

I have bitten my tongue and kept quiet on this issue for a long time, but tonight I just have to say that the system response when logging finds at weekends in appalling. We have had a wonderful day out during which we found 65 caches. Nice to get home, pour a gin and tonic, and then start logging. I have been at the computer 2½ hours and have managed to log just 12 finds. Most of the time is just waiting for the system to respond. I have also had to re-enter four of the logs again as I got an "Internet Explorer cannot display the web page" message after pressing the 'Submit' key and the log was lost. At this rate it is going to take me 12 hours to log my finds - longer than it took us to actually find them! Come on Groundspeak. I pay my premium membership and that should allow me to log my caches on the day I find them.

This is getting beyond a joke. We found 28 caches today and over the last three hours we have been able to log just five. We have typed our logs, pressed Submit and then the system has crashed and everything is lost. We used to enjoy a day's caching. When we got home we would have a couple of G&Ts and do our logging - no hassle. Now we dread the thought of logging. You have taken much of the fun out of geocaching. Come on GS - get rid of resource hungry challenges and avatars. Concentrate on the important issues. Invest in the infrastructure. If you don't others might and that would be a shame.

If they don't do something about it soon perhaps they will lose their monopoly!

No it's not just you! Have been trying to log my day's finds (19:30 UK time) for over an hour and am getting nowhere. GS should plough resources into improving the system response and not on implementing crazy 'challenges' (eg; 'kiss a frog') or putting daft little pictures alongside logs. Come on GS - get your act together.

I am getting utterly fed up with the geocaching web site. The response was bad before the last update but it is now totally unacceptable. It is now 19:00hrs UK time and I am trying to log my finds. It can take several minutes for a cache page to load and then several more before the 'Log Find' screen appears. I then type my log, press Submit and what happens "Internet Explorer cannot display web page" and my log is lost. This has happened several times. Come on Grounspeak! We pay our dues. We do not want to see pretty pictures. We just want to be able to log our finds.

Don't like the new log layout at all - a retrograde step in my opinion. I don't want to see a picture - it makes an already sluggish site even slower and it takes up real estate on my screen - keep them for Facebook! As for the dates ... madness! What was wrong with the previous logs?

I have recently updated my phone to an HTC TyTN II and am busy discovering all the new things I can do with it. One of the most exciting is the ability to download from the GC WAP site which I find really useful. My wish list is very similar to others already posted: 1. Fix the bug that causes logs containing '[]' to be encrypted 2. Add container size, difficulty and terrain 3. Provide a URL link. I use Memory Map and have cache details overlaid. It would be really nice to be able to click on a cache in Mamory Map and have the details of that cache displayed without having to tap in the coords 4. Option to filter out caches already found 5. As the HTC has built-in GPS it would be nice to have a button on the Find Caches page to insert the current location from the GPS. A great interface - I look forward to it getting even better.