<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel>
        <title>Filtering by GC-Code from Tag</title>
        <description> Previous conversation is here

After Mar 2017, no documentation about qualifying the challenge is required from the finder. This means that the cache owner needs accurate tool to verify the claim, after the finder has logged the challenge as found. It is logically impossible that the challenge cache itself could be used prematurely before to qualify.

In many cases this is absolutely irrelevant but the result may be wrong. For example if the challenge needs one (1) found and the checker accepts the challenge itself, then it never fails when the owner confirms the finder&amp;#039;s qualification with the checker - as it shoud.

Most effective solution could be a filter option for PGC_GetFinds which use the GC-Code from the Tag. This way the Tag is fully clonable and for a bonus there is no need to sequentially search the output to exlude this single cache.</description>
        <link>/forum/read.php?5,12054,12054#msg-12054</link>
        <lastBuildDate>Sun, 06 Sep 2026 23:56:52 +0000</lastBuildDate>
        <generator>Phorum 5.2.23</generator>
        <item>
            <guid>/forum/read.php?5,12054,13032#msg-13032</guid>
            <title>Re: Filtering by GC-Code from Tag</title>
            <link>/forum/read.php?5,12054,13032#msg-13032</link>
            <description><![CDATA[ This way it is possible to keep tags clonable which is the most important advance.]]></description>
            <dc:creator>arisoft</dc:creator>
            <category>Method requests</category>
            <pubDate>Wed, 27 Sep 2017 13:12:32 +0000</pubDate>
        </item>
        <item>
            <guid>/forum/read.php?5,12054,13031#msg-13031</guid>
            <title>Re: Filtering by GC-Code from Tag</title>
            <link>/forum/read.php?5,12054,13031#msg-13031</link>
            <description><![CDATA[ I am not sure it will actually help much in reality, and also most checker scripts would have to be adjusted.<br />
<br />
But regardless, it has been the plan for quite long and it&#039;s not a big change. I have implemented it in our development environment today. When it goes live, the skeleton code when creating a new script will include this line:<br />
<pre class="bbcode">
local gccode = args[1].gccode -- gccode belonging to the tag
</pre>]]></description>
            <dc:creator>magma1447</dc:creator>
            <category>Method requests</category>
            <pubDate>Wed, 27 Sep 2017 13:01:13 +0000</pubDate>
        </item>
        <item>
            <guid>/forum/read.php?5,12054,12054#msg-12054</guid>
            <title>Filtering by GC-Code from Tag</title>
            <link>/forum/read.php?5,12054,12054#msg-12054</link>
            <description><![CDATA[ Previous conversation is <a href="https://project-gc.com/forum/read?4,11980,11980#msg-11980"  rel="nofollow">here</a><br />
<br />
After Mar 2017, no documentation about qualifying the challenge is required from the finder. This means that the cache owner needs accurate tool to verify the claim, after the finder has logged the challenge as found. It is logically impossible that the challenge cache itself could be used prematurely before to qualify.<br />
<br />
In many cases this is absolutely irrelevant but the result may be wrong. For example if the challenge needs one (1) found and the checker accepts the challenge itself, then it never fails when the owner confirms the finder&#039;s qualification with the checker - as it shoud.<br />
<br />
Most effective solution could be a filter option for <i>PGC_GetFinds</i> which use the <i>GC-Code</i> from the <i>Tag</i>. This way the <i>Tag</i> is fully clonable and for a bonus there is no need to sequentially search the output to exlude this single cache.]]></description>
            <dc:creator>arisoft</dc:creator>
            <category>Method requests</category>
            <pubDate>Sun, 27 Aug 2017 20:19:31 +0000</pubDate>
        </item>
    </channel>
</rss>
