The Guide to Loot Filters

"

Hellcat5 wrote:

"

Antnee wrote:

"

lunaz wrote:

I searched the thread for the meaning of DropLevel, but not understanding it.

Is it required Character Level to use an item or Area/Monster Level where the item starts dropping?

Like The Ledge: 6 / 42 / 56 but my character is 50.
Is there a list of item DropLevels?

Droplevel is the item level that's required for it to drop. For example:

The above item has a DropLevel of 15. It usually corresponds to the required level.

I don't think Antnee's clear enough about this. I'm going to simplify it:

Droplevel is the level of monster the BASE item starts dropping from, which so happens to be itemLevel (unless it's a magic rarity monster, or rare rarity monster, or unique rarity monster (aka exile) / boss / thing you chop up into pieces)

So, it's simple. You chop up monster that is level 15, and he can drop item with "Required Level 15" ( example - Broad Sword) or lower.

Bolded the important bit. It all boils down to that.

"

Hellcat5 wrote:

I might be lost on the topic, but you can most certainly use more than one class in the class definition (I've been using it for months without missing anything that falls into the condition defintion. NOTE: you MUST use the FULL class name or it will not work. Divination will not work. Must use Divination Card with exact capitalization - Antnee didn't mention that to you xhul):

The bolded bit is wrong. This is what I've been using for Divination Cards from the beginning:

Class Card

Divination would work also. Read through my filter, I think you'd be surprised by how many times I truncate and it works just fine.

"

Hellcat5 wrote:

Why, exactly, would you limit a condition like the above in your example to = 71 instead of >=? I can't think of any good reason, other than hunting for Maraketh bows explicitly (and you'll die if it's not a Maraketh bow), and checking dropLevel for a specific item. While an attempt to shorten code, it doesn't guarantee the correct item as you showed. It could also be possible, with your example, that another bow could work it's way up to having a level req of 71 based on mods. Now, I've not checked exactly if that's possible to happen considering the other basetype level requirements, and maximum level increase based on mod power, but let's go with it.

Why? I don't know, but it's an example. Like I said, using the required level would break certain things. Options are good, and DropLevel is the most versatile option at the moment.

I think you're the only one who's really hung up on this, after an explanation. Strange hill to die on.

"

Hellcat5 wrote:

Another note - Cameria's Maul and Mjolner both have same Required Level (obviously). Since dropLevel wouldn't change due to the same basetype, having DropLevel and RequiredLevel wouldn't affect the ability to discern between the two. What would, is having ItemName access. I must say, I do prefer concrete examples. :P

Fair enough, but you do see the point, right? Was there an actual purpose to this paragraph other than "WELL TECHNICALLY...." There are items that share a base which have a different level requirement. You use the wiki. Go wiki.

"

Hellcat5 wrote:

Sidenote: Antnee, this stuff is FAR easier than CSS. I don't see it as hard at all for anyone who's touched cascading style sheets with an ounce of success in web development. CSS teaches enough precedence to work with this simplified CSS like scripting. Yet, it is intimidating enough for players who don't get into techy stuff, and thus they use filters that we've created instead of making their own.

I sincerely doubt that this is the reason why people don't write their own. Even if the syntax is dead simple and crystal clear (isn't it already?), the big problem is that it's time consuming and somewhat risky. No one wants to fuck up and hide an exalt. Many people are afraid of that.

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.

"

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 actually wonder if it has more to do with the way Quest items are handled, though. You should test a multiclass line that doesn't include "Quest". Maybe something arbitrary like

Class Currency Bow

"

Antnee wrote:

I actually wonder if it has more to do with the way Quest items are handled, though. You should test a multiclass line that doesn't include "Quest". Maybe something arbitrary like

Class Currency Bow

Like i said, other classes seem OK.
Class Body Divination, for example, works fine.
But that doesn't mean other specific classes aren't involved, for sure.
I wouldn't be surprised if labyrinth items suffer the same flaw.

"

xhul wrote:

"

Antnee wrote:

I actually wonder if it has more to do with the way Quest items are handled, though. You should test a multiclass line that doesn't include "Quest". Maybe something arbitrary like

Class Currency Bow

Like i said, other classes seem OK.
Class Body Divination, for example, works fine.
But that doesn't mean other specific classes aren't involved, for sure.
I wouldn't be surprised if labyrinth items suffer the same flaw.

Ah sorry, must have missed that.

I think you'll probably end up with the same result with any other class that GGG doesn't let you hide. Quest is the only one I'm for sure about; there could be others.

"

Antnee wrote:

I think you'll probably end up with the same result with any other class that GGG doesn't let you hide. Quest is the only one I'm for sure about; there could be others.

Kinda funny that you talk about "unhideable" classes, cause i exactly thought the bug had something related to that.
It really looks like the parser behaves similarly (using the default text & sound setup).
Something like :
1) A quest item drops.
2) The parser finds the quest items class in the current loaded filter data.
3) It verifies if it is actually in a "Show" block.
4) It is, but GGG's algorithm is only compatible with class being the first in the line, so for some reason, it returns false.

"

xhul wrote:

"

Antnee wrote:

I think you'll probably end up with the same result with any other class that GGG doesn't let you hide. Quest is the only one I'm for sure about; there could be others.

Kinda funny that you talk about "unhideable" classes, cause i exactly thought the bug had something related to that.
It really looks like the parser behaves similarly (using the default text & sound setup).
Something like :
1) A quest item drops.
2) The parser finds the quest items class in the current loaded filter data.
3) It verifies if it is actually in a "Show" block.
4) It is, but GGG's algorithm is only compatible with class being the first in the line, so for some reason, it returns false.

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.

"

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.

"

Antnee wrote:

"

Hellcat5 wrote:

I might be lost on the topic, but you can most certainly use more than one class in the class definition (I've been using it for months without missing anything that falls into the condition defintion. NOTE: you MUST use the FULL class name or it will not work. Divination will not work. Must use Divination Card with exact capitalization - Antnee didn't mention that to you xhul):

The bolded bit is wrong. This is what I've been using for Divination Cards from the beginning:

Class Card

Divination would work also. Read through my filter, I think you'd be surprised by how many times I truncate and it works just fine.

Just tested and remembered the exact situation from which I made that statement. First off, I'm wrong. You don't need the full class name. What you DO need is capitalization. Once upon a time I accidentally tried "card." lol. Since that didn't work, I presumed that it must require the full (with capitalization) class name instead (a safe assumption). Skipping reading your filter for now.

"

Antnee wrote:

"

Hellcat5 wrote:

Why, exactly, would you limit a condition like the above in your example to = 71 instead of >=? I can't think of any good reason, other than hunting for Maraketh bows explicitly (and you'll die if it's not a Maraketh bow), and checking dropLevel for a specific item. While an attempt to shorten code, it doesn't guarantee the correct item as you showed. It could also be possible, with your example, that another bow could work it's way up to having a level req of 71 based on mods. Now, I've not checked exactly if that's possible to happen considering the other basetype level requirements, and maximum level increase based on mod power, but let's go with it.

Why? I don't know, but it's an example. Like I said, using the required level would break certain things. Options are good, and DropLevel is the most versatile option at the moment.

I think you're the only one who's really hung up on this, after an explanation. Strange hill to die on.

I don't like to give people examples that don't work. I like firm, concrete, useable, logical examples. Again, I guess that comes from my development background. From my view, giving unworkable examples only serves to confuse people interested in working with filters, people who might not have a background in development and programming like I do. Let's avoid metaphorical stabs shall we because it's not that cut and dry. Your explanation was founded on air. That's not metaphor. It doesn't provide concrete example, nor does it really apply to help someone understand the metastructure of filter design, again, because your example doesn't work.

"

Antnee wrote:

"

Hellcat5 wrote:

Another note - Cameria's Maul and Mjolner both have same Required Level (obviously). Since dropLevel wouldn't change due to the same basetype, having DropLevel and RequiredLevel wouldn't affect the ability to discern between the two. What would, is having ItemName access. I must say, I do prefer concrete examples. :P

Fair enough, but you do see the point, right? Was there an actual purpose to this paragraph other than "WELL TECHNICALLY...." There are items that share a base which have a different level requirement. You use the wiki. Go wiki.

Dude, if you know anything about me, you know there's always a point. Sorry I left too much of the point to implication, so here you go - can you give the readers a concrete example of using your filter "concept" in a real situation? That would be lovely.

"

Antnee wrote:

"

Hellcat5 wrote:

Sidenote: Antnee, this stuff is FAR easier than CSS. I don't see it as hard at all for anyone who's touched cascading style sheets with an ounce of success in web development. CSS teaches enough precedence to work with this simplified CSS like scripting. Yet, it is intimidating enough for players who don't get into techy stuff, and thus they use filters that we've created instead of making their own.

I sincerely doubt that this is the reason why people don't write their own. Even if the syntax is dead simple and crystal clear (isn't it already?), the big problem is that it's time consuming and somewhat risky. No one wants to fuck up and hide an exalt. Many people are afraid of that.

LOL! sorry. maybe I shouldn't laugh, but you really made me laugh there. Let's break this down so potential filter creators can stop being afraid to accidentally hide a Mirror of Kalandra:

Code Example:


Show
BaseType "Exalted Orb" "Eternal Orb" "Divine Orb" "Albino Rhoa Feather"
SetBackgroundColor 170 158 130
SetBorderColor 170 158 130
SetTextColor 0 0 0
SetFontSize 64
PlayAlertSound 2 100


Hide
Class Currency
BaseType "Scroll of Wisdom" "Portal Scroll"


To hide something in a filter, one must specifically hide the item's class or basetype. You don't accidentally hide the Currency class, or accidentally hide the "Mirror of Kalandra." Let's talk about precedence here first before I talk about the "hide" block. Blocks defined ABOVE a specific block (ex: the above hide block) take precedence over blocks below them (of course people who make filters prob. know this (hopefully? lol), but I'm adding this in for those reading who don't know a thing about making a filter script). This type of precedence is similar in function to that you'd find in mathematics - multiply, divide, add, subtract.

The above "code" you can see this hides any Currency not named in the above Show block (I have more currency Show blocks in my filter, but this is a concrete example, and I love those..) In short, there's absolutely no way i've seen to accidentally hide a mirror or an exalted orb, or anything. You have to ignore making a show block for a mirror (all filter providers made a show block for mirror to my knowledge, because mirror), or put the show block below the hide block. lol.

Now, to address something else. I said -

"

Hellcat5 wrote:

Yet, it is intimidating enough for players who don't get into techy stuff, and thus they use filters that we've created instead of making their own.

then you said -

"

Antnee wrote:

I sincerely doubt that this is the reason why people don't write their own. Even if the syntax is dead simple and crystal clear (isn't it already?), the big problem is that it's time consuming and somewhat risky. No one wants to fuck up and hide an exalt. Many people are afraid of that.

So, you disagree to turn around and say the same thing (in different words) I just said? Interesting. Again -

"

Hellcat5 wrote:

[...]it is intimidating enough for players who don't get into techy stuff [...]

then:

"

Antnee wrote:

the big problem is that it's time consuming and somewhat risky. No one wants to fuck up and hide an exalt. Many people are afraid of that.

Not getting into techy stuff means a person doesn't have knowledge about techy stuff. When you don't know something, you fear making mistakes. Fear / Intimidation. Hmmm. Did you miss the meta there man?

I had respect for you based on a conversation we had over a year ago from a comment you made on my youtube channel. With your comments toward me lately, however, I'm losing that respect because your comments seem antagonistic. Lets not do that. Lets be respectful toward each other ok?

We are, after all, two people trying to help the path of exile community to the best of our abilities. Now, I'm gonna go help the guy you skipped over named "Chebudeeh". l8r man.