Skills.txt, for a long period of time (1.00 until 1.09) was a pretty small file with only a few things to alter (this was mainly limited to the animation used, the parameters passed to the skill and the damage done by the skill), the rest was completely hardcoded. How the skills themselves work is still hardcoded (the skill functions), but all other aspects of their behaviour can now be controlled via skills.txt, including which skills access which functions. The file is vast, by far the largest and most complex in Diablo II, it contains 256 columns, the maximum supported by M$ Excel. The purpose of this fileguide is not to provide a 100% accurate description of each column, as this is impossible (because how some columns are used depends foremost on the skill function accessing them!), it will also not deal with formulae, Xeno wrote a comprehensive guide about the formulae used by the D2 parsing engine, and there is no point repeating this here.
[align=center]GENERAL SKILL SETTINGS[/align]
skill: the ID pointer used to reference this skill within CharStats.txt, Missiles.txt and Monstats.txt, SkillDesc.txt, it is also used within Skills.txt itself. This ID pointer can also be used within AutoMagic, Gems, MagicPrefix, MagicSuffix, MonProp, QualityItems, Runes, SetItems, Sets and UniqueItems.txt, however the parsing mechanism used for those files is bugged, and skill names with a space will more often then not fail to work properly (just because Blizzard can do it that way doesn't mean we can!). I recommended to use the actual ID numbers rather then the ID pointer in those files. Warning Never use the same ID pointer twice, all skills but the first will be ignored if they have the same pointer!
Id: the actual ID number of the skill, this is what the pointer actually points at, this must be a unique number, the game supports 32767 skills, but you won't be able to use them in conjunction with items, unless you modify ItemStatCost.txt, encoded stats (chance to cast level xxx yyy on zzz, and charges) can only store IDs up to 1023, no matter what. Warning Some IDs are referenced by the code (such as aurae used by bosses), you should thus refrain from randomly moving skills around inside the file unless you know what you're doing.
charclass: to what character class is this skill assigned, this controls mainly from what DC6 icon library the skill icons are picked and by what bonus stat the skill is going to be effected (+to all Amazon skills etc). Warning All characters must have the same amount of skills assigned to them, otherwise only the class(es) with the highest amount of skills will be able to enter games (since the game is preparing the save file for each class for xxx skills, thus those with less then xxx skills will be treated as if their save files are corrupted. To solve this problem just add a number of dummy skills to that class (which will not appear on the skill tree or be useable in any way). Leaving this column blank means that the skill has not been assigned to any class.
skilldesc: ID pointer from SkillDesc.txt, this controls all the user interface related aspectes of the skill such as the skill icon used, the text displayed in the skill description and how/if the damage and attack rating is displayed on the character screen. Warning Never use two identical entries for the same skill if they are assigned to the same character class, unless of course you enjoy crashing.
[align=center]SERVER-SIDE SKILL FUNCTIONS[/align]
These functions where originally referenced by a hardcoded table during 1.00-1.09, as of 1.10 this function index has been softcoded and can now be modified by editing skills.txt, this is the heart and soul of a skill, almost everything that makes a skill differ from the others is controlled by the functions used. The functions control but are not limited to: whenever the skill can apply a state or not, whenever the calc columns are used, whenever a parameter is referenced by code directly, whenever, and how, a missile is launched and anything else you can think of.
srvstfunc: Server starting function, this controls the server side function executed when you rightclick or shift+leftclick somewhere while the skill is assigned to a button.
srvdofunc: Server finishing function, this controls the server side function executed when the starting function finishes executing, it might either be called repeatedly as long as the mouse button remains down, or it may be called periodically (for skills like paladin auras and blade shield).
prgstack: Boolean used by charge-up skills, true means the individual charges will stack (Fists of Fire, Claws of Thunder and Blades of Ice), false will make each new charge replace the previous one (Phoenix Strike etc). And indeed, you can make all three charges of Phoenix Strike occur at the same time by setting it to true
srvprgfunc1: Server side function to execute when releasing (using a finishing move) charge number 1.
srvprgfunc2: Server side function to execute when releasing (using a finishing move) charge number 2.
srvprgfunc3: Server side function to execute when releasing (using a finishing move) charge number 3.
prgcalc1: Calculation used by the server side function of charge number 1 (this column is also used by Shock Web and Blade Fury because the skill functions of those skills access it!).
prgcalc2: Calculation used by the server side function of charge number 2.
prgcalc3: Calculation used by the server side function of charge number 3.
prgdam: Related to the heavily hardcoded progressive stats. 1 is to be used in conjunction with PROGRESSIVE_DAMAGE, 2 is to be used in conjunction with PROGRESSIVE_STEAL, 3 is to be used with the unused PROGRESSIVE_OTHER stat and 4 is to be used with PROGRESSIVE_<elemental type> stats. I have yet to do research on this, but adding new progressive stats would involde expanding the list of functions linked to by this field!
[align=center]SERVER-SIDE MISSILE SETTINGS[/align]
These columns control the various aspects the missiles launched by this skill server side, that is, this is independant from what the player (client) sees on the screen, thus the client-side missile settings must match this to avoid weird behaviour and stupid questions from users. But you don't have to make the functions match, nothing will happen if they don't, the missile will just not appear, or appear the way it should, on screen.
srvmissile: Primary missile to launch when the server side starting function is executed. This is launched independant of the server side starting function involved (even when no function is execute at all: see fireball and firebolt for example).
decquant: A boolean that controls whenever this skill will decrease stack or ammunition each time the starting function is executed (this is disabled for strafe, enabling it will make strafe waste as many arrows as you fire).
lob: Another boolean, when enabled the missiles fire will be lobbed (tossed like a grenade). A lobbed missile will vanish (collide with the ground) at the location you clicked with the mouse. Warning A lobbed missile only 'appears' to fly in an arc, that is it will still damage everything it would damage if it wasen't lobbed, to make it behave properly the missile being lobbed must be modified (see Missiles.txt fileguide).
srvmissilea: First secondary server-side missile (how and if this is accessed depends on the server side functions used by the skill).
srvmissileb: Second secondary server-side missile (how and if this is accessed depends on the server side functions used by the skill).
srvmissilec: Third secondary server-side missile (how and if this is accessed depends on the server side functions used by the skill).
[align=center]SERVER CONTROLLED OVERLAYS[/align]
srvoverlay: Overlays are usually controlled by client-side code, however mission-critical overlays are handled by the server-side code. This usually applies to those overlays applied to a targeted units when the server-side finishing function executes. Mission critical overlays are those used by melee attacks, various monster buffs/curses and by Fist of the Heavens (the downward moving missile is actually an overlay). This is an ID pointer from Overlays.txt. Whenever this is used depends on the server-side finishing function used.
[align=center]AURA / CURSE / BUFF RELATED SETTINGS[/align]
These columns don't necessarily have to be used by an aura / curse / buff at all - for example, the game also uses these fields for skills that have some sort of search radius or an AoE.
aurafilter: This is a binary filter that controls what type of unit is effected by this skill, a discussion on how aurafilters work can be found here. Not all aura filters will work properly with all skills, it largely depends how the server side skill functions search for potential targets! This is used by most skills that search for targets.
Code: Select all
0001000010110000011 - inner sight, taunt 0001100010110000011 - slow missiles 0001010010110000011 - lightning fury, conviction, tornado 0001000011110000011 - static field 0000000000000000011 - amplify damage, weaken, iron maiden, life tap, decrepify, lower resist [work on bosses] 0000000000000000010 - dim vision, terror, confuse, attract, grim ward [don't work on bosses] 0010010000000000011 - might, prayer, resist fire, thorns, defiance, resist cold, blessed aim, cleansing, resist lightning, concentration, vigor, fanaticism, salvation, defense curse, blood mana 0001010011110000011 - holy fire, holy shock, hurricane 1001010001010000011 - holy freeze 0001110011110000110 - sanctuary 0001010010110000111 - fist of the heavens 0000001000100000010 - redemption 1100000000000000000 - battle cry 0001110000000000011 - cloak of shadows 0001000001110000011 - mind blast, blade shield 0001000011100001011 - blades of ice 0010000000100000011 - spirit of barbs aura, heart of wolverine aura, oak sage aura
auratargetstate: The state being applied to the reciever of the aura / buff / curse. This is an ID pointer from States.txt. Warning Never use the same state here as you can never know whenever two skills with the same state will be applied to the same unit, the game uses an index table to determine which state (and thus which stat changes) are currently active on the unit, a state currently present on a unit cannot be applied to it again while the first state is present, thus two skills using the same state will never be able to apply at the same time. This does not mean they will always prevent stacking, it means that you will experience the strangest of glitches.
auralencalc: This field can either contain a calculation or a static value, it controls how long (in frames) the effects of the aura / buff / curse will last. Real auras dont use this, because they are refreshed periodically.
aurarangecalc: This field can either contain a calculation or a static value, it controls the area of effect (in subtiles) in which the aura / buff / curse will effect other units. Some other types of skills also use this (such as Lightning Fury) to determine the search radius or damage radius of the missiles released by them.
aurastat1-6: The stats this aura / buff / curse can alter. It contains ID pointers from ItemStatCost.txt.
aurastatcalc1-6: The amount to add or subtract from the stat in question. This field is limited to values between -2147483647 and +2147483647. Higher or lower values will roll.
auraevent1-3: This field specifies what events the aura / curse / buff should react to when this event occurs to the caster (user) of the skill. This is an ID pointer from Events.txt.
auraeventfunc1-3: This field specifies the function to execute when the coresponding event occurs (like the above, this refers to the caster of the skill only). A list of event functions can be found here. Warning The majority of these functions will not work properly when called by a skill.
auratgtevent: Not used by vanilla. Warning I couldn't get this to work properly in my tests, but as far as I can say, this is the equivalent to the auraevent columns, but for the reciever of the aura.
auratgteventfunc: Not used by vanilla. Warning I couldn't get this to work properly in my tests, but as far as I can say, this is the equivalent to the auraeventfunc columns, but for the reciever of the aura.
[align=center]PASSIVE SKILL SETTINGS[/align]
Whenever a skill is a true passive or not depends whenever the Passive boolean is switched to true, otherwise the behaviour of these columns depends on the server side skill functions used, they might function as a secondary passive bonus granted by the skill, as an extension of the Aura / Curse / Buff columns or applied to a summoned creature.
passivestate: The state used by the game to assign the stats and events related things granted by this passive to the unit. This is an ID Pointer from States.txt. Warning You shouldn't use the same state on more then one skill if both skills are available to the same character or monster, the game uses an index table to determine which state (and thus which stat changes) are currently active on the unit, a state currently present on a unit cannot be applied to it again while the first state is present, thus two skills using the same state will never be able to apply at the same time. This does not mean they will always prevent stacking, it means that you will experience the strangest of glitches.
passiveitype: This field is used in conjunction with the passive stats used by weapon masteries, they contain an ID pointer to ItemTypes.txt which tells the game what item types will recieve a bonus from the coresponding passive stat. Warning This does not work with stats that aren't meant to be part of weapon masteries, forget about it, the only stats this works with are passive_weaponblock and passive_mastery_<type>_<stat>, period.. Weapon masteries are no hardcoded to the lines in Skills.txt, this has been a die hard rumor.
passivestat1-5: This field tells the game which stats are assigned by this passive skill. This contains an ID pointer from ItemStatCost.txt.
passivecalc1-5: This field can either contain a static value or a caltulation telling the game how much to add or subtract from the associated stat. This field is limited to values between -2147483647 and +2147483647. Higher or lower values will roll.
passivevent: Not used by vanilla. Warning I couldn't get this to work properly in my tests, but as far as I can say, this will control what event this passive will react to.
passiveeventfunc: Not used by vanilla. Warning I couldn't get this to work properly in my tests, but as far as I can say, this field controls what function to execute if the associated event occurs.
Special stats added to a summoned creature are either appended via MonEquip.txt, MonProp.txt or via the aurastat or passivestat columns.
summon: This field specifies what creature is summoned by this skill. This is an ID Pointer from MonStats.txt.
pettype: This controls what group the summoned creature is placed in. This controls what icon appears, whenever this summon can co-exist with other summons or not (such as there being only 1 golem, rather then one golem of each type), warping behaviour and more. This is an ID Pointer from PetTypes.txt.
petmax: This field can contain either a static value or a calculation which controlls how many summons of this group a player can have at a time. Leaving it blank means there is no limitation.
summode: The animation mode that the summoned creature will play when you summon it. Lets say you want to summon a Zombie, and it should look as if the Zombie crawls out of the soil, then you'd set this to S1 (the special animation of the Zombie). Usually you'd use NU (neutral) mode here, because most units won't have animations suitable for this.
sumskill1-5: These fields control the skills that are assigned to the summoned creature. This doesn't meant the summon will use these skills. This is mostly used to pass a synergy bonus to the summoned creature (such as additional damage for Hydra). Whenever a summon will actively use any of these skills depends on the AI used. You can forget using the Necropet AI, this AI is totally hardcoded and will not use these skills unless the code is modified. The best AI to use is the Shadowmaster AI, be aware that the skills that the summon should use must also be referenced in MonStats.txt. More on how to properly use the Shadowmaster AI can be found here.
sumsk1-5calc: These fields can contain either a static value or a calculation that tells the game what sLvl to assign to the coresponding skill assigned to the summoned creature.
sumumod: This field is pretty neat, it controls what boss modifiers to grant the summoned creature, this means you can make grant your summons properties like Lightning Enchanted or Aura Enchanted (random aura). This column contains ID numbers from MonUMod.txt. There is only one minor side effect, because the summoned creature doesn't have a special boss seed, the name that is displayed when you hover over it with Unsummon will be Mind Maw the Slasher.
sumoverlay: This field controls what graphical overlay to display when the creature is summoned (this overlay is applied to the summoned creature, not the caster). This is an ID Pointer from Overlays.txt.
[align=center]SOUND and OVERLAY SETTINGS[/align]
Quite obviously all columns ending with 'sound' are meant for ID pointers from
Sounds.txt whereas those ending with 'overlay' are meant for ID pointers from Overlays.txt.
stsuccessonly: A boolean that controls whenever the assigned sounds and overlays will keep playing even when the casting of the skill is interrupted by an attack landed on the caster. Correction by brappy
stsound: This field controls what sound will be played when the starting function of the skill executes, it will play irregardless of the character class using the skill.
stsoundclass: This field controls what sound will be played when the starting function of the skill executes, it will play only for the character class this skill is assigned to in the charclass column. This is useful for preventing grunts from one class to be played when another class uses it (this wasen't the case prior to 1.10, so if you gave Bash to lets say a Sorceress, she would play the Barbarian grunt wavs).
stsounddelay: Boolean of unknown functionality. Warning Again, I couldn't see a difference in-game while testing. But I believe this controls whenever the sound should start playing at the moment the starting function beings execution (false) or when the function finishes executing (true).
weaponsnd: This boolean controls whenever or not to play the sound associated with the weapon you have equipped when using this skill when the starting function executes.
dosound: This field controls which sound to play every time the finishing function executes (for a skill like Zeal this would mean every time your Paladin swings at an enemy).
dosound a: How this and the next field work is depending on which finishing functions are associated with the skill. It ranges from specific sounds to play after the attack, to the sounds associated with summoned creatures.
dosound b: How this and the previous field work is depending on which finishing functions are associated with the skill. It ranges from specific sounds to play after the attack, to the sounds associated with summoned creatures.
tgtoverlay: This field controls what overlay to associate with the unit targeted by the skill, this overlay is drawn once the finishing function executes. In the case of Zeal this would mean that the initial swipe will not draw an overlay over the monster you attack, but all following swipes will.
tgtsound: This field controls what sound to play (originating from the targeted unit) once the finishing function associated with the skill executes. In the case of Zeal this would mean that the initial swipe will not play a sound but all following swipes will.
prgoverlay: How this field is used depends on the skill functions associated with the skill. In the case of charge-up skills, this field contains the first overlay for the charge-up graphics group used by this skill. For other other skills like Hurricane it controls what overlay to display while the skill is active.
prgsound: Like the previous field, the way this field works varies with the functions used. It can contain the sounds to play for each charge-up or the sounds to play while a skill like Hurricane is active.
castoverlay: This field controls what overlay to associate with the unit using the skill. This overlay is drawn when the skill is successfully started (the starting function begins to execute - this does not mean the skill succeeds, it only means that the code for the skill starts executing).
cltoverlaya: Usually this will work like the previous field, but depending on the skill functions used (such as those of the Sorceress' cold armors) this can vary greatly.
cltoverlayb: Usually this will work like castoverlay, but depending on the skill functions used (such as those of the Sorceress' cold armors) this can vary greatly.
[align=center]CLIENT-SIDE SKILL FUNCTIONS[/align]
These functions where originally referenced by a hardcoded table during 1.00-1.09, as of 1.10 this function index has been softcoded and can now be modified by editing skills.txt. The client side functions handle how the skill will appear on the users screen, you should stick with the client/server function pairs Blizzard have used (the skill will otherwise do something completely different from what is shown on screen, which can lead to desync and possibly crashes if the client isn't updated properly in MP games), but feel free to experiment.
cltstfunc: Client starting function, This controls the client side function executed when you rightclick or shift+leftclick somewhere while the skill is assigned to a button.
cltdofunc: Client finishing function, this controls the client side function executed when the starting function finishes executing, it might either be called repeatedly as long as the mouse button remains down, or it may be called periodically (for skills like paladin auras and blade shield).
cltprgfunc1: Client side function to execute when releasing (using a finishing move) charge number 1.
cltprgfunc2: Client side function to execute when releasing (using a finishing move) charge number 2.
cltprgfunc3: Client side function to execute when releasing (using a finishing move) charge number 3.
[align=center]CLIENT-SIDE MISSILE SETTINGS[/align]
These columns control the various aspects the missiles launched by this skill client side, that is, this is independant from what the server-side code does, thus the server-side missile settings must match this to avoid weird behaviour and stupid questions from users. But you don't have to make the functions match, nothing will happen if they don't, the missile will just not appear, or appear the way it should, on screen.
cltmissile: Primary missile to launch when the client side starting function is executed. This is launched independant of the client side starting function involved (even when no function is execute at all: see fireball and firebolt for example).
cltmissilea: First secondary client-side missile (how and if this is accessed depends on the client side functions used by the skill).
cltmissileb: Second secondary client-side missile (how and if this is accessed depends on the client side functions used by the skill).
cltmissilec: Third secondary client-side missile (how and if this is accessed depends on the client side functions used by the skill).
cltmissiled: Fourth secondary client-side missile (how and if this is accessed depends on the client side functions used by the skill).
[align=center]CLIENT-SIDE SKILL CALCULATIONS[/align]
cltcalc1-3: These fields serve special purposes and are referenced by the client side skill functions, what they do depends entirely on the functions involved. You reference them inside other calculations if you wish or require additional space for a very long formula (but you should make sure the functions used don't actually access these fields first!). They can of course also contain a static value instead of a calculation.
[align=center]MISCELLANEOUS SETTINGS I[/align]
warp: A boolean of unknown function. Warning Set to true only for skills that shift you to another spot, but altering this seams to have no influence on the game at all. Maybe this has to do with MP games and synchronisation, leave it alone to stay on the safe side.
immediate: A boolean that controls whenever an aura will apply immediately after it is assigned to a mouse button or whenever to wait until the first predelay has elapsed. Usually those aurae that grant a bonus to the players stats will be set to true herein, while those that effect monsters (like Conviction) will be set to false.
enhanceable: A boolean of unknown function. Warning This is set to true only for skills that are always sLvl 1, nonetheless this doesn't influence if the skill gains any bonus from items, it seams to do nothing noteable (if it does anything at all).
attackrank: This field is related to how monsters react when the skill in question is used against them. Ever wondered why monsters don't attempt to retaliate if they are hit by a elemental damage aura, this field is what controls the retaliation behaviour. As a rule of thumb, the higher the more likely a monster will retaliate against the attack. 0 will make them ignore it (like they ignore elemental damage auras).
[align=center]EQUIPMENT RELATED USAGE RESTRICTIONS[/align]
noammo: This boolean controls whenever the player requires ammunition to use this skill. Use this, in conjunction with decquant to make other missile skills behave like Magic Arrow. Obviously setting this to true means no ammo is required .
range: This switch field can take one of four values. It controls how the player can launch this skill. First of all, none means it has no restrictions on it, and is a spell (like Fire Ball), rng means this skill is a ranged skill (Javelin skills, Bow/Crossbow skills), h2h means that this is a Hand to Hand combat skill (melee) (Bash, Sacrifice etc), both means that the skill can function as both h2h and rng (like Attack). Warning Setting a skill to h2h will not prevent the player from launching it from afar, he can always shift-click!
weapsel: This field controls how to access the gear necessary to use this skill. A blank value means it wont handle this skill in a special way (that is, it'll look for the weapon in the Right hand of the player). 1 in this field will make it look for a weapon in the Left hand of the player. 2 in this field means that it can either use the Right or the Left or Both weapons (used by Whirlwind). 3 in this field means that it will always use Both weapons and finally a value of 4 means that the game will not use a weapon, but a piece of armor. Be aware that code 4 is heavily hardcoded and will only work with those skill functions using it in vanilla!
itype1-3: The item type required to use this skill (needed to use this skill, this restriction is imposed on the players right hand). This is a ID pointer from ItemTypes.txt.
etype1-2: The item types this skill cannot be used with (even if they are included in the former fields! This restriction is imposed on the players right hand). This is a ID pointer from ItemTypes.txt. This is why you cannot use Attack with a throwing potion for example (you could before LoD).
itypeb1-3: The item type required to use this skill (needed to use this skill, this restriction is imposed on the players left hand). This is a ID pointer from ItemTypes.txt.
etypeb1-2: The item types this skill cannot be used with (even if they are included in the former fields! This restriction is imposed on the players left hand). This is a ID pointer from ItemTypes.txt. This is why you cannot use Attack with a throwing potion for example (you could before LoD).
anim: The animation mode that the game plays when the player uses this skill. The list of animation modes for players can be found within PlrMode.txt. Setting this to mode SQ will make the player use the associated sequence instead. This also controls whenever the skill is effected by FCR or IAS! In case of a sequence it depends on what animations are used by the sequence. Warning Certain modes (like GH) will crash the game as they aren't meant to be used by skills.
seqtrans: This field apparently doesn't do anything, it probably was meant to control animation mode played before starting the sequence, but is obviously not used (it never was, not even in 1.00 IIRC).
monanim: Monsters always use the skill mode that you assign in MonStats.txt. The only units that access this field are Shadow Masters and Shadow Warriors, because they use Assassin animations. A list of modes can be found within PlrMode.txt for these two summons. If a value of xx is supplied the Shadow's will look for the sequence assigned inside MonStats.txt this workaround was put there by Blizzard because monsters are unable to use Player sequences. New wording in part on a suggestion by Myhrginoc.
seqnum: This field contains the ID of the player-animation-sequence to play when this skill is used in case the anim column is set to use mode SQ. Unlike monster sequences, player sequences are unfortunately still hardcoded in a table within D2Common.dll. Below is a list of sequences (the proper characters are needed for each sequence, but some work on more then one class).
Code: Select all
0 = no sequence (if you use this you'll see half of a casting anim, and then an assertion error) 1 = used by Jab 2 = messed up sequence originally used by Sacrifice (flashes on some weapons) 3 = unused sequence (uses casting anim) 4 = used by Charge 5 = unused sequence (from the times conviction wasen't an aura, the sequence still works on a pally with a sword) 6 = used by Inferno 7 = unused sequence (uses casting anim) 8 = used by Impale 9 = messed up sequence originally used by Fend (doesn't work properly) 10 = used by Whirlwind 11 = used by Double Swing 12 = similar to 6, used by Lightning skills 13 = used by Leap 14 = used by Leap Attack 15 = used by Double Throw 16 = used by Double-Claw attacks 17 = unused Assassin? sequence 18 = used by Arctic Blast 19 = unused sequence originally used by Dragon Talon 20 = unused Assassin? sequence 21 = used by Dragon Flight 22 = unused sequence originally used by Were-transform skills 23 = used by Blade Fury Sequences >24 but exist in the DLL (the highest confirmed one is 41, but there are likely more).
durability: A boolean of unknown function. Warning This doesn't have anything to do with skills that can reduce durability. It's apparently related to skills that use sequences however. No idea what it does, follow the Blizzard approach and just use it with those skill functions they use it with to be safe of unexpected side effects.
UseAttackRate: A boolean of unknown function. Warning This is not related to Attack Rating if you wonder. The name suggests that it is related to Attack Rate however (which is the stat increased by IAS) however it seams to have no influence whatsoever in game, most likely a deprecated leftover from alpha D2 times.
While these columns all look straitforward, they usually aren't. What and whenever a skill can target something depends foremost on the skill functions involved, these columns are just a second layer of minor importance, unfortunately.
LineOfSight: This field seams to be a binary flag switch, but only one flag is used by the game, which is 4 (100). It controls whenever or not the skill takes into account the players Line of Sight. That is, if this is set to 4 you cannot cast the skill through walls, but if it is left blank you can. This is easy to test with summoning skills. If for example you'd set this to 0 on a skill like Valkyrie you can summon a valk in a different room, without ever opening the door.
TargetableOnly: A boolean of unknown function. Warning It doesnt do what the name suggests anyhow. Frankly enough it doesn't seam to do anything.
SearchEnemyXY: A boolean of unknown function. Warning This usually comes in conjunction with the previous field, likewise it doesnt seam to do anything (noteable at least).
SearchEnemyNear: A boolean that controls whenever the skill will [strike]make other people call you a noob in MP games[/strike], I mean whenever it should automatically pick its own targets (this works best with the left button (combined with shift obviously - it doesn't need to be an enemy, it can also be a corpse for skills that target corpses), heck the character will even pursues monsters on his own as long as the button is held down!). This worked on all skills I tested it on. Don't abuse this field, it will make D2 even easier then it is, as you won't even need to target anything, just hold the button...
SearchOpenXY: When set to true, this boolean will make the skill look for an unoccupied subtile (apparently depending on the size settings of the controllermissile created by the skill) as the target for the skill (this is used by skills like Fire Wall, Meteor and Blizzard which create a invisible controller missile), it makes sense because no two units (and missiles ARE units) can occupy the same subtile, so if Fire Wall or a similar skill was to spawn in an occupied subtile the game would either crash OR the skill would never show any effect since the missile is destroyed before it triggers. If no free subtile is found in proximity to the target of the skill, the execution of the skill will fail. Confirmed by Brother Laz.
SelectProc: This field is always to be used in conjunction with the following field. It controls which corpses you can target and has 6 different filter lists. 1 is used by the variants of Corpse Explosion, 2 is used by Raise Skeleton and Raise Skeletal Mage, 3 is used by Revive, 4 is used by Find Potion, 5 is used by Find Item and 6 is used by Grim Ward. I haven't tested if this works on living monsters (such as making a skill that cannot target bosses). Warning This does not control whenever a skill can actually be used on the targeted corpses (you cannot make Revive work on boss-corpses etc), but you will be able to highlight them. Not very useful...
TargetCorpse: This boolean controls whenever the skill can be cast on a corpse (it doesn't control whenever the corpse can be selected, it only controls if the skill is cast on the corpse AFTER it is selected, whenever or not it can select the corpse depends on the skill functions and filter list used).
TargetPet: This boolean controls whenever the skill can be cast on a summon or hireling (it doesn't control whenever the summon or hireling can be selected, it only controls if the skill is cast on the summon or hireling AFTER it is selected, whenever or not it can select the summons or hirelings depends on the skill functions used).
TargetAlly: This boolean controls whenever the skill can be cast on a other players (it doesn't control whenever the another player can be selected, it only controls if the skill is cast on another player AFTER it is selected, whenever or not it can select another player depends on the skill functions used).
TargetItem: This boolean controls whenever the skill can be cast on items lying on the ground (it doesn't control whenever the item can be selected, it only controls if the skill is cast on the item AFTER it is selected, whenever or not it can select an item depends on the skill functions used).
TgtPlaceCheck: This boolean is only used by monster resurrection spells. Setting it to false will break those skills (Resurrect and Resurrect2), I don't know what it does other then enabling those skill functions though.
[align=center]MISCELLANEOUS SETTINGS II[/align]
AttackNoMana: A boolean that controls whenever or not the player should perform a regular attack in-case he runs out of mana while using this skill. Correction by Nameless.
[align=center]ITEM-EVENT RELATED SKILL SETTINGS[/align]
These columns only influence the behaviour and looks of a skill when it is launched by a Chance-To-Cast event function, they don't effect the skills normal behaviour. I didn't test most of these because I have no idea how exactly I should see the differences as they appear to be minimal, so they are listed as unknown or unclear with my best guess appended.
ItemEffect: Server-side launcher function. This field controls what function is called when this skill is launched by a chance-to-cast modifier. Leaving it blank means no function is called, and the skill isn't cast. You would usually use function 1. But there are at least two others (36 and 151). Function 36 will fire the skill from the target rather then the wielder of the item. Additional info supplied by Brother Laz
ItemCltEffect: Client-side launcher function. This is only required if an abnormal launcher function is used in the previous field. Blizzard uses 10 and 96 as equivalents to server-functions 36 and 151.
ItemTarget: A switch of unclear functionality. Warning This seams to be another one of those targeting filters. By default this is blank (0), but for some skills special targeting functions are used. 1 is used by Enchant (which can also be cast on nearby allies), 2 is used by Teleport (which picks a random empty subtile), 3 is used by the corpse explosion variants and probably selects a random corpse and 4 is used by homing missiles (Bone Spirit) and Fist of the Heavens (skills that need an absolute target).
ItemCheckStart: A boolean of unknown function. Warning I assume that this is used to prevent collisions between the Hydra and Bone Prison who have this switched to true and occupied subtiles before the starting function is execute.
ItemCltCheckStart: A boolean of unknown function. Warning This seams to serve a similar purpose to the one assumed for the previous field, seams to tell the game to check if the server-side starting function has executed successfully before calling the client function (used by Corpse Explosion skills, probably to prevent the gore-graphic from showing up even if the skill fails).
ItemCastSound: This controls the sound that is played instead of the regular sound when the skill is launched by an Item Event. This is a ID pointer from Sounds.txt.
ItemCastOverlay: This controls the casting overlay displayed instead of the regular overlay when this skill is launched by an Item Event. This is a ID pointer from Overlays.txt.
[align=center]POINT PLACEMENT and PRE-REQUIREMENT SETTINGS[/align]
skpoints: This field can contain either a static value or a calculation. This controls how many skill points are necessary in order to boost this skill by 1 sLvl.
reqlevel: The minimum character level required in order to put a point in this skill. To remove the hardcoded level requirement from OSkills you can set this to -6.
maxlvl: The maximum sLvl this skill can achieve. Warning The actual absolute maximum skill level is controlled by the MaxLevel row in Experience.txt and is thus always equal to the maximum cLvl of the class using the skill.
reqstr: How much strength the player requires in order to put a point in this skill (first point only). This is functional as it was always, but it isn't displayed on screen.
reqdex: How much dexterity the player requires in order to put a point in this skill (first point only). This is functional as it was always, but it isn't displayed on screen.
reqint: How much energy the player requires in order to put a point in this skill (first point only). This is functional as it was always, but it isn't displayed on screen.
reqvit: How much vitality the player requires in order to put a point in this skill (first point only). This is functional as it was always, but it isn't displayed on screen.
reqskill1-3: These fields contain the ID Pointers (name column) of the other skills you need in order to put your first point in this skill (aka simply the prerequired skills).
[align=center]STATE RELATED RESTRICTIONS[/align]
restrict: This switch field controls under what state (shape in case of a druid) this skill can be used. 0 means that it can only be used while in Human form, 1 means that it can be used both under shifted and under Human form and 2 means that it can only be used when in one of the states defined in the three following columns.
state1-3: This field controls which states this skill is restricted to, in the case restrict is set to 2. This is an ID pointer from States.txt.
[align=center]SKILL DELAY SETTINGS[/align]
delay: This field can contain either a static value or a calculation. This controls how many frames the skilldelay state will be applied to the character after using this skill. Among others this also controls which skills will be disable while that state is active. Any skill with a value greater then 0 in this column will be disabled while under the influence of the skilldelay state. When the skill delay is applied depends on the skill used, usually they initialize once the trigger frame of the animation has triggered an event. The delay counter will be reset should the execution of the skill be interrupted by an attack.
[align=center]MISCELLANEOUS SETTINGS III[/align]
leftskill: A boolean that controls whenever or not you can use this skill will appear on the list of skills you can assign to the left mouse button. Warning A bunch of skills (especially all auras) cannot be used on the left mouse button, no matter what you set this to, this is caused by engine limitations, forget about it. You shouldn't put things like curses, summoning and the like in here, it only serves to causes gameplay related annoyance.
repeat: A boolean of unclear functionality. Warning This boolean is used in conjunction with skills that keep repeating their finishing function for as long as you keep the button pressed (Inferno, Arctic Blast, Blade Fury), however unchecking it doesn't have any influence on the game, the skills work like they did before, so I'm a bit puzzled regarding the real purpose of this field. Set it to true on clones of those three skills, to prevent possible problems.
checkfunc: This field contains a reference to a slot in a function table of a special function to call, but the purpose is still unknown. Warning This appears to be a sort of callback function to execute once the main skill functions finish executing. The game uses function 1 for all skills that can use up ammunition (arrows, bolts), 2 is used for throwing (but not the Amazons javelin skills!), 3 is used for Left Hand Throw, 4 is used for Left Hand Swing, 5 is used for the scroll and book skills (these aren't skills at all, what they do is controlled solely by the functions assigned in misc.txt and books.txt) and 6 is used by Double Throw. These are most likely related to updating quantity data in multiplayer games from the looks of this.
[align=center]MANA COST SETTINGS[/align]
The following fields control the mana cost of the skill, and how the mana cost is to be applied. In order to not over-complicate the explanations below, here is a formula to calculate mana cost (replace the column names with the values you've put in those columns in Skills.txt, obviously).
manacost = max((mana+lvlmana*(sLvl-1))*(manashift/8),minmana);
nocostinstate: A boolean related to the other state-restriction related columns found earlier in the file. This controls whenever or not the skill will require no mana while the player is transformed (shape shifted), this is used to make Werebear and Werewolf cost no mana when the Druid is shape shifted, so he can return to human form without any mana cost.
usemanaondo: A boolean that controls when the mana pool is diminished, I can't properly explain this but the following example will demonstrate how it works, this field is usually not noteable, but if you set this to true on a skill like Inferno you will only loose mana once you let the button go (even if you cast the Inferno for a whole hour, day, month or year), but once you let the button go and the game finishes executing the functions you get the whole mana cost thrown at you. Warning This doesn't always work, sometimes you will not loose any mana, even after you let go of the mouse button, so don't overuse this.
startmana: The minimum amount of mana required to cast this skill. This does not control how much mana the skill uses, but the icon will remain red as long as mana is below this. For example Inferno is not castable by a Sorceress who only has 5 mana. This can be quite nasty, see it as if it was called ReqMana.
minmana: The mana cost for this skill will never fall below this minimum value. This functions like max(minmana,manacost);, this is useful for skills with decreasing mana cost per sLvl while preventing them from dropping too low.
manashift: This field controls the precision of the mana cost. Mana Cost is handled in 256ths for extra precision (mana is handled in 256ths by code). Internally this is simply a bitwise shift, but for not making this too complicated see the table below for multiplies and some other values that will aid you in understanding how it works. The mana cost in the example is 1000. To get the proper mana cost just multiply it by the multiplier I've listed below.
Code: Select all
manashift precision multiplier percentage example mana cost (skills.txt = 1000) ------------------------------------------------------------------- 0 1/256 = 0.00390625 ( 0.390625%) 3.90625 1 2/256 = 0.00781250 ( 0.781250%) 7.8125 2 4/256 = 0.01562500 ( 1.562500%) 15.5625 3 8/256 = 0.03125000 ( 3.125000%) 31.25 4 16/256 = 0.06250000 ( 6.250000%) 62.5 5 32/256 = 0.12500000 ( 12.500000%) 120 6 64/256 = 0.25000000 ( 25.000000%) 250 7 128/256 = 0.50000000 ( 50.000000%) 500 8 256/256 = 1.00000000 (100.000000%) 1000 9 512/256 = 2.00000000 (200.000000%) 2000 (etc)
lvlmana: The additional mana cost added to the base mana cost with every additional sLvl.
THE REST OF THE FILEGUIDE IS A FEW POST FURTHER SOUTH