Old Wiki:Category Module Manager

From EVEmu Wiki
Revision as of 15:17, 3 April 2021 by Admin (talk | contribs) (Bot: Automated import of articles)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
NAVIGATION HOME / Game Operation / Module Manager (you are here)



Contents

Resources

The links with strike-through are deprecated since Reve had discovered that the EVEHQ tool has resource files in CSV format for the following groups: Effects, Skill Bonuses, Ship Bonuses, Subsystems, Implant Effects, Ship Effects, Booster Effects, and Booster Bonues. These will be adapted to our existing, but currently empty dgm tables.

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

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

Effect and Bonus Modifier Calculation Types - source: src/eve-server/ship/modules/ModuleDefs.h: enum EVECalculationTypes
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.

Effect and Bonus Modifier Calculation Types - source: src/eve-server/ship/modules/ModuleDefs.h: enum EVECalculationTypes
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

Module States - source: src/eve-server/ship/modules/ModuleDefs.h: enum ModuleStates
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  ?
Module State Transitions
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

Charge States - source: src/eve-server/ship/modules/ModuleDefs.h: enum ChargeStates
State Name Enum Code Enum Name Description
Unloaded 1200 MOD_UNLOADED  ?
Loading 1201 MOD_LOADING  ?
Reloading 1202 MOD_RELOADING  ?
Loaded 1203 MOD_LOADED  ?
Charge State Transitions
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

Module Effect Applied Behaviors
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

Module Target Equipment Types
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

Module Effect Applied To Target Types
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:

Module Target Equipment Types
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

Module Effect Application Types
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 States
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

Module Power Levels
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.

dgmEffectsInfo table 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.

dgmEffectsInfo table Entries for Armor Thermic Hardener effectID = 2098
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.

dgmEffectsActions table Fields
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:

dgmEffectsActions table Entry for Armor Thermic Hardener I effectID = 2084
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:

dgmEffectsInfo table Entries for Armor Thermic Hardener effectID = 2098
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.

dgmEffectsActions table Entry for Armor Thermic Hardener I effectID = 2098
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.

dgmEffectsInfo table Entries for Armor Thermic/EM/Explosive/Kinetic Hardener I module group effectIDs = 3029, 3030, 3031, 3032
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.

dgmEffectsActions table Entries for Armor Thermic/EM/Explosive/Kinetic Hardener I module group effectIDs = 3029, 3030, 3031, and 3032
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.

M


Retrieved from ‘https://wiki.evemu.dev/index.php?title=Old_Wiki:Category_Module_Manager&oldid=73’