New pickit property skin

[ryancrunchi]

• Prototype.js, NTItemAlias.dbl, NTItemParser.dbl

  • Added new property keyword Skin for pickit to filter rings, amulets, jewels and charms skin.

• GameAction.js, MuleLogger.js, Misc.js

  • Refactored getting the skin value of item with property skinCode in Unit prototype.

Possible skin values are based on these :

• Rings :

  • coral or chain
  • smallblue or sloop
  • bigblue or bband
  • orangestone or orangering
  • crown or eturn

• Amulets :

  • dot or cross
  • sun
  • penta or star

• Jewels :

  • pink
  • blue
  • orange or peach
  • green
  • red
  • white

• Small charms :

  • brown or football
  • bear or bearfoot or bearclaw
  • m or coin

• Large charms :

  • paw or paper
  • horn
  • tower or obelisk

• Grand charms :

  • eye
  • dna or lace or spaghetti
  • dragon or monster

• Usage :
  You can specify the skin without item to be identified. This means that the skin property goes the same way as type, name or quality.
  In your pickit :

// keep any unique rings unid with coral skin
[type] == ring && [quality] == unique && [skin] == coral
// or even shorter, as the skin is related to the item type. Only rings can have coral skin.
[quality] == unique && [skin] == coral

// keep any mara with dot skin
[type] == amulet && [quality] == unique && [skin] == dot # [strength] == 5 && [ColdResist] >= 20

// keep perf light rbf white
[type] == jewel && [quality] == unique && [skin] == white # [PassiveLtngMastery]+[PassiveLtngPierce] == 10

• Caution :
  If by mistake you specify a skin that does not exist for the item type, this item will NOT be kept.
  For example
  [type] == ring && [quality] == unique && [skin] == orange # [ItemAllSkills] > 0
  It will NOT take any soj or bk because orange skin does not exist for rings.

[imbalanced]

This is the common names I've seen being used. You may want to refer to this for alias as well.

[imbalanced]

Capitalized aliases are unnecessary as they are lower cased in the parser anyways.

[imbalanced]

Capitalized aliases are unnecessary as they are lower cased in the parser anyways.

[noah-]

can you change skinCode to getSkinCode()
it should not be a value that can be set

[ryancrunchi]

Defining a property with a get only function avoid this property to be writable.
If you try to do so, you will get an error like Uncaught TypeError: Cannot set property skinCode of #<Unit> which has only a getter.

[noah-]

Sure, but that is at runtime - changing it to a get function makes it’s clear statically that it is not a property of the object, and follows convention with getColor.

[noah-]

change to getSkinCode() to match existing kolbot convention (eg getColor)

[jaenster]

Sure, but that is at runtime - changing it to a get function makes it’s clear statically that it is not a property of the object, and follows convention with getColor.

I understand what your saying, but there are loads of these kinds of "calculated" values in kolton and d2bs already.

Stuff that isnt settable, but retrievable as an variable on the unit object, like: idle, gold,dead,inTown,attacking,parentName, dexreq, strreq and itemclass. And those build-in d2bs variables on units, like classid, type, mode, name, act gid, x ,y, hp , hpmax, mp ,mpmax , stamina, staminamax, charlvl, itemcount, owner, ownertype, uniqueid, code, prefixes,suffixes,prefixnum,suffixnum, fname, quality, node, locations, sizex,sizey, itemtype, description, bodylocation, ilvl, lvlreq and gfx

Those are all already on the item unit, why can't skinCode be one of them?

skinCode seems to make sense to be also one of these variables.

[noah-]

Sure, but that is at runtime - changing it to a get function makes it’s clear statically that it is not a property of the object, and follows convention with getColor.

I understand what your saying, but there are loads of these kinds of "calculated" values in kolton and d2bs already.

Stuff that isnt settable, but retrievable as an variable on the unit object, like: idle, gold,dead,inTown,attacking,parentName, dexreq, strreq and itemclass. And those build-in d2bs variables on units, like classid, type, mode, name, act gid, x ,y, hp , hpmax, mp ,mpmax , stamina, staminamax, charlvl, itemcount, owner, ownertype, uniqueid, code, prefixes,suffixes,prefixnum,suffixnum, fname, quality, node, locations, sizex,sizey, itemtype, description, bodylocation, ilvl, lvlreq and gfx

Those are all already on the item unit, why can't skinCode be one of them?

skinCode seems to make sense to be also one of these variables.

The main difference is those are done by d2bs or are extremely trivial, this is a change in kolbot so it should follow kolbot convention for similar functions (like getColor).