Moderator: OpenTTD Developers
Currently you can sort stations by name, station type, freight and rating. I would like to add how many vehicles drive to this station.
So you can find well and poorly frequented stations on large maps easier.
that is, unless you add a cache for this kind of information, which in turn would require you to analyze all situations which would need to invalidate and recalculate the cache.
Effort: ca. 100LOC
I dont think you need 100 lines of code, because you can reuse the code from station, which shows the value for one station. You only need to iterate through all stations. But you have to do it for the other existing filters, too.
PS: But I understand the principle problem with the nested iteration.
What I do not understand is why does a vehicle have to go through all its orders? I just want to know how many trains stop at station xy, not how many trains unload or load there.
But can you explain more on your assessment of problems?Eddi wrote:fine, you can ignore my advice and assessment of problems. i'm awaiting your 10loc patch that magically avoids all the problems i mentioned, then. should be done in an hour?
I looked at the code, and the main issue I saw as someone unfamiliar with all the inner workings of OpenTTD and C++, is that there is no object-relation between orders (and thus vehicles) and stations, an order just has an ID that links it to the station (or depot or whatever else an order can point to)*. This would mean that the vehicle list that you can open from a station indeed needs to do a loop in some way to get the vehicles that are having orders for that station, but I couldn't find the piece of code responsible for that...
*I do find this very odd, so I'm not sure if my analysis is correct in any way.
Of course, this means if you want to build a map of vehicle count for all stations, it's not much more work than finding vehicle count for a single stations, so you could just do that instead. Question is then if you want to maintain that station-vehicle count map as a cache that then needs ongoing maintenance, as a cache that just gets recomputed once in a while, or not actually cache it.
Regardless, for large games, visiting all orders/vehicles in existence is not a cheap operation.
yes, that sounds correct. most of this code is from before object oriented programming was a thing.Transportman wrote:*I do find this very odd, so I'm not sure if my analysis is correct in any way.
TTO and TTD were written in pure assembler (back in the 90s this was commonly done because you could squeeze every bit of speed out of it, because compilers were sometimes not generating very optimized code, modern compilers are better in that respect). For OpenTTD that was rewritten in C (not ++), often very close to the original assembler code. C also does not have object orientation, but after OpenTTD got more and more code that resembled object oriented programming concepts, but had to reimplent that with plain C, it was finally decided to move to C++. However, large parts of the code remained untouched since then, still using the old concepts.
i haven't looked at the actual code, but there should e a static method "Station::FromID(id)" that can resolve this kind of link. (this is an inexpensive operation that hides some pointer/array arithmetics)Transportman wrote:an order just has an ID that links it to the station