5
1
m_aCore[2]
in some .cpp:
m_aCore[CurTickMode] = ...
m_aCore[PrevTickMode] = ... (e.g. if one must access the previous state) (note here prev: is basically the current for client, while cur is the prediction, on server both would be the same, so u basically only access a core)
I don't think a third core is needed (smth like prev core), this usually only creates delays. If we want smoother interpolation for smth like cursor movement we can think about increasing the package count for such things, the way its handled rn is really weird (tsfreddie and me talked about it long before).
If the server sends fewer cores/snapshots the client should simply rely on its prediction cores (swap the current prediction core with the current simulation tick).
Smooth prediction should uses the 2 cores to calculate whatever state is wanted. and it should only do it when its needed, and that's usually at rendering. liblua.so is 527KB and it does not pull more dependencies. The server-side bindings add 6Kb to the 
1
Rebuilding packages after a dependency update is a huge PITA, so a number of distros ban static linking.
Rebuilding packages after a dependency update is a huge PITA, so a number of distros ban static linking. 
join the static club, it's the master race 1
