Advanced search, publishers and tags listsings added to Module Library

The Module Library now has:

These are functional, but not finished. Please report any problems you encounter.

1 Like

I notice a number of duplicate publishers listed, specifically misspelled duplicates.

For example, there’s a Victory Point Games and a Victory Points Games, the latter containing the misspelling.

Immediately ahead and after those, Victory Games is listed twice, and I don’t know why, since I don’t see a misspelling in either. Maybe one of them has an underline connecting the two words.

I would guess that this is an issue that presumably should be fixed by the module owners, not by site admins.

The amount of work you’ve put into this Vassal project, and continue to put in, seems mind boggling, Uckelman (and whoever else).

The publisher is just a text field stored for each project. At some point I aim to extract the publishers to their own table in the database, clean up the names, and offer autocomplete for publishers in the editor to encourage users to select publishers by their canonical names—but I won’t get to that for a while.

1 Like

Yes, the second of them has an underscore in between the words, which can be seen looking at your browser’s on-hover preview of the URL (often in the lower left of the window).

If anyone wanted to help with the publisher names, listing duplicates and what they should be combined into would be useful.

If it only involves removing underlines, spelling corrections and that sort of thing, I suppose I could do that. OTOH, if it gets complicated, you might find that it’s more work explaining things to me than just doing it yourself. :confused:

I would have liked to help previously with the reorganization of the library, but it seemed way over my pay grade, complexity wise.

So yeah, I suppose I could try helping with the duplicate publisher thing. It doesn’t seem like there’s that much to do (famous last words?).

We buzzed through the publishers this afternoon, pretty minimal work actually. But when it comes time to “sanitize” the rest of the tags (era, scale, series, topic) there will be more to do, even in the most minimal treatment that doesn’t involve many judgment calls.

Before we do anything with the tags, we need to figure out what we should do with them.

The current tag format (e.g., era:WWII, scale:Tactical) is the way it is only because it was convenient for preserving the data from the old module library until such time as we had a plan for it.

We need answers to questions such as:

  • Are tags something we want at all?
  • How should users interact with tags?
  • How should project owners set them?

I raised this during the library conversion process to scant response, which is why I’ve done nothing with tags thus far.

The four games in Victory Points Games are mine. I have now removed the “s”.

2 Likes

Would tags include the ‘Owner’ category to search modules by owner, or is that going to be handled with its own search process?

1 Like

You can already search by owner using the owner field in the advanced search form.

1 Like

Awesome. Found some additional project splits I was still an owner as and removed myself.

1 Like

I don’t understand the difference between a text search and a “Tag”. Or does the advanced “Full-text search” only search the titles?

I thought “Tags” were just key words that could be added to a description, in case they weren’t already in there, to result in a “hit” if those words were searched for?

Great! A few comments

  • Apart from a Full text search - which presumably searches both the Game title and README fields of the database entries - I think there should also be a simple Game title search - i.e., one that only searches the game titles and not the README.
  • The Year search field should allow for a range of years - e.g., 1965 through 1970.
  • The search should report how many matches was found.
  • Search by BoardGameGeek ID - would require a storage of that ID in the database, but that could really enable a lot of cross-communication and referencing between BGG and VASSAL.
  • Seems like searching on multiple tags does not work, e.g.,
    • era:wwii
    • scale:operational
      Should give loads of hits, but finds nothing.
  • How, exactly, are the Inclusive and Exact options to be understood?

Yes - tags are really useful to provide a more searchable information about the modules etc. I think tags should be much more aggressively used.

  • Through searches
  • Make tags on modules etc. There could be some sort of “voting” on tags before they are accepted as proper tags on a module or the like, Or a project owner would have to approve of user tags.

Free-form on the project pages - preferably on the project itself, on individual packages, and perhaps even on individual releases. Tags should be auto-completed on existing tags, but also allow for new tags.

As for the format: I think the current key:value format is OK, though, if not enforced, is somewhat sub-optimal. I think a better way would be to have key and value separated.

For example, a key could be complexity and the values could be from low to high, and similar for solitaire-suitability.

I’ve made an issue at GLS: Unique and spell-checked publisher names #5. There you will find two JSON files:

  • mapping.json maps from current publisher name to a spell-checked, unique publisher name.
  • reverse.json is the reverse mapping. The spell-checked, unique publisher name maps to one or more current publisher names.

Both are AI-generated, so a bit of hand-editing is probably needed.

Yours,
Christian

Tags are meant to “tag” a module or game with some attribute, e.g.,

  • era:medival
  • theatre:europe
  • scale:operational
  • automation:high

In that sense you can search for all operational level modules by searching for the tag scale:operational.

The Full text search presumably search both the game title and the README section.

No, tags are meant to be more powerful than simply adding text to the README. It is a way to find similar games or modules more easily. In terms of data-base execution, tags can be quite efficient because you only need to search simple text fields to quickly get a list of possible targets, rather than doing full text search for a few words.

Yours,
Christian

The tags as they are now came from the Era, Topic, Scale, and Series items in the game info boxes on module pages in the old wiki. The Era, Topic, Scale, and Series values were “Categories” in the old wiki, which meant that there was an index page for each one which listed every member of the Cagetory. E.g., the Operational scale category.

Tags presently aren’t included in full-text searches; full-text searches are over title, publisher, year, description, and the readme text.

Make an issue for it.

Year is vexing. It’s not an integer because there were some nonnumeric values we brought over from the old library, which I didn’t want to deal with at the time.

Make an issue for it.

There’s already a note in app/src/SearchPage.svelte about this:

<!-- TODO: show number of results -->

The results count display needs to be split out of app/src/ProjectsPage.svelte and app/src/SearchBar.svelte. I haven’t gotten that far yet.

Make an issue for it (in the GLS).

The same as with the BGG Advanced Search, which has an explanation that I grasped only because I had already encountered what I describe below and went there specifically looking to see how BGG handled searches by number of player.

The natural interpretation of “a minimum of three players” when searching is that the game accommodates at least three players, not that the game requires at least three players. If you enter “3” expecting the former but you get search results for the latter, it’s confusing to the point that you start to think the search results are wrong.

“Inclusive” selects a search where the given minimum is an upper bound for the game minimum and the given maximum is a lower bound for the game maximum. 'Exact" selects a search where the given minimum and maximum are equal to the game minimum and maximum.

I don’t know of a succinct way to explain this, so I haven’t.

Let me see if I understand this correctly.

With Inclusive option selected:

  • If min is set, then games with min_player <= min are selected
  • If max is set, then gamed with max_player >= max` are selected
  • If both min and max are set, then games with min_player <= min and max_player >= max.

In other words, in this mode,

  • at least min players must be possible with the game, and
  • at least max players must be possible with the game.

For example, if I set min=3 then games with a minimum number of players equal to 0, 1, 2, and 3 are selected (no matter the maximum number of players). If I set max=4, then games with a maximum number of players equal to 4 or higher will be selected. The first part sounds a bit counter intuitive. If I set min=3 I will also get games that are for a maximum of 2 players.

Running a few tests on the query, I think what you do is that

  • if min is set, then games with max_player>=min are selected
  • if max is set, then that is interpreted as min
  • if both are set, then games with max_player>=min and max_player>=max are selected.

Effectively, it is a selection only on the gamed max_player property.

With the Exact option chosen:

  • If min is set, only games with min_player=min are selected.
  • If max is set, only games with max_player=max of players are selected.
  • If both are set, then only games with min_player=min and max_player=max are selected.

Have I misunderstood something?

Yours,
Christian

No, this isn’t correct.

With the inclusive option, for all results the query min and max will not be outside the game min and max.