The Guide to Loot Filters

"

xhul wrote:

"

Hellcat5 wrote:

I mentioned this in a previous post -

I've been using multiple class definitions for months. You'll find an example in a previous comment. :) You CAN put more than one class in a class definition line. I don't know about quest items because i've never felt the need to change them. I'll do some testing with my low character and get back to you later tonight.

I think we've all seen your post, dude, don't worry =]
Everthing in it seemed accurate, except that Class conditional lines don't require full class names to work. They are handled the same way as BaseType lines.
So "Divination" alone WILL work, for example.
Also, if we are continuing to post about that, it's because there is an obvious bug, and we are trying to understand it better.
In short, the "Quest Items" class is buggy, and needs to be the first in the line, otherwise, default text & sound settings will be used.
Regards.

Yep. Got it. Tested myself, and agree. "Quest" works fine in a massive line of Classes as long as it's first. Now, let's get technical. In what condition would you want "Quest Items" to have the same style as any other class? I'm trying to elicit a concrete situation from you in regards.

I can't call this differing functionality a bug because no one from GGG has stated re: this topic and we don't know if it's a programmatic decision, or something that happens only due to how GGG implemented filters into the game. Perhaps time to message Mark_GGG? As a developer, in situations similar to this, I'd ask myself "is this really necessary?" do you plan to make a show block that will make Quest Items class the same color as any other class?

And of course, Why? As a developer, I don't like "just cause" as an answer.

Best wishes.

"

Hellcat5 wrote:

Yep. Got it. Tested myself, and agree. "Quest" works fine in a massive line of Classes as long as it's first. Now, let's get technical. In what condition would you want "Quest Items" to have the same style as any other class? I'm trying to elicit a concrete situation from you in regards.

I can't call this differing functionality a bug because no one from GGG has stated re: this topic and we don't know if it's a programmatic decision, or something that happens only due to how GGG implemented filters into the game. Perhaps time to message Mark_GGG? As a developer, in situations similar to this, I'd ask myself "is this really necessary?" do you plan to make a show block that will make Quest Items class the same color as any other class?

And of course, Why? As a developer, I don't like "just cause" as an answer.

Best wishes.

Well, i actually discovered that bug by accident, cause i'm displaying both quest & labyrinth items the same way in my filter, since they share very similar properties.
And, i need to know a little bit more about a bug before asking the company to fix it.
I have a few more things under my jacket.
In the mean time, i'm probably the only person using quest items in a multiclass line right now, so, i guess it can wait XD

"

xhul wrote:

Performed a few more tests about the "Quest Items" class.
I thought at first that the parser was simply ignoring the block in case the class isn't the first in the line, but that's not the case.
It actually stops the parsing (matching object considered found), and ignores the settings associated with that condition.
I discovered that with this :

Class Divination Quest < parsing actually ends here
blablabla 1 < ignored

Class Quest < not processed
blablabla 2 < not processed

I updated my previous post and put what i found in bolded text.
For now, and since we don't know how many classes are affected, i suggest not using multiclass lines.

I've been using non "Quest Items" multiclass lines for a long time without trouble. To avoid over-complication based from fear of negative impact, test. Don't just avoid using multiclass lines because you fear that the classes might not work how you think they should, but fear they don't.

I can say firmly that show blocks with Quest at the front do indeed process all classes after the Quest Items class. I tested it with this:


Show
Class Quest Card Boots Gloves Body Armour Amulets
SetBackgroundColor 200 100 0
SetBorderColor 200 100 0
SetTextColor 0 0 0
SetFontSize 64
PlayAlertSound 9 100


I also moved "Quest" to the end of the Show block, and found that it reverted to original style formatting. I did not test what would happen if I added classes after "Quest" when I moved it to the end. Again I return to this question:

In what case would you want to have the Quest Items class look like any other class? Please give me a concrete beneficial scenario.

"

Chebudeeh wrote:

Hello all. Hope someone is still checking this post and i would love to get some help.

I got you bro. ;)

"

Chebudeeh wrote:

İ started the game a week before talisman , because im from d3 i just öade a charaxter to lv50 in standart just to learn some mechanics etc.

İ don't play every day by hours but still i enjoy the game , learning aomething everyday.

So far in 5 months i only played 3-4 spellcaster builds which i usually ended up using es gear because i used to be suck ( witch = int based item = es gear ) or if i cannot color a gear i simply used eva or armor based and all mixed up.

Now im a bit into game and atleast i learned jewels jewelleries es gear what is good whats sucks etc , and that im going to try ci discharger i would like to make some changes in my filter.

1. İ still cant understand many items just by looking at their name and pick them up , i gotta look the picture to see what base item it is such as for example vaal regalia.

2. İ always used neversinks filter so i just want to make some changes on it i really used to play with the sounds colors rbg gear/stone hammers/+-75ivi stuff colors etc.

EEEEEW. Neversink's filter is UGLY. use mine. Mine's at least "not so ugly". lol. (Sorry Neversink. It's the designer in me that hates your filter, not the developer.)

"

Chebudeeh wrote:

3. Because i suck and because i havent played any eva armor based character i have no idea what to pick up and what to leave behind so i usuallly ended up not picking any ( same as with quivers etc )

Anyway because the es gear worth lots of currency and im gonna play ci character i just wanted to change the background color of hubris helmets/itanium shields/sorcarer gloves etc so i can just pick them up s/o slowing down and continue.

Just like neversinks filter shows sorcerer boots , is there any way to do this ?

Yep. Here's a way you can do that:


#Show crafting base items
Show
BaseType "Hubris Circlet" "Rustic Sash" "Titanium Spirit Shield" "Graceful Sword" "Lithe Blade"
Rarity < Magic
SetBackgroundColor 255 255 0
SetBorderColor 255 255 0
SetTextColor 0 0 0


First thing, you'd probably want to remove the "Rarity < Magic" line so it shows ALL the hubris circlets that drop. Easy enough. Next, the issue with adding this code lies in that I don't know what's going on with neversink's precedence order, so I would say best bet is to put that show block at the top of the filter script, unless you'd consider switching filters. Have you tried asking on Neversink's thread about how to do what you want with his filter?

If, however, you grab my standard edition filter here, that block is inside toward the bottom of the filter, and it's very easy to delete a line, or comment it out with # in the front of the line:

# Rarity < Magic

"

Chebudeeh wrote:

İ would like to change all ilvl rare colors , and 70+ilvl blue ones too. How to add them and change the filter ?

So, you want to change all rares regardless of itemLevel, and if an item is itemLevel 70+ and magic rarity you want to change the style for those. Why 70?

Regardless, here's the blocks you'd need:

Show
Rarity = Rare
SetBackgroundColor 255 255 255
SetBorderColor 255 255 255
SetTextColor 0 0 0
SetFontSize 64

Show
itemLevel >= 70
Rarity = Magic
SetBackgroundColor 255 255 255
SetBorderColor 255 255 255
SetTextColor 0 0 0
SetFontSize 64

"

Chebudeeh wrote:

İ tried to read this post and looked the filter txt and tried to do some s**t but ended up doing nothin so i erased it.


İ know i want too much , but if its a easy think to do and won't take much time , i would love that someone could code it for me , ( on the top of neversnks full filter )

Ah. You're requesting customizations to neversink's filter. I'm willing to do that for you. However, I think you might be better off learning to do it yourself so you can, without delay, change your filter when you want to. Also, I believe there's a tool floating around somewhere that allows you to visually change or add things to a filter... ah! here it is - filter script visual editor.

If you don't find that to your liking, let me know in PM using the messaging system, and I'll make the customization changes you're looking for. I prefer to teach someone to do for themselves, than to put a person in position to need me.

"

Chebudeeh wrote:

Have a nice day/evening/night.

Stay safe and good luck


P.S.: i write this on my phone. Sorry for the wrong letters , and for bad english

Best wishes to you too!

"

Hellcat5 wrote:

I've been using non "Quest Items" multiclass lines for a long time without trouble. To avoid over-complication based from fear of negative impact, test. Don't just avoid using multiclass lines because you fear that the classes might not work how you think they should, but fear they don't.

I just said "don't use multiclass lines" for several reasons :
1) We don't know the scope of this bug.
2) You could have a bad interaction involving this bug without knowing it.
Test it ? of course, but since it hasn't been done with all classes, that was my temporary recommendation.
Feel free to follow it or not, i guess you're old enough.

"

Hellcat5 wrote:

I can say firmly that show blocks with Quest at the front do indeed process all classes after the Quest Items class.

And i believe it also does if Quest is at another place.

"

Hellcat5 wrote:

In what case would you want to have the Quest Items class look like any other class? Please give me a concrete beneficial scenario.

I already answered in my previous post.
And by the way, it's not because something doesn't seem useful that it shouldn't be investigated, especially when you discover larger implications with further testing.
If you're indeed a programmer, i'm sure you understand what i mean (at least if you happen to test & debug your own stuff).

"

xhul wrote:

"

Hellcat5 wrote:

I've been using non "Quest Items" multiclass lines for a long time without trouble. To avoid over-complication based from fear of negative impact, test. Don't just avoid using multiclass lines because you fear that the classes might not work how you think they should, but fear they don't.

I just said "don't use multiclass lines" for several reasons :
1) We don't know the scope of this bug.
2) You could have a bad interaction involving this bug without knowing it.
Test it ? of course, but since it hasn't been done with all classes, that was my temporary recommendation.
Feel free to follow it or not, i guess you're old enough.

"

Hellcat5 wrote:

I can say firmly that show blocks with Quest at the front do indeed process all classes after the Quest Items class.

And i believe it also does if Quest is at another place.

"

Hellcat5 wrote:

In what case would you want to have the Quest Items class look like any other class? Please give me a concrete beneficial scenario.

I already answered in my previous post.
And by the way, it's not because something doesn't seem useful that it shouldn't be investigated, especially when you discover larger implications with further testing.
If you're indeed a programmer, i'm sure you understand what i mean (at least if you happen to test & debug your own stuff).

As a developer, I believe all cases should be well defined and explored, and shouldn't leave room for scenarios like this. The call center for GE Money (General Electric credit card) used my call center application for over 5 years flawlessly, until they decided to move to a different platform. Not a good idea to follow the white rabbit of what seems like it should be. That gets people fired when the boss is looking for the necessity of what works, and before 8A.M. the next morning.

Thanks for giving a concrete example of what classes you want to combine. That makes it MUCH more understandable, and I can agree with it in that situation. If I were to do that, desire to make quest items the same color as the labyrinth items, if the classes on the same line don't work, just make two show blocks one above the other. That won't add much work for the computer considering one character = 1 byte, and the function of applying the style to the class doesn't take much processing. Sure, it's not the ideal way to handle it, but it works until GGG decides this scenario takes precedence over other tasks they need to accomplish.

I am a potato banana.

That's what i'm using right now (2 separate blocks), until i'm sure labyrinth items class is safe.
When i'm sure it is, i'll use "Class Quest Labyrinth" (and not "Class Labyrinth Quest", like i used to).
But something tells me labyrinth items will provoque a jump to the same buggy piece of code (in which case 2 separate blocks will be the only solution in my case).
I'll test in my next lab run and let you know guyz, for sure.
But technically, like we suggested with Antnee, this buggy code probably leads to the same code the game is using when you try to hide items that are not allowed to (and lab items probably fall in that category aswell).

"

Hellcat5 wrote:

EEEEEW. Neversink's filter is UGLY. use mine. Mine's at least "not so ugly". lol. (Sorry Neversink. It's the designer in me that hates your filter, not the developer.)

Hmm, yeah, I had a feeling, and that solidified it.

Take a look around. Filter creators are very nice to each other regarding each other's works. We help each other out... trade ideas and feedback. More importantly, we don't bash each other's creations like that. No one even feels the need. You crossed a line for no fucking reason right there.

"

Hellcat5 wrote:

Lets not do that. Lets be respectful toward each other ok?

"

Antnee wrote:

"

Hellcat5 wrote:

EEEEEW. Neversink's filter is UGLY. use mine. Mine's at least "not so ugly". lol. (Sorry Neversink. It's the designer in me that hates your filter, not the developer.)

Hmm, yeah, I had a feeling, and that solidified it.

Take a look around. Filter creators are very nice to each other regarding each other's works. We help each other out... trade ideas and feedback. More importantly, we don't bash each other's creations like that. No one even feels the need. You crossed a line for no fucking reason right there.

Hmm, i believe he was just stating his very personal opinion (in the very subjective world of esthetics).
I don't see any disrespect so far, but maybe i missed something before that.

"

Antnee wrote:

"

Hellcat5 wrote:

EEEEEW. Neversink's filter is UGLY. use mine. Mine's at least "not so ugly". lol. (Sorry Neversink. It's the designer in me that hates your filter, not the developer.)

Hmm, yeah, I had a feeling, and that solidified it.

Take a look around. Filter creators are very nice to each other regarding each other's works. We help each other out... trade ideas and feedback. More importantly, we don't bash each other's creations like that. No one even feels the need. You crossed a line for no fucking reason right there.

"

Hellcat5 wrote:

Lets not do that. Lets be respectful toward each other ok?

Spoiler

"

Hellcat5 wrote:

As a developer, in situations similar to this...

"

Hellcat5 wrote:

Why? As a developer...

"

Hellcat5 wrote:

As a developer, I believe all cases should...

"

Hellcat5 wrote:

I guess that comes from my development background.

WE GET IT. YOU VAPE.

LOL. I can't tell if you're serious or if you're joking. (you didn't use /s for sarcastic D8 you aren't a reddit?) If you're serious, you definitely missed the meta again bro. lol. Hell, mine looks like a kid got a hold of some highlighters inside the game. xD But hey, it makes it MUCH easier for me to see, and I find it more enjoyable to look at. How dare I state my opinion directly, subjectively, and without making my opinion seem like it's fact. How dare I.

But hey, that's only as a designer. As a developer ... ta-dum, I couldn't give an opinion on neversink's filter because I've not analyzed it, nor have I analyzed yours.

Would you like me to? xD HUGS