blitzmann

{
  "42": {
    "displayName": "Armor HP bonus", 
    "displayNameID": 521916, 
    "locationGroupModifiers": [], 
    "developerDescription": "Erebus Effect Generator : Armor HP bonus", 
    "operationName": "PostPercent", 
    "locationModifiers": [], 
    "locationRequiredSkillModifiers": [], 
    "itemModifiers": [

blitzmann

Windows English locale - french folder - works
Linux Mint Hebrew Locale - Hebrew folder - works
Windows Russian locale - russion folder - works
Windows english locale - russion folder - fails (cxfreeze, not pyfa)

blitzmann

Optimal Range

Original: 75000

Two unscripted modules

• Module 1: 7.5% (modifier of 1.075)
• Module 2: 7.5% * 0.869 = 6.5175 (modifier of 1.065175)

So it's 75000 * 1.075 = 80625 (first, unpenalized module)

blitzmann

-   metaGroupID: 2
    parentTypeID: 377
    typeID: 380
-   metaGroupID: 2
    parentTypeID: 393
    typeID: 394
-   metaGroupID: 2
    parentTypeID: 399
    typeID: 400
-   metaGroupID: 2

blitzmann

....................................................................................#..#..................................................................................................|.............................................................................................................................................................
....................................................................................#..#..................................................................................................|.............................................................................................................................................................
....................................................................................#..#................#.........#.......................................................................|...................................................................................................................................................

blitzmann

So, quick rundown on eos:

There are two datasources: game data (eve.db) and user data (saveddata.db). Tables for these databases are defined in eos.db.(gamedata/saveddata). Most of the tables also have a class mapped to them that handles the business logic of the entity. For game data, they all reside in eos.gamedata - most of them are skeleton objects, since most eve data is simply there to provide lookup of values and not necessarily do anything. The interesting objects here are Item and Effect.

The tables for the user's data are mapped to classes defined in eos.saveddata, and this is the majority of where the logic for the calculation engine lies, and many helper functions. For example, the Module class contains logic on what a module should do (for example, it has a method isValidCharge which checks to see if a passed in Charge object is valid for the module).

A quick how to stand up a bare bones Rifter fit with an Afterburner and a 200mm Autocannon with EMP S:

blitzmann

Infection group 1 would deal defending group 1 185832 damage *
Infection group 1 would deal defending group 2 185832 damage 
Infection group 2 would deal defending group 2 107640 damage *
Immune System group 1 would deal defending group 2 153238 damage *
Immune System group 2 would deal defending group 1 24725 damage *
Immune System group 2 would deal defending group 2 24725 damage 

Infection group 2 attacks defending group 2, killing 84 units, dead: False
Immune System group 2 attacks defending group 1, killing 4 units, dead: False
Immune System group 1 attacks defending group 2, killing 51 units, dead: False

blitzmann

Note: this document is meant for developers. If you have no interest in pyfa development, then this doesn't offer you much

In early 2018, as part of a large effort to update pyfa's codebase to Python 3, pyfa also updated it's versioning standard to use PEP-440. As such, version strings in pyfa must be strictly compatible with with PEP-440, and must not raise an exception with packaging.version.Version.

In early 2019, pyfa moved to a process of automated versions. Before these changes, for every release, developers had to manually update the version information in config.py to match the intended release version, and then tag that commit properly. Since 2019, pyfa versioning has been automated by the use of git describe --tags. As such, pyfa versions are wholly determined by tags in git - literal tagged commits are considered releases, and other builds that

Automated Builds

When AppVeyorr or Travis-CI (coming soon) picks up a build job, one of the

blitzmann

# Variables in Ruby
$dsides = 20

players = [ "Nick", "Lucas", "Ryan", "Josh", "Stephen", "Steve"  ]

puts "Rolling a D#{$dsides}"
puts

def do_round(players, i)
  puts

blitzmann

<div class=tab-container>
  <ul class="tabs" >
    <li>
      <a href=# >Tab 1</a> 
    </li>
    <li class=active > 
      <a href=# >Tab 2</a> 
    </li>
    <li> 
      <a href=# >Tab 3</a>