Pyfa does not calculate multiple projections of the same fit

[blitzmann]

Seems to be due to the way fits are calculated.

elif targetFit not in self.__calculatedTargets:
    return

When there is multiple projections of the same fit, the first one is not marked as calculated and goes through the process. The other one, however, satisfies the above condition and is just returned...

We can perhaps separate the calculations from the application of stats and projections... That was a fit that is calcuated can be cached and we can apply it multiple times instead of stopping.

Another reason is simply the way projected fits are expressed in the database, in which the sourceID and victimID are coupled into the Primary key, so we can only have 1 unique pair. There is, however, and amount attribute that doesn't seem to be used that we may be able to tap into.

[blitzmann]

So, to access the amount attribute, we pretty much have to implement the same thing as #83.

In the meantime, will look into the calculated cache to see what we can do...

[blitzmann]

Was able to get multiple projections from the same fit working by replacing this block of code:

    # Else, we're checking all target projectee fits
    elif targetFit not in self.__calculatedTargets:
        self.__calculatedTargets.append(targetFit)
        targetFit.calculateModifiedAttributes(dirtyStorage=dirtyStorage)
        forceProjected = True

    # Or simply apply projected drones and modules and return
    else:
        for runTime in ("early", "normal", "late"):
            c = chain(self.drones, self.modules)
            for item in c:
                targetFit.register(item)
                item.calculateModifiedAttributes(targetFit, runTime, True)
        return

However, it's really hackish. And it only works for the session - since the database table cannot have more than 1 source-victim, it won't be saved...

Speaking of which, I can't decide what to do with the database table. There are a few options:

Association Object: Will require us to write an association object to let us access the amount attribute (as well as planned state attribute). In addition, this would require us to implement an amount-loop in calculateModifiedAttributes(), and GUI logic to handle fit "stacking".

Redesign Table: Leaning more towards this. Instead of the traditional two-column model, have primary key on traditional ID column, and have each projection association get it's own ID. This will allow us easy access to any additional attributes.

[blitzmann]

Decided to go with association object. See #83 for development on this and other improvements