New cache types (requested by OCNA)

[andrixnet]

The is a list of new cache types requested by OCNA in advance of their migration to OCPL-current:

• BIT Caches (special QR code label, similar to Munzee); ID=12
• MP3 Caches; to drop
• USB Dead Drop Caches (as cache type, instead of just attribute); ID=11 to drop
• Guestbook Caches; ID=13; must change at import from id=10
• Letterbox Caches; (as cache type, instead of just attribute); ID=13 to drop
• Benchmark Caches; ID=14
• Challenge; ID=15
  [updated IDs according to wiki, 2019-07-04]

Caches should be added with ID's according to column F as described here:
https://wiki.opencaching.eu/index.php/Cache_types

New cache types should go into forbidenCacheTypes by default for existing nodes.

Code changes needed (at least):

• cache type definitions (in code)
• other necessary code changes
• cache type definitions in database (still required)
• translations
• default graphical resources
• default config

[andrixnet]

I also suggest using this opportunity to redefine current porentially overlapping IDs in the code and database and have the code define the complete set of cache types, even if only a subset is available by default.

[deg-pl]

I think it is not a very good idea. It is source of GIGANTIC problems with incompatibility with 3'rd party software (c:geo and MANY others).

I think better way is migrate these cache types to right cache type and use attributes. For example - USB Dead Drop cache can be traditional cache, multi-cache (http://opencaching.pl/viewcache.php?cacheid=53498), moving cache (http://opencaching.pl/viewcache.php?cacheid=17058), mystery cache (http://opencaching.pl/viewcache.php?cacheid=18287), other type cache (http://opencaching.pl/viewcache.php?cacheid=23419). Dead Drop is type of logbook (attribute!) not type of cache.
Letterbox means that is a stamp in the cache. It can be every cache type!

If I go for caches - I usualy don't search multicaches because them requre much more time. I can't determine easily that Dead Drop or Letterbox is multicache or traditional cache. In PL we have attribute "letterbox" or "dead drop" - so cache type is adequate to phisical type. Thats a big difference for me.

[Mr-Yuck]

@deg-pl Most of these cache types were added by our founder in 2010 (he is no longer involved with the site). I think our userbase would be very upset if any of them went away! Generally not too much of a problem with c:geo, they all show up on the maps or in a list, they generally just have a mystery cache icon, rather than their own unique icon.

[andrixnet]

If userbase is c:geo, contributions to c:geo can help mitigate.

[andrixnet]

There are also some cache types unique to OCNA, that have no corresponding type or attribute in neither OCPL nor OCDE. See Bitcache, Benchmark. And by their nature, I don't think they can be equally equivalated to traditional / puzzle / multi and an attribute.
I presume, even if MP3 cache might be contended and converted to attribute, these others should be added.

[wrygiel]

I think better way is migrate these cache types to right cache type and use attributes.

I think the same. I also think the same about some of the other cache types we use in Poland (e.g. webcam).

In my mind, cache types should to be very broad and general. It's a big mistake to introduce new, specific ones, because - once the users realize what happened - they will simply require of us to introduce even more. This won't end happily.

[wrygiel]

If OCUS's <1k users managed to think of 6 special types of caches, then imagine what our 36k users will do.

[Mr-Yuck]

@wrygiel I cannot argue with that. Although I would not necessarily say our users came up with the cache types, rather our founder, RvRoadTrip, who ultimately ran the site for less than 2 years. We were founded in 2010, and the last type was added in 2011, although we did come up with a new one we want to add now (Benchmarks). I really think our userbase would be highly pissed off if they were all reverted to Mystery type caches identified only by attributes after all these years. @andrixnet had told me in another conversation they could be "forbidden caches" on any other site using OCPL code?

[wrygiel]

I really think our userbase would be highly pissed off if they were all reverted to Mystery type caches identified only by attributes after all these years

True. Every change brings some haters along with it.

You (OCUS and OCPL developers) could make this work in such a way, that no users see any changes (OCPL would have cache types of its own, and you would have yours). But this, on the other hand, would be much more work for OCPL developers (and possibly external app developers, such as c:geo), so - if you choose this path - the users will not object, but the developers probably will. In the end run, users might still suffer, because of broken app implementations (because many developers have hard-coded cache types in their apps).

There is no good choice here. Either way, someone will be mad with the decision.

[Mr-Yuck]

@wrygiel I agree no real good choice here. I will say that all our unique cache types have always shown up on the map or list of caches as "?" (mystery or unknown) on c:geo, and we're all used to that, and fine with it. I don't even remember when c:geo came online with OCNA, but I'll bet it was around 2013.

[kojoty]

I agree that it seems to be much more easy to add a attributes instead of new cache types.
@Mr-Yuck how many active caches of every requested type you have right now?

[andrixnet]

Graphical resources created by US team, to be integrated soon.

[andrixnet]

Graphical resources here: andrixnet@9c5f0c5

[andrixnet]

First part of code implementation, database preparation and some translation work: andrixnet@95475f6

Will be amended according to #2076 if necessary.

[andrixnet]

I worked on introducing the cache types and making all the necessary side preparations.
However I am uncertain about several things, which I attempt to list here, please help.

1. GeoPath FINAL / Podcache type is being removed, this is OK.
2. New types : BIT cache, guestbook, benchmark, challenge.

• specify which of these have physical container with specified size
  (waiting answer from US team). I assume at this time that guestbook has container.
• specify which of these types may be part of a geopath.
  (waiting answer from US team). I assume the first three yes, challenge no.
• specify geopath points given by each type
  (waiting answer from US team). I assume BIT cache and benchmark = 1 (same as virtual), guestbook = 2 (same as traditional)
• none of these have moving property; none of these have attend property

3. I am not sure I am handling correctly the search page(s) and their bitfields.

4. ajaxGetPowerTrailCaches.php line 132
   I do not understand the purpose of this line.

5. editlog.php is not well documented. From the numbers I assume at line 163 it allows different log types for event caches. Is this correct?

6. in search.php, line 381, 1017 I increaset the bitfield to fit the new number of cache types (13 total now). Is this correct?

7. in search.php how much are lines 1500 to 1505 still required? Especially mystery -> quiz and .gif replaces (all files are .png)

8. what is the purpose of log_cache_multi.php and the incomplete list of types at line 36-47?

9. why not all types are listed in src/Views/newcache_beginner.tpl.php ?

See andrixnet@7007934 (and previous commits on same branch.
This one is finalizing according to latest version of https://wiki.opencaching.eu/index.php?title=Cache_types (revised after #2076 )

[andrixnet]

Submitted OKAPI update in sync with these changes.
opencaching/okapi#594

[andrixnet]

Work in my fork, cache_type branch can be seen live on a copy of OCRO: http://ocro.dev.andrix.eu/

[TermiteHunter]

BIT cache- No container, no log, cache is a 2"x 3" label, sticker, card etc. Geopath Yes
guestbook- No container, cache is typical book which acts as log, Geopath Yes
benchmark- No container, no log, cache is a metal or similar disk or marker in permanent location, Geopath Yes
challenge- No container, no log, no location, OCTeam placed only, Geopath No

As for points... I don't know. Your post suggested 1 for each except guestbook (2) which I assume is because there is an actual log involved. My thought would be 1 for Bit & Guestbook with 2 for benchmark. Reasoning is that the benchmark would likely more often present more of a challenge to find like a traditional whereas the Guest and Bit are usually easy to locate.
Or
Simply 1 for all 3 of them.

[andrixnet]

Thank you @TermiteHunter for your answer.
Implemented with commit andrixnet@c166b92

[andrixnet]

At this time I am asking for help from @kojoty @deg-pl .
I have done all that I know to implement up to this point.
The following I do not know how to handle, please help:

• exclude forbidden cache types from search page, myroutes search, geopath search
• handle search page bitfields and ensure search consistency
• ajaxGetPowerTrailCaches.php line 132
  I do not understand the purpose of this line.
• editlog.php is not well documented. From the numbers I assume at line 163 it allows different log types for event caches. Is this correct?
• in search.php, line 381, 1017 I increaset the bitfield to fit the new number of cache types (13 total now). Is this correct?
• in search.php how much are lines 1500 to 1505 still required? Especially mystery -> quiz and .gif replaces (all files are .png)
• what is the purpose of log_cache_multi.php and the incomplete list of types at line 36-47?
• why not all types are listed in src/Views/newcache_beginner.tpl.php ?
• Powertrail defines some of it's own strings to denote cache types (but only a subset). is this correct/intended?
• does ocxml11.php need work? (I can't figure it out)

[andrixnet]

Once deployment is ready, must coordinate with corresponding change in OKAPI and the Geokrety team