-
Notifications
You must be signed in to change notification settings - Fork 9
Quest Options
Quest options change program behavior only for the specific quest they are associated with.
Filtering provides ways to control which posts are processed in the process of tallying a vote. There are several different types of filters you can use, and they are presented on the first tab of the Quest Options dialog.
Below, the different types of filters are described. The specific syntax for entering filters is on the Filters page.
XenForo forums have the option to use threadmarks for bookmarking posts within their threads. NetTally uses these threadmarks to find the most recent update post, and start tallying after that point, if the option in the main window is checked. However not all threadmarks are actual updates, and these secondary threadmarks can cause the program to find the wrong post to start tallying from.
By default, the program ignores threadmarks with the word "omake" in the title. An omake would be a user-created side-story, and wouldn't be the starting point for a vote tally. Some authors also add additional non-story posts, such as for clarifying rules, providing revealed information, and various other miscellany, or perhaps just label their omakes differently (eg: "Interlude").
If you provide custom threadmark filters, any threadmarks containing the filter words or patterns will be ignored when searching for the most recent threadmark. That way the program can find the proper starting point in the threadmark list.
Custom task filters may be used to limit what portions of each vote are included in the tally. For example, partitioning by line and specifying a custom task filter means that only vote lines that contain that task will be tallied. That also means that a later vote by that same user, but which does not include the specified task, will be ignored, and not cause the later post to replace the original vote.
This can be useful for handling voting for options where the votes themselves can cross multiple 'normal' vote periods. Thus a user could have any number of normal votes, and only need to include a special [task] vote somewhere in the broader range that's being considered, without worrying about it being lost by any later vote they make.
The default handling of task filters will cause only vote lines that contain the specified task to be included in the vote tally.
Custom task filters are not saved across program runs, as their use tends to be fairly narrowly specialized.
At times it may be useful to include or exclude specific users from the tally. Perhaps the quest is a closed run, and only certain people should be allowed to vote, or perhaps someone enters a vote that interferes with the rest of the tally, or is revealed to be a sock puppet that you want to ignore. There may also be times when you want to turn off the filter that prevents any posts by the thread author from being counted.
The default handling of username filters will cause any posts made by the specified users to be skipped during the tally.
There are times when specific posts are problematic, rather than the user that made the post. You may use the custom post filters to cause NetTally to skip the specified posts entirely. You can enter the post by post number (the number shown in the thread), or the post ID (the number typically used to create a permalink to that post). The post number is easy to see on screen, while the post ID is often something you can copy from the tally output, if you can identify which part of the tally you want to block.
The second tab of the Quest Options dialog, titled 'Options', contains a variety of options for how to handle formatting issues in your quest.
You may specify the number of posts that are listed on each page of a forum thread. The program has default values that it uses, but some forums may use a different default. Sufficient Velocity and SpaceBattles both use a default of 25 posts per page, and Quesionable Questing uses 30 posts per page. All other XenForo-based forums default to 25, and all vBulletin-based forums default to 20.
The program allows you to set a value for each quest for a number of posts per page between 5 and 50, in increments of 5. Adjust the value as needed. If you set it to 0, the program will re-generate the default value for the given forum.
By default, the program ignores whitespace and punctuation differences in a number of areas of the program. For example, [x] Yes. and [x]Yes would be treated as the same vote.
However, sometimes the difference in punctuation matters. For example, [x] Smile politely and [x] Smile "politely" imply two different things, and should not be merged together.
If you need to ensure that such punctuation differences are treated separately, turn on this flag.
By default, the program ignores the case of the vote text. [x] YES and [x] yes are considered the same. There may be times, however, when you need to be able to distinguish between votes of different casing, for similar reasons to the whitespace and punctuation option, above. For example, [X] TSUNdere vs [X] tsunDERE.
In order to compare vote lines in a case-sensitive manner, enable this option.
When someone creates a plan —
[X] Plan: All the way!
-[X] Going.....
Other voters can vote for it using either
[X] Plan: All the way!
or
[X] All the way!
Both of them will be treated as a reference to the plan in question. Sometimes this is not desirable, and you only want people who are specifically voting for the 'plan' to count as doing so.
If you enable this option, then the second form of referring to a plan to vote for will be forbidden, and it will be treated as just a normal vote lines.
One of the methods of defining plans is to label the very first line of the vote with a plan name. For example:
[x] Plan squee
[x] Squeeeee
This form of naming plans can occasionally cause problems, because there's no explicit content for the plan (additional lines indented underneath the main plan naming line)
Turning this option on will mean that such plans will not be created, and the label line will be treated as just another line in the vote.
Proxy votes allow a voter to reference another user by name, and import that user's vote into their own. Essentially, they vote for whatever the other user voted for.
In some cases this can cause problems, most notably when there's another user who is voting whose name matches one of the things being voted for. For example, [x] Valor, when there's another user in the thread named 'Valor'.
Disabling user proxy votes means that anyone who voted [x] Valor does not have Valor's vote imported into their own. However it also means that all the other proxy votes in the thread are not imported, either. Manual merges will be necessary in the Manage Votes window to clean things up.
Proxy votes by default refer to the most current version of the referred-to user proxy (plan proxies only ever have one version, so this doesn't apply to them). This allows voters to vote for another user, and if that user later changes their vote, the proxy vote will still refer to the latest version.
Setting this option disables that process, and makes it so that proxy vote can only ever refer to the most recent vote made by the proxy at the time of the voter's post.
For example, imagine a series of posts:
User 1
[x] Idea 1
User 2
[x] User 1
User 1
[x] Idea 2
Under normal circumstances, User 2 will be voting for Idea 2, since that's the last version of User 1's vote that was tallied. However with this option set, User 2 will be voting for Idea 1.
This is effectively making all proxy votes into pinned proxies.
When tallying a thread, the program normally looks inside any spoiler blocks as part of collecting each post's text, since sometimes votes are placed inside spoilers in order to save space. However there are also times when information inside spoilers will interfere with a tally.
Turning this flag on will cause the program to ignore all spoilers when constructing the text of each post.
Sometimes vote lines are extremely long, and are difficult to read or distinguish. Enabling this option allows the program to trim long vote lines down to something more manageable. There are two types of reductions:
- If a vote line has two 'parts', with those parts separated by a colon, hyphen, or dash. If such a separator is detected within the first 30% of the overall vote line, the line will be trimmed to just the first part.
- If a vote line has multiple sentences, and the first sentence uses up less than half of the entire vote line, then only the first sentence will be included as a tally value.
For example:
[x] A treaty on ethics: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Will be reduced to just:
[x] A treaty on ethics
And:
[x] Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Will be reduced to just:
[x] Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
There are various rules to ensure an appropriate cutoff point is selected, such as ignoring any such separators inside parentheses. It's somewhat experimental, but it should generally help keep such votes in a more readable state in the final tally.
This tracks whether the forum that uses threadmarks provides an RSS feed of those threadmarks. This is likely done to reduce the load on the server from loading the full threadmarks page.
This is in an indeterminate state by default. If the site is known to provide RSS threadmarks, this can be checked (and it will automatically do so if it finds an RSS feed). If the site is known to not provide RSS threadmarks (or if the RSS feed is broken), it can be turned off to force the program to load the full threadmarks page instead.