Sort train (vehicles) list
Moderator: OpenTTD Developers
Sort train (vehicles) list
Hello,
I have implemented new feature -- possibility of sorting train list window by:
train number, train profit, train profit last year and train age.
I'm finding this very useful when managing large number of trains.
But have a few doubts...
First of all, should I directly submit the patch to Patch tracker on SourceForge?
Or rather clear all my doubts before doing so here?
I don't want to trash OTTD repository on SF with unwanted patches.
Another issue, is that I'm aware that my patch may be a bit CPU hungry.
I don't think that can affect any recent machine (mine doesn't at all), but
I would prefer that developers tell what they think about that kind of soulutions.
I was trying to follow way of how 'Industry Directory' sorting is done.
But for trains, I believe, storing presorted array is pointless (profits data keep changing
continuously).
So I end up on resorting train list on every WE_PAINT and WE_CLICK. And this may eventually affect some old machines.
I'm attaching screenshot and will add patch after I clean it up.
Of course it will be easy to enhance it for other vehicles as well....
BTW. Do you prefer patch against latest official version or aginast CVS (or whatever you call it)?
Jan
I have implemented new feature -- possibility of sorting train list window by:
train number, train profit, train profit last year and train age.
I'm finding this very useful when managing large number of trains.
But have a few doubts...
First of all, should I directly submit the patch to Patch tracker on SourceForge?
Or rather clear all my doubts before doing so here?
I don't want to trash OTTD repository on SF with unwanted patches.
Another issue, is that I'm aware that my patch may be a bit CPU hungry.
I don't think that can affect any recent machine (mine doesn't at all), but
I would prefer that developers tell what they think about that kind of soulutions.
I was trying to follow way of how 'Industry Directory' sorting is done.
But for trains, I believe, storing presorted array is pointless (profits data keep changing
continuously).
So I end up on resorting train list on every WE_PAINT and WE_CLICK. And this may eventually affect some old machines.
I'm attaching screenshot and will add patch after I clean it up.
Of course it will be easy to enhance it for other vehicles as well....
BTW. Do you prefer patch against latest official version or aginast CVS (or whatever you call it)?
Jan
- Attachments
-
- Example: sort train list by profit last year
- trainlist_sort.png (46.61 KiB) Viewed 8986 times
Re: Sort train (vehicles) list
All patches should go to the SF repository. If a patch is wrong or messy, comments, suggestions and maybe help (if we know how to do it) will be given on how to improve the patch. No patch will be flamed or shot down because of problems. The only issue is that of course the patcher, or coder should look on SF once in a while to see if comments have been added to his post/patch/bugreport (if he/she hasn't registered, and so SF cannot send an email notification).follow wrote:First of all, should I directly submit the patch to Patch tracker on SourceForge?...
I don't want to trash OTTD repository on SF with unwanted patches.
You do have to keep in mind that OTTD not only runs on PXII with 3TB of mem, but also on handhelds or older P100 machines. Thus best would be to try to write the code as efficiently as possible.follow wrote:Another issue, is that I'm aware that my patch may be a bit CPU hungry.
I don't think that can affect any recent machine (mine doesn't at all), but
I would prefer that developers tell what they think about that kind of soulutions.
All patches should be made against the latest available SVN development version. That way you can test your code with the latest code, and the developers don't have to resolve any issues and conflicts that arise because the patch was made for an old version.follow wrote:BTW. Do you prefer patch against latest official version or aginast CVS (or whatever you call it)?
I have to ask around about this patch. There has already been such a patch [ 955500 ] All vehicles lists Sorting. It has however been turned down because the general idea was to have a different setup for vehicles. As I am not sure if this will be done in any short term

TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
Ok,
So after all:
I understand performace issues, and that's way I'm asking if you fill
that one qsort of user all trains (or other vehicles) per WE_PAINT and WE_CLICK.
per train list window may be ok or not...
Also, should I spend any more time, to prepare the patch, or this is pointless,
because it will be rejected for the same reason as 955500 you reference.
To be honest, 955500 seems to be much superior than mine (but patch itself
is no longer available, only screenshot, so I can't test myself).
My personal opinion is that if you not currently reworking vehicles array, you should
generally accept these patches.
Just let people use it for a while (or years, who knows...).
Eventually maybe you can impose condition, that patch should be written in such
way that you can change behaviour to the initial one with one click (or rather #define)
This should be doable in general.
Thanks
Jan
So after all:
I understand performace issues, and that's way I'm asking if you fill
that one qsort of user all trains (or other vehicles) per WE_PAINT and WE_CLICK.
per train list window may be ok or not...
Also, should I spend any more time, to prepare the patch, or this is pointless,
because it will be rejected for the same reason as 955500 you reference.
To be honest, 955500 seems to be much superior than mine (but patch itself
is no longer available, only screenshot, so I can't test myself).
My personal opinion is that if you not currently reworking vehicles array, you should
generally accept these patches.
Just let people use it for a while (or years, who knows...).
Eventually maybe you can impose condition, that patch should be written in such
way that you can change behaviour to the initial one with one click (or rather #define)
This should be doable in general.
Thanks
Jan
Real programmers know when qsort isn't quick. True, the trains list may become somewhat unsorted in time, but in general it's pretty well sorted. In such cases, bubblesort performs pretty well, and naive qsorts fail miserably. qsort is not designed for nearly-sorted lists but for general-purpose sorts. So you'd use it only the first time, and use bubblesort to stay sorted.
(bubblesort is the optimal sort when your list is already sorted
)
(bubblesort is the optimal sort when your list is already sorted

Yes, unfortunately patch has been removed. I have talked about reworking the list. When SVN is back up I will see if that can be done easily and in a short notice. If not, then I will add your patch, since I also do feel that that list really needs to be sorted.follow wrote:My personal opinion is that if you not currently reworking vehicles array, you should
generally accept these patches.
Just let people use it for a while (or years, who knows...).
Eventually maybe you can impose condition, that patch should be written in such
way that you can change behaviour to the initial one with one click (or rather #define)
This should be doable in general.
Thanks
Jan
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
I understand your point, but you overlooked one think. My patch is (or will be) givingmsalters wrote:Real programmers know when qsort isn't quick. True, the trains list may become somewhat unsorted in time, but in general it's pretty well sorted. In such cases, bubblesort performs pretty well, and naive qsorts fail miserably. qsort is not designed for nearly-sorted lists but for general-purpose sorts. So you'd use it only the first time, and use bubblesort to stay sorted.
(bubblesort is the optimal sort when your list is already sorted :D )
possibility of sorting the list by different criteria, so assumtion that list is already
(nearly) sorted, will be wrong in most cases.
There is an option is to keep sorted lists (in currently selected criteria) for every vehicle type and for every player, and yes - you can bubblesort it then, but you need to keep all these lists in memory for all the time.
So you can save some CPU, but loose some memory. And this was my question in general.
To be told by somebody experienced, which approach he likes better.
Ok, thanks for looking at this.Darkvater wrote: Yes, unfortunately patch has been removed. I have talked about reworking the list. When SVN is back up I will see if that can be done easily and in a short notice. If not, then I will add your patch, since I also do feel that that list really needs to be sorted.
If you fell that patch may be accepted, let me know (here). I'll cleanup the patch agains latest
SVN, and add sorting of all vehicle types.
Or earlier, I'll try to conatct autor of patch 955500 to resubmit it to SF.
Thanks again.
Jan
If you're swapping the vehicles as you sort them, surely you could just swap entries in the vehicle array?follow wrote:<blablabla>
There is an option is to keep sorted lists (in currently selected criteria) for every vehicle type and for every player, and yes - you can bubblesort it then, but you need to keep all these lists in memory for all the time.
So you can save some CPU, but loose some memory. And this was my question in general.
To be told by somebody experienced, which approach he likes better.

You not really want to do that. All kinds of other stuff depend on the correct index in the vehicles array. If you sort them there, you need to update those too; then the things that depend on them, etc. etc.BobXP wrote:If you're swapping the vehicles as you sort them, surely you could just swap entries in the vehicle array?
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
Argh...BobXP wrote:If you're swapping the vehicles as you sort them, surely you could just swap entries in the vehicle array?
To avoid confusion...
I do not sort vehicle records. I sort only indexes to them.
Otherwise it would mean awful memory copying...
(and of course I'm not touching original array)
Sorry I didn't initially post the patch for reference, but I would prefer to review
it and add missing parts before doing so.
Jan
You can sort by age...at least I think you can.Cipri wrote:Would it also be possible to sort the train list by Engine-type?
I'm sure we've all sat there at one point scrolling all the way down trough that list, to upgrade older engines to newer ones
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
Who is online
Users browsing this forum: Ahrefs [Bot] and 15 guests