Projected fit improvements - multiple projections, modifying state

[blitzmann]

Be able to toggle projected fit on/off. I assume it doesn't allow for it atm as a fit doesn't have a state like modules.

If this is the case, might be possible to work it in. Look into adding state information to fits, and investigate possible issues related to this (I project fit A onto both fit B and C. I toggle state of A from B, does this affect the toggled state of C? etc)

[blitzmann]

I looked into this a few weeks ago. We require an Association object that is mapped to the relationship table: http://docs.sqlalchemy.org/en/rel_0_9/orm/relationships.html#association-object

I was able to kinda get it to work, but not really. I've put it on the backburner for now until I can look into it a bit more.

[blitzmann]

I started working on this today and have been able to get it to work. Testing has been minimal, but it looks promising. Association objects are a pain in the ass. Will continue work on this - I'm hoping that I can get this and projection recursion fixed within the next few weeks.

I'll be using this space for documentation on issue.
https://github.com/blitzmann/Pyfa/tree/toggleProjectionFit

As it is right now, projected fits are stored in a HandledList collection just like modules and whatnot. The problem is that this does not open us up for accessing project-specific information (is this projection enables for this fit, etc). We need an association object for that.

With my current prototype, projected fits are still accessed as a list in Fit.__projectedFits. There are a few new variables as well, some that we may not need but I'm keeping around at the moment. Projection information is stored in a new variable Fit.projectionInfo when the projected fit is loaded, which contains the ProectionInfo class the represents the m2m row of that relationship. We can simply toggle the "amount" attribute (might be renamed) to 1 or 0 from the service, and then look for it in the fit calculation when the projected fit loop happens.

Things to test / todo:

• Interference between fits. This does happen. Projected fits are loaded and their projection info is loaded when them. However, these objects travel between fits. Disabling one projection of a fit will disable others. This fit itself can be the same, but the way we load and change projection info needs to be different. Perhaps make a dict of {source fit: projectionInfo for this relation}?
• Fit deletions - make sure that deleting a fit removes it from the m2m table both ways
• Containment - make sure that modifying one fit relation does not affect any other (most likely not, but I had some strange outcomes before I got the association right and it has made me paranoid)
• Remove the HandleProjectedFitList class if it is no longer needed
• Support fit amount
• I think source and victim are switched in current implementation, confirm and fix if needed
• With recent changes, adding a fit as projected when that fit is already listed triggers a crash
• With current master, if an invalid (bad itemID) source fit is removed, it does not remove the entry from m2m table. Haven't tested with my changes as of yet.
• Activate projection pane if dragging a fit
• Fit copies - test and fix

[blitzmann]

I've been able to get calculations to take quantity into account and only go to 1 degree of recursion (all that's needed). This is wonderful - there is virtually no difference in the time to calculate 1x of the projected fit vs 5x of the projected fit. There will definitely be a hardcoded limit of how much qty you can add, but the current test of 5 seems very capable. Might bump it up - I will still need to test with actual fully-loaded fits. right now it's a simple Vengence with a small remote shield transfer projected onto a retribution.

A note on fit caching:
The fit calculation logic is very complicated and hard to follow. It seems that there used to be a desire to cache fits so as to not recalculate them. This would be useful for projected fits. In B > A, if we change A, there is no reason to calculate B again. However, this does not seem to work, and I don't think it ever worked - the projected fits are still recalculated. It's not something that is a priority and indeed currently if we don't recalculate the projected fits, we can't apply the items to the target fit, but it's something to look into and think about.

[blitzmann]

Needed to rethink things. Originally I was setting the ProjectionInfo as a class variable on the fit. This worked well, however I totally didn't take into consideration the fact that each fit persists throughout the program. So if I load a projected fit on ship A, it will load it's projection data into that variable. However, if I load another ship that has the same projection, THAT projection info is loaded. Switch back to the other fit, and you'll have the incorrect association.

To combat this, I needed a way to reference which ProjectionInfo we need. I decided to go for a dictionary collection, which will load the ProjectionInfo into dictionaries with the format {victimFitID: ProjectionInfo, ...}.

I should note one think that proved difficult for about 12 hours. The source fits projection info key did not seem to update. ong story short, this is because we use a database session with expire_on_commit = False. Basically even when we flushed / committed the information, the source fits information did not update. To fix this, we flush and refresh the fit with the new info from the database when we add a projected fit:

eos.db.saveddata_session.flush()
eos.db.saveddata_session.refresh(thing)

I think this is one of the only cases where we deviate from the standard eos.db.commit() to save stuff. Projections are special. =)

[blitzmann]

Should be done with the merge e74e261