Field Filters for All Libraries

[Weissrolf]

No problem. I mostly asked because in April you queried which libraries I am most interested in (spells). So it seemed like you were going to work on it at some point and I was curious about the progress. If PF2 support is not coming anytime soon then I can (and will have to) live with it.

Searching in the "Description" field would already be a nice improvement. Currently for spells the search text field only seems to search for spell names. So a search for "penitent" will return "brand of the imPENITENT", but not "Atone", the latter of which includes the word "penitent" in its description (Effect) text.

For PF2 there really should be a "Traits" search field, allowing to search for specific traits like "audible" or "flourish". Traits are effectively hashtags and being able to search for tags when the whole system is built around them seems like a no-brainer. But that seems less of a job for extensions, but more of the main module. I will post a feature request to Trenloe about it in the corresponding forum.

[Trenloe]

I will post a feature request to Trenloe about it in the corresponding forum.

See my comment earlier in this thread: https://www.fantasygrounds.com/forum...l=1#post523106

[Trenloe]

Over the years I have seen some very respected community contributors go off on a rant. It happens once in a while. My time has come.

Yup, it happens to us all. Unfortunately there will always be some who will push for (and expect) more... Hang in there, your contributions to the community are appreciated and valued.

[Weissrolf]

Traits aren't that simple. There are literally hundreds of them in PF2, and each spell has multiple traits. To add those to a filter is going to....

Does it have to be a filter list, though? A simple text search field would help a lot already. If more than one search term can be entered via comma we could even combine searches for several traits, like all "audible, visible".

[Minty23185Fresh]

Does it have to be a filter list, though? A simple text search field would help a lot already. If more than one search term can be entered via comma we could even combine searches for several traits, like all "audible, visible".

To my mind this would be completely new functionality. The underlying data is not set up for that.

[EDIT] an example is in order here. Say you have a small warehouse of boxes and you want to search for the ones containing broken merchandise. You can’t just look in all the boxes at once. You either have to open them up and look in each one individually, or you have to reformat the search by opening up all the boxes setting them side by side Or emptying them into a pile, then looking into all of them, or at the pile, at the same time.

[Weissrolf]

I see the point. That being said, we are decades into computerized data management (aka databases), including search. Don't get me started about PDF search and search presentation capabilities, at times it feels like the digital stone-ages.

[Minty23185Fresh]

Oddly enough, I designed and implemented databases and database front ends (GUIs) for, at the time, the largest slot machine company in the world. I suspect Smiteworks did not anticipate user database search capabilities in their original design specs. I only have what’s available to me, some lua and some xml. On the other hand I applaud Smiteworks and the Fantasy Grounds design and implementation team for exposing even that much to us community developers. One doesn’t often get even that much in their wish list.

[damned]

There are two big challenges here and they probably contribute to why this is not part of Core and the challenges contribute to the complexity and the time invested by Minty in this extension already.

1. Its not as simple as searching a PDF where the PDF simply displays the same thing on every search result. A highlighter word on a page. In Fantasy Grounds every piece of data has a data type and a completely different set of related data fields and presentation requirements for each type of data. A weapon displays different data fields in a different data field window to what a Spell or a Feat or a Background or a section of text. The FFAL needs to search all of these data types and present the data link so that it will open with the correct presentation.
2. FGU does not handle long lists very well at this point in time and PF2 is going to have a huge amount of data over time if history is any guide.

It may not be obvious to people making requests on expansions to this extension but it is a lot of work and peoples time is finite.

[damned]

Oddly enough, I designed and implemented databases and database front ends (GUIs) for, at the time, the largest slot machine company in the world. I suspect Smiteworks did not anticipate user database search capabilities in their original design specs. I only have what’s available to me, some lua and some xml. On the other hand I applaud Smiteworks and the Fantasy Grounds design and implementation team for exposing even that much to us community developers. One doesn’t often get even that much in their wish list.

No... they did not. The original team who started FG had little idea I think, about how their product would grow up. There are plenty of design bottlenecks...

[Minty23185Fresh]

I see the point. That being said, we are decades into computerized data management (aka databases), including search. Don't get me started about PDF search and search presentation capabilities, at times it feels like the digital stone-ages.

This comment indicates to me, a lack of understanding of what the issues are here. You want something done, it seems as though it should be simple enough to accomplish, yet you can't so you resort to Fantasy Grounds bashing. To my mind a less than productive methodology.

First, Fantasy Grounds is a game playing platform. I'm assuming and damed confirms that database mining was not in the original, and it is probably still not in the project's scope.

Even huge databases such as those being compiled by Google cannot be mined by just an idea. Every time someone wants to extract data from a database, unless it has been done before and the routines already exist, some code monkey like me, must write the routines necessary to extract and present and sometimes interpret the data in a manner that meets the intended result. An example: the vast amounts of medical data being accumulated by Google (and others) are predominately aimed at medical statistical research. To believe that one should just somehow be able to play a game of "Let's Play Doctor" without some sort of out-of-scope interface is ludicrous. Yet this is exactly what i have done with Fantasy Grounds. I recognized the data treasure trove and provided a front end (user interface) to present the data in a means that satisfies my intent. It doesn't satisfy your desires or intent but that's because I never designed it to.

The implementation of FG's database by Smiteworks is actually quite clever and far from "stone age". With its "distributed" database, rather than have one huge database on a bottlenecked server somewhere that they must maintain they distribute micro-databases, called modules. They are all internally consistent, so that one "program" (e.g. FFAL) can access them individually or all at the same time. It also allows Smiteworks to update every user's unique database when the user purchases another product.

[EDIT] OMG. I’m glad I caught this. The diatribe above reads as though FFAL was solely my idea. Nothing could be further from the truth. The Field Filters were in the rule sets already, although, scant - only a few fields had filtering. I just took the idea to the next level.