Log for on 27th April 2014:
Times are UTC Toggle Colours
00:54:48  <frosch123> <- 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
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> <- 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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
12:18:19  *** Alberth has joined
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
13:11:07  <michi_cc> Which I experimentally verified, IIRC
13:21:30  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r26523 || Logs: || 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>
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
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> <- 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> <- the string backport thingy; creates patches that often don't apply cleanly, but gives enough information to do it manually
15:07:19  <frosch123>
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> <- 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: || 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: || 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: || 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: || 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: || 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
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:
16:25:06  <fonsinchen> Basically, as long as we don't know all times refreshing the link is enough.
17:13:57  <fonsinchen> 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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
17:55:22  <frosch123> <- 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> <- 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
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: <- 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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:33:28  *** Alberth has left
19:36:40  <frosch123> <- 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:
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: || 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>
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>
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: <- 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>
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: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
20:42:52  <fonsinchen> <- 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: || 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: || 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: || 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>
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> 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

Powered by YARRSTE version: svn-trunk