Xeverous

I have another questions:

• What is the difference between = and == for AreaLevel condition (the official post mentions both)? So far all such conditions (ItemLevel, DropLevel, Quality, GemLevel etc) only allowed < or > or <= or >= or = but not ==.
• What is the default opacity value for colors that do not specify it? I noticed it is not fully opaque.

You are allowed to use == for numeric values, but it is exactly the same as =.

The default alpha value is 50 (out of 255). Edit: actually not. See below

Furycrab

So if you corrupt and get a corrupted implicit on these jewels it'll be a separate modifier?

Implicit Mods (including corrupted implicits) are separate from Enchantment Mods.

NeverSinkDev

Filters can detect enchantments, however the jewel 'type' does not count as an enchantment.

As for the cluster jewels... well, I hope GGG will implement a special way of filtering the jewels by jewel "type", as of right now the filter can't distinguish them.

By the way here's a full list of economy-data I rely on.

These tierlists get updated every update and the economy-updated versions get improved every 4 hours:

https://imgur.com/iZdtmgc

Each tierlis has it's own configuration, lots of special aspect information to represent ingame knowledge and some special rules to keep everything sophisticated and accurate.

Hey, so, in that Item Filter update, I made AnyEnchantment only match Labyrinth Enchants, since those were the only type of enchants that could drop at the time. But since we are adding Cluster Jewels in 3.10.0, which always have a special enchant, I have reconsidered this decision and so from 3.10.0 "AnyEnchantment" will match any visible enchantment mod, including Labyrinth enchants, Anointments, and Cluster Jewels, as well as any future enchant mods we may add.

So for 3.10, you should be able filter for Cluster Jewels as any Jewel that also has an enchant. Or, by simply filtering by their specific base types (TBA).

Occasionally you get these extra long Delve paths where you can't see the end node, but if you mouse over the darkness ("fog of war") you can find the end node and do the Delve without needing to run ahead with flares to reveal more of the map.

We'll get this UI display bug fixed.

Xeverous

I have another question. The post mentions "By default (operator =) the number requires an exact match." but gives examples using only ==.

So:

• What is the difference between SocketGroup == 5GGG and SocketGroup = 5GGG?
• What is the difference between Sockets == 5GGG and Sockets = 5GGG?

SocketGroup == 5GGG requires exactly a 5 link, with exactly 3 green sockets. The other two must not be green.

SocketGroup 5GGG (and SocketGroup = 5GGG) require exactly a 5 link with at least 3 green sockets.

Sockets == 5GGG requires exactly 5 total sockets, with exactly 3 green sockets. The other two must not be green.

Sockets 5GGG (and Sockets = 5GGG) require exactly 5 total sockets with at least 3 green sockets.

_xhul_

I wasn't expecting that.

Are you implying that "SocketGroup < 4RG" is parsed the same way as "SocketGroup < 4 R G"?

Not parsed the same, but they are effectively equivalent

Dissolator

Thanks! So exact match "==" with "5RRR" will not match if item has 4 red sockets, but match item with 3 red and 2 sockets of any other color?

what if it's SocketGroup == 5RRG - it'll match 2 red 1 green and others are not red and not green? while regular match = will allow at least 2 red and 1 green and others may be red or green too?

How < will work with "4RG" ? It will match 3 or 2 linked items with at least 1 red and 1 green in the link? so "RG" part does regular "=" check, not "less then", otherwise it hard to get what "less than 1 red and 1 green" shall check. So < <= => > operators are only applied to number of links, and socket types are have regular "=" match in all those cases?

So exact match "==" with "5RRR" will not match if item has 4 red sockets, but match item with 3 red and 2 sockets of any other color?

Yes

if it's SocketGroup == 5RRG - it'll match 2 red 1 green and others are not red and not green? while regular match = will allow at least 2 red and 1 green and others may be red or green too?

Yep

How < will work with "4RG"

The < and > operators are a bit weird for sockets. I'm not sure how useful they will be in practice. They will match an item that is "greater" or "less" in some way. So if you specify SocketGroup < 4RG then it will match any item with less than a 4 link, or any item with less than 1 red socket, or any item with less than 1 green socket. Operator > is similar, but only checks the number of sockets if you specified a number.

Abdiel_Kavash

The "continue" option does almost everything that my massive preprocessor built on top of your filter language ever tried to achieve, many thanks for that! I think I'll switch to using native filters again once this goes live. (I am using a LOT of disjunctive conditions that previously weren't possible to do natively).

If I may be so bold as to ask for one more thing; it would be variables/macros, even on a purely textual substitution basis. Just one example of what I mean and what this would be useful for:

Define $GoodCurrencyColor 255 240 160

Show
    BaseType "Exalted Orb"
    PlayAlertSoundPositional ShExalted
    SetTextColor $GoodCurrencyColor

Show
    BaseType "Divine Orb"
    PlayAlertSoundPositional ShDivine
    SetTextColor $GoodCurrencyColor

Show
    BaseType "Chaos Orb"
    PlayAlertSoundPositional ShChaos
    SetTextColor $GoodCurrencyColor

This would be good for both good coding practices (don't repeat yourself), also for making changes to your filter later. For example, in my scripting language, I have a macro that contains all the bases that I'm looking for at the moment. I can simply add or remove a base to that macro, and the rest of the script makes sure the items are shown, sized, and styled properly according to rarity, sockets, level, etc. Although this degree of automation would probably still require abusing the "continue" rule maybe too much, if we were given even purely string replacement macros, I believe it would be possible, or close to.

Thanks for the suggestion. I'll have a think about it and see what we can do.

Dissolator

Please check if those are correct:

SocketGroup == 5RRR

shall fail in any case since it needs 5 links and exactly "RRR" group, which is 3 link, so it doesn't match

Sockets == 5RRR

will work and catch any 5 sockets (may not be linked) with 3x Red sockets in any order, since "RRR" here is not a socket group but just a condition to have number of specific types(colors)... or "==" will require number of sockets to be matched to number of listed socket types?

SocketGroup == 5RRR can match items with exactly 5 linked sockets, if the link has exactly 3 red sockets. This should be more useful than just matching nothing.

Sockets == 5RRR will match items with exactly 5 sockets and exactly 3 red sockets.

Xeverous

/u/RhysGGG, can you clarify this? And /u/_xhul_, FYI:

https://cdn.discordapp.com/attachments/175290321695932416/678285728093831177/unknown.png

• I got the post on == vs = but:

• I'm unsure whether the syntax is SocketGroup "GGG" or SocketGroup GGG. There are 2 conflicting examples (in red).

• I'm also unsure how both Sockets and SocketGroup will behave when there are multiple color groups (with = and == we have 4 different cases)

• It's also not specified whether the order of letters matters - you never published any EBNF spec or anything similar and the parser container multiple unintuitive/bugged assumptions previously so I'm asking if there is anything regarding syntax that is worth to know

• It's unclear whether CorruptedMods will work with comparison operators. Also why only 0-2 range? What If I drop the multi-corrupted Sirus gloves?

The syntax for SocketGroup should be unchanged: SocketGroup GGG

Ordering of letters doesn't matter.

As with all rules, if you specify multiple matches if match against any (rather than all). So you could use SocketGroup == RRR GGG BBB to match items with exactly 3 sockets all the same colour. If you didn't use the == operator, it would also match items with extra sockets.

CorruptedMods actually takes any number, but currently nothing in the game drops with more than two corrupted mods. Not even Hands of the High Templar.

I've updated the post to be more accurate, thanks.

is the implicit operator really an exact match for the number, but not for the colours? is it just a typo?

No typo. For Sockets and SocketGroup, the default operator (=) is a little odd, in order to preserve backwards compatibility. So yes, the number is an exact match but the colours are not.

The exact equals (operator ==) will force both number and colours to exactly match, if you want. Or you can use operator >= to make both number and colours accept more.

does such condition apply to multiple groups on the same item?

Yes, operators affect all conditions, if multiple conditions are specified.

would SocketGroup 4 match an item that has 1 group of 4 linked sockets and 1 group of 2 linked sockets?

Yes. SocketGroup matches items that contain a matching link. It doesn't care if there are other non-matching links. If you want to filter for 4 links with no other sockets, use Sockets == 4.

NeverSinkDev

Thoughts:

• CorruptedMods, Mirrored, Socket changes will add a lot of QOL to the state of the filters.

• AreaLevel is huge. It's much more reliable than droplevel and allows highlighting currencies and gems, only while leveling. Things like starter-gems will never be hidden again, no matter the strictness.

• Continue is a gamechanger, when it comes to filter-making. It adds nothing new, but makes things much more elegant and allows more control for custom styles, aspects and advanced constructs. FilterBlade will benefit from it greatly as well!

• In short I'm excited for these changes (especially since I've been suggesting/asking those). Most of these are rather easy to integrate into my filters and will find their uses!

• You'll likely see use of all of these commands in 3.10. "Continue" is a tricky one to bring to www.FilterBlade.xyz , but I think that'll work out as well.

Thanks GGG.

Speculations for 3.10:

• The linkedsockets rework is a bit surprising. It's probably preparation for 4.0, but chances are we'll see more delve socket or abyssal socket action in 3.10.

• "AnyEnchantment" now only recognises Labyrinth enchantments... that's surprising. That likely means there's either going to be enchantment relevant changes in 3.10. Maybe new enchantment types that have an alternative source or are droponly, because otherwise, you can just filter by slot.

Thank you for your detailed suggestions! Sorry I couldn't implement everything you wanted, but hopefully there's enough here to keep you busy for a little while.

The linked sockets rework was mostly QoL but was also necessary to support multiple Abyss/Delve socket matching, i.e. "Sockets AA" and "Sockets DDDD" which couldn't work with SocketGroup since Abyss/Delve sockets are not linked.

(also, for anyone reading this still wondering what Delve sockets are, it just means Resonators)

StupidFatHobbit

please more light options please more light options please more light options

...fuck

AreaLevel changes everything though. One of the main reasons for having separate filters is because you can't distinguish area levels. Now you can have wisdoms showing at low level, but not high level, in the same filter. There's a ton that can be done with that command alone and it's possible that I could eliminate a strictness level and go down to 2 filters from 3. At the very least a lot of the override blocks will be reduced or removed.

Mirrored is nice, especially for chance bases. Sockets finally recognizing Abyss sockets is also neat.

edit:

SocketGroup "X": Groups of linked sockets on an item, for example "RGB". Can have multiple SocketGroup requirements within one filter, for example 'SocketGroup "RGB" "BB"' would filter for any option in that line rather than all options in that line.

Not sure what's changing here, SocketGroup could already filter for multiple options in one line - it's how my levelling section has been written for over a year now.

SocketGroup could already filter for multiple options in one line - it's how my levelling section has been written for over a year now.

Ah, you're right. This isn't new.

Outstanding work! I love it!

Help Alva find the Vaal Architects

nice

We're looking into it.

Onceuponanupvote

Really happy with the change but is there any way we can get to display the region while hovering over the map in the map tab?

It does.

hakitabaraki

Hoping this also works when you encounter Zana in a map, If we hold alt over the maps she offers for her mission.

It does. And her shop, too.

rEDNiNE150

For the record this problem is not all too uncommon, and there are scenario's where the wiggling trick (to reveal a bit more of the fog) does not work to resolve it. For clarity's sake, the wiggling "bug" can be used very, very frequently even when such a long delve node does not exist. Or at least, I don't think it has to exist. The wiggling bug works almost all the time whenever used in a place of fog that almost "overlaps" horizontal and vertical fog clearing, if that makes sense. Like a horizontal line where you have also gone 1 cell up.

This problem is at least as old as last league and to my knowledge a lot of people get it.

But is that what you guys actually need? For us to throw you our account names when our delve is in such a state? Because I'd like to see this (sometimes, very, very costly/annoying problem depending on re-route time) tackled as much as the next guy.

Generally speaking "long" Delves work perfectly. I already fixed the problem last league, afaik, but apparently it can still rarely happen. This is literally the first report I've seen of this in months.

The wiggling thing is known and on my todo list.

Is this one of cases where "wiggling" the map around reveals a but more? Does that fix it for you?

Otherwise can you link me your account/character so I can have a look?

FreedomOfNothing

I suspect its worse; that an impasse has been reached. That the delay in ignite applying is caused by the server not wanting to blindly allow for damage which would kill the targeted boss if unchecked.

My theory, having seen none of their code:

1. The game attempts to check to determine if the damage is real, putting all damage on hold, but by the time it figures out it is real, a new ignite has been applied.

2. Only one ignite can be on a target at a given moment, and the one picked is the bigger one. Since the second ignite has not yet been evaluated, no ignite is applied because the game doesn't know which is bigger.

3. Then, the second ignite evaluates and a third ignite is applied, but the first ignite has already expired, and the same scenario ensues. Infinite loop of zero damage.

This theory holds up in that the threshold for doing zero damage varies based on boss life. You can run into this wall very early with weaker bosses. If I attempt to run T1 maps, I can cap with no damage supports.

The real problem is that this type of checking to make sure a corrupted data packet doesn't instantly kill a boss is probably a good idea for GGG to have in this game. They just need to change something more nuanced in how it is error correcting/checking and have it not eat into ignite duration and/or just apply and then override the ignite after checked instead of trying to compare and getting stuck in a zero damage state.

Ultimately, too much work for GGG. They'll probably nerf the skill to fix the problem at the end of the league and never actually address the interaction past investigating it.

I'd just like to say at the risk of sounding ego-maniacal, I saw this coming the day the gem info was posted.

Edit: Fixed image link.

We have a fix for this coming. It was indeed caused by overflow, so your damage will be capped instead. There are plans for a larger refactor to the damage pipeline, but this is quite a major task.