Trackables handling in version 3.31.0

SV Hovland shared this question 5 years ago
In Progress

How is the new version supposed to work regarding geocaching trackables?

I still have to load the trackable on every found log on geocaches. I supposed Locus Map was going to remember which trackables I own and log them as visited on found logs without me having to load them and mark them as visited on each found log.

So half a year after we where promised better handling of trackables, nothing has really changed. Only a redesign of the log screen, but still have the same work for each found log.

Replies (9)



if you do a new "Found" log, load a trackables and mark them as "visited", then when you log the second cache, you have to again manually load your inventory? Should be pre-filled with all trackables from previous cache where you mark them as "Visited".

Jiří M. aka Menion



I do not even write anything...

I'll wait........................

I believe the dream will be a reality.


Wait wait ... wait? This should already work, or it doesn't? Just tested it and works correctly for me!

Check this video and tell me please, what should I do differently to achieve any problem with online logging of trackables:

Jiří M. aka Menion


Doing it the same way as in the video, but on my trip on saturday I had to reload the trackables 11 times while logging 13 caches. So it remembered them 2 times, but mostly forgot the last status.


Hmm currently status is taken from the last log. Maybe you made some log without marking trackables as "visited", which break the flow?


Yes. This can be a reason!

But editing is part of the work. Almost always precedes editing. It is normal.

@Menion sorry ;-)

You make it very complicated. And everywhere there are problems.

A simple solution would be better ;-)


Hehe, no way. As I have been waiting for this functionality, I am very aware of how it is doing and what is not working.

But maybe this helps: I also noticed that several found logs was also stored offline as Field notes even if it was successfully logged online. Could it be there is a connection here?


Just to make it clear - some found logs was both successfully submitted online and also stored as offline field notes.



To use one cache entry, please apply this requirement.

Well thank you :-)

It is unnecessary to complicate the process of memorization.

Default seting - visitet. (preserved choice of change).

shared this idea 2 years ago
Merged Objects
Geocaching online log TB/CG default settings on VISITED (navštívený)


Geocaching Trackables online log TB / CG default settings on visited.

What more can I say ... We do not want to do it over and over again ;-)

Thank you for your support.


Geocaching online log Trakovacích predmetov TB/CG východzie nastavenie na NAVŠTÍVENÝ.

Čo viac dodať... Nechceme to robiť stále dokola znova.

Ďakujem za Tvoju podporu.
19 I like this idea 0 
In my view, it is also an unnecessary action - to download a TB list. The list should be downloaded together after the event - log on online. Excluding the unnecessary step and forgetting the TB list. 99% This load list is always followed by an online log event.

Simple, clear, no complications.



This procedure is intuitive and exactly the same after the action to write a log on the GC page. (web)


Analysis of memorized:

- no action - default - unnecessary

- insert - unusable for the following log

- visit - yes, for the next log

The result:

There is only one possible one!

Q: why do I have to store the settings hard if there is only one?

Is not it easier to choose this setting as a default?


The one cache and TB are OK.

The last state of TB is sometimes remembered and sometimes not. Yesterday was just 2 and on the other I had to re-visit mark.

Bulk log via Field Note Manager waiting for... And not just me. all.

From yesterday's lecture, the result was the number one priority!

The next question on the lecture was:

Can I use bulk log via FNM?

The answer:

He can not. There is no possibility to send TB together. Not applicable. (21)

(3 answered yes - new cachers who do not yet know TB)

The Remember my Visit feature failed to demonstrate my lecture.


Hi guys,

firstly ... small change (not tested) ... after "Load" of inventory, items should be pre-marked as "Visited". Hope it will work correctly (not tested on my side).

Problem with restoring the previous state of items is still a mystery for me. If you notice anything that may help to de-mystify why second new log does not restore "visited items" from the previous log, it will be really welcome.

And @SV Hovland, all logs (caches, trackables) are firstly stored into the database (offline) and then uploaded to server.

Jiří M. aka Menion


Problem with restoring the previous state of items is still a mystery for me. If you notice anything that may help to de-mystify why second new log does not restore "visited items" from the previous log, it will be really welcome. 
@Menion Do you have an even more complicated task? :D Activity between first and second logos: Everything that Locus allows! Including Locus Restart and Restart Device.

The analysis (unnecessary complication) is unrealistic.

Great thanks for implementing the visit-default!

At least me and 30 friends have a reason to celebrate and open good champagne. It has been a long journey for 3 years.

In the following lecture, this simple change will be a great presentation ;-)

But the effort does not end with this "small" victory.


Funny discussion with you. Write me, if you will be in future near Prague, we have to give a beer :).


I've been planning Prague for about three years now. This will be another strong reason ;-)



It seems that the TB list and the visit setup works correctly.

I have a question:

Why (what is the reason) is not to implement this simplification?

unnecessary action - to download and TB list. The list should be downloaded together after the event - log on online. Excluding the unnecessary step and forgetting the TB list. 99% This load list is always followed by an online log event.

This implementation would also bring (secondary) benefit!

And that:

"verifying" Internet connection availability before editing the record! It happens that sometimes a person is out of the internet. I edit a log and want to send. Ups ... conection error. Editing can not be saved. I lose my job.

This is also the reason for "my" implementation.

Aaaach .... I have to thoroughly describe all the reasons and context ....


Why can't you accept that your simplification makes it a lot harder when you drop travel bugs or pick up new ones while logging offline. The way it works now, Locus Map is able to store what happens with TB's on a trip. And that is important if you don't have a uniform way of doing this. I pick up and drop TB's while offline and I am sure other do as well. With your simplification we have to write down what happens and that feels rather silly when Locus Map is perfectly able to store this when bugs are sorted out.

So what has this offline logging to do with online logging, you could ask. Well, I think it makes a good user experience if both online and offline logging is working in a similar way. If you have full flexibility while logging online, I think it is also a good thing to have exactly the same flexibility while logging offline.

The only thing missing now is getting the offline logging as we saw in the last beta version to be implemented and released.


@SV Hovland

I've already explained the situation to dozens of topics.OK

I think the two of us are exactly the same thing.

Simple, fast, with minimal effort, automate all the same repetitive actions, etc.

The result should be:

Send all offline field processed records, including TB.

Provide this for the shortest time and with the least number of clicks. Prerequisite to minimize errors. (any, system-based, even unexpected)

To accomplish this task, simple, understandable, without errors.

What do you disagree with?

What other overall solution do you suggest?

What are your plans and visions for the continued development of this feature?

Thank you for your response.


After your answer to the basic question (above)

we can discuss the details together.

assignments and assumptions:

- save offline

- Check the current status

- exclude sending a TB record without an existing cache record

- synchronize the time stamp of a record (TB / cache)

- solution procedure and TB change status (unpredictable)

- Exclude changes to other records

- the possibility of stopping the process (forcing the user, and accidentally for any reason)

- the possibility to proceed exactly from the process stop point

- Complete all previous tasks even after editing the records. (in a different order)

- send a record (TB)

- verify send record.

Additional contexts and subsequent implementation to other functions are more extensive.


I agree that the whole process should be fast, easy, error free and so on. But I don't like it when the solution get to minimalistic. I have used Maaloo geocaching for Windows Mobile and that app had only a single check box in the settings saying "Log all trackables in my posession as visited when offline logs are uploaded to the api". It worked most of the time, but not very well if I had dropped a TB while on a trip. I logged the TB as dropped online in the app and Maaloo didn't make a note of this for internal use. It didn't had support for any advanced logging of TB's so this was the only way of doing it. So while sending in my logs it failed already on sending cache A, B, C and so on because that particular TB wasn't in my posession anymore. I dropped it in cache D, but Maaloo failed to log it as visited on cache A.

That is the main reason I want Locus Map to maintain the full chronological log of what happens with a TB. If I can log a TB as visited for cache A, B, and C and then log it offline as dropped in cache D, I am sure this will work fine if this is sent to the api in chronological order.


But there has to be some good error handling in Locus Map. One pitfall is when someone grab a TB before I am able to send in my offline logs. I will then not be able to log TB 1 as visited or dropped because it isn't in my posession anymore. But Locus Map should of course still log TB 2 and TB 3 as visited.


Graduation and grading of my suggestions. After completing and verifying flawless implementation of small segments. Consequently, segments (if verified and functional) are merged into collaborative functions.

Order is the highest number of people according to priority of use of the most frequent work.

The first task - default - visited

is being implemented today and we will test it.

I'm just making suggestions.

implementation is dependent on Locus Team (Menion).

For example,

it is important to skip (omit - automate - independently of the user) download button list of TB. In order for the next 3 operations (segment) to be followed, the process was not stopped due to the fact that the first step was not an Internet connection. Or it was forgotten to push the user.


The implementation of drop, grab, and also activity is very rarely used (compare - visit). It brings the most trouble. (many variations) therefore has little priority for me. This task will be easily fulfilled even in the system without it. Involve the user in the process (split up the process). Its solution is larger than the result achieved. (saving time, saving battery life, user comfort).

You can analyze this feature, all possible variations that can occur. Suggest a solution.

We will discuss it.


For a better understanding of my suggestions.

My goal (all the way to that) is to come home evening (to the hotel), all day in nature, (3 or 100 or xy cache offline note, even TB) press one button in Locus. Go to the shower. After the shower, look at the display and read the "The process was successful" and sleep. Enjoy the next day full of experiences.


While doing some geocaching today, I saw that after logging a cache offline, I had to reload the trackables on the next online found log. I often log caches online I don't want to write as much about and caches I can write more about later, I log offline. After each offline log, the trackables has to be reloaded.


If I correctly understand this way, do you ask for this?

In my view, it is also an unnecessary action - to download and TB list. The list should be downloaded together after the event - log on online. Excluding the unnecessary step and forgetting the TB list. 99% This load list is always followed by an online log event.

Leave a Comment
Attach a file