Category Module Manager.html
Introduction
This page is for how modules interact with the server. It is not about creating new modules/items, though it may help depending on how creative at coding you are.
Luck and I brainstormed for quite a while on this redesign of the ModuleManager and its associated classes. This article contains conversations I've had with Luck on the subject for some deep background on this topic.
The Module Manager is probably the most important aspect of the entire EVE game since it is what makes ships useful to do things such as combat, support, transportation, and mining. Without the ability to fit modules to a ship and have them do things, the game is pretty much useless. The Module Manager has many classes contained inside and are used for a great many things, so we will begin with a few critical classes and drill deeper as we go.
Notable sections to take a look at in this large article are the Important Classes section describing each of the Module Manager's critical classes and the Connecting the Missing Links section describing how we connect Module Effects to the attributes on the module used to modify ship/charge/target attributes and how we connect Ship/Implant/Skill bonus modifiers to item attributes used to modify ship/charge/module/target attributes.
Important Classes
- Module Manager - the heart of it all: its methods are called by the Ship class and owns and maintains all banks of modules installed on a ship
- Module Container - a container class containing separate container structures for each module bank, rig bank, and subsystem bank on a single ship
- Modifier -
- ModifierMap -
- MEffect -
- DGM_Effects_Table -
- ModuleEffects -
- GenericModule -
- Module Classes -
- Module Components -
Module Manager
TBD
Effect and Bonus Modifier Calculation Types
NOTE: THIS TABLE DATA WAS PULLED FROM THE EVEHQ APPLICATION SOURCE CODE EveHQ.HQF\Classes\Fitting.vb SOURCE FILE. SEE THAT FILE FOR THE SOURCE OF THE TABLE SHOWN HERE
| Calculation Name | Enum Name | Enum Code | Description |
|---|---|---|---|
| ? | ? | ? | ? |
NOTE: THIS TABLE IS BEING DEPRECATED IN FAVOR OF THE CALCULATION TYPES, FORMULAS, AND CODES PULLED FROM THE EVEHQ APPLICATION FOUND IN THAT PROJECT'S EveHQ.HQF\Classes\Fitting.vb FILE. SEE THAT FILE FOR THE SOURCE OF THE TABLE ABOVE.
| DEPRECATED | Calculation Name | Enum Name | Enum Code | Description |
|---|---|---|---|---|
| DEPRECATED | NONE | CALC_NONE | 2000 | This is the default NONE calculation, only use this for effects that require NO calculation to modify any attributes. |
| DEPRECATED | AUTO | CALC_AUTO | 2001 | This is the code used to direct the Effects Processor to pick the calculation formula automatically, also DO NOT USE THIS! |
| DEPRECATED | Add | CALC_ADD | 2002 | Add two values |
| DEPRECATED | Subtract | CALC_SUBTRACT | 2003 | Subtract second value from the first |
| DEPRECATED | Divide | CALC_DIVIDE | 2004 | Divide the first value by the second value |
| DEPRECATED | Multiply | CALC_MULTIPLY | 2005 | Multiply first value with the second value |
| DEPRECATED | Add Percent | CALC_ADD_PERCENT | 2006 | (val1 + (val1 * val2)) |
| DEPRECATED | Reverse Add Percent | CALC_REV_ADD_PERCENT | 2007 | (val1 / (val3 + val2)) |
| DEPRECATED | Subtract Percent | CALC_SUBTRACT_PERCENT | 2008 | (val1 - (val1 * val2)) |
| DEPRECATED | Reverse Subtract Percent | CALC_REV_SUBTRACT_PERCENT | 2009 | (val1 / (1 - val2)) |
| DEPRECATED | Add As Percent | CALC_ADD_AS_PERCENT | 2010 | (val1 + (val1 * (val2 / 100))) |
| DEPRECATED | Subtract As Percent | CALC_SUBTRACT_AS_PERCENT | 2011 | (val1 / (1 + (val2 / 100))) |
| DEPRECATED | Modify Percent With Percent | CALC_MODIFY_PERCENT_W_PERCENT | 2012 | (val1 * (1 + (val2 / 100))) - same as Add As Percent |
| DEPRECATED | Reverse Modify Percent With Percent | CALC_REV_MODIFY_PERCENT_W_PERCENT | 2013 | (100 * ((val1 / val2) - 1)) |
| DEPRECATED | Special Handling for Microwarpdrives and Afterburners | CALC_MWD_AB_EQUATION | 2014 | See see Ship Combat -> Space Operations for details on this equation, since it will be implemented in the module class for groupID 46 |
| DEPRECATED | Special Handling for Electronic Countermeasure modules | CALC_ECM_JAM_EQUATION | 2015 | See Electronic Countermeasures for details on this equation, since it will be implemented in the module class for groupID 201 |
| DEPRECATED | Reduce By Percent | CALC_REDUCE_BY_PERCENT | 2016 | (val1 * (1 - (val2 / 100)) |
| DEPRECATED | Reverse Reduce By Percent | CALC_REV_REDUCE_BY_PERCENT | 2017 | (val1 / (1 - (val2 / 100)) |
Module States
Each Module has a number of states that it moves through and operates in while it is fitted to a ship and the pilot is doing things with the ship. Most modules will either be in the Online state or Offline state, but many will enter into the Active state and even the Overload state. Some modules take charges into them that are either consumed or launched into the environment and those have additional states related to the loading and unloading of those charges. The first table below shows the entire list of module states allowed and what each one means. The second table shows each allowed module state transition, such as Offline to Online. An example of a state transition that would not be allowed would be Offline to Active, because every module MUST go through the Online state before entering the Active state.
USED IN - dgmEffectsActions table - effectAppliedInState field
| State Name | Enum Code | Enum Name | Description |
|---|---|---|---|
| Unfitted | 1100 | MOD_UNFITTED | ? - not sure if we'll even use this state |
| Offline | 1101 | MOD_OFFLINE | ? |
| Online | 1102 | MOD_ONLINE | ? |
| Activated | 1103 | MOD_ACTIVATED | ? |
| Overloaded | 1104 | MOD_OVERLOADED | ? |
| Deactivating | 1105 | MOD_DEACTIVATING | ? |
| Current State | Next State |
|---|---|
| Unfitted | Offline |
| Offline | Online |
| Online | Activated |
| Online | Overloaded |
| Activated | Deactivating |
| Overloaded | Deactivating |
| Deactivating | Online |
| Online | Offline |
| Offline | Unfitted |
Charge States
Each module that can take charges will also have a Charge State associated with it. Actually, all module classes that inherit from the GenericModule class will have a private varible for Module State AND one for Charge State, but many modules will not make use of the Charge State simply because they do not take charges. The allowed Charge States and Charge State transitions are shown in the two tables below, respectively.
USED IN - TBD
| State Name | Enum Code | Enum Name | Description |
|---|---|---|---|
| Unloaded | 1200 | MOD_UNLOADED | ? |
| Loading | 1201 | MOD_LOADING | ? |
| Reloading | 1202 | MOD_RELOADING | ? |
| Loaded | 1203 | MOD_LOADED | ? |
| Current State | Next State |
|---|---|
| Unloaded | Loading |
| Loading | Loaded |
| Unloaded | Reloading |
| Reloading | Loaded |
Module Effect Applied Behaviors
NOTE: THIS FIELD IS DEPRECATED SINCE EVEHQ STATE CODES REPRESENT SINGLE BIT POSITIONS IN A BINARY NUMBER SO THAT A SINGLE STATE CODE FOR AN EFFECT CAN REPRESENT MORE THAN ONE STATE
USED IN - dgmEffectsInfo table - effectAppliedBehavior field
| Effect Behavior Name | Enum Code | Enum Name | Description |
|---|---|---|---|
| Effect Persistent | 1300 | EFFECT_PERSISTENT | means the effect is active AT ALL TIMES; used ONLY for skill, ship, subsystem effects |
| Effect Online | 1301 | EFFECT_ONLINE | means the effect takes effect on the target (see below) upon entering the ONLINE state |
| Effect Active | 1302 | EFFECT_ACTIVE | used only for ACTIVE modules operating in non-Overloaded mode |
| Effect Overload | 1303 | EFFECT_OVERLOAD | used only for ACTIVE modules operating in Overloaded mode |
Module Target Equipment Types
TODO
USED IN - dgmEffectsInfo table - targetEquipmentType field
ALSO SPECIFY target equipment groupIDs using dgmEffectsInfo table - targetGroupIDs field as a comma separated list of numbers with NO SPACES all in one string
| Equipment Type Name | Enum Code | Enum Name | Description |
|---|---|---|---|
| Module | 1400 | EQUIP_MODULE | ? |
| Charge | 1401 | EQUIP_CHARGE | ? |
| This Ship | 1402 | EQUIP_THIS_SHIP | ? |
| Drone | 1403 | EQUIP_EXTERNAL_SHIP | ? |
| External Ship's Module | 1404 | EQUIP_EXTERNAL_SHIP_MODULE | ? |
| External Ship's Charge | 1405 | EQUIP_EXTERNAL_SHIP_CHARGE | ? |
Module Effect Applied To Target Types
TODO
USED IN - dgmEffectsInfo table - effectAppliedTo field
| Target Type Name | Enum Code | Enum Name | Description |
|---|---|---|---|
| Self | 1500 | EFFECT_TARGET_SELF | means the target of the effect is the module's own attribute(s) |
| Ship | 1501 | EFFECT_TARGET_SHIP | means the target of the effect is the attribute(s) of the ship to which the module is fitted |
| External Target | 1502 | EFFECT_TARGET_EXTERNAL | means the target of the effect is the attribute(s) of the current target of the ship to which the module is fitted |
| Module on Ship | 1503 | EFFECT_MODULE_ON_SHIP | means a module or modules that are fitted to the current ship, this special case will indicate when the effect is applied to other modules applied to the same ship - the dgmEffectsActions table fields of targetEquipmentType and targetGroupIDs will have additional information for the Module Manager to make use of this effect |
| Module containing Charge | 1504 | EFFECT_LOADED_CHARGE | means that the effect is from a charge loaded into a weapon module so this will affect charges of the specified groupID loaded into any module on the ship |
| Charge loaded into a Module | 1505 | EFFECT_CHARGE | means that the effect acts upon a charge loaded into a weapon module so this will affect charges of the specified groupID loaded into any module on the ship |
| Character that owns the skill | 1506 | EFFECT_CHARACTER | means that the effect acts upon the character's attribute specific to the effect |
targetGroupIDs
You may use these codes to indicate special behaviors other than simply which groups of modules on which apply the effect:
| Special 'targetGroupIDs' Code | Additional Parameters | Example | Description |
|---|---|---|---|
| -1 | a comma separated list of attribute IDs | "-1,1211" | Indicates that the Module Manager should apply this effect ONLY to all modules that have one of the listed attribute IDs |
| -5 | a comma separated list of attribute IDs | "-5,1211,1212" | Indicates that the Module Manager should apply this effect ONLY to all modules that have ALL of the listed attribute IDs |
| -10 | a code indicating slot bank to be modified | "-10,1801" | Indicates a slot bank code that is to be modified, primarily used for Tech 3 Strategic Cruiser subsystem module effects that modify the slot configuration. See Module Power Levels for these codes. |
| -15 | a comma separated list of effect IDs | "-15,1615" | Indicates that the Module Manager should apply this effect ONLY to all modules or ships that have one of the listed effectIDs |
Module Effect Application Types
NOTE: TO BE REVISED AND REMOVED - MODULE STATE IS ENOUGH TO DETERMINE WHAT THE MODULE APPLICATION TYPE IS, THE THIRD CODE IS UNNECESSARY AS EACH MODULE CLASS WILL KNOW IF IT SHOULD CONSUME SOMETHING OR ACCUMULATE SOMETHING
USED IN - dgmEffectsInfo table - effectApplicationType field
| Effect Application Type Name | Enum Code | Enum Name | Description |
|---|---|---|---|
| Maintain Effect in Online State | 1600 | EFFECT_ONLINE_MAINTAIN | applied by PASSIVE or ACTIVE modules where an effect is maintained; means the effect takes effect on the target (see below) upon entering the ONLINE state. It may or may not then be reversed when going out of ONLINE state; this is specified in other fields of the dgmEffectsActions table, specifically the nullifyOnlineEffect and nullifiedOnlineEffectID fields. |
| Maintain Effect in Activated State | 1601 | EFFECT_ACTIVE_MAINTAIN | applied by ACTIVE modules where an effect is maintained; means the effect takes effect on the target (see below) upon entering the ACTIVATE state, then reversed when going out of ACTIVATE state |
| Effect Repeatedly Consumes while in Activated State | 1602 | EFFECT_ACTIVE_ACCUMULATE | applied by ACTIVE modules where an effect is applied cumulatively on each cycle; means the effect takes effect on the target (see below) one extra time when in ACTIVATE state after each CYCLE duration expires |
Module Stacking Penalty
TODO
USED IN - dgmEffectsInfo table - stackingPenaltyApplied field
| Stacking Penalty State | Enum Code | Enum Name | Description |
|---|---|---|---|
| No Stacking Penalty Applied | 1700 | NO_STACKING_PENALTY | No Stacking Penalty applies |
| Stacking Penalty Applies | 1701 | STACKING_PENALTY_APPLIES | Stacking Penalty applies |
Module Power Levels
TODO
| Power Level Name | Enum Code | Enum Name | Description |
|---|---|---|---|
| High Power | 1800 | MODULE_BANK_RIG_POWER | High Power module slot bank |
| Medium Power | 1801 | MODULE_BANK_LOW_POWER | Medium Power module slot bank |
| Low Power | 1802 | MODULE_BANK_MEDIUM_POWER | Low Power module slot bank |
| Rig | 1803 | MODULE_BANK_HIGH_POWER | Rig bank |
| Subsystem | 1804 | MODULE_BANK_SUBSYSTEM | Subsystem bank |
ModuleContainer
TBD
Modifier
TBD
ModifierMap
TBD
MEffect
TBD
DGM_Effects_Table
TBD
ModuleEffects
TBD
GenericModule
TBD
Module Classes
- PassiveModule
- ActiveModule
TBD
Module Components
TBD
Analysis via EFT of Order of Effects and Bonuses Application
There are so many ways that changes are made to ship, module, and other items' attributes by other items such as modules, charges, implants, rigs, boosters, subsystems, etc that we need to figure out the order in which they should be applied because it has to matter somehow.
To wit, we turn to EFT to find the answers and my discoveries will be recorded here.
Empty Maller: Amarr Cruiser skill: 10% bonus to Medium Energy Turret capacitor use per level | 5% bonus to all Armor Resistances per level
Resistances: EM 0%/50% | Thermal 20%/35% | Kinetic 40%/25% | Explosive 50%/20%
AFTER Amarr Cruiser Level 3 APPLIED:
Resistances: EM 0%/57.5% | Thermal 20%/44.8% | Kinetic 40%/36.3% | Explosive 50%/32%
Connecting the Missing Links
Nowhere in CCP's static Database dump are the connections or relations that we can find that tie a module's effects to that module's attributes which are then used to modify specific attributes on the module itself or a loaded charge or the ship or even an external target ship or module on that target ship. Nor are there any indications as to by which specific mathematical formulas are those attributes to be applied to the target's attributes.
Close inspection of the attributes and effects of the modules added with knowledge of the actual EVE game play and how modules work to affect attributes all show how these connections can be made.
The dgmEffects table contains information on each effect type a module may have assigned to it in the dgmTypeEffects table, the later being keyed on the item's typeID. The dgmAttributes table contains information on each attribute type an item type may have assigned to it in the dgmTypeAttributes table, the later being keyed on the item's typeID.
The dgmTypeAttributes and dgmTypeEffects tables list which attributes and which effects each module/ship/skill/drone/other item type has assigned to it and what the value of that attribute is. What is missing is the information that describes exactly what calculations are performed for each effect of a module or other item type, which attribute(s) on that item type are used in the calculation, and which attribute(s) on the target item type is affected by the calculation result.
The connections are formed using three new tables dgmEffectsInfo, dgmEffectsActions, and dgmTypeAttributeModifiers. What follows are detailed descriptions of how each table is populated with information from a skill, ship, module, charge, implant, etc so we have the information to make effects and bonus modifiers work properly.
Adding Effects Data from a Module
In order to add field data to the dgmEffectsInfo and dgmEffectsActions tables, you really do need to understand how modules' effects make changes to attributes on whatever target it is supposed to affect. An example of this would be that an Active Armor Hardener module when active adds a bonus percentage to a ship's armor resonance attribute. That knowledge will not be replicated here as it is too vast. Your best bet is to play EVE live or hopefully EVEmu works and can demonstrate what modules and other items do. Alternatives are to use EFT or EVEHQ to make ship fittings and discover how character skills, ship bonuses, and modules can affect one another to make a ship fitting do whatever it is you want it to do. To aid you in this endeavor, EVEmu has an API Server capable of many of the official API calls, most notably those required to connect EFT and EVEmon to your character on the EVEmu server. See the EVEmu API Server article for information on how to use it to make a new API account and then connect it to these out of game EVE tools adapted for use with the EVEmu server.
Now, the following procedures assume you are specifying the correct source attribute(s), skill, target attribute(s), and the calculation formula used to make the change on the target attribute(s) of the target item type. As for ship, skill, and implant bonuses, there is more information contained in the list of effects and attributes for these items but knowledge to connect them is still required. These last sets of data are entered into the dgmShipBonusModifiers, dgmSkillBonusModifiers, and dgmImplantBonusModifiers tables.
These procedures will be described by way of example for the Armor Thermic Hardener I fitted to an Amarr Maller cruiser, which gets 5% bonus to all armor resistances per level of the Amarr Cruiser skill. The armor hardener module is an active one, however, it is rather unique in that it not only has effects for the Active state but also for the Online (not active) state. It also has an effect for the Overload Active state. So, given that it has effects for all three critically important Module States (Online, Active, Overload), this module will prove to be a good example on how to insert data into the aforementioned tables in order to make the proper connections between the effects, the source attributes, and the target attributes.
Implementing Effects
PART I - Getting the Module Information
First, use EVEmu Control Panel to connect to your EVE Database and then move over to the Item/Ship Editor tab and select Category Module, then type "Armor Thermic Hardener" into the Search box and press Search button. Now, in the results window, right-click and hit Edit on the Armor Thermic Hardener I. The new window will show you Info, Attributes, and Effects of this module. You can do this for any item type in the game (just choose a different category and either search or just scroll through the complete list of the items in that category).
Now, click on the Effects tab to view this module's effects. You'll see these three effects:
- (id = 2084) modifyArmorResonancePassivePostPercent
- (id = 2098) modifyActiveArmorResonanceAndNullifyPassiveResonance
- (id = 3030) overloadSelfThermalHardeningBonus
These three effects are the ones for which we wish to enter data into the dgmEffectsInfo and dgmEffectsActions tables. Here's how we do that.
Note, as stated before, you have to know what these modules DO in the real game to figure out what attributes on the module are used and which formula they are used with, which attributes on the 'target' are affected, and what that 'target' is, whether it's a ship to which the module is fitted, the module itself or it's own charge, or even an external target such as another hostile/friendly ship/drone/station/structure.
PART II - Inserting Effects Information into dgmEffectsInfo table
First, let's enter data for the modifyArmorResonancePassivePostPercent. This effect is meant to take effect when the module is in the Online state. See Module States section above for information on the possible state of each module. This effect uses as sources the attributes on this module with IDs of 994, 995, 996, and 997. So, we need to enter 4 rows of data into the dgmEffectsInfo table. The dgmEffectsInfo table contains the following fields.
| effectID | targetAttributeID | sourceAttributeID | calculationTypeID | reverseCalculationTypeID |
|---|
The calculation for this is odd since armor and shield resonances are not like most attribute calculations. Resonances are kind of opposite of EFT Resistances that are in % and the higher the Resistance % the less damage you take from a certain amount of HP on that damage type. Resonances are opposite in that the smaller the number the less damage you take, more like just multiplying the resonance value with the actual damage HP and the result is the real damage applied to your shield or armor. So, essentially, Resistance % = 100% - Resonance %, where the resonance value is a decimal between 0.0 and 100.0 and is a percentage. Now, to use one of those passiveXXXXDamageResistanceBonus values from the Armor Thermic Hardener I, we take the value, for say passiveThermicDamageResistanceBonus, which is -1, because the others are 0 (come on, this IS an Armor THERMIC Hardener I after all...). Take the value of -1, which is resonance as percentage, or -1%, and it gets applied to the current ship's armorThermalDamageResonance, which in the case of the Maller with NO SKILLS on the character has a value of 0.65 or 65%. Keep in mind that if you use EFT to check the Maller with no skills, you'll see the Armor Thermal Resistance value to be 35%, which is simply 100%-resonance%. Please forgive the fact that you cant actually fly the ship like this, but NO skills makes separating out the calculations easier. To apply the -1% resonance to the 65% current resonance value, we first have to add the -1% to 100%, yielding 99% and then multiply that with the 65%, which yields 64.35% for Armor Thermic Resonance. If you now fit the Armor Thermic Hardener I to the Maller in EFT again with NO skills on the character, you'll see the Armor Thermal Resistance increase from 35% (100% - 65%) to 35.7%, which is simply 100% - 64.35% = 35.65% rounded up to 35.7%. This all means you use a formula code for Modify Percent With Percent, so see the Effect and Bonus Modifier Calculation Types section for the actual codes for each calculation allowed to be done with an effect or bonus modifier. Finally, the target attribute ID you'll find by inspecting the Maller ship attributes list for armor resonances, in this case the armorThermicDamageResonance with ID = 270. Now, how did we know to look at the ship's attribute list and not some other "target"? Well, because we know the game mechanics and that the Armor Thermic Hardener I module changes the ship's damage resistance for Thermal damage. By way of example, if this had been an Omnidirectional Tracking Link I module, which gives bonuses to drone optimal range and tracking speed, we would know that the target would be the drones' attributes for tracking speed and optimal range, which are TWO different effects thus requiring two new rows added to the dgmEffectsInfo table. Finally, back to our Armor Thermic Hardener I example, here are the four rows we add to the dgmEffectsInfo table to make the linkage between the effectID of 2084 for modifyArmorResonancePassivePostPercent the source attributes on the module and the target attribute on the ship.
| effectID | targetAttributeID | sourceAttributeID | calculationTypeID | reverseCalculationTypeID |
|---|---|---|---|---|
| 2084 | 267 | 994 | 2012 | 2013 |
| 2084 | 268 | 995 | 2012 | 2013 |
| 2084 | 269 | 996 | 2012 | 2013 |
| 2084 | 270 | 997 | 2012 | 2013 |
BOOM, now you've just added effectID 2084 for ALL modules in the Armor Hardener groupID 328. Yep, all 177 of them. Congradulations, but then again I just did that work for you and you watched, hahahahaha. And, actually, we're not done since we've only covered half the story for this effect not to mention that we have to do the same for the other two effectIDs on this module.
PART III - Inserting Effects Action information into the dgmEffectsActions table
NOTE: THIS TABLE HAS BEEN REMOVED AND effectAppliedInState FIELD MOVED TO dgmEffectsInfo TABLE TO CONFORM WITH IMPORT FROM EVEHQ Effects.csv RESOURCE FILE. THIS IS LESS EFFICIENT STORAGE BUT MORE CONCISE AND NOT REALLY ALL THAT MUCH EXTRA SPACE IN THE DATABASE FOR A COUPLE THOUSAND EFFECTS. THIS ENTIRE SECTION _MUST_ BE REVISED TO DESCRIBE HOW THE effectAppliedInState NOW COMES FROM THE EVEHQ IMPORT.
Now that we've defined the what of this effect in the dgmEffectsInfo table, the other half of the definition of the effect is to define what action to take and when to take it. This data goes into the dgmEffectsActions table.
| effectID | effectAppliedInState | effectAppliedTo | effectApplicationType | targetEquipmentType | targetGroupIDs | stackingPenaltyApplied | nullifyOnlineEffect | nullifiedOnlineEffectID |
|---|
The dgmEffectsActions table is used by the Module Manager to manage the operation of a module in its different states. It needs to know in which state or states that a particular effect is to go active and what actions to take on what target. There will be one row added to this table for each effectID. For our example case of the Armor Thermic Hardener I and the modifyArmorResonancePassivePostPercent effect that we're still working on, we need to define this table's field data for this effect. The effectAppliedInState allows us to define which Module State in which this effect goes active. In this case, it is Passive Resonance bonus so we will choose the 'Online' state (see Module States for the correct state code). The effectAppliedTo allows us to define which type of target this effect is meant to affect, be it itself (the module), the ship to which it's fitted, or some external target. See the Module Effect Applied To Target Types section for the correct code to use in this case where we want to affect the SHIP to which this module is fitted. It is an Armor Hardener and is meant to change attributes of the ship to which it is fitted. The effectApplicationType lets us define how this effect is applied to the target, be it a maintained level of effect or a cumulative effect. In this case, when this effect is active, it will maintain a new value for the Armor Resonances that it affects while it is in the 'Online' state. The new values will maintain until the state changes out of 'Online', so we chose the Effect Online Maintain code found in the Module Application Types section. The targetEquipmentType field is used to define the typeID of the target being affected by this effect, however, this field is only used for entries that are coupled with entries placed into the dgmTypeAttributeModifiers so it is left empty, or zero, for Effects Processing. The same is said for the targetGroupIDs field, but since this one is a text field, we just leave it with empty text: "". Moving on, we have the stackingPenaltyApplied field, which is used by the Module Manager to either apply module stacking penalty analysis including this effect or excluding this effect. This module does have stacking penalties applied to it when more than one module has an effect that affects the attributes affected by this effect. See the Module Stacking Penalty section for the correct code to use here. Affect, Effect, too confusing? Go play EVE live. Anyway, go read that last sentence ten more times and I promise you'll get it... I PROMISE. Ok, well if not, too bad, we're moving on anyway since you're such a noob. The nullifyOnlineEffect field lets us tell the Module Manager that when this effect is active and the active state is Activated, that it is to undo any effects applied to the attributes affected by this effect when it was in the Online state. In this effect's case, it is active in the Online state, so it does not apply and we leave the value for this field at Zero, or 0. Finally, the nullifiedOnlineEffectID field lets us tell the Module Manager which of the other effects on this module is the one that needs to be undone when moving from the Online state to the Activated state, but again as is the case with this effect, it is active in the Online state, so we leave this field also at Zero, or 0. These last two fields we will make use of and explain how to set them with the next effect. So, let's take this data and place it into the dgmEffectsActions table for this effectID as shown here:
| effectID | effectAppliedInState | effectAppliedTo | effectApplicationType | targetEquipmentType | targetGroupIDs | stackingPenaltyApplied | nullifyOnlineEffect | nullifiedOnlineEffectID |
|---|---|---|---|---|---|---|---|---|
| 2084 | 1102 | 1501 | 1600 | 0 | "" | 1701 | 0 | 0 |
RINSE and REPEAT - Keep doing PART I through PART III for all effectIDs on a module
The next effect is the modifyActiveArmorResonanceAndNullifyPassiveResonance which is a bit different than most other effects in that what first must happen before this effect goes active is the Passive Resonance bonus effect modifyArmorResonancePassivePostPercent effect must be nullified, or removed. Then, this effect can go active. So, just like the previously handled effect, this one also modifies the current ship's damage resonances but using the other set of damage resonance attributes on this module, not the ones with the passive prefix. Again, for each damage type hardener module, only one of these attributes will be non-zero, however, we're going to enter into the dgmEffectsInfo table rows that correspond to these source attributes. Source attributes are the damage resonance bonuses without the passive prefix on this module, target attributes are same as for the previous effect we took care of, and calculation types are also the same as the previous effect. Putting all that into a table for insertion yields this below:
| effectID | targetAttributeID | sourceAttributeID | calculationTypeID | reverseCalculationTypeID |
|---|---|---|---|---|
| 2098 | 267 | 984 | 2012 | 2013 |
| 2098 | 268 | 985 | 2012 | 2013 |
| 2098 | 269 | 986 | 2012 | 2013 |
| 2098 | 270 | 987 | 2012 | 2013 |
Now, to insert data for this effect into the dgmEffectsActions table, here we're going to note that another effect (modifyArmorResonancePassivePostPercent) is supposed to be reverted before applying this effect. First, this effect is applied in the Activated state, the effect is applied to the Ship, the application tye is the same as the previous effect: EFFECT_ACTIVE_MAINTAIN, the targetEquipmentType and targetGroupIDs can be left blank, and the stacking penalty applies. Finally, the nollifyOnlineEffect is set to 1, meaning the Online effect of this module is nullified on Activated state transition. The last field tells which actual effectID on this module to revert when this effect is supposed to go active, so use the previous effect's ID of 2084.
| effectID | effectAppliedInState | effectAppliedTo | effectApplicationType | targetEquipmentType | targetGroupIDs | stackingPenaltyApplied | nullifyOnlineEffect | nullifiedOnlineEffectID |
|---|---|---|---|---|---|---|---|---|
| 2098 | 1103 | 1501 | 1601 | 0 | "" | 1701 | 1 | 2084 |
The last effect on the Armor Thermic Hardener I is the overloadSelfThermalHardeningBonus, which has id = 3030. Now, overload effects are going to be a bit different than other more general effects, such as the previous two that we encountered on this module. This effect is specific to THERMAL armor hardeners, so by that logic, and you can verify this by looking up the other damage type hardeners in EVEmu Control Panel, the other damage type hardener modules will have their own overload effects. So, since this example is meant to completely fill out all modules in this group, we will show all four overload effects data rows below as to how you would insert them into the dgmEffectsInfo and dgmEffectsActions tables.
The Armor Thermic Hardener I module as well as its companions for EM, Explosive, and Kinetic damage types will all have their own effects for overloading. They have IDs 3029 (EM), 3031 (Explosive), and 3032 (Kinetic). Although each damage typed hardener module has its own overload effectID, they all make use of the same overload attribute ID: 1208 for overloadHardeningBonus, which for all basic Tech 1 hardeners has a value of 20. This value is 20% bonus to the base attribute that the module offers toward the ship's damage resonance. Since these modules offer 50% bonus to armor damage resonance when the module is in the Activated module state, then when the module is put into the Overloaded module state, the 50% bonus will be increased by this 20% overload bonus, so the new damage resistance bonus offered by the module will be (100% + 20%) * (50%) = 60%. Now, this calculates onto the Maller cruiser's Thermal Armor Resistance to increase its base resistance of 35% to 100% - [100% - (35% * (100% - 60%))] = 74% Thermal Armor Resistance. Now, this is a two level calculation and the Module Manager will handle overload bonuses BEFORE applying the module's bonus to the ship or whatever the target object is, so when we enter information into the dgmEffectsInfo and dgmEffectsActions tables for overload effects, the target will be the MODULE, not the other target that regular effects might have. So, for these overload effects, the data entered into the dgmEffectsInfo table will be as shown below for a sourceAttributeID of 1208 (the overloadHardeningBonus) the targetAttributeID will be the module's own damage resistance bonus attribute that corresponds to the module's damage type (EM, Thermic, Kinetic, Explosive), the calculationTypeID will be Modify Percent As Percent, and ID of 2012 with the reverse ID = 2013.
| effectID | targetAttributeID | sourceAttributeID | calculationTypeID | reverseCalculationTypeID |
|---|---|---|---|---|
| 3029 | 984 | 1208 | 2012 | 2013 |
| 3030 | 987 | 1208 | 2012 | 2013 |
| 3031 | 985 | 1208 | 2012 | 2013 |
| 3032 | 986 | 1208 | 2012 | 2013 |
Adding data to the dgmEffectsActions table is crucial as well because it makes the final linkage from the attributes that get changed by the module, what module state it is in when the change happens, and if there are any stacking penalties and Online state effects that need to be nullified when this effect goes into... ahem... effect, hehe. So, the table below shows all four damage type overloaded hardener effects, the Overloaded state encoding (1104), the code for target of the effect being the Module not the ship (1500), no targetEquipmentType or targetGroupIDs (0, ""), stacking penalty not applied (1700), and Online effect (2084) nullified. Now, the weird thing about Overloaded effects of modules is that the Activated state effect (because every overloadable module has one) will ALSO be active along with the Overload effect. The ModuleManager will take care of this, but for the purposes of this section, we're only showing how the Overload effects get detailed in the dgmEffectsInfo and dgmEffectsActions tables so that when the ModuleManager and the Module classes do what they do, they do it correctly based on how the information is encoded into these tables.
| effectID | effectAppliedInState | effectAppliedTo | effectApplicationType | targetEquipmentType | targetGroupIDs | stackingPenaltyApplied | nullifyOnlineEffect | nullifiedOnlineEffectID |
|---|---|---|---|---|---|---|---|---|
| 3029 | 1104 | 1500 | 1601 | 0 | "" | 1701 | 1 | 2084 |
| 3030 | 1104 | 1500 | 1601 | 0 | "" | 1701 | 1 | 2084 |
| 3031 | 1104 | 1500 | 1601 | 0 | "" | 1701 | 1 | 2084 |
| 3032 | 1104 | 1500 | 1601 | 0 | "" | 1701 | 1 | 2084 |
Finally, we're done with this module and it was a bit of a doosey because it's rather complicated having a passive effect, an active effect (which nullifies the passive one), and an overload effect. Now, that concludes this lesson, but the fun's not over, not by a long shot, so all modules will be scratch-padded in the way of these tables for both the dgmEffectsInfo and dgmEffectsActions tables in the article linked here:
Module Effects Info and Actions Complete List
Implementing Type Attribute Modifiers
TBD
Ship Bonus Modifiers Complete List
Skill Bonus Modifiers Complete List
Implant Bonus Modifiers Complete List
Pages in category "Module Manager"
This category contains only the following page.