IRC logs for #openttd.dev on OFTC at 2013-03-17
⏴ go to previous day
08:39:23 *** Alberth has joined #openttd.dev
08:39:23 *** ChanServ sets mode: +v Alberth
08:52:22 *** ntoskrnl has joined #openttd.dev
09:22:04 *** FLHerne has joined #openttd.dev
11:15:31 <Alberth> It adds sorting on rating for towns. 20 is mine, and I rewrote the rating sorter (don't use values outside minimum or maximum, and also have a fixed order for unrated towns).
11:15:31 <Alberth> Biggest point of worry is whether I should copy the population string change in 10 to other languages as well
11:20:24 *** frosch123 has joined #openttd.dev
11:20:24 *** ChanServ sets mode: +v frosch123
11:21:06 <Alberth> I was a bit early I see :)
11:21:14 <Alberth> (12:15:31 PM) Alberth: It adds sorting on rating for towns. 20 is mine, and I rewrote the rating sorter (don't use values outside minimum or maximum, and also have a fixed order for unrated towns).
11:21:14 <Alberth> (12:15:31 PM) Alberth: Biggest point of worry is whether I should copy the population string change in 10 to other languages as well
11:25:21 <frosch123> haha, STR_SORT_BY_POPULATION looks funny between the engine sorting criterions :)
11:27:46 <Alberth> maybe we should add a sort for most popular engine to the buy menu :)
11:30:25 <frosch123> we had some sort-stability issues in the past, so maybe TownRatingSorter should detet towns with equal rating and sort them by name
11:32:00 <frosch123> + this->last_sorting = this->towns.GetListing(); // Store new sorting order <- is this correct in 30? or does it belong to an earlier diff?
11:43:46 <Alberth> In ~TownDirectoryWindow(): this->last_sorting = this->towns.GetListing();
11:44:23 <Alberth> so it was a 'save last sort order' value, and now it gets used more often
11:44:48 <frosch123> remove it from ~TownDirectoryWindow() then?
11:44:51 <Alberth> the sorter functions are not part of the window
11:47:35 <Alberth> I'd move it to the BuildSortTownList then
11:58:43 <Alberth> you are right, it can be removed then
12:14:55 *** Ristovski has joined #openttd.dev
12:47:08 <frosch123> in preparation of fs#5504
13:31:28 <frosch123> i posted a diff in fs#5504
13:31:36 <frosch123> it works for SDL but needs work for other video drivers
13:31:43 <frosch123> however, it changes quite a lot :p
13:34:25 *** frosch123 has joined #openttd.dev
13:34:25 *** ChanServ sets mode: +v frosch123
13:40:26 *** ntoskrnl has joined #openttd.dev
13:56:46 <Alberth> I stabilized the order for populations as well
13:58:05 <Alberth> that broke the Toggle sorter as well, so I had to move more code to an earlier place in the queue
13:59:19 <frosch123> hmm, so the secondary name sorter does not follow the sorting order?
13:59:30 <frosch123> in that case ToggleSortOrder would never work
13:59:51 <frosch123> why not just reverse the naming order as well in that case?
14:01:39 <Alberth> then in the rating you keep ascending, and in population you swap
14:02:13 <Alberth> which didn't seem like a good idea
14:02:30 <frosch123> well, fine either way
14:03:05 <frosch123> it just feels weird that adding a secondary sorting criteria just to make it stable breaks something fundamental like reversing sort order
14:04:13 <Alberth> the other option is of course to reverse non-rated towns as well
14:04:34 <Alberth> then only the 'rating' case is not truly sorted
14:07:29 <frosch123> yeah, treating the "not rated" case separately is fine
14:07:51 <frosch123> though i wonder whether the industry directory does the same wrt. industries with no production :p
14:13:48 <Alberth> return (r == 0) ? IndustryNameSorter(a, b) : r;
14:15:38 <Alberth> I should revert 'always ascending sort' in population?
14:17:01 <frosch123> wrt. population or wrt. secondary name?
14:17:18 <frosch123> sorting population descending by default sounds useful
14:20:06 <Alberth> the secondary sort criterium
14:20:42 * Alberth ponders secondary sort criteria in general :(
14:20:51 <frosch123> i think reversing the list should just reverse it
14:21:05 *** ChanServ sets mode: +o orudge
14:21:07 <frosch123> i don't think forcing the secondary order to be always ascending would be right
14:22:01 <frosch123> sorting items with "no rating" at the end independent of ascending/descrending rating sorting is fine though :)
14:22:02 <Alberth> I thought it'd be nicer, but I can live without it very well too
14:22:28 <Alberth> it's broken there anyway :)
14:51:09 *** Ristovski has joined #openttd.dev
14:58:37 <Alberth> I also removed the 'always ascending' order by name for equal rated towns
15:01:25 <frosch123> apparently i was not able to trick you into fixing the industry directory :)
15:04:56 <frosch123> sorting industry without any output cargos always at the end when sorting by producton/transportation amount
15:05:41 <Alberth> oh, I thought just stabilizing, but that was already done
15:05:46 *** Tiku has joined #openttd.dev
15:06:57 <Alberth> well, mostly a-b is not always overflow safe :p
15:07:47 <frosch123> i am quite sure in this case it is :p
16:00:53 *** ChanServ sets mode: +v Rubidium
16:02:19 <Rubidium> Alberth: is there a 'fix translations' commit in the pipe line? In r25094 you changed a string which could easily be fixed by a regexp; the order of strings in the translation does not matter, and WT3 will automagically order them correctly on its first commit of the language
16:04:09 <Alberth> there wasn't one planned, but that can be changed :)
16:04:39 <Alberth> so just change the string name and remove the '{BLACK}' ?
18:22:12 <frosch123> both AircraftVehicleInfo::acceleration and Vehicle::acceleration are bytes
18:26:42 <Alberth> I always wonder how many bits the intermediate types have in these case :) it looks fine to me
18:32:05 *** Zuu has joined #openttd.dev
19:07:57 *** Supercheese has joined #openttd.dev
19:30:41 <frosch123> hmm, looks like the aircraft acceleration stuff in ottd is all nonsense
19:30:58 <frosch123> all screwed up in unit conversions
20:05:08 *** Alberth has left #openttd.dev
20:31:44 <Zuu> I was taking a look on a GS and realised that users are not given the choice to edit GS settings in a running game (unless they know that it is possible via the AI debug window) Thus I've created a small patch for this https://secure.openttd.org/bugs/task/5507
20:59:49 <Rubidium> I doubt the aircraft mess will be resolved soon, and it probably needs more testing anyhow
20:59:58 <Rubidium> the current state seems fairly trivial to me
21:02:33 <frosch123> hmm, it's actually easy
21:02:40 <frosch123> i just need to remove the 128/10 conversion
21:34:34 *** Dewin has joined #openttd.dev
21:57:21 <frosch123> broken since r8973 :)
21:57:31 <frosch123> which added unit conversion for newgrf, but not for default
21:57:47 <frosch123> and the acceleration code seems to use some random multiplier
22:54:27 <Zuu> Hmm in-game changing of AI settings appears to also be disabled via the config GUI for players. Only via the AI debug window this have been possible. Thus a) my patch/commit might be a -Feature rather than a -Fix. b) it should enable editing AI settings the same way.
22:55:19 <Zuu> c) notice, that AI/GS settings can only be edited if an author activly have told OpenTTD so. Default is that settings can't be changed. That being said, most AIs/GSs have at least one setting that can be configured in a running game.
continue to next day ⏵