Trackables handling in version 3.31.0

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.

@Menion

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
Condor
Geocaching online log TB/CG default settings on VISITED (navštívený)

(EN)

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.

(SK/CZ)

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 

Simple, clear, no complications.

+edit:

Apropos...

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?

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. 

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 ;-)

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.

Etc......

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.

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.