VTClassic Advanced Tips

From VirindiPlugins
Revision as of 21:17, 23 August 2010 by Darktorizo (talk | contribs)
Jump to: navigation, search

Loot profile optimization

If you are running VTClassic in version 1.0.0.7 or higher, you can make optimized profiles which reduce the number of IDs required to come to a looting decision, which can speed up the total time invested in looting a lot. In this guide I will explain what you need to do to optimize your profile and at the same time show you some more advanced rules.

First you should open the latest editor, which since version 1.0.0.5 is part of the VTClassic loot plugin. Go to the folder you installed VTClassic to and start ""uTank2 Settings Editor.exe"". Open a profile or create a new one and add some rules. You will notice that in the right half of the editor some text is red rather than the usual black. Requirements that are written in red usually require an ID. There are two exceptions to this, ""SpellNameMatch"" and "SpellCountGE"", which both do not require an ID if the item is not magical at all.

To optimize your profile, you should have as many black requirements as possible per rule and ideally no red ones. This is not always easy, but it can be achieved and the improved speed while looting is worth the effort.

If you loaded an existing (not optimized) profile you will probably see that one or more rules in the list on the left side of the editor have a red background. This will happen whenever a rule consists of red requirements only. As long as you have one rule like that in your profile, VTClassic is forced to ID every item, so the goal in profile optimization is to have no rule with red background in the listing on the left side.

Workmanship

If you spent some time looking at all the values an item can have, you probably have noticed that there are two keys that contain information about the workmanship, LongValueKey Workmanship and DoubleValueKey SalvageWorkmanship. For anything except salvage bags these two values will always be the same, but only the DoubleValueKey SalvageWorkmanship is available without an ID, so you should always use that.

Salvage

MaterialId, SalvageWorkmanship and Value are all black requirements, available without ID data for the item, so no matter if you loot salvage to use it in tinkering or to sell it, there is no reason to have any red requirements in rules with loot action "salvage".

Salvage Material IDs

Looting rares - the optimized way

One thing that probably everyone wants to loot is rare items. Most people probably have a rule with one requirement for that: "LongValueKeyGE RareId >= 1". If you look at that rule in the editor, you will see that RareId is a property that requires the plugin to ID the item first. But fortunately there is a workaround for this. Rare items share a common background for their icon and VTClassic can check for that without ID data. So if you want to loot rares, make a rule with two requirements: "LongValueKeyLE IconUnderlay <= 23308" and "LongValueKeyGE IconUnderlay >= 23308".

In the new version (1.0.1.0) of VTClassic Looter options were added so you can now replace the two requirements ("LongValueKeyLE IconUnderlay <= 23308" and "LongValueKeyGE IconUnderlay >= 23308") with a single requirement: "LongValueKeyEE IconUnderlay == 23308"

Armor set pieces

Another thing many people want to loot are pieces of armor sets. Just like RareId, ArmorSetId requires an ID of the item. But we can still optimize our rules a bit. First, set pieces are always armor or clothing (which, from a technical point of view includes not only underwear, but some head-, hand- and footwear). So instead of one rule with a single requirement "LongValueKeyGE ArmorSetId >= 1" we can make 2 rules with that requirement and give each rule a requirement on "ObjectClass", one for Armor and one for Clothing. Unless you are really desperate for set items, you might want to add some more requirements to each rule, for example on SalvageWorkmanship, Value and ArmorLevel.

Also, "LongValueKeyEE ArmorSetId == X" can be used to loot specific Sets. See the Armor Set IDs section for ID numbers.

Armor Set IDs

No covenant please

If you have rules for armor, you probably don't want your rules for plate, celdon, etc to pick up covenant as well, as a al300 (plate) helmet is good, a non-magical al300 covenant helmet is not. You can easily achieve that and make your profile more optimized at the same time by adding a "String Value Match Name" requirement to your armor rule(s), using "^((?!Covenant).)*$" as value for the requirement.

Splitting up rules to reduce IDs

Many people use a single rule to pick up items with cantrips (epics, majors) or level 8 spells, using a single "Spell Name Match" requirement. Of course this works well, but the rule will lead to a lot of IDs and some of the picked up items will probably be considered unuseable. In this case it makes sense to split up the one rule and make more specific rules for armor, clothing with al, clothing without al and jewelry. In each rule we add the desired "Spell Name Match" requirement and an ObjectClass requirement. For armor and clothing with AL there surely is a minimum acceptable ArmorLevel, maybe a maximum Value and a maximum SalvageWorkmanship. For clothing with al we should add a "String Value Match Name" requirement, eg "Bandana|Beret|Fez|Turban|Gloves|Loafers|Sandals|Shoes|Slippers", for clothing without al (in other words: underwear) we also should have a requirement for the name to filter out items that can not possibly be part of a full coverage underwear set: "Smock|Shirt|Viamontian Pants".

There are other scenarios were splitting up one rule into several can lead to a better optimization. As a rule of thumb, if you can add a black requirement to one or all rules after splitting up that you could not use on the combined rule, you should split up the rule.

Color requirements

Each type of armor has specific slots for each color that can appear on it. For instance, for amuli leggings, the 'leg' color is slots 0 and 1 and the 'trim' color is slots 2 and 3. For an amuli coat, slot 0 would instead be the color of the BP part.

So, if you create a rule that just specifies slot 0 is red, it will match amuli leggings with red legs and amuli coats with red BPs, and all kinds of other stuff.

What you need to do is have other requirements that confine the armor type, and then also a color requirement. So you might have something like this:

Requirements:

  • Name matches: Amuli Coat
  • Slot 0: Color Red, 10, 0.1 (a Slot Similar Color req)

That would give you amuli coats with red BPs.

Now, the Armor Type Similar Color reqtype is exactly the same as Slot Similar Color, except that it has presets builtin for which slots to look for based on the armor type you choose. So you could go:

Requirements:

  • Name matches: Amuli Coat
  • Amuli Coat (Chest): Color Red, 10, 0.1 (an Armor Type Similar Color req)

...and it would be exactly equivalent to the above rule.

So for armor types that are not listed under the Armor Type Similar Color reqtype, you can do /vt testitem on some armor of that type and figure out based on the slot colors which slot it is you are looking for, then make a Slot Similar Color requirement based on that slot.

Aetheria

Long Value Key == <Property><#>

Type = Color of Aetheria

  • 42635 = Blue
  • 42637 = Yellow
  • 42636 = Red

(Could also be done with Long Value Key == WieldReqValue <75, 150, or 225>)

IconOverlay = Level

  • 27700 = 1
  • 27701 = 2
  • 27702 = 3
  • 27703 = 4


(Many thanks to Ioconnor for helping with these numbers)


Sample files