Times are UTC Toggle Colours
00:54:48 <frosch123> http://devs.openttd.org/~frosch/settings2014.ods <- complete reshuffle of settings 00:54:57 <frosch123> removal of some settings from gui 00:55:17 <frosch123> merging of mapgen and game options into adv.settings tree 00:55:58 <frosch123> regrouping of settings into a tree from scratch which tries to group settings which are more likely to be accessed in the same context 00:56:53 <frosch123> which has as a side effect that game/company/client settings are in almost all cases separated in the tree at the top level 00:57:12 <frosch123> so that the filter for that is less important and could be removed 00:57:36 <frosch123> night 00:57:43 *** frosch123 has quit IRC 08:16:19 *** Supercheese has quit IRC 10:18:56 *** frosch123 has joined #openttd.dev 10:18:56 *** ChanServ sets mode: +v frosch123 10:24:37 <frosch123> any thoughts on my settings rant from last night? 10:26:00 <LordAro> sounded/looked reasonable to me 10:26:07 <LordAro> not that i looked very closely 10:27:37 <fonsinchen> Maybe the distinction between client and company settings should be toplevel 10:27:51 <fonsinchen> Then you can color code the categories to show what is saved where 10:28:16 <fonsinchen> How many km-ishs are a tile? 10:28:30 <fonsinchen> And does a day have 24 hours in OpenTTD? 10:29:03 <fonsinchen> (tile diameter in any direction, of course) 10:30:42 <frosch123> we have no hours in ottd? 10:30:47 <fonsinchen> I'm trying to come up with a rough estimate of travel times even before a vehicle has actually traveled the link 10:30:59 <frosch123> a day is DAY_TICKS ticks 10:31:12 <fonsinchen> I have distance and max speed. It should be possible to use that somehow. 10:31:33 <frosch123> a vehicle needs TILE_SIZE * GetAdvanceDistance(direction) to traverse a tile 10:31:51 <fonsinchen> What unit does that yield? 10:31:53 <frosch123> first thing to screw you is plane speed setting :) 10:32:37 <fonsinchen> I don't care about such details for now. 10:33:14 <frosch123> i think the GetAdvanceDistance is km-ish/h per tick 10:33:28 <frosch123> but maybe there is a factor 2 hidden somewhere 10:33:42 <fonsinchen> uh, tick is a time unit and h is a time unit, too. 10:33:48 * fonsinchen will have to dig into that 10:33:51 <frosch123> what is "h" ? 10:33:56 <fonsinchen> hours 10:34:05 <frosch123> from km-ish/h ? 10:34:10 <fonsinchen> yes 10:34:45 <fonsinchen> It might be that GetAdvenceDistance actually yields acceleration, but somehow I doubt that 10:35:03 <frosch123> ok, so: "distance in tiles" = "speed in km-ish/h" / (TILE_SIZE * GetAdvanceDistance(direction)" 10:35:45 <frosch123> * "time in ticks" 10:37:16 <fonsinchen> OK, I will try that. 10:38:25 <frosch123> if it fails, try adding some small integer factors like "2" :) 10:40:53 <Rubidium> IIRC a tile is 686 km or so 10:41:23 <Rubidium> A tile is, for vehicle speed purposes 664.(216) km-ish, 668 km or 415 miles long (game mechanics on wikipedia) 10:42:00 <Rubidium> s/pedia/page/ 10:43:32 <frosch123> @calc 664 / (16 * 192) * 74 / 24 10:43:32 <DorpsGek> frosch123: 0.666449652778 10:43:52 <frosch123> @calc 664 / (16 * 256) * 74 / 24 10:43:52 <DorpsGek> frosch123: 0.499837239583 10:44:02 <Rubidium> an hour is 3.08|3| ticks 10:44:06 <frosch123> ok, so above formula is off by factor 2 10:44:14 <frosch123> and the wiki assumes horizontal/vertical travelling 10:44:23 <fonsinchen> DAY_TICKS / 24 10:45:22 <frosch123> so: "distance in tiles" = "speed in km-ish/h" * 2 / TILE_SIZE / GetAdvanceDistance(direction) * "time in ticks" 10:46:37 <fonsinchen> thanks 10:49:21 <frosch123> or even: "distance in tiles using maximum norm" = "speed in km-ish/h" * 2 / TILE_SIZE / GetAdvanceDistance(direction) * "time in ticks" 10:55:46 <Rubidium> frosch123: that ods looks okay to me 10:56:50 <frosch123> idea would be to add all settings from mapgen/game options also into the tree (which won't work currently, since the tree cannot handle stuff like base media and custom curency) 10:57:15 <frosch123> and then remove most settings from game options/mapgen and instead adding a "details" button, which shows a pre-filtered adv. settings window 10:58:23 <Rubidium> yeah, I reckon 10:59:03 <frosch123> i think the older idea from fs#5147 to add different layouts to mapgen window is too complicated/not worth the effort. that is i would rather directly redirect to the tree 10:59:14 <Rubidium> I think the "solution" might be a generic class for drawing and getting height and some other stats which the current "advanced" settings use 10:59:23 <Rubidium> and specialisations for certain cases 11:00:30 <Rubidium> e.g. the base set: the description at the bottom of the settings thing could say something like: "Select the main graphics to be used for the game.\nDescription of the currently selected base graphics:\n{STRING}" 11:00:46 <frosch123> yeah, thought the same 11:01:48 <Rubidium> if "we" abstract enough, it should be that the data for the dropdown is on of those functions of the class 11:15:58 <frosch123> http://devs.openttd.org/~frosch/diffs/8bppsupport_2.diff <- reduced patch from last week 11:16:15 <frosch123> 8bpp support is now disabled by default, ottd will always use a 32bpp blitter and video mode 11:16:37 <frosch123> the setting is now config-only for people who want to "optimise their ottd" :p 11:22:13 <fonsinchen> I think the above formula has "time in hours", not "time in ticks" 11:22:43 <fonsinchen> So we need another "* DAY_TICKS / 24" somewhere 11:23:52 <frosch123> there is no 24 in ottd 11:24:27 <frosch123> ottd does not know about hours, so your formula should not have any 24 11:25:13 <frosch123> don't get fooled by the speed unit being named "per hour" 11:25:21 <frosch123> it's just an arbitrary number 11:26:28 <fonsinchen> Well, all results are off by a factor of 3 and the units suggest it. 11:27:17 <frosch123> maybe something with your distance metric? diagonal vs. orthogonal? 11:27:33 <fonsinchen> Manhattan and a road vehicle as test case 11:29:10 <frosch123> you get a factor 3 when using GetAdvanceDistance for the wrong direction 11:29:49 <frosch123> ah, wait, GetAdvanceSpeed() is missing in the formula 11:29:55 <fonsinchen> I should get 3/4 or 4/3 then 11:30:40 <frosch123> rv and trains use GetAdvanceSpeed, while ships and aircraft use GetOldAdvanceSeped or something 11:31:19 <frosch123> ah, ships and aircraft do not use GetAdvanceDistance, that's why there is a difference 11:32:19 <fonsinchen> So, you're saying that kmish/h should be called kmish/tick, right? 11:32:45 <frosch123> no, subcoords/tick :p 11:32:56 <fonsinchen> And GetAdvanceDistance should be called kmish/tile 11:33:05 <fonsinchen> what is a subcoord? 11:33:31 <frosch123> you need to get GetAdvanceSpeed and GetAdvanceDistance into the formula 11:33:53 <frosch123> there is a difference between diagonal/orthogonal movement 11:34:06 <fonsinchen> I'm only considering orthogonal for now 11:34:10 <frosch123> the speed is scaled since the map coordinates have different distance 11:35:20 <frosch123> the concatenation of GetAdvanceSpeed and GetAdvanceDistance seems to translate between km-ish/h and world-coordinates/tick 11:35:35 <frosch123> maybe with an addtional factor 2 hidden in the weird vehicle controllers 11:36:57 <frosch123> for orthogonal movement GetAdvanceSpeed and GetAdvanceDistance seem to concatenate into a simple 256 11:38:02 <frosch123> so, "orthogonal distance in tiles" = "speed in km-ish/h" * 2 / TILE_SIZE * "time in ticks" 11:38:16 <frosch123> err, "orthogonal distance in tiles" = "speed in km-ish/h" * 2 / TILE_SIZE / 256 * "time in ticks" 11:40:26 <fonsinchen> actually I think VehicleCache::cached_max_speed is way off and that's my problem. 11:41:26 <frosch123> that var may not use km-ish/h 11:42:10 <fonsinchen> argh 11:43:01 <frosch123> there are no floats in ottd :) vars use arbirtary fractional bits 11:43:25 <frosch123> maybe use a train for a start 11:43:34 <frosch123> for trains there is only km-ish/h afaik 11:44:37 <fonsinchen> GetDisplayMaxSpeed for the different vehicle types reveals some of the fun. 11:46:01 <fonsinchen> case OCV_MAX_SPEED: skip_order = OrderConditionCompare(occ, v->GetDisplayMaxSpeed() * 10 / 16, value) 11:46:04 <fonsinchen> great 11:46:31 <frosch123> so that one is in mph? 11:50:23 <fonsinchen> It comes from order_gui.cpp 11:50:53 <fonsinchen> Which is definitely on speed, big time 12:07:43 <Rubidium> you have to be on speed to understand the speed mess anyhow ;) 12:15:15 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26522 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 12:18:19 *** Alberth has joined #openttd.dev 12:18:20 *** ChanServ sets mode: +v Alberth 12:23:37 <fonsinchen> It seems that factor of 2 is bogus and otherwise GetAdvanceSpeed instead of speed is fine 12:23:54 <fonsinchen> Why did we introduce the *2 actually? 12:24:31 <fonsinchen> The remaining problem is due to the fact that the vehicle takes some time to reach full speed and starts braking well before it reaches the stop. 12:25:36 <frosch123> the traincontroller is called twice per tick, so in theory it may move twice per tick. but that part is so weird, that i do not remember the details 12:25:52 <frosch123> that's why i said the formula may be off by factor 2 or so 12:26:00 <frosch123> we added the 2 after it matched the wiki article 13:09:53 <michi_cc> fonsinchen: For YACD I used the formular in http://www.icosahedron.de/openttd/git/yacd.git/commitdiff/44c8d339cef81f434d872d8753264b62ceba580c#patch1 13:11:07 <michi_cc> Which I experimentally verified, IIRC 13:21:30 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26523 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 13:44:24 <frosch123> it's kind of hillarious how much code you can remove when removing the screenshot format setting from the gui 13:48:52 <Alberth> :) 14:00:07 <Rubidium> why? 14:00:56 <Rubidium> it doesn't look like a lot of code; looks like two dozens of lines or so to me 14:02:33 <frosch123> http://devs.openttd.org/~frosch/diffs/settings2014/10_screenshotformat.diff 14:02:47 <frosch123> all the magic involved in drawing the format names 14:05:13 <Rubidium> oh, removing it so it doesn't come back ;) 14:05:45 <frosch123> i don't think one would use the SPECSTR_ magic again 14:05:55 <Rubidium> nope 14:19:38 *** Alberth has left #openttd.dev 14:47:57 <fonsinchen> The auto-autofill timetable thing is too confusing, IMO. 14:48:05 <fonsinchen> I think I'll drop it. 14:48:36 <fonsinchen> I'll instead show the measured or estimated times in grey, and set them as default when you edit a time. 14:50:17 <fonsinchen> That way I can estimate a time right away when creating a link. I think I'll go for a very low and safe estimate like one day per tile, to keep that speed can of worms closed. 14:54:02 <fonsinchen> michi_cc: That seems better than my formula, but as I would rather like an upper bound on the time than a lower bound, I think I'll just go with something very simplistic. 14:54:34 <fonsinchen> If the estimated time is too low, the link will be overloaded and cargo may get stuck. 14:54:56 <fonsinchen> If the estimated time is too high, the vehicle will wait a little longer before it travels the first time. 14:55:06 <fonsinchen> The second one is clearly preferable. 14:56:32 <frosch123> if you want an upper bound you may want to use DistanceMaxPlusManhattan again, instead of pure manhattan 14:56:46 <fonsinchen> That's what I'll do. 14:57:40 <frosch123> http://devs.openttd.org/~frosch/diffs/settings2014/ <- the easy part, removal of settings from the gui 14:58:10 <frosch123> 620k diff of trashing translations :p 14:58:57 <LordAro> the best sort of diff 14:59:21 <frosch123> oh, i just hope i am not trashing something that supercheese already translated :p 14:59:58 <Rubidium> I guess you are ;) 15:00:18 <Rubidium> 10 looks okay 15:02:42 <Rubidium> 20/21 too 15:03:21 <Rubidium> likewise for 30 15:03:37 <Rubidium> do you still have the sed to remove all those strings? 15:03:56 <frosch123> in the console backlog 15:03:58 <frosch123> why? 15:04:16 <Rubidium> cause I'd need it for the string backporting 15:04:45 <Rubidium> the string backporting needs to remove those strings from the 1.4 source as well before doing the diff with strings to update 15:04:57 <LordAro> might be an idea to include it in a script in the repo? 15:05:34 <frosch123> LordAro: one line is one line 15:05:46 <Rubidium> the script itself isn't really interesting, it's the metadata 15:06:08 <LordAro> frosch123: yeah, but other people don't know it :p 15:06:15 <LordAro> would likely be useful to patch makers 15:06:46 <Rubidium> http://rbijker.net/openttd/make_diff.txt <- the string backport thingy; creates patches that often don't apply cleanly, but gives enough information to do it manually 15:07:19 <frosch123> http://paste.openttdcoop.org/show/3274/ 15:07:43 <Rubidium> updating the three needed lists of seds in the repo is going to be a good way to get the next part "soon" 15:08:11 <frosch123> mind that i did not bother separate seds for the _HELPTEXT tinhgies 15:08:25 <frosch123> except for DYNAMIC_ENGINES where there is some text remaining 15:09:56 <Rubidium> that's fine 15:10:26 <frosch123> http://paste.openttdcoop.org/show/3275/ <- missed STR_MAPGEN_RANDOM_SEED 15:11:54 <Rubidium> thanks; if there's something else I'll notice during backporting the strings I guess 15:12:10 <Rubidium> (like I normally do) 15:13:28 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26524 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 15:13:47 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26525 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 15:15:29 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26526 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 15:35:33 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26528 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 15:41:11 <frosch123> someone has a patch around for comitting? :p 15:41:50 <frosch123> one of the commit hooks got lost, so wt3 is out of sync and reports 23 missing strings for everyone :p 15:45:54 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26529 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 15:45:58 <frosch123> found something :p 15:56:41 <planetmaker> frosch123, I like the settings changes :) 15:57:21 <frosch123> yay, so i have at least some support when the forums notice them :p 15:58:16 <planetmaker> definitely you do :) 16:19:32 *** Alberth has joined #openttd.dev 16:19:32 *** ChanServ sets mode: +v Alberth 16:24:30 <fonsinchen> I found a very simple solution that doesn't require speed and distance estimations: https://github.com/ulfhermann/openttd/commit/28d1dfd07a2266fb1659c49e149df90fdad38580#src-linkgraph-refresh-cpp-P46 16:25:06 <fonsinchen> Basically, as long as we don't know all times refreshing the link is enough. 17:13:57 <fonsinchen> https://github.com/ulfhermann/openttd/commit/1ba2d7c12ea3cb3ec17143603e2ecd82ddcaa009 is less confusing than the autofill idea 17:14:55 <fonsinchen> Measured times are added to the timetable in braces: "Travel (last time: 5 days)" 17:16:19 <fonsinchen> If you click "change time" the field is populated with that value. 17:16:35 <fonsinchen> And "clear" removes it. 17:19:27 <frosch123> hmm, is it disallowed for the user to enter "0 ticks" loading time? 17:19:54 <fonsinchen> That is the same as "clear" 17:20:05 <fonsinchen> Has always been like that, actually. 17:20:11 <frosch123> ok :) 17:49:37 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26530 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 17:55:22 <frosch123> http://devs.openttd.org/~frosch/settings2014.png <- current status after shuffling, no new settings from other windows added yet 17:56:14 <frosch123> i wonder whether to move the "news/advisory" to top-level after "company" or so 17:58:23 <Rubidium> I'd move construction to be just after viewports 17:58:50 <Rubidium> news and advisors might not be really interface, so moving it top level seems okay to me 17:59:36 <planetmaker> company, news+advisors and accounting somewhat belong to eachother. So should be close to eachother, I think 18:01:45 <planetmaker> also following eachother: vehicles, limitations, disasters 18:02:24 <Rubidium> the construction move is to basically get sub sections before single element siblings 18:02:38 <planetmaker> world gen, environment and competitors in that order, too 18:03:24 <Rubidium> also s/Authorieties/Authorities/, s/Cargo Distribution/Cargo distribution/ and s/News and Advisors/News and advisors/ (for consistency's sake) 18:03:51 <planetmaker> and as to your question, frosch123: news+advisory can easily be a main section 18:15:06 <Alberth> first 3 can be interface too (localization, graphics, sound) 18:16:26 <planetmaker> yes. Should they be? 18:18:09 <Alberth> they look a bit small perhaps as top-level 18:19:22 <planetmaker> in my understanding, graphics and sound are supposed to gain the things so-far in game options 18:27:25 <planetmaker> but maybe you're right. It's logically a sub-category thereof 18:28:57 <Rubidium> http://rbijker.net/openttd/unmax.diff <- kinda replacing max with maximum for consistency 18:29:30 <Rubidium> e.g. in the (new) limitations section there's mixing of max and maximum 18:31:06 <planetmaker> hm, +1 18:40:10 *** Supercheese has joined #openttd.dev 18:40:10 *** ChanServ sets mode: +v Supercheese 19:11:39 <frosch123> i don't think the tree should be too deep 19:12:07 <frosch123> if we add the basesets and language and stuff then localization/graphics/sound is definitely toplevel 19:12:09 <planetmaker> no, not deeper than 3 at very most 19:12:28 <planetmaker> 2 is actually already quite deep 19:12:48 <planetmaker> but I've no strong opinion either way for those top or not top level 19:13:22 <frosch123> Supercheese: http://devs.openttd.org/~frosch/settings2014.ods <- that is about the target 19:15:16 <Supercheese> I presume "removed from GUI" but they can still be edited in the .cfg file 19:15:50 <Supercheese> although for most of those settings, who would ever change them, I know not... 19:17:36 <frosch123> many of them are compatibility settings for old savegames 19:18:21 <planetmaker> I agree on them being moved to invisible 19:18:39 <frosch123> anyway, that part is already done an committed :p 19:18:48 <frosch123> set in stone forever :) 19:19:06 <Supercheese> Indeed, and no one is sad to see them go methinks 19:19:45 <planetmaker> they're not gone anyway :) 19:19:54 <planetmaker> just... cleaned and stowed-away 19:32:23 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26531 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:33:28 *** Alberth has left #openttd.dev 19:36:40 <frosch123> http://devs.openttd.org/~frosch/settings2014_2.png <- i think in incorporated all 19:38:43 <Supercheese> Heh, "localisation" needs to be localized to "localization" ;) 19:39:04 <frosch123> that's not new 19:39:12 <Supercheese> I just find it humorous 19:39:45 <Rubidium> isn't localisation the UK spelling and locatization the US spelling? 19:39:58 <frosch123> maybe that's why people only write l10n :p 19:41:18 <Rubidium> since the 'base' language is UK English, it is localised correctly 19:47:47 <Supercheese> Right, I just meant in US english 19:48:16 <Supercheese> Of the few words that actually end up getting localized from UK -> US, the very word localisation is one 19:49:35 <Rubidium> few? 19:49:44 <Rubidium> sweets <-> candy 19:49:47 <Rubidium> quit <-> exit 19:49:53 <Rubidium> grey <-> gray 19:50:01 <Rubidium> candy floss <-> cotton candy 19:50:10 <Rubidium> litre <-> liter 19:50:20 <Rubidium> railway <-> railroad 19:50:23 <Supercheese> Sure, but statistically most words aren't changed 19:50:34 <Rubidium> tramway <-> streetcar 19:50:40 <Supercheese> Ugh, streetcar 19:50:40 <Rubidium> colour <-> color 19:50:42 <Supercheese> I hate that one 19:50:54 <Rubidium> cargoes <-> cargos 19:51:01 <Supercheese> If anything they're trolleys, but I'm fine with trams 19:51:13 <Rubidium> lorry <-> truck 19:51:32 <Supercheese> East Coast US English vs West Coast US English vs Southern US English :P 19:51:51 <Rubidium> and then all the ou -> o conversions, ize -> ise, yze -> yse etc. 19:52:22 <frosch123> planetmaker: do you also think, streetcar and trolley are like s-bahn and u-bahn? 19:53:42 <planetmaker> strassenbahn 19:53:49 <Rubidium> stadtbahn! 19:54:15 <Supercheese> For me at least, any cable-hauled or overhead-wire light rail systems that run in the same roads as cars are trolleys 19:54:15 <frosch123> exactly :) 19:54:18 * Rubidium was really annoyed to learn they taught him S-bahn was always the tram... 19:54:34 <Rubidium> Berlin kinda disobeys that 'rule' 19:54:40 <Supercheese> not streetcars, I don't even use that word 19:54:50 <frosch123> Supercheese: http://www.youtube.com/watch?v=_5hkR-IAnwQ 19:54:57 <planetmaker> Rubidium, s-bahn hardly ever is a tram, really. I think 19:55:03 <Supercheese> but then there's the streetcar named desire thing 19:55:10 <planetmaker> s-bahn is kinda railway but within the metropolitan area 19:55:21 * Supercheese shrugs 20:00:50 <Rubidium> planetmaker: but I was taught it was on school 20:01:22 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26532 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:01:33 <Rubidium> and it basically means they lied to me :( 20:01:50 <planetmaker> they probably just were ill-educated ;) 20:01:58 <frosch123> i don't think i learned about s-bahn in school 20:02:11 <frosch123> there was none in my home town :p 20:02:27 <Rubidium> planetmaker: it was in the book 20:02:41 <planetmaker> bad bad bad authors :) 20:08:54 <fonsinchen> http://devs.openttd.org/~fonsinchen/timetable.png 20:09:21 <fonsinchen> Is this clear enough or will people still be confused? 20:10:51 <planetmaker> fonsinchen, they will be confused. The time tabled time is 20 days while it says 'at least 12 days'. Not wrong, but... funky :) 20:11:20 <planetmaker> actually... there's more time scheduled, I just counted travel time, not load time 20:11:35 <planetmaker> another 18 days scheduled for stations 20:12:07 <fonsinchen> The question is how to make it clearer. It think it would be nice to have the new information available there. 20:12:29 <planetmaker> I like the 'last time: xxx' 20:12:33 <planetmaker> that's good 20:15:55 <frosch123> does it look silly if you make it grey? 20:16:04 <fonsinchen> I could add another line "The non-timetabled stops took xxx days on the last tour." 20:16:06 <fonsinchen> or that 20:16:31 <Rubidium> frosch123: that'll mess with the highlighting 20:17:01 <frosch123> yeah, it would not change when highlighted 20:17:55 <planetmaker> fonsinchen, what about "(unscheduled, ~4 days)" 20:18:41 <fonsinchen> let's see how that looks 20:19:29 <planetmaker> on first look I missed out on the difference between scheduled and unscheduled 20:20:16 <planetmaker> (unscheduled, approx. 4 days) might be better than ~4 days 20:21:00 <fonsinchen> maybe "(not timetabled, xxx days)" so that it matches the "not timetabled" where nothing is known 20:22:30 <Rubidium> maybe use ± ? 20:22:46 <Rubidium> requires some drawing for the base sets though 20:23:05 <planetmaker> that's why I suggested "approx" :) 20:23:10 <planetmaker> or ca. 20:23:12 <fonsinchen> "about 4 days"? 20:23:16 <planetmaker> or about :) 20:23:32 <Rubidium> though that might get pretty long 20:23:37 <fonsinchen> actually the measurements reflect the real time the vehicles have taken 20:24:25 <planetmaker> yes, I know. ... So leave out 'about' or alike. Just (not time tabled, 4 days) 20:24:27 <fonsinchen> "ca." is pretty short. Or "+/-" as a poor man's ± 20:25:55 <fonsinchen> http://devs.openttd.org/~fonsinchen/timetable2.png 20:27:33 <planetmaker> hm... what about the exact same format as the time tabled stuff, just append the (not timetabled) to the end of the string? 20:29:19 <fonsinchen> OK, let's try that ... 20:30:17 <planetmaker> you then could even re-use the strings. maybe 20:30:30 <frosch123> Rubidium: http://paste.openttdcoop.org/show/3280/ <- more for your script 20:31:26 <planetmaker> frosch123, what does the first line (et al) do? 20:31:43 <planetmaker> oh, remove? 20:32:04 <frosch123> /<pattern>/ <command> 20:32:10 <frosch123> D = remove current line 20:36:08 <fonsinchen> http://devs.openttd.org/~fonsinchen/timetable3.png 20:36:25 <fonsinchen> OK, the "(not timetabled)" should probably be before the speed limit ... 20:37:11 <planetmaker> hm, yes. But I like that version most 20:37:48 <fonsinchen> The other speed limit string is highly confusing, too... 20:37:55 <planetmaker> which other? 20:37:57 <fonsinchen> STR_TIMETABLE_TRAVEL_NOT_TIMETABLED_SPEED :Travel with at most {2:VELOCITY} (not timetabled) 20:38:15 <fonsinchen> "Uh, what? Is there a speed limit or not?" 20:38:20 <planetmaker> :) 20:38:46 <planetmaker> (not timetabled) Travel ist at most {2:VELOCITY} 20:38:50 <fonsinchen> Maybe we can just drop the "not timetabled" there as there isn't any time being mentioned anyway 20:39:35 <fonsinchen> - and the speed _is_ timetabled after all. 20:39:43 <frosch123> we need spreadsheets in ottd :) 20:39:55 <planetmaker> for orders we indeed could well use one 20:40:03 <frosch123> same here 20:40:53 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26533 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:42:52 <fonsinchen> http://devs.openttd.org/~fonsinchen/timetable4.png <- I like this one 20:44:41 <Rubidium> to me it feels like there is a timetable, after all... "stay for X days" 20:45:13 <planetmaker> fonsinchen, "Travel (not timetabled) with at most 44 km/h" ? 20:45:32 <planetmaker> makes it slightly more consistent imho 20:46:44 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26534 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:48:22 <fonsinchen> maybe the braces are better, after all 20:48:43 <fonsinchen> go to Blatown (5 days, not timetabled) 20:48:59 <fonsinchen> travel (4 days, not timetabled) 20:49:05 <planetmaker> no :) 20:50:30 <fonsinchen> planetmaker: What is wrong with that suggestion? 20:51:29 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26535 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:51:35 <planetmaker> nothing really 20:52:25 <planetmaker> just that I'd keep the time as for the timetabled strings and only add (not timetabled). But that really is just my personal favour and putting the time in the parenthesis as well for the non timetabled stuff is just as well justified 20:52:42 <planetmaker> and I might change my opinion on that tomorrow anyway. Bikeshedding XXL 20:52:57 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26536 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 20:54:15 <fonsinchen> I can add a "for"/"stay for" inside the braces 20:55:34 <planetmaker> hu? 20:57:02 <fonsinchen> so that it matches the timetabled strings better 20:57:08 <fonsinchen> screenshot coming 20:57:15 <fonsinchen> Oh, and it has a bug ... 20:58:29 <fonsinchen> http://devs.openttd.org/~fonsinchen/timetable5.png 21:01:16 <planetmaker> +1 21:02:04 <Rubidium> hmm... that reorder and add/remove strings is going to be a pain in the arse to backport 21:02:12 <Rubidium> guess I'll go for the nuclear option 21:02:31 * fonsinchen hides in the basement 21:04:53 <Rubidium> yeah... that works better... but results in slightly worse backports 21:05:45 <Rubidium> just marked the moved strings as removed and added so they don't show up in the diff and applying other changes might remain feasible 21:09:25 <fonsinchen> Rubidium: You're not talking about the timetable things, are you? I don't intend to backport those. 21:09:47 <Rubidium> nope, I'm talking about frosch123's work 21:10:09 <Rubidium> it just caused some strings to not be synced to 1.4 anymore 21:17:41 <fonsinchen> https://github.com/ulfhermann/openttd/commits/capacity contains the fix and the changed strings 21:18:28 <fonsinchen> I'll let it hang around there for a day or two just in case I find more strange corner cases to be handled. 21:19:12 <fonsinchen> good night 21:19:24 <planetmaker> g'night indeed 21:58:45 *** frosch123 has quit IRC 22:34:42 *** Supercheese has quit IRC