Parser failing or throwing errors on correct syntax when opening a real filter

[dbgs-piggy]

First and foremost, great program, thank you for your work. Ill describe what im seeing with regards to the eccentricities of the parser when trying to load in pre-existing filters but my question is : Is the parser a wip or is the intention to drive towards one syntax to rule them all? If the former the parser at grinding.zone is very effective accepting everything ive thrown at it thus far, maybe contacting them to pick their brain can help.

Tested this on the expedition and scourge build.

DisableDropSound will cause parsing to fail with an ambiguous "expected eoi" message if followed by True or False. Only accepting the symbol on its own despite "DisableDropSound True" being very common in the wild.

Having more than one condition eg HasExplicitMod in a block throws an error stating ...
"the same condition can not be specified again in the same block or nested blocks" ...
despite having more than one being quite common. eg for a block to match items that have one or more of SetA AND one or more of SetB by writing
...
HasExplicitMod SetA
HasExplicitMod SetB
...

SocketGroup "GGG" is perfectly valid but throws an error because the "'s exist stating that socket_spec was expected and that it got a string instead. A similar situation occurs with HasInfluence only it doesnt complain about the fact that "Shaper" etc is a string.

Thank you for your time.

[Xeverous]

Is the parser a wip or is the intention to drive towards one syntax to rule them all?

If you mean the parser of the real filter syntax (not FS-specific templates) then it's intended to support everything that the game allows in order to support (planned/WIP) loot simulator/debugger UI.

So far the project's main focus was templating and the real parser might be a bit behind. It's also not fully tested.

---

DisableDropSound will cause parsing to fail with an ambiguous "expected eoi" message if followed by True or False. Only accepting the symbol on its own despite "DisableDropSound True" being very common in the wild.

GGG does not release any formal grammar specification like EBNF so situations like this are inevitable - I just don't know how exactly their parser works (just read doc/actual_filter_quirks too see all kinds of oddities) so I can't write code that has 100% same behavior. All of my work is based on their examples and sometimes extra communication taken from reddit. But again, it's not really formal/proper specification so some ambiguities may still appear (just find in my docs info about SocketGroup and try to imagine how big pain it was to test and verify).

Of course, I could make the parser (or semantic analysis) better. Some stuff is planned, including better diagnostics and treatment of errors. I can link you a discussion I made on boost/spirit project but it's very technical.

In this specific case, it could be turned to something like "warning: extra expressions detected after 0-parameter action, ignoring them". If you got more cases like this one, let me know.

---

Having more than one condition eg HasExplicitMod in a block throws an error stating ...
"the same condition can not be specified again in the same block or nested blocks" ...
despite having more than one being quite common. eg for a block to match items that have one or more of SetA AND one or more of SetB by writing

This is described in doc/known_issues. The story is that I have implemented a significant amount of FS code before I knew that such thing was possible and now it would require significant amount of time to rewrite relevant code to support multiple actions of the same type in 1 block. But don't worry, I have it planned too.

---

SocketGroup "GGG" is perfectly valid but throws an error because the "'s exist stating that socket_spec was expected and that it got a string instead. A similar situation occurs with HasInfluence only it doesnt complain about the fact that "Shaper" etc is a string.

Again, the issue that GGG does not release any formal documentation. This can also be fixed but the reason why such error appears is that for any person with enough programming grammar experience it just seems inappropriate/unnatural/inconsistent. Apparently GGG focuses way more on "braindead always working" approach for least skilled users than "proper programming grammar with conventional rules". I get motivation for their decision, but obviously no one can expect me to guess what other kinds of syntax inconsistencies they are going to support. Filters grammar is already a bit hard to write code for because it has basically no delimeters or recovery points (stuff like ,, ;, ()) other than line breaks.

---

Let me know if the answers are clear. I'm writing in a bit of a hurry as I the league starts soon and I got a bit less time for preparation than expected.