There are two realtime problems with the simplex algorithm.
The first is that the simplex algorithm requires you to generate a connectivity matrix, which in our case is really expensive since it demands we check network ids, item names, thresholds and train availability for every possible combination of provide (p) and request (r) stations. Just the connectivity matrix would have dimensions p * r, and we would have to do repeated matrix operations on this. There are some sparse matrices shenanigans you could do to improve this, but they are absurdly difficult to program. So to oversimplify, our current algorithm has amortized runtime of O(p*r) (with average case being more like O(p + r)), whereas for simplex we have Ω(p*r), aka p*r is a lower bound on runtime.
The second is that the simplex algorithm cannot give partial solutions, it has to be run more or less to completion before the solutions it produces can be used. The current algorithm uses a greedy iterative approach which allows it to produce one solution, i.e. one train order, one at a time, so we can generate a fixed number of orders per tick. We would of course run a small amount of simplex every frame, instead of all in one frame, but then this means there will be potentially dozens of seconds of time where no orders at all are being generated.
These paired with how much time it would take to program an efficient simplex solver makes me not want to even try to test how such a solution would work in practice. Better performance than LTN was one of my design requirements, and it also doesn't use simplex.
