Hi, dschu012. I appreciate your great job and enjoying it over other Diablo 2 loot filters. It has great potential but I'd like to do few friendly suggestions for further improvements:
New Check statement
In metadata section of filter file, many Show .... Continue constructs are used. But the name Show is confusing and Continue at end is not graceful. Once you use Show statement it should actually show something. I suggest to introduce new Check statement. Check is equivalent of Show .... Continue construct without confusing Continue statement. Example:
Show
Class Amethyst
SetName {Purple}0 {White}{Name}
Continue
become clean and clear
Check
Class Amethyst
SetName {Purple}0 {White}{Name}
New Or condition
Currently all conditions are combined with And relationship. But it would be nice to have condition statements combined with Or prefix. For example:
Show
Class Healing Potion, Mana Potion, Rejuve Potion
Or Type Antidote Potion, Thawing Potion, Stamina Potion
..... do something
Then we can combine two or more Show statements with same action can be combined into single action part. Multiple level of And - Or is not needed. Simply, Or condition should have just one level higher precedence over next And conditions. Multiple consecutive Or's have same level.
More color selections and case-sensitivity in names
I found that current 12 color names are bit limited. I'd like to have more light and soft(unsaturated) colors like light gray (silver), light azure, light green(lime), light coral etc. Make them16 colors out of Diablo II color pallet. The color of {Tan} is too close to {Gold} so it is easily mistaken.
Here is list of colors for Diablo text: {Brown}, {Dark Blue}, {Light Blue}, {Light Green}, {Sky Blue}, {Azure} (renamed to avoid clash with existing "Magic" {blue}) may be added to existing name color value.
ÿc1 (Red)
ÿc2 ("Set" Green)
ÿc3 ("Magic" Blue)
ÿc4 ("Unique" Gold)
ÿc5 (Grey)
ÿc6 (Black ~ Not visible on the profile)
ÿc7 ("Unique" Gold ~ There are two)
ÿc8 ("Crafted" Amber)
ÿc9 ("Rare" Yellow)
ÿc0 (White ~ There are two)
ÿc! (Brown)
ÿc" (Dark Blue)
ÿc+ (Light Blue)
ÿc< (Light Green)
ÿc; (Purple)
ÿc. (Sky Blue)
ÿc* (Blue)
At least some way to use Dia2 palette color index in hexa code in SetName and SetDesciption (ex: SetName {X9E}{Name}{White} ) Or alternatively, user can define new named color like DefineColor PaleBlue, X9F and {PaleBlue} name will be available in SetName and color value. Meta color name {Original} can refer original text color name before change color of item name text to cancel any change of color of name. And the color names should be case-ignored. i.e. {white} should be same as {White} And remove other unnecessary case-sensitiveness in various symbol names.
Inconsistent ChatNotify argument
ChatNotify takes \<boolean> argument. But it is used like ChatNotify "Ping Level" >= 5. Why use quoted string and inconsistant name "Ping Level", not "PingLevel"? I think that it would be better to ChatNotify {PingLevel} >= 5 or simply number range argument like ChatNotify 1-5. I don't see need of boolean conditional test or range evaluation. I prefer even simpler just minimum Ping level number like ChatNotify 5. More versatile is taking variable args like ChatNotify [n] [message] .... Both args are optional. If 1st arg is number, it is minimum ping level number. If 1st arg is not number, it is unconditional (regardless of ping level) chat massage string without quote. If message arg is omitted, default to {Name}.
Provision for multiple Diablo characters sharing same filter file.
Currently all game characters share same filter set and file. We can not selectively apply the filter rule to subset of characters. At least, there must be some condition value like {CharacterName} to access which character is playing.
Or It would be nice to have filter file selection in d2lootfilter.ini like this:
But it seems little bit complicated. I can live with the {CharacterName} variable and means to change ping level and filter level in filter file statement itself Like SetVarble "PingLevel" 5
Extending Difficulty with Act numbering
Difficulty condition is one of Normal, Nightmare, Hell. It can be extended to include act number like Difficulty in Nightmare Act1-Act3 or just Act number like Difficulty in Act2, Act3 regardless of difficulty.
AreaLevel, InTown(InField), AreaName
Similar to Difficulty condition, It would be nice to have access to area level and game area name. At least, area level should be available for testing. AreaLevel in Town should be same as nearest field area, not zero. For example, Act II Town (Lut Gholein) in Nightmare difficulty should be same as Sewers Level 1 in Nightmare difficulty, that is level 43. And simple boolean InTown (or InField) condition that test character is in town like Rogue Encampment or in wild field.
Ex) AreaLevel in 36-47, InTown, AreaName Den of Evil
Place of the item
Condition where the item is placed in. One of Ground, (Equipped, Hiring), Inventory, Stash, Vendor.
Requirement condition
A boolean condition that tests whether the character meets item use/equip requirements (like level, strength, dexterity, class and item durability /quantity > 0 etc, but regardless of unidentified item) and can be equipped or used or not. ex) Usable <boolean>
Special Token {Type}, {ItemLevel}
Like named token {Price}, {Soket}, string value Type name {Type} and item level {ItemLevel} will be available in SetName or SetDescription
Debugging Provision
Debugging <boolean> condition: A condition that checks "/deugging" switch is set or not. And "/filterlevel 0" chat command to show all "hidden" items. All hidden item will be shown with special tag that denotes that the item will be hidden. Same as Show SetName {Name} {Gray}*{White} just before final Hide (all) at end of item filter file.
Easier automatic filter reload
As I suggested in previous issue (#22), there must be easier way to reload filter file other than current "/reload" command. I suggest automatic reloading of filter file on start of new game session.
line continuation in condition list
As I suggested in previous issue (#30), condition list should be able to span multiple lines with trailing comma.
Show
Type Balrog Blade, Cryptic Sword, Feral Axe, Small Crescent,
Conquest Sword, Highland Blade, Champion Sword
Rarity < Magic
............
Condition Armor and Weapon is not so useful. It is hardly used in filter file and can be replaced with Class Any Armor and Class Weapon. Condition Hight and Width are too. I suggest to remove them. Add more useful Condition like (average) Damage sum (excluding DOT damage like poison ) My suggestion: Category {Weapon, Armor, Charm, Socketable (Rune, Gem, Jewel), and Consumable} Throwable Potions should be categorized as Consumable, not weapon, And Size condition that counts number of square it occupies.
Rarity Normal should not include items without any real rarity like potion and consumables. Rarity of Potion and others should be something like Misc or Consumable. Other than Weapons Armors and Jewel, Consumable and Throwable Potion, Rune, Gem should not be of Normal Rarity.
Hi, dschu012. I appreciate your great job and enjoying it over other Diablo 2 loot filters. It has great potential but I'd like to do few friendly suggestions for further improvements:
New
Checkstatement In metadata section of filter file, manyShow....Continueconstructs are used. But the nameShowis confusing andContinueat end is not graceful. Once you useShowstatement it should actually show something. I suggest to introduce newCheckstatement.Checkis equivalent ofShow....Continueconstruct without confusingContinuestatement. Example:become clean and clear
New
Orcondition Currently all conditions are combined with And relationship. But it would be nice to have condition statements combined with Or prefix. For example:Then we can combine two or more
Showstatements with same action can be combined into single action part. Multiple level of And - Or is not needed. Simply,Orcondition should have just one level higher precedence over nextAndconditions. Multiple consecutiveOr's have same level.More color selections and case-sensitivity in names I found that current 12 color names are bit limited. I'd like to have more light and soft(unsaturated) colors like light gray (silver), light azure, light green(lime), light coral etc. Make them16 colors out of Diablo II color pallet. The color of {Tan} is too close to {Gold} so it is easily mistaken. Here is list of colors for Diablo text: {Brown}, {Dark Blue}, {Light Blue}, {Light Green}, {Sky Blue}, {Azure} (renamed to avoid clash with existing "Magic" {blue}) may be added to existing name color value.
At least some way to use Dia2 palette color index in hexa code in SetName and SetDesciption (ex:
SetName {X9E}{Name}{White}) Or alternatively, user can define new named color like DefineColor PaleBlue, X9F and {PaleBlue} name will be available in SetName and color value. Meta color name {Original} can refer original text color name before change color of item name text to cancel any change of color of name. And the color names should be case-ignored. i.e.{white}should be same as{White}And remove other unnecessary case-sensitiveness in various symbol names.Inconsistent ChatNotify argument
ChatNotifytakes \<boolean> argument. But it is used likeChatNotify "Ping Level" >= 5. Why use quoted string and inconsistant name "Ping Level", not "PingLevel"? I think that it would be better toChatNotify {PingLevel} >= 5or simply number range argument likeChatNotify 1-5. I don't see need of boolean conditional test or range evaluation. I prefer even simpler just minimum Ping level number likeChatNotify 5. More versatile is taking variable args likeChatNotify [n] [message] .... Both args are optional. If 1st arg is number, it is minimum ping level number. If 1st arg is not number, it is unconditional (regardless of ping level) chat massage string without quote. If message arg is omitted, default to {Name}.Provision for multiple Diablo characters sharing same filter file. Currently all game characters share same filter set and file. We can not selectively apply the filter rule to subset of characters. At least, there must be some condition value like {CharacterName} to access which character is playing. Or It would be nice to have filter file selection in
d2lootfilter.inilike this:But it seems little bit complicated. I can live with the {CharacterName} variable and means to change ping level and filter level in filter file statement itself Like
SetVarble "PingLevel" 5Extending Difficulty with Act numbering Difficulty condition is one of Normal, Nightmare, Hell. It can be extended to include act number like
Difficulty in Nightmare Act1-Act3or just Act number likeDifficulty in Act2, Act3regardless of difficulty.AreaLevel, InTown(InField), AreaName Similar to
Difficultycondition, It would be nice to have access to area level and game area name. At least, area level should be available for testing. AreaLevel in Town should be same as nearest field area, not zero. For example, Act II Town (Lut Gholein) in Nightmare difficulty should be same as Sewers Level 1 in Nightmare difficulty, that is level 43. And simple boolean InTown (or InField) condition that test character is in town like Rogue Encampment or in wild field. Ex)AreaLevel in 36-47, InTown, AreaName Den of EvilPlace of the item Condition where the item is placed in. One of Ground, (Equipped, Hiring), Inventory, Stash, Vendor.
Requirement condition A boolean condition that tests whether the character meets item use/equip requirements (like level, strength, dexterity, class and item durability /quantity > 0 etc, but regardless of unidentified item) and can be equipped or used or not. ex)
Usable <boolean>Special Token {Type}, {ItemLevel} Like named token {Price}, {Soket}, string value Type name {Type} and item level {ItemLevel} will be available in SetName or SetDescription
Debugging Provision
Debugging <boolean>condition: A condition that checks "/deugging" switch is set or not. And "/filterlevel 0" chat command to show all "hidden" items. All hidden item will be shown with special tag that denotes that the item will be hidden. Same as Show SetName {Name} {Gray}*{White} just before final Hide (all) at end of item filter file.Easier automatic filter reload As I suggested in previous issue (#22), there must be easier way to reload filter file other than current
"/reload"command. I suggest automatic reloading of filter file on start of new game session.line continuation in condition list As I suggested in previous issue (#30), condition list should be able to span multiple lines with trailing comma.
Condition Armor and Weapon is not so useful. It is hardly used in filter file and can be replaced with Class Any Armor and Class Weapon. Condition Hight and Width are too. I suggest to remove them. Add more useful Condition like (average) Damage sum (excluding DOT damage like poison ) My suggestion: Category {Weapon, Armor, Charm, Socketable (Rune, Gem, Jewel), and Consumable} Throwable Potions should be categorized as Consumable, not weapon, And Size condition that counts number of square it occupies.
Rarity Normal should not include items without any real rarity like potion and consumables. Rarity of Potion and others should be something like Misc or Consumable. Other than Weapons Armors and Jewel, Consumable and Throwable Potion, Rune, Gem should not be of Normal Rarity.
Keeping doing good work.