Projected fit stats occasionally 'lost' when changes are made to the fit.

[ftsartek]

When projecting fits onto each other (the problem is seen when it is multiple different fits, not one fit projected onto itself like a logi chain), and modules are changed/activated/inactivated on one fit, the projected stats will be lost on the other fit until the projection is removed/replaced or state is changed.

Easy to reproduce. See attached .gif for an example. Doesn't seem to be dependent on what modules are being projected, nor what ship(s) the projections are coming from. Doesn't appear to be an issue with command ships added under the 'command' tab.

[blitzmann]

I took a look at this a little bit a while back, and peaking at it again now. I think I have an idea on why it may be doing this, but no real idea on how to fix it right now. It deals with the complex order of operations that happens during fit calculations.

1. Fit1 and Fit2 are projected onto each other: Fit1 <-> Fit 2
2. Fit 1 gets recalculated. This causes Fit 2 to be recalculated because it is projected onto Fit1 and so we need to make sure all it's projected modules get their proper bonuses applied locally before they get applied to the target fit.
3. When Fit2 get calculated, it does not calculate it's projected fits. There are two reasons for this: 1) to prevent an infinite loop (which would happen in a situation like this), and 2) because a projected module can't (at least with current game mechanics) affect another projected module, so it doesn't really matter what's projected onto the projected fit, it's not going to affect Fit2's projections
4. Once Fit2 is calculated, it gets a flag set noting that it's been calculated so that we don't waste time trying to recalc it again unless something changes
5. Apply Fit2 to Fit1 after Fit2 is calculed

The problem seems to stem from step 3 - the fact that we don't apply Fit2's projections to the fit when calculating it as part of a projection. And the fact that we flag it as "calculated" causes it to skip recalculations when switching to it's tab.

I am not sure off the top of my head the best way to handle this. It might suffice to say "don't set the calculated flag on a fit if it's being calculated as part of another fit's projection and it also has projections itself... that way the fit will always receive a fresh calculation when witching to it's tab. I'm not sure what other kind of logic that might affect, so I'll have to research into this a bit more and do some testing. :)

[feyyd]

Perhaps, for each fit using projection, create a new object/class (or even copy) to respresent other fits instead of using the other fit object.

Instead of the relationship being Fit 1 <-> Fit 2 we would end up with something like Fit 1 <- Fit 2 copy and Fit 2 <- Fit 1 Copy

[blitzmann]

Perhaps, for each fit using projection, create a new object/class (or even copy) to respresent other fits instead of using the other fit object.

This was something that was investigated the last few times the projection code was refactored. I don't exactly remember all the reasons against it (I'm sure it's documented in an issue somewhere), but while it seems like a clever solution on the surface, it doesn't really work out all that well. I know that's not a very helpful answer :/

That being said, IIRC, a version of it is used with self projections, since that's literally the only way to do them without running into recursions (or at least this is one of the ways I solved self-projections way back when, can't remember if it's still the method we use today)

[TFT-Ben]

Revisiting this as I've been simulating spider tanks and it's annoying.
From your above reply:
"Once Fit2 is calculated, it gets a flag set noting that it's been calculated so that we don't waste time trying to recalc it again unless something changes"

When switching tabs to a fit involved in a looped projection, would it be possible to recalculate the fit being actively viewed when switched to, only in this specific circumstance?