> comment on the purpose of [9432077
I don't remember exactly and can't investigate in detail now as I'm travelling, with limited / distracted time. It was probably mainly reorganizing how the data is stored, not how the pathfinding is done in terms of using different filtered graph views.
> as far as i understand we just need one graph and the views should be filter on that one
yes
> but the change seems to try to remove the filters
no, it changed how the data was stored, I think with views now stored by value instead of with pointers to views or graphs
> the results of path calculations are not cached anyway.
as far as I recall, correct
> so I think views should use the generic system_graph and create the filters on the fly
probably not; creating the filtered views is not trivial.
> ALL_EMPIRES as a shared view is not necesssary as there is the system_graph?
the main thing in the quoted bullet is just how the data is stored. if I recall correctly, it used to have a common graph view and store a pointer to it for each empire, indexed by each empire id. after the change, it should just store the single graph view under ALL_EMPIRES. the actual pathfinding should still use the same common graph view, as long as the lookup is working correctly.
storing a common graph view like this is supposed to be done on the clients, so that pathfinding will treat the locally known graph as if it was the full universe. on the server, it uses the unfiltered graph or empire-knowledge-filtered views. generally, a fleet doing pathfinding doesn't know if it's doing so on the server or in a client, so the same lookup call has to work in either case.
Statistics: Posted by Ophiuchus — Fri Apr 11, 2025 9:37 am