Times are UTC Toggle Colours
00:00:12 <glx> hmm but I don't think this one is called 00:02:16 <glx> XXXtype_list() functions in action0properties.py 00:03:34 <glx> only checks it's an array of litterals, but doesn't check the length of the litterals 00:06:58 <FLHerne> Yuck, more copy-pasting 00:07:07 <glx> yeah noticed 00:09:32 <FLHerne> Also, I don't see why it shouldn't take identifiers, like railtypetable? 00:09:36 <FLHerne> (optionally) 00:11:54 <glx> they're just label lists 00:12:18 <glx> without any validation because these labels could be defined by other grfs 00:14:28 <FLHerne> That's equally true of railtypetable entries, no? 00:14:37 <FLHerne> It's just a list of 4-character labels 00:14:41 <glx> yes 00:15:10 <glx> it's just nobody ever though to check the length :) 00:15:32 <glx> and factorise the 3 things 00:16:23 <FLHerne> I wrote a patch that factorized most of the other 3 things 00:16:26 <FLHerne> Missed this one 00:16:32 * FLHerne tries to fix 00:16:37 <FLHerne> Unless you've started 00:16:50 <glx> no I'm just reading the code :) 00:17:12 <FLHerne> Seriously, the entire implementation of NRT was this copy-pasted-in-triplicate nonsense 00:17:14 <glx> but the 3 ListProp are exaclty the same 00:52:32 <DorpsGek_III> [OpenTTD/nml] FLHerne opened pull request #132: Cleanup: Tidy tracktype properties and check label length https://git.io/JfCqU 01:56:14 *** spnda has quit IRC 02:13:24 *** D-HUND has joined #openttd 02:16:41 *** debdog has quit IRC 02:16:55 *** Tirili has joined #openttd 02:22:56 *** Flygon has joined #openttd 03:13:37 *** glx has quit IRC 03:32:24 *** Tirili has quit IRC 04:38:57 *** Laedek_ has quit IRC 05:02:44 *** snail_UES_ has quit IRC 05:21:18 *** namad7 has joined #openttd 05:27:12 *** namad7 has quit IRC 06:19:11 *** andythenorth has joined #openttd 06:19:16 <andythenorth> o/ 06:52:22 *** Progman has joined #openttd 07:24:32 *** sla_ro|master has joined #openttd 07:25:15 *** Wolf01 has joined #openttd 07:27:11 *** iSoSyS has joined #openttd 07:41:57 <DorpsGek_III> [OpenTTD/nml] LordAro commented on pull request #125: Codechange: Build examples in regression testing https://git.io/JfC02 07:43:10 <DorpsGek_III> [OpenTTD/nml] LordAro commented on pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests. https://git.io/JfC0K 07:44:36 <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #123: Doc: Add a use of `roadtype()` to the examples. https://git.io/JfC0M 07:45:45 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8124: Fix #8119, f538179: Update docking tile area when placing a diagonal rail next to a dock end https://git.io/JfC0y 07:47:36 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #8116: Old patchpack savegame versions will soon overlap https://git.io/JfZsT 07:47:36 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on issue #8116: Old patchpack savegame versions will soon overlap https://git.io/JfZsT 07:49:43 *** supermop_Home has quit IRC 07:54:41 *** iSoSyS has quit IRC 08:05:08 <DorpsGek_III> [OpenTTD/nml] FLHerne merged pull request #123: Doc: Add a use of `roadtype()` to the examples. https://git.io/Jfc2O 08:08:27 <FLHerne> LordAro: That's from copying the equivalent command for the current regression tests, which is also -u 08:08:29 *** cHawk has joined #openttd 08:09:19 <FLHerne> As you say, I can't imagine a good reason for it though 08:16:40 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests. https://git.io/JfcjU 08:28:38 <FLHerne> LordAro: It actually makes zero difference, since it just prints "Binary files * and * differ" anyway 08:30:04 *** WormnestAndroid has quit IRC 08:30:17 *** WormnestAndroid has joined #openttd 08:33:55 *** WormnestAndroid has quit IRC 08:34:08 *** WormnestAndroid has joined #openttd 08:47:36 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #125: Codechange: Build examples in regression testing https://git.io/JfcXX 08:49:27 <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests. https://git.io/JfCzp 08:49:34 <DorpsGek_III> [OpenTTD/nml] LordAro merged pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests. https://git.io/JfcjU 08:56:16 <Wolf01> andythenorth: new trucks https://9gag.com/gag/abG5PKL 08:56:58 <andythenorth> haha 08:57:23 <Wolf01> https://img-comment-fun.9cache.com/media/a5Z1rpV/apr5Q39R_700w_0.jpg it seem to be for this reason 08:57:40 <andythenorth> looks suicide, probably fine 09:04:56 *** iSoSyS has joined #openttd 09:05:32 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl commented on issue #8116: Old patchpack savegame versions will soon overlap https://git.io/JfZsT 09:07:33 *** matt21347 has joined #openttd 09:13:59 <_dp_> https://www.lmwindpower.com/-/media/images/stories-and-articles/h-88-transport-2.jpg 09:20:39 <nielsm> definitely an oversized transport 09:25:27 <_dp_> I wonder how much will it glitch if done in openttd 09:26:37 <LordAro> "a lot" 09:27:43 <_dp_> overglitchy load xD 09:28:06 <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick updated pull request #8124: Fix #8119, f538179: Update docking tile area when placing a diagonal rail next to a dock end https://git.io/Jfcyk 09:28:26 *** Samu has joined #openttd 09:31:26 <Samu> hi 11:15:00 *** Laedek has joined #openttd 11:21:53 <FLHerne> nielsm: Do you remember what the general intention of the industry example was meant to be? Some sort of stockpiling mechanic? 11:23:30 <nielsm> I don't think there was any functional purpose of it other than showing valid syntax 11:23:43 <nielsm> the example in the wiki documentation is more complete 11:40:46 *** plstc has quit IRC 11:42:16 *** plstc has joined #openttd 11:51:41 <andythenorth> I was considering maybe 4 example industries 11:51:52 <andythenorth> primary, secondary, town black hole, water based 11:52:03 <andythenorth> I'm having a few days off writing any code though :) 11:52:07 <andythenorth> so feel free to ignore me 12:02:26 <FLHerne> I don't think I'll try writing an example, I don't know how to do it :P 12:04:49 <Samu> i rebased and it seems to have failed 12:04:59 <Samu> https://github.com/OpenTTD/OpenTTD/pull/8124#issuecomment-626123647 12:05:04 <Samu> LordAro, 12:06:40 <Samu> https://github.com/OpenTTD/OpenTTD/pull/8124/checks?check_run_id=658719384 it succeeded but still says Some checks haven’t completed yet 12:07:38 <LordAro> weird. 12:08:29 <LordAro> must be a github/azure thing 12:08:33 <LordAro> can't imagine what else it would be 12:12:46 <DorpsGek_III> [OpenTTD/OpenTTD] Mysteron347 opened issue #8126: Stations being visited against instructions. https://git.io/JfCiO 12:13:49 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro opened pull request #8127: Add: [AzurePipelines] Ubuntu Focal (20.04) build for releases https://git.io/JfCiG 12:15:46 *** glx has joined #openttd 12:15:46 *** ChanServ sets mode: +v glx 12:16:30 <LordAro> trains have always stopped at stations they pass through, unless a non-stop order is explicitly specified, right? 12:16:52 <glx> yeah I think 12:16:54 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #8126: Stations being visited against instructions. https://git.io/JfCiO 12:16:55 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh closed issue #8126: Stations being visited against instructions. https://git.io/JfCiO 12:17:00 <LordAro> yes :) 12:17:05 <glx> implicit orders 12:20:29 <DorpsGek_III> [OpenTTD/OpenTTD] TrueBrain requested changes for pull request #8127: Add: [AzurePipelines] Ubuntu Focal (20.04) build for releases https://git.io/JfCiB 12:20:38 <nielsm> also the network construction in that save is really weird and it will give the player countless headaches 12:20:46 <TrueBrain> silly LordAro :) 12:21:53 <FLHerne> I do find it weird that implicit orders are the default 12:22:11 <FLHerne> Very few people intentionally use them, and they cause a lot of confusion 12:22:48 <FLHerne> (tbh, I find it weird that implicit orders /exist/, what problem do they solve?) 12:23:04 <FLHerne> Except for the SRNW people 12:23:25 <DorpsGek_III> [OpenTTD/nml] FLHerne opened pull request #133: Doc: Remove broken code from industry example. https://git.io/JfCi2 12:23:49 <glx> hehe reminds me of #7811 12:24:11 <DorpsGek_III> [OpenTTD/nml] TrueBrain commented on pull request #115: Fix #112: use setuptools_scm to determine version https://git.io/JfCiV 12:26:48 <FLHerne> glx: Looking at ^, I don't really see what setuptools_scm helps with :-/ 12:27:33 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8127: Add: [AzurePipelines] Ubuntu Focal (20.04) build for releases https://git.io/JfCiM 12:27:46 <FLHerne> I guess it saves having our own git-version code, but that's already written 12:28:10 <TrueBrain> LordAro: last time you did it right :D Seems you are getting old my friend :) 12:29:50 <LordAro> :< 12:30:06 <LordAro> i did pass 1/4 century a few days ago 12:30:17 <TrueBrain> gratz :) 12:30:48 <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #133: Doc: Remove broken code from industry example. https://git.io/JfCi5 12:30:57 <DorpsGek_III> [OpenTTD/CompileFarm] LordAro opened pull request #43: Add: Ubuntu focal image https://git.io/JfCid 12:32:32 <TrueBrain> good luck with these new errors :D 12:32:40 <TrueBrain> cannot utime .. really .. wth 12:33:00 <LordAro> oh heavens 12:38:12 *** plastic has joined #openttd 12:38:57 <andythenorth> 1/4 century is so far in my past :( 12:38:59 <andythenorth> oof 12:40:32 <TrueBrain> I did not want to highlight that part andythenorth ; we are just silently letting that slip ;) 12:40:34 *** frosch123 has joined #openttd 12:43:29 <DorpsGek_III> [OpenTTD/nml] glx22 approved pull request #132: Cleanup: Tidy tracktype properties and check label length https://git.io/JfCP9 12:45:28 <LordAro> TrueBrain: something to do with parent directory ownership, i think? 12:45:38 <TrueBrain> I really and honestly don't know 12:45:42 <TrueBrain> never seen that error 12:45:46 *** plstc has quit IRC 12:46:04 <glx> it's really weird, maybe an hardware issue 12:46:04 <LordAro> https://superuser.com/questions/1219214/permissions-cannot-be-restored-for-a-tar only thing i can find 12:46:31 *** Yexo has joined #openttd 12:46:31 *** ChanServ sets mode: +o Yexo 12:47:43 <LordAro> glx: it's suspicious that it only happened for the 32 bit focal image though 12:50:18 <glx> but I see no trace of libc in 64 bit log 12:50:36 <LordAro> well yes, because that would be already installed 12:50:46 <LordAro> this is it trying to install libc:i386 on a 64bit system 12:51:01 <LordAro> https://hub.docker.com/layers/ubuntu/library/ubuntu/focal/images/sha256-5747316366b8cc9e3021cd7286f42b2d6d81e3d743e2ab571f55bcd5df788cc8 no sign of 386 architecture here, though i think i'm looking in the wrong place 12:51:13 <glx> is there a 32 bit focal ? 12:51:48 <LordAro> i thought there was... 12:51:56 <LordAro> perhaps not 12:52:45 <LordAro> error message is weird, anyway 12:52:56 <glx> https://packages.ubuntu.com/fr/focal/libc6-i386 12:53:01 <TrueBrain> maybe also drop i386 for focal? Sounds about time to do so ;) 12:53:14 <DorpsGek_III> [OpenTTD/CompileFarm] LordAro updated pull request #43: Add: Ubuntu focal image https://git.io/JfCid 12:53:26 <glx> it's an amd64 package 12:54:35 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro updated pull request #8127: Add: [AzurePipelines] Ubuntu Focal (20.04) build for releases https://git.io/JfCiG 12:54:36 <LordAro> glx: but it always has been 12:55:59 <TrueBrain> know that the docker URL for i386 and amd64 are widely different 12:56:12 <TrueBrain> I believe i386 is even not done by upstream maintainers, but by some random people :) 12:56:17 <TrueBrain> anyway, i386 is silly in 2020, tbfh 12:57:02 <LordAro> mm yes 12:58:43 <LordAro> "Maintained by: Canonical and Tianon (Debian Developer)" 12:58:46 <LordAro> well, not entirely random 13:01:05 <glx> https://wiki.ubuntu.com/FocalFossa/ReleaseNotes says it "Upgrades on i386 13:01:05 <glx> 13:01:05 <glx> Users of the i386 architecture will not be presented with an upgrade to Ubuntu 20.04 LTS. Support for i386 as a host architecture was dropped in 19.10. " 13:06:41 *** iSoSyS has quit IRC 13:37:38 <DorpsGek_III> [OpenTTD/OpenTTD] Mysteron347 opened issue #8128: Mexican Stand-off https://git.io/JfCyz 13:38:19 <FLHerne> Signalling mistake? 13:39:10 * FLHerne tries 13:39:22 <glx> haha python is so annoying, I had an issue with the install path containing non ascii, but python 3.7 generated temp path were generated using short names 13:39:58 <glx> I fixed the install path issue for python 3.8, but now it generates temp path with full name, so back to the non ascii path issue :) 13:41:07 <DorpsGek_III> [OpenTTD/OpenTTD] Mysteron347 commented on issue #8126: Stations being visited against instructions. https://git.io/JfCiO 13:45:33 <FLHerne> Hm, the behaviour in that save does seem a bit odd 13:46:01 <Yexo> Reversing the train makes a pbs reservation, which increases the cost for the other train enough so it goes around 13:46:33 <Yexo> Looks odd, but I don't think this is fixable in a general sense: any tweak to pathfinder costs will lead to the same situation with a slightly modified scenario 13:46:58 <Yexo> Don't trains automatically reverse at some point? Or am I misremembering that? 13:47:38 <FLHerne> There's a setting for it 13:47:40 <Yexo> Oh, "Automatic reversing at signals" is off by default 13:47:44 <Yexo> and also off in that savegame 13:47:55 <FLHerne> I'm sure this doesn't normally happen 13:48:18 <FLHerne> Even if I change the "passing loops" so they're almost the same length, they still wait 13:48:45 <Yexo> It's easily fixable by changing the signals: don't allow trains to wait at the entrance to the section with the passing loop 13:48:56 <FLHerne> *exactly* the same length (with offset ends) works 13:49:15 <FLHerne> And yes, it's not a very sensible design 13:49:32 <FLHerne> But it seems that the train in the loop has no pathfinder cost at all 13:49:47 <FLHerne> Or not enough to outweigh two tiles of empty plain track 13:50:03 <FLHerne> Which doesn't seem right 13:50:10 <Yexo> I don't think trains have a pathfinder cost, only the pbs-reserved rails have 13:50:23 <FLHerne> Hm, and because they're really short...? 13:50:40 <Yexo> And with sensible tracks you want that cost to be low, since if you assume the train is moving the track most likely clears before you get to it 13:50:48 <Yexo> Yes, the really short length makes this worse here 13:55:55 <DorpsGek_III> [OpenTTD/nml] FLHerne merged pull request #132: Cleanup: Tidy tracktype properties and check label length https://git.io/JfCqU 14:00:16 <DorpsGek_III> [OpenTTD/nml] jrook1445 opened issue #134: nml 0.5.0 - PALETTE_CC_RED value in global_constants.py https://git.io/JfCSl 14:04:24 <LordAro> looks like c&p error 14:04:48 <DorpsGek_III> [OpenTTD/nml] FLHerne opened pull request #135: Fix #134: Incorrect value of PALETTE_CC_RED https://git.io/JfCSu 14:05:14 <DorpsGek_III> [OpenTTD/OpenTTD] nickpan commented on issue #7623: Support for macOS Catalina. https://git.io/fj2uh 14:05:31 <FLHerne> Yexo: It looks like no-one spotted that since you typed it 9 years ago :P 14:05:41 <DorpsGek_III> [OpenTTD/nml] Yexo approved pull request #135: Fix #134: Incorrect value of PALETTE_CC_RED https://git.io/JfCSz 14:06:03 <Yexo> Exactly. Last change was already a fix for wrong values: https://github.com/OpenTTD/nml/commit/dcc837be5255beb7cecc43ff65a77b46136f8be9 14:06:46 <FLHerne> LordAro: What does the "testing" GH action actually do? 14:07:02 <DorpsGek_III> [OpenTTD/nml] FLHerne merged pull request #135: Fix #134: Incorrect value of PALETTE_CC_RED https://git.io/JfCSu 14:07:03 <DorpsGek_III> [OpenTTD/nml] FLHerne closed issue #134: nml 0.5.0 - PALETTE_CC_RED value in global_constants.py https://git.io/JfCSl 14:08:14 <LordAro> FLHerne: pretty sure it does something 14:08:17 <LordAro> can't remember what :p 14:08:32 <Yexo> Looks like a no-op on ubuntu/macOS. On windows it builds a standalone executable 14:08:38 <Yexo> If the logs are to be believed anyway 14:08:47 <LordAro> it does pylint & black checks after my reformatting PR is merged :p 14:08:47 <LordAro> ah yes 14:10:09 <FLHerne> LordAro: I see on Windows it does pyinstaller, but the other jobs seem like duplicates of eh Yexo typed this already 14:10:44 <LordAro> "Testing" isn't a great name 14:11:16 <FLHerne> If we want to get the bugfix time below 7 minutes, the tests need to run faster :P 14:11:27 <LordAro> :p 14:13:15 <LordAro> be a lot faster if we didn't have to install dependencies over and over 14:13:21 <LordAro> but that's how it be 14:15:16 <glx> well they are cached (when caching works) 14:17:20 <FLHerne> 'PALETTE_IDENTITY' : 775, 14:17:22 <FLHerne> 'PALETTE_CC_FIRST' : 775, 14:17:24 <FLHerne> 'PALETTE_CC_DARK_BLUE' : 775, # = first 14:17:25 <FLHerne> 'PALETTE_CC_PALE_GREEN' : 776, 14:17:26 <FLHerne> I'm confused 14:17:56 <FLHerne> That doesn't seem right, but there aren't enough other numbers to be a typo 14:17:58 <glx> that's ok 14:18:14 <FLHerne> Oh, wiki's the same there 14:18:31 <glx> 775 is dark blue and the first cc palette 14:20:03 <FLHerne> Ok, I see 14:29:52 <andythenorth> wtf? why do we require Aaux Pro Medium font? 14:30:17 *** iSoSyS has joined #openttd 14:31:59 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #8128: Mexican Stand-off https://git.io/JfCyz 14:32:16 <michi_cc> andythenorth: First font on the list that starts with a :p He said "missing A font". 14:32:33 <michi_cc> More like total bogus. 14:33:42 <andythenorth> is it just spam? 14:33:57 <andythenorth> seems like quite a detailed way to spam to advertise a font 14:34:21 <andythenorth> :P 14:41:45 *** matt21347 has quit IRC 15:19:09 <FLHerne> "Interestingly, if you use an industry set with stockpiles like BSPI, it will intelligently divide the cargo between the industries instead of wasting it all on one. I'm not sure how that works, but it does " 15:19:13 <FLHerne> *does* that work? 15:19:21 *** supermop_Home_ has joined #openttd 15:19:25 <FLHerne> andythenorth keeps complaining that it doesn't :P 15:20:05 <andythenorth> maybe it rapidly closes and opens the stockpile alternately? 15:20:55 <frosch123> i think there are two things to that 15:21:26 <frosch123> when one industry refuses cargo, the next one will get it (if there is a next one). that should always have been the case 15:21:52 <frosch123> afaik 1.10 changed for cargo is distributed, from everything to one, to a bit to everyone 15:22:31 <frosch123> but the latter is very "afaik", i don't know how it really works 15:22:43 <andythenorth> I missed that :) 15:23:08 <frosch123> anyway, the complaint about stockpiles was always when there is no "next one" 15:23:31 <frosch123> then cargo will stay in the train, and mess everything up 15:25:45 *** mcbanhas has joined #openttd 15:38:51 <supermop_Home_> ooh open gfx+ stations 15:40:22 *** iSoSyS has quit IRC 15:41:44 <Yexo> Am I missing anything or is this indeed an if masquerading as a while? https://github.com/OpenTTD/OpenTTD/blob/master/src/script/api/script_log.cpp#L60 15:48:02 <nielsm> looks like it 15:53:59 <glx> finally found a way to workaround my encoding issue in python 16:09:45 <mcbanhas> https://wiki.openttd.org/Manual_of_style almost done with this, can I get some feedback? 16:10:16 <mcbanhas> I haven't fixed the images yet, but I will do so soon 16:19:20 <FLHerne> mcbanhas: Looks like you fixed most of the things I complained about before :-) 16:19:38 <FLHerne> Worth adding a 'correct' order for shortcuts? 16:20:03 <mcbanhas> What do you mean? Correct order? 16:20:22 <FLHerne> Empirically, that seems to be Ctrl+Click, then Shift+Click 16:20:49 <FLHerne> Maybe it's just obvious 16:21:18 <mcbanhas> Ah, that's not a bad idea 16:21:27 <FLHerne> Hm, I disagree with "When writing additional shorcuts, always use one sentence per function." 16:21:38 <_dp_> if (ofs.load != (enum OrderLoadFlags)-1) 16:21:42 <_dp_> tf is this sorcery? 16:21:53 <FLHerne> "Ctrl+Click+Drag selects an area, and Shift+Click shows price preview." is more readable than the two-sentence version IMO 16:22:59 <Yexo> _dp_: where did you find that? 16:23:21 <mcbanhas> I'm trying really hard to avoid coordinating conjunctions when it's technical stuff like shortcuts. 16:23:21 <_dp_> Yexo, order hotkeys patch 16:23:37 <nielsm> "Should a descriptive text refer to a list or a category of items of which one requires a numeral, write the remainder in numerals as well, even if they are below ten ("There are 15 trains, followed by 5 trains, followed by 1 train") " <-- thank you for adding this, it's one of my pet peeves :) 16:23:41 <frosch123> mcbanhas: about tooltips, we have a rule to join them with "+". good: Ctrl+Click, bad: Ctrl-Click 16:23:59 <nielsm> writing "between five and 12" just looks terrible 16:24:27 <frosch123> mcbanhas: also, i am not sure whether your page is consistent about ending sentences with ".". Our style is to never put a "." at the end of the whole text 16:24:41 <_dp_> Yexo, I don't even know how to google what that does %) 16:24:46 <FLHerne> frosch123: Ah, we had this the other day 16:24:56 <mcbanhas> Ahah, no problem. I'm just future-proofing here. 16:25:29 <Yexo> _dp_: without knowing the context of that line: an enum is just an integer. It's casting -1 to enum OrderLoadFlags and comparing that with the OrderLoadFlags stored in ofs.load 16:25:38 <nielsm> mcbanhas: That part about numerals, would it make sense to rephrase as "when a text refers to multiple numbers that relate to each other, always use numerals for all numbers"? 16:25:39 <FLHerne> I'm very certain "our style" is wrong, and if there are going to be written rules they might as well be sane ones :P 16:25:54 <mcbanhas> frosch123, what FLHerne said. I initially had a rule to never have a period on the last sentence of a tooltip, but people seemed to prefer it with a period. 16:26:09 <mcbanhas> By people I mean FLHerne and LordAro which are both natives. :p 16:26:25 <_dp_> Yexo, oooh right, I didn't notice that's an explicit cast 16:26:32 <frosch123> mcbanhas: i doubt anyone will accept changing 90% of strings in ottd :) 16:26:39 <frosch123> so you have to stick to the existing style 16:26:47 <nielsm> the original transport tycoon (not deluxe) printed manual had a peculiar way of always writing the word "window" when referring to the UI element in quotation marks 16:26:59 <FLHerne> frosch123: Did you miss the PR changing, like, 90% of strings in OTTD? 16:27:05 <nielsm> I wonder if I still have it somewhere... 16:27:07 <FLHerne> (exaggerating, probably) 16:27:33 <mcbanhas> frosch123, changing most of the tooltips is why I wrote this guide. 16:27:58 <mcbanhas> So people can have a tool for reviewing and have the rules explicitly written. 16:28:51 <mcbanhas> nielsm, give me a moment, I'll look into it. :) 16:28:52 <FLHerne> frosch123: So far, most people's opinion seems to be "well, okay, that sounds good in principle" ;-) 16:29:11 <FLHerne> I imagine the translators to other languages might find it annoying? 16:29:40 <frosch123> FLHerne: i would argue for: if there was a style decided in the past, keep it. if there is no consistent style, pick one 16:30:09 <mcbanhas> FLHerne, that will be a problem, but if the translation is based on a messed up original text, then it won't be a good translation eiher. 16:30:17 <mcbanhas> In fact that's why I started this whole thing. 16:30:27 <mcbanhas> I wanted to retranslate OTTD to Portuguese. 16:30:50 <mcbanhas> But I found so many issues with the original that I thought it might be best to fix English beforehand. 16:34:22 <mcbanhas> This is just the first version of the document for the sake of passing the PR. There's still more stuff that needs to be added. I did not include a section for Punctuation & Spacing because I did not find it essential yet. 16:35:16 <mcbanhas> And if you have any additional ideas for expansion, I can add them in too. 16:35:52 <nielsm> some specific glossary might be a good addition along the way 16:36:29 <nielsm> (the web translator could also use a way of offering glossary for the target language to make it easier to stay consistent) 16:37:24 <mcbanhas> Yeah a glossary would be something for the future, definitely, very useful tool for translators. 16:37:43 *** andythenorth has quit IRC 16:39:34 *** Flygon has quit IRC 16:43:17 <mcbanhas> In case you guys approve of this, how can I edit the orange side pan to include this on the list of development documentation? 16:45:21 <Yexo> https://wiki.openttd.org/?title=Template:DevDoc&action=edit 16:45:28 *** gnu_jj has quit IRC 16:45:40 <mcbanhas> Thanks! 16:45:42 *** gnu_jj has joined #openttd 16:58:20 <_dp_> hm, got desync by randomly adding orders to a single vehicle (I'm client 20)... https://pastebin.com/KGwPYWLJ 16:58:29 <_dp_> can't reproduce :( 17:21:24 <Samu> are there ships, docks or so in the map? 17:22:13 <Yexo> Is that in a non-patched version? 17:23:26 <Samu> how does this cache checking works? https://github.com/OpenTTD/OpenTTD/commit/86e9326b7f9a0f74e5e8b271289685a1d5deeaf2 17:24:50 *** andythenorth has joined #openttd 17:25:37 <Yexo> 1. It creates a copy of all tiles in st->docking_station. 2. It empties st->docking_staion (done in UpdateStationDockingTiles). 3. It adds all tiles that belong in st->docking_station (again in UpdateStationDockingTiles). 4. It compares the backup to the new version, they're supposed to be equal 17:26:24 <Yexo> If there is a difference, the original st->docking_station was wrong. Most likely an update to it was forgotten somewhere 17:26:55 <Samu> it doesn't require a server and a client? 17:27:04 <Yexo> Nope 17:31:42 <Samu> I'm trying to remember of a fix related to client renaming... 17:31:51 <Samu> closing the building tools 17:32:21 <Samu> wondering if that could be related to desync 17:36:14 <Yexo> _dp_: where you the only one that got desynced? 17:36:24 <_dp_> Yexo, yes 17:37:03 <_dp_> though later someone desynced with similar log 17:37:41 <Yexo> Can you upload that as well? 17:37:53 <Yexo> No guarantees that it'll help, I'm simply trying to spot patterns at this opint 17:38:21 <_dp_> Yexo, client 40 https://pastebin.com/WZJTSdUD 17:38:26 <Yexo> Thanks 17:39:25 <_dp_> he did a lot of stuff with vehicles though so could be a known desync 17:39:44 <Samu> Company 18 is a game script 17:39:51 <Samu> you have a GS running 17:41:12 <_dp_> Samu, where did you find it? I filtered out GS command spammage 17:41:17 <Yexo> Are there known desyncs (apart from the ship-based one that'll desync immediately after joining)? 17:41:33 <Yexo> _dp_: 2nd line 17:41:41 <Samu> SET_GOAL_TEXT 17:41:46 <Samu> ID 18 17:41:49 <Yexo> Also in your first pastebin: 789203 9 1 GOAL_QUESTION_ANSWER (88) 32850 1 0 17:42:15 <Samu> I remember a fix regarding goals 17:42:19 <Yexo> Can you upload the unfiltered ones as well? 17:43:09 <_dp_> Yexo, known vehicle desync https://github.com/OpenTTD/OpenTTD/pull/8103 17:43:28 <Yexo> Thanks 17:43:51 <Samu> ah, it was _dp_ who created it 17:43:56 <Samu> https://github.com/OpenTTD/OpenTTD/commit/f14a69e52f77b442e8615f102f5152cb0ef0d2ed 17:44:16 <glx> _dp_: still on 1.10.1 ? 17:44:43 <_dp_> Yexo, unfiltered first one looks like that https://pastebin.com/GgqErbz1 17:45:40 <_dp_> glx, what else? 17:45:51 <DorpsGek_III> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JfCNm 17:45:51 <DorpsGek_III> - Update: Translations from eints (by translators) 17:46:05 <_dp_> not going to run master on a public server xD 17:46:28 <glx> yeah, but could be an already fixed desync 17:47:05 <Yexo> Time for 1.10.2 so we can be sure any new desyncs are not the known ones? 17:47:11 <_dp_> glx, second one yes, but first one doesn't match afaict 17:47:27 <Samu> my PR needs merging first 17:47:41 <glx> yeah second one is a good candidate for the refit desync 17:47:43 <Samu> or tested first, then merged or however u do it 17:47:44 <_dp_> yeah, I guess 1.10.2 will help a bit 17:47:52 <_dp_> can always do 1.10.3 later xD 17:48:24 <glx> just playing in the build vehicle gui without even building one can trigger it 17:50:35 <frosch123> mcbanhas: FLHerne: https://gist.github.com/frosch123/401146e4146b35aa416481649b8008e0 <- those are the string-consistency fixes from the past 17:51:56 <Yexo> _dp_: I'm assuming that the log is from the server. Do you have a log from your own client to compare against that as well by chance? 17:52:16 <_dp_> glx, how? by changing cargo type filter? don't think I did that 17:52:28 <_dp_> Yexo, no, unfortunately not 17:56:30 *** tokai|noir has joined #openttd 17:56:30 *** ChanServ sets mode: +v tokai|noir 18:03:19 *** tokai has quit IRC 18:05:27 <_dp_> btw, just noticed you can estimate cost of dragging orders 18:13:28 <_dp_> these non-standard types are driving me crazy, why not just typedef it all to std::(u)int*_t ?? 18:15:00 <nielsm> visual c++ 2005 didn't have stdint.h and that was an important target at one point 18:15:06 <nielsm> I don' 18:15:16 <nielsm> I don't remember if it was added in 2008 or only 2010 18:16:33 <_dp_> at least define them differently for those exceptions only 18:16:42 <_dp_> just to be sure that most platforms have it the same 18:16:57 <milek7> it won't compile on ancient toolchains anyway 18:17:33 <_dp_> coz when I see enum typed as byte I grep byte, find it as usigned char and google for 30 mins what size it can have %) 18:17:52 <Yexo> That might all be true now, but wasn't when a lot of code was written. It's easy enough to say "it doesn't need to be that way anymore", but another to go and update all the existing code 18:17:59 <DorpsGek_III> [OpenTTD/OpenTTD] kkkozlov opened issue #8129: OpenTTD is crashed after hours of playing https://git.io/JfCAR 18:18:25 <_dp_> Yexo, I know, but there already was a big shift to c++11 18:19:36 <_dp_> also it doesn't have to a huge update, just changing stdafx.h will do a lot 18:21:18 <_dp_> Yexo, do you have a mac by any chance btw? 18:21:29 <Yexo> No 18:21:50 <_dp_> macs seem to be much more consistent at getting desynced for some reason 18:23:13 <Yexo> Compared to windows or also to linux? 18:24:05 <_dp_> If we're talking about that instant desync it's so far only known to happen on mac and win7 18:24:14 <_dp_> I can't get linux to desync no matter what I try 18:33:16 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo approved pull request #8124: Fix #8119, f538179: Update docking tile area when placing a diagonal rail next to a dock end https://git.io/JfCAF 18:33:52 <nielsm> https://www.jernbanen.dk/forum/index.php?id=153927 (derelict) DMU tipped on its side, quite unusual sight 18:41:32 <Samu> wow, elitegameservers are really slow 18:41:44 <Samu> joined one of the advertisements game 18:43:44 <Samu> just desynced it 18:43:53 <_dp_> lol 18:44:12 <Samu> used the ship track thing 18:44:17 <Samu> docking tile 18:45:04 <Yexo> Please don't do that on purpose on multiplayer servers 18:45:22 <_dp_> those are basically scammers 18:45:36 *** Eddi|zuHause has quit IRC 18:45:38 <Samu> their game runs at 0.75x speed 18:45:46 <Samu> and it's an advertising game 18:45:49 <Samu> funny 18:45:54 <_dp_> spamming server list with adv for payed servers that don't even work properly 18:46:11 <Yexo> So propose a policy against advertising in the server list, so we can ban them from there (after sufficient warning) 18:48:14 <nielsm> "Businesses offering game server services are not allowed to publish servers that act as advertisements in the public server list. This covers both server name as well as in-game advertisements. Servers breaking this policy may be blacklisted from the public server list service." 18:48:16 *** iSoSyS has joined #openttd 18:48:17 <nielsm> something like that? 18:48:39 <Samu> well, there are 15 companies in them 18:49:47 <Yexo> Soemthing like that, yes. But why ban in-game advertisements as well? Are there any problematic examples of those? 18:50:28 <nielsm> not sure really... mainly just to cover servers that spam the console with "go buy our services" constantly 18:50:36 <Yexo> And as an alternative: engage with them, if they actually want to offer this as a proper service, maybe they're willing to donate X per server in exchange for listing them on openttd.org. Can help with our hosting/other costs that way 18:51:19 <Yexo> And I'd drop the "game server" from the first sentence. All advertising there is most likely problematic 18:51:20 <nielsm> as _dp_ says, they seem to be running on shoestring 18:51:58 <nielsm> or at least not want to spend budget on actual service quality 18:52:09 <_dp_> idk if there is any good policy to establish here tbh 18:52:18 <Yexo> Maybe, or maybe they only did a quick test, saw the game was running and left it at that 18:52:43 <Yexo> I'm totally fine with banning such behavior, but if we want that we should do it properly, not "break" their servers via known bugs 18:52:58 <_dp_> it's all good when we only have one service like that, but what if, say, citymania starts offering servers can we not continue to run public ones? 18:53:20 <_dp_> not that I plan on doing that any time soon 18:54:47 <Yexo> Could allow advertisements as long as the server itself is playable to cover that 18:55:02 <_dp_> every server is playable.. kinda :p 18:56:12 <nielsm> take the right to delist servers that repeatedly exhibit unacceptable performance for normal play, i.e. are underdimensioned for the game settings 18:57:03 <_dp_> make servers report tick rate and delist the slow ones xD 18:57:33 <Yexo> List tickrate (in a more userfriendly way) in the server list 18:57:46 <Yexo> Let's users see quickly if a server is fast enough to play 18:57:48 <_dp_> but that doesn't rly matter, even if they were perfectly fine servers it's still annoying to have that spam 19:00:04 <Yexo> Allow url, but not direct advertising like "get your server". I think that should solve the citymania example as well 19:06:50 <_dp_> Yexo, yeah, that's better but then is it fine to spam, say, 10 servers with url that just offers paid servers? what about 100? 19:07:21 <mcbanhas> frosch123, I'll keep these in mind. Thanks. 19:08:37 <_dp_> Yexo, what I'm trying to say it may be better to just deside on case by case basis than changing policy every time :) 19:10:07 <Yexo> Sounds good, but then I think we need a fairly generic policy first. Something like nielsm proposed might work for that. The "may be blacklisted" leaves room for interpretation 19:10:10 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8119: Desync after building diagonal track next to dock end https://git.io/JfnI2 19:10:35 <nielsm> maybe "that act purely as advertisement" 19:11:24 <nielsm> which would cover flooding the list, but not reasonable numbers 19:11:48 <Yexo> For this specific case: would we be fine with a single server? 19:12:09 <Yexo> If so, we should probably send them an email first before doing anything more. Seems like a much simpler solution 19:13:43 <nielsm> one would be fine, five would also be fine as long as they are reasonably different (e.g. supporting different playstyles), but a ton of identical but barely used and poorly performing servers are not 19:14:45 <_dp_> nielsm, all default servers are reasonably the same if you ask me :p 19:15:05 <nielsm> if they configure the servers with sufficient resources to offer a good play experience, they're also offering a service to the community in general 19:19:01 <frosch123> https://www.tt-forums.net/viewtopic.php?p=1066038#p1066038 <- related? 19:25:01 <Yexo> Yes, same exactly problem for me. Providing a link to forums is fine, as long as the content itself is valuable. Only providing a link but no content is problematic 19:25:25 <Yexo> Advertising your service in a server name but at the same time providing a good server would be fine for me, but only advertising and not providing a server is problematic 19:29:24 *** gelignite has joined #openttd 19:31:33 <frosch123> anyway, the solution back then was to not waste time with making policies, but just stating "due to overwhelmingly demand we removed xyz" 19:32:08 <frosch123> so, case by case basis 19:32:18 <Yexo> Thanks, the outcome wasn't immediately obvious (didn't read all of the thread) 19:32:21 <frosch123> it doesn't happen that often :) 19:33:39 <frosch123> Yexo: from out pov it comes down to "remove without stating any reasons, and just referring a convoluted discussion" 19:33:55 <frosch123> which leaves no space for argueing or reference for future cases :) 19:34:35 <frosch123> essentially it puts the task of "figureing out what is the policy" to whoever disagrees with what happened 19:35:56 <frosch123> if you do that too often, you annoy people, but it works if the action matches the expectation of the huge majority 19:37:02 <Yexo> Randomly looking at 2 of the servers, it seems like people actually play(ed) on them 19:37:06 <frosch123> the streaming platforms essentially do the same. it's impossible to have clear policies on what is allowed to stream with what age restrictions 19:37:20 <Yexo> Not very actively perhaps, and I can't tell if the servers haven't been sitting in the same paused state for a long time 19:37:53 <frosch123> Yexo: did you join them as spectator? 19:37:59 <Yexo> Yes 19:38:36 <frosch123> i only looked at the server list, and 2 clients for 15 companies is rather wtf 19:38:55 <Yexo> True 19:39:15 <frosch123> i guess 15 companies is the default, so they only bothered to decrease the client limit 19:39:16 <Yexo> For msot of them the company list is full, so it could be some casual players, then never restarting the server/cleaning out old companies 19:39:38 <Yexo> oh, I even missed that 19:39:39 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8129: OpenTTD is crashed after hours of playing https://git.io/JfCAR 19:39:46 <Yexo> Yes, limit of 2 is absolutely bogus for this kind of server 19:40:20 <glx> this->status_height = FindWindowById(WC_STATUS_BAR, 0)->height; <-- FindWindowById() return nullptr 19:40:31 <glx> I don't see how that can happen 19:42:05 <frosch123> yeah, never heard of statusbars vanishing in-game :) 19:42:18 <LordAro> in the menu, perhaps? 19:43:04 <glx> the trace shows a normal running game, 19:43:14 <_dp_> is that a network game, do you know? 19:43:44 <frosch123> NetworkGameLoop is in the stack 19:44:07 <_dp_> there is some weird thing going with game states sometimes 19:44:16 <_dp_> may enter some broken state 19:44:31 <_dp_> like half-exited to menu :) 19:45:07 <_dp_> though for what I saw status bar stayed 19:45:32 <frosch123> wow, crash.png shows the "tycoon of century" newspaper 19:45:42 <frosch123> that's not supposed to show in multiplayer 19:46:05 <LordAro> that is the other time when there's no statusbar though 19:46:11 <frosch123> though i don't think that removes the statusbar, it just hides it 19:46:21 <glx> oh I didn't check the screenshot 19:47:42 <_dp_> try to repro with #6598 methods 19:48:15 <frosch123> hmm, or does it show in multiplayer? 19:48:50 <nielsm> I think it does 19:48:58 <nielsm> show both newspaper and scoreboard 19:49:57 <frosch123> ok, end-game screen *does* delete the statusbar and main toolbar 19:50:29 <frosch123> if (!_networking) DoCommandP(0, PM_PAUSED_NORMAL, 1, CMD_PAUSE); <- it pauses the game in singleplayer 19:50:37 <frosch123> but in multiplayer it crashes on the next news, nice :) 19:50:44 <LordAro> nice 19:51:19 <_dp_> lol, guess I was right to start servers in 2060 xD 19:51:22 <nielsm> should we turn the end game screen into a regular pop-up window in multi? :) 19:51:58 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 commented on issue #8129: OpenTTD is crashed after hours of playing https://git.io/JfCAR 19:52:26 <_dp_> does mp even need that end game screen? 19:52:40 <frosch123> to me it looks like this bug existed forever, so no idea why noone noticed 19:52:52 <frosch123> _dp_: does singleplayer even need that end game screen? 19:53:17 <glx> many server have an autorestart system maybe 19:53:43 <nielsm> the scoring is rather meaningless when you don't play on default rules (actually one of the original easy/medium/hard difficulties) 19:54:12 <nielsm> and even then the performance rating isn't that difficult to max when you know how 19:54:15 <_dp_> frosch123, for me singleplayer exists only to test stuff so I've no opinion what it needs :p 19:54:16 <frosch123> nielsm: we deleted easy/medium/hard years ago :p 19:54:34 <nielsm> frosch123 yes that just makes it more pointless 19:54:58 <frosch123> so, i guess "do not show endgame thingie in multiplayer" is the solution? 19:55:41 <LordAro> i'd say so 19:55:50 <LordAro> be a shame to lose it entirely 19:56:21 <frosch123> i have no opinion on single player either :) i think i never reached 2050 19:56:26 <LordAro> are there any other TTD sprites that are no longer used at all? 19:56:38 <_dp_> there are ppl who seriously play it like that though: https://cryptottd.tk/tournament-info/tournament-ii-alpine-hills-prize/ 19:56:43 <frosch123> i only learned that there are two different end-game screens, when andy was fixing the animated pixels in opengfx 19:57:06 <frosch123> LordAro: yes, multiple 19:57:37 <frosch123> but they are not as prominent 19:59:05 <frosch123> otoh, we added usage of 1 or 2 sprites, which were not used in original TTD, so maybe we can call it a compensation? :p 20:02:07 <LordAro> oh? which ones? 20:02:47 <frosch123> nielsm: actually, since they backgrounds are only 640x480, a simple window would be nice, the fullscreen looks bad anyway 20:03:12 <LordAro> nah, forcibly resize the game window 20:03:15 <frosch123> LordAro: when V made a baseset, he found alternative sprites for the rough land 20:03:23 <nielsm> well someone _might_ be playing on 640x480 ?? or 1280x960 at 2x scale 20:03:24 <frosch123> and we added support for it 20:03:38 <LordAro> frosch123: neat 20:04:34 <frosch123> LordAro: it got a bit more messy, because we had to add a newgrf flag to enable them. turned out some other basesets noticed before that they were unused, and did not supply them 20:04:56 <LordAro> heh 20:05:03 <frosch123> so, i probably would not have added it, if i knew that first :p 20:06:51 <frosch123> anyway, the baseset contains some sprites from TTO, that were never used in TTD or OTTD. we moved some "binary data" that was stored as sprites into the code, and some exotic sprites like the black outside-map area unused 20:06:51 <Yexo> frosch123: I'd appreciate another pair of eyes on https://github.com/OpenTTD/OpenTTD/pull/8124 20:07:35 <frosch123> ah, another of those "someone requested your review" :) that generally gets lost in the notification spam :) 20:09:09 <_dp_> is there some way to protect game state in general I wonder 20:09:16 <_dp_> so it wouldn't even compile ideally 20:10:43 <_dp_> not without rewriting half of the game I guess :( 20:11:10 <nielsm> storing all game state in transactional memory that could be chekcpointed and rolled back would be very convenient 20:11:25 <LordAro> i suspect to do it in sufficient detail would run into halting problem difficulties 20:11:43 <LordAro> with the current architecture, anyway 20:11:51 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 approved pull request #8124: Fix #8119, f538179: Update docking tile area when placing a diagonal rail next to a dock end https://git.io/JfWeB 20:12:04 <_dp_> persistent structures huh? 20:19:21 <_dp_> frosch123, one more thing out of spam for you ;) https://github.com/OpenTTD/OpenTTD/pull/7912 20:20:18 <glx> but this one won't be in 1.10 branch 20:20:46 *** iSoSyS has quit IRC 20:21:01 <_dp_> glx, why? 20:21:09 <glx> savegame bump 20:21:36 <_dp_> hm, I though there were bumps between minor versions before 20:21:42 <frosch123> also, "feature" 20:21:50 <_dp_> and features :p 20:21:51 <frosch123> _dp_: only once, because of a major bug 20:21:56 <Yexo> LordAro: "OpenTTD CI" still shows "expected" on https://github.com/OpenTTD/OpenTTD/pull/8124 after several hours 20:22:01 <Yexo> How to give it a kick? 20:22:04 *** Guest24490 has quit IRC 20:22:14 <_dp_> well, bummer :( 20:22:40 <glx> Yexo: if checks tab is ok it's mergeable 20:22:51 <LordAro> glx: only if admin 20:23:30 <Yexo> ah, it shows it succeeded in that tab, but the merge button is disabled for me 20:23:40 <Yexo> If anyone else can merge it, please go ahead 20:23:52 <glx> oh, I quickly run check it and I'll merge 20:24:03 <Yexo> Thanks 20:24:20 <frosch123> hmm, so it got worse. the other day it worked like glx said: if the check tab was happy, then the merge was possible 20:25:33 <Yexo> Has https://github.com/OpenTTD/OpenTTD/pull/7248 or something similar seen any progress? 20:25:54 <Yexo> It's easy enough to reproduce for me: stripping out the vehicle PerformanceAccumulator gives me a ~5% performance improvement 20:26:26 <LordAro> needs peter/someone else to pick it back up, really 20:26:56 <Yexo> @seen petern 20:26:56 <DorpsGek> Yexo: petern was last seen in #openttd 8 years, 3 weeks, 2 days, 3 hours, 40 minutes, and 35 seconds ago: <petern> I wonder if there's such a thing as a decent android port... 20:27:06 <LordAro> @seen peter1138 20:27:06 <DorpsGek> LordAro: peter1138 was last seen in #openttd 1 week, 5 days, 1 hour, 48 minutes, and 26 seconds ago: <peter1138> I see I fucked everything up. 20:27:08 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 merged pull request #8124: Fix #8119, f538179: Update docking tile area when placing a diagonal rail next to a dock end https://git.io/Jfcyk 20:27:09 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 closed issue #8119: Desync after building diagonal track next to dock end https://git.io/JfnI2 20:27:13 <Yexo> Right :p 20:28:06 <glx> hmm I should probably reopen 8119 and add CmdClearArea :) 20:28:32 * _dp_ starts campaign for 1.11 "It's just an anagram" 20:28:42 <_dp_> 1.10.1 --> 1.11.0 20:29:01 <LordAro> wouldn't bet on it :p 20:29:47 <_dp_> only one swap away ;) 20:31:06 <mcbanhas> https://wiki.openttd.org/images/4/43/Iconbutton.png Period at the end looks better for you guys? 20:31:42 <nielsm> better yes 20:32:04 <mcbanhas> Another sample https://wiki.openttd.org/File:Textbutton.png 20:32:52 <frosch123> in the settings tree the period looked worse 20:33:10 <mcbanhas> what's the settings tree? 20:33:13 <frosch123> since there were multiple "key: value" pairs, and only some having a period was weird 20:33:17 <_dp_> wow, I though #7248 was long fixed 20:33:31 <frosch123> mcbanhas: the settings window with the tree :) 20:34:34 <mcbanhas> frosch123, I will not apply periods on those. 20:34:54 <mcbanhas> I think the settings window needs special rules. tbh I haven't touched it yet 20:35:19 <mcbanhas> But I can tell from the start I don't see putting periods on every option either 20:35:50 <mcbanhas> Oh besides, these technically qualify as UI labels, not descriptive texts 20:36:17 <frosch123> mcbanhas: i guess my main point is. style rules should not be changed in places where stuff is displayed mixed with stuff from addons. any changes there create inconsistencies :) 20:36:29 <frosch123> but tooltips are isolated, so safe 20:36:47 <frosch123> errors messages and "key: value" lists are not safe 20:36:47 <mcbanhas> frosch123, I've covered that on the rules too :p 20:37:19 <mcbanhas> From the Scope section: "Text belonging to mods obtained through the in-game content downloader or anywhere else is not covered by this guide. It is however recommended for modders to follow these rules while creating new content as to keep consistency with the original texts." 20:37:33 <frosch123> mcbanhas: that's the opposite of what i mean 20:37:49 <frosch123> there are windows where texts from ottd are shown next to texts from addons 20:37:58 <frosch123> if you change the style for ottd, the addon will look bad 20:38:21 <frosch123> and different addons following styles from different eras make it even worse 20:38:28 <mcbanhas> But that will always happen. Mods can do that to in-game windows too, if you're inserting new vehicles for example. 20:39:01 <mcbanhas> If a modder decides to capitalize or not capitalize all the new vehicles in his mod by accident 20:39:15 <frosch123> it does not happen if you do not change stuff that was consistent before 20:39:27 <mcbanhas> But stuff is not consistent right now 20:39:33 <frosch123> but some things are 20:39:40 <mcbanhas> That's a bad argument 20:39:41 <frosch123> take the vehicle purchase list 20:39:52 <frosch123> it has a panel with properties at the bottom (speed etc) 20:40:01 <frosch123> various newgrf extend that "key: value" list 20:40:35 <frosch123> if you change to color or punctuation style of the ottd texts there, you make the addons look bad, which were consistent with ottd before 20:40:57 <FLHerne> I wonder if the "Ctrl+Click" could be highlighted in a different colour or something 20:41:15 <mcbanhas> Listen, mods can't get in the way of improving textual quality. Otherwise you will always end with a bad product. You're making a point to keep things broken because some mods use a broken standard instead of setting a better one. 20:41:18 <FLHerne> The ones with several of those (like the signals) are hard to scan atm 20:41:43 <mcbanhas> There are compromises that can be made, but there are limits to that too. 20:41:53 <FLHerne> mcbanhas: There are a *lot* of grfs in existence 20:41:58 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8119: Desync related to diagonal track next to dock end https://git.io/JfnI2 20:41:58 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 reopened issue #8119: Desync related to diagonal track next to dock end https://git.io/JfnI2 20:42:02 <frosch123> mcbanhas: strong disagree. there is a differene between "making new rules" and "changing old rules". if you change old rules, it's your fault, not the addon's 20:42:12 <FLHerne> So yes, ^ 20:42:28 <LordAro> see also: Linus' "never break userland" rant 20:42:34 <glx> easier to track the test savegame 20:42:37 <mcbanhas> I disagree with that. 20:43:36 <FLHerne> frosch123, mcbanhas: Do either of you have an example of what exactly you're arguing about? :P 20:44:06 <FLHerne> I don't see how any of the currently-proposed changes would be a problem 20:44:09 <frosch123> FLHerne: i specifically refer to the purchase list, and to error messaged like "cannot place industry ... \n ... because" 20:44:21 <mcbanhas> One moment let me demonstrate. 20:44:42 <frosch123> FLHerne: i have no objection against tooltips, since none of them interact with addon, afaik 20:45:14 <mcbanhas> By the purchase list you mean vehicle names? 20:45:16 <Yexo> mcbanhas: to me your manual of style looks good, but I think this discussion highlights a problem: I can't tell which points are "already followed / consistent", which rules are explicitly different than the old convertion/rule, and which rules are new in area's where strings where inconsistent before 20:45:37 <LordAro> https://lkml.org/lkml/2012/12/23/75 20:45:44 <frosch123> FLHerne: also add the settings windows to that list. newgrf/ai/gs/ottd settings should be consistent, despite provided from different origins 20:46:33 <mcbanhas> Sorry, but linus is terrible at community management hahaha 20:46:40 <LordAro> for sure 20:46:42 <FLHerne> frosch123: I understand the *scope*, I don't see what proposed changes actually affect that 20:46:44 <LordAro> but he's not wrong 20:47:10 <frosch123> FLHerne: i do not know either. i did not understand the proposed changed to punctuation :) 20:47:15 <FLHerne> The periods at the end? 20:47:24 <mcbanhas> frosch123, I don't think the changes i'm proposing interfere with the settings tree at all 20:47:48 <FLHerne> TBH, for me the missing periods are so painful I'd prefer any resulting inconsistency from using them :P 20:48:01 <frosch123> FLHerne: i assumed the proposal is all lines shall end with a ".", while you only seem to mention tooltips 20:48:05 <mcbanhas> They're all UI labels in sentence capitalization. It's literally the rule I'm proposing 20:48:26 <mcbanhas> frosch123, it's only for tooltips 20:49:12 <FLHerne> Well, I think it should apply to multi-sentence popup windows and things too at some point 20:49:31 <FLHerne> Which could indeed cause some inconsistency where grfs provide the text 20:50:52 <mcbanhas> The rule I've written is for descriptive texts. The only descriptive texts in game right now are tooltips are prompts like "Do you want to quit OpenTTD?" 20:51:06 <mcbanhas> That's about it. 20:51:17 * andythenorth zones out 20:51:24 <andythenorth> way too close too my day job 20:51:43 <andythenorth> except in my day job, I just decide how we're capitalising and stuff 20:51:52 <andythenorth> and then people subtly undermine it by ignoring me 20:52:04 <mcbanhas> LordAro, I don't think Linus argument applies to this situation, this is plain text, not a gamebreaking feature. It has to be judged by a different standard. 20:52:55 <mcbanhas> andythenorth, haha I was a textual reviewer so I understand what you mean. 20:53:01 <andythenorth> so after the raging success of NRT 20:53:04 <LordAro> of course it's obviously not as serious as gamebreaking - it's not breaking newgrf compatibility or anything 20:53:05 <andythenorth> can we do pipelines / belts? 20:53:11 <LordAro> but the similarities are there, imo 20:53:43 <FLHerne> mcbanhas: Does "descriptive texts" not include the "Can't build industry here" things frosch mentioned? 20:54:02 <mcbanhas> Hmm let me check 20:54:04 <FLHerne> That's the same kind of window as the exit confirmation 20:54:07 <Yexo> mcbanhas: I still think it would be very beneficial to split up your document. Most likely 90% is "no change compared to current practice", 5% is "fix existing inconsistencies" and only the last 5% are things that really need discussion. (obviously made up numbers) 20:54:17 * _dp_ thinks any capitalization is fine as long as it's not a camelCase 20:54:27 <Yexo> Getting the first 95% out of the way makes it a lot easier to discuss the remaining few items 20:54:53 <mcbanhas> Yexo, not at all. Capitalization is changing completely for one. 20:54:53 <FLHerne> _dp_: WhAt AbOuT BaNaNaS CaSe? 20:55:18 * _dp_ urgently needs an exorcist 20:55:25 <mcbanhas> Because it's totally bonkers right now, and most people around here say they preferred sentence capitalization 20:55:42 <FLHerne> We ShOuLd MaKe AlL StRiNgS In OpEnTtD MaTcH It 20:56:09 <Yexo> mcbanhas: Sure, maybe my numbers are completely wrong. The rest still holds: start with a version that everyone agrees on (and thus is missing rules for contentions areas). Then discuss the missing rules one by one 20:56:56 <LordAro> Yexo: that's ultimately what i said on the original PR - the individual types of changes needed to be split out into separate commits 20:57:08 <Yexo> The change you want to make now is way too big, which makes it very hard to get to a consensus 20:57:37 <mcbanhas> Yes but it's impossible to review text on individual commits like that. 20:57:58 <Yexo> I'm specifically not talking about the commits, but about the style page document 20:58:13 <FLHerne> mcbanhas: Ok, so now we just need to review the rules as separate 'commits' ;-) 20:58:23 <FLHerne> Which is more workable 20:59:04 <mcbanhas> Then please, do have a look at the rules. Separating them on a document on what is currently present and what is currently not present is somewhat difficult. 20:59:07 <mcbanhas> For example 20:59:30 <mcbanhas> There are irregular instances of sentence and title capitalization 20:59:52 <Yexo> Sure, it's difficult, but without that separation, how should I review that document? Without that separation I can't tell what the impact of the rules is, which is important 21:00:19 <mcbanhas> The best way would be by comparing the PR I am finishing with all these changes 21:00:39 <mcbanhas> You will the see rules put in practice 21:00:50 <LordAro> you are ignoring what we are telling you 21:00:51 <mcbanhas> and all the changes highlighted on github 21:01:05 <LordAro> a big massive blob of a document/PR/whatever will get ignored or closed 21:01:10 <LordAro> no one will review it 21:01:34 <LordAro> one change/consistency fix/new rule at a time 21:01:48 <mcbanhas> But why not? It's text, not code. With a manual of style this takes about 2 hours max to review 21:01:49 <Yexo> mcbanhas: that PR is way too large to meaningfully review it. Size is fine, if it's a simple change (add a dot to all tooltips), but not if it's 10 different changes merged into a single large commit 21:02:43 <mcbanhas> Yexo you are forgetting upgrading a text also implies re-writing it. It's not possible to separate rewrites from reformatting. 21:02:43 <Yexo> It takes much longer to properly review: for many strings the context is important, which might mean actually starting the game, looking at the current text, seeing the context etc. 21:02:57 *** Eddi|zuHause has joined #openttd 21:03:05 <LordAro> of course it's possible 21:03:19 <LordAro> it might mean changing the same string multiple times, but that's still much easier to review 21:03:52 <mcbanhas> LordAro, that's a nightmare of a commit. 21:04:05 <Yexo> mcbanhas: The first problem I have is that I cannot properly review your style manual since there is no base version to compare against 21:04:29 <mcbanhas> I would have to do various separate lang files 21:04:39 <mcbanhas> one with all the rewritten text 21:04:45 <mcbanhas> one with all the capitalization 21:04:50 <mcbanhas> one with all the punctuation 21:04:53 <Yexo> There certainly are some (implicit, not written down) style rules on text currently. You're introducing a good overview (nice!), adding some new ones (good for consistency) but also changing some old ones (bad if I can't tell which ones you're changing) 21:04:56 <mcbanhas> and overlapping variants for each 21:05:05 <mcbanhas> it's an impossible standard to apply to text. 21:05:08 <FLHerne> Yexo: To be fair, that's because there never has been a proper base version 21:05:15 <LordAro> mcbanhas: this is what individual commits are for 21:05:19 <LordAro> one thing at a time 21:05:40 <LordAro> you can flip between them and make intermediate changes if needed 21:05:45 <Yexo> Sure, which is why I proposed adding a small base version that corresponds with the current style first, then building on that afterwards with discussion for the changes 21:05:50 <FLHerne> LordAro: That does sound like a pain to edit 21:06:01 <mcbanhas> LordAro, but you can't do that with text. You are asking me for example, do to a version with rewritten text but old capitalization. 21:06:08 <FLHerne> I don't see how it makes sense to do the actual changes that way 21:06:10 <mcbanhas> It means I would have to rewrite thing 4 or 5 times 21:06:11 <LordAro> mcbanhas: yes, i am 21:06:19 <mcbanhas> especially when there are no rules right now 21:06:22 <LordAro> that's precisely what i've been asking you to do for the last 6 months 21:06:22 <mcbanhas> no consistency 21:06:33 <mcbanhas> what you are asking me would make sense if there were rules prior 21:06:40 <mcbanhas> but there are no rules right now 21:06:50 <Yexo> There are, they're just not written down 21:07:22 <mcbanhas> You guys are putting me through a bureaucracy nightmare for little reason here. 21:07:30 <Yexo> We seem to have "no dot at the end of tooltips" for example. Also "Ctrl+Click", not "Ctrl+click" or "Ctrl-click" 21:08:08 <LordAro> mcbanhas: welcome to software development 21:08:29 <mcbanhas> LordAro, it's sort of bad practice to apply code standards to text. 21:08:40 <mcbanhas> Can we reach a commitment here? 21:08:51 <mcbanhas> I can provide examples with pictures of the things that I am changing. 21:09:07 <mcbanhas> How does it affect the current text. 21:09:09 <LordAro> please stop trying to come up with workarounds 21:09:10 <Yexo> Out of curiosity: what's so bad about that? 21:09:14 <LordAro> we will not budge on this 21:09:47 <mcbanhas> LordAro why are you going back on your word then? You agreed with me previously on me creating a style guide a reviewing it from there. 21:10:45 <LordAro> we are trying to help you come up with a way of feasibly reviewing it 21:11:29 <mcbanhas> LordAro, I wouldn't even know how to properly write the changes to do what you are asking me. 21:11:39 <FLHerne> LordAro: I don't see how "review every string five+ times" is feasible 21:12:35 <Yexo> LordAro: I think I have to agree with mcbanhas / FLHerne here, reviewing the text changes that way would be nice, but is likely too much work 21:12:36 <FLHerne> Do the changes once, have a document listing the systematic changes from existing practice 21:12:45 <Yexo> I do want to review the manual properly, which I still cannot do 21:13:14 <LordAro> well, whatever 21:13:18 <FLHerne> Review the effects in-game *of each systematic change* carefully 21:13:28 <LordAro> manual needs to have individual changes reviewed, or the code does 21:13:33 <FLHerne> But you can do that without actually making the changes separately 21:13:51 <FLHerne> A trailing period doesn't look different because the capitalization changed 21:13:55 <nielsm> how about applying the rules one by one and making gradual changes, to only a small segment of texts 21:14:15 <nielsm> like painting a corner of a room to evaluate the colour 21:14:23 <FLHerne> And yeah, definitely makes sense to review/commit changes to each general category of strings separately 21:14:29 <mcbanhas> nielsm, that's doable. I can do it for all tooltips first, for example. 21:14:30 <nielsm> and if it turns out satisfactory, do the remaining in one huge chunk 21:14:39 <nielsm> less than all tooltips I think 21:14:43 <nielsm> that's still a very large chunk 21:14:58 <mcbanhas> What about all button labels? 21:15:01 <nielsm> e.g. tooltips for the main toolbar and railroad construction only 21:15:11 <mcbanhas> ok that's fair yeah 21:15:16 <LordAro> "this is some text. ctrl+click does something" -> "this is some text. Ctrl+Click does something" -> "This is some text. Ctrl+Click does something" -> "This is some text. Ctrl+Click does something." is what i was imagining, where each '->' is a separate commit (or section in the style guide, if we're going that route) 21:15:30 <FLHerne> nielsm: i.e. just as an example "it will look like this" before putting effort into changing the rest? 21:15:31 <LordAro> no need to review *every* string 21:15:34 <FLHerne> That seems sane 21:15:35 <LordAro> just the changed ones 21:15:35 <Yexo> mcbanhas: https://pastebin.com/eNhSjRvF is the sort of questions I want to see answered, and this is only on your summary 21:16:07 <nielsm> FLHerne: yeah review the approach and make a sample of it that's reviewable 21:16:16 *** sla_ro|master has quit IRC 21:16:38 <FLHerne> LordAro: That's what I imagined you were imagining, I still don't think it's feasible 21:16:53 <FLHerne> Each change affects many of the strings 21:17:06 <FLHerne> You just end up reviewing basically the same string multiple times 21:17:19 <mcbanhas> Yexo, these are fairly easy to answer 21:17:40 <LordAro> FLHerne: yes, but it makes it much easier to see that only what you expect has been changed 21:17:43 <mcbanhas> If you can compile a list all your doubts I can answer everything with examples easily. 21:18:38 <mcbanhas> Personally I think nielsm is the best solution. 21:18:39 <FLHerne> LordAro: It's easy to distinguish which systematic change was relevant to any issue 21:18:48 <LordAro> there's also the *massive* amount of translator churn to consider 21:19:04 <FLHerne> Yeah, I brought that up earlier :-/ 21:19:24 <FLHerne> At this scale, I almost wonder if it's worth patching the translator 21:19:25 <mcbanhas> Yeah but the problem is that currently, translations are inconsistent too because the original text is inconsistent 21:19:49 <FLHerne> Add a "no semantic change" flag that doesn't force translation updates 21:20:02 *** Samu has quit IRC 21:20:17 <FLHerne> AAUI, none of the proposed changes affect tags or anything like that? 21:20:21 <mcbanhas> One translator here once told me (I don't rememeber who) he had to use a bunch of custom formatting on the french translation if I'm not mistaken. 21:21:21 <nielsm> mcbanhas: have you experimented with adding colour codes to the modifier keys in tooltips? was an idea I had 21:21:26 <mcbanhas> FLHerne, only on tooltips. I added a paragraph break on the tooltips that require titles 21:21:41 <mcbanhas> nielsm, I did actually. It doesn't look so good 21:21:51 <nielsm> ok 21:21:54 <mcbanhas> the yellow background is a bit too light 21:22:20 <mcbanhas> but we can do further experimenting later :) 21:22:23 <FLHerne> nielsm: <FLHerne> I wonder if the "Ctrl+Click" could be highlighted in a different colour or something 21:22:43 <nielsm> heh right, I haven't followed the entire conversation detailed I'll admit 21:22:54 <nielsm> and now bedtime 21:22:55 <nielsm> gn 21:22:58 <mcbanhas> LordAro, can we compromise on nielsm's suggestion of doing only a few strings of small sections at a time? 21:22:59 <FLHerne> Bye 21:23:17 <mcbanhas> good night 21:23:50 <LordAro> mcbanhas: possibly, though i would rather do one *type* of change at a time 21:24:15 <LordAro> arbitrarily splitting by window or whatever doesn't really make much sense 21:24:45 <frosch123> mcbanhas: i recommend starting with tooltips only. they are isolated and do not interact with anything else. you can do batches as you like, to test the waters of acceptance :) 21:24:54 <mcbanhas> It does allow you to see all changes in action in a manageable number of strings, and explanations can easily be added. 21:25:16 <mcbanhas> frosch123, I agree 21:29:02 *** Progman has quit IRC 21:30:56 *** nielsm has quit IRC 21:32:18 <FLHerne> tbh, I think small batches are useful as a review of the review process, as much as the actual changes :D 21:32:28 *** Foveafoxy has joined #openttd 21:33:04 *** Foveafoxy is now known as Guest24596 21:33:51 <Yexo> mcbanhas: https://pastebin.com/dVU6pK9b 21:34:02 <Yexo> Wiki is really a terrible format to review :( 21:35:58 <Yexo> And then I'm ignoring the consistent: "How much does this deviate from what is done now?" question. 21:38:10 <mcbanhas> Generally a lot. The thing is that it's not enough to just change formatting. There is text that is literally written in broken english right now. 21:39:07 <FLHerne> mcbanhas: tbh, the formatting is what people are going to care about for review ;-) 21:39:39 <FLHerne> It's much easier to spot inconsistencies in that than the writing style 21:40:10 <FLHerne> (but do you have an example for the "broken English"? I don't remember seeing anything terribly bad 21:40:11 <FLHerne> ) 21:40:19 <mcbanhas> Give me a moment 21:40:22 <FLHerne> Except maybe a couple of the setting names/descriptions 21:42:04 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 opened pull request #8130: Fix #8119: Update docking area when clearing a shore rail tile https://git.io/JfWU8 21:45:16 <andythenorth> did we agree something? 21:45:28 * andythenorth was watching a train go round in a circle 21:45:40 <andythenorth> on the trainset that 'belongs to my kids' 21:46:10 <Yexo> glx: There are several calls to SetDockingTile(t, false); Are those in general correct or would they need RemoveDockingTile as well? 21:46:37 <glx> ah I should check that 21:46:50 <FLHerne> andythenorth: I think mostly we just agreed to pretend all the ideas are compatible :P 21:47:39 <andythenorth> isn't capitalisation just a text filter? 21:47:44 <andythenorth> my editor can change cases 21:47:53 <andythenorth> I mean, even css can do it now :P 21:50:14 <mcbanhas> FLHerne, https://i.imgur.com/QjS6n5Z.png just some I remember from the top of my head. First one, description in between brackets, no other tooltip has it like that. Second one, weird vague phrasing, exit signal with an hyphen inbetween and truncated last sentence. Third one, "bridge heads" shouldn't have a space inbetween. It's either bridge-head or bridgehead. 21:51:49 <mcbanhas> Also, signal tooltips are the only ones that have a paragraph break, for some arbitrary reason. 21:53:32 <FLHerne> Hm, I think "bridge heads" is closer to being right than the other two 21:54:02 <mcbanhas> https://en.wikipedia.org/wiki/Bridgehead 21:54:34 <FLHerne> Yes, but that's a slightly different meaning 21:55:31 <FLHerne> No-one's invading over the bridges, so there are no bridgeheads around the bridge heads :p 21:55:56 <glx> Yexo: all the calls are in map accessors, but I'll check the context 21:56:35 <mcbanhas> Then we need the correct engineering term 21:56:51 <mcbanhas> Because I find no references to "bridge head" applied to the topic 21:57:11 <mcbanhas> and "bridge head" does not exist alone as a term 21:57:16 <mcbanhas> AFAIK 21:58:16 <Yexo> https://english.stackexchange.com/questions/251227/is-there-a-word-for-the-end-of-a-bridge says "head of the bridge" or "bridgehead" 21:59:25 *** iSoSyS has joined #openttd 21:59:47 <milek7> 'Bridge ends not at the same level'? 22:00:00 <frosch123> it's certainly better than "anchorage block" :) 22:01:03 <mcbanhas> Either way, just to illustrate current English text is lacking. 22:01:10 <FLHerne> I can find all of "bridge head", "bridge-head" and "bridgehead" in technical papers from Google :P 22:01:15 <FLHerne> Yay English 22:02:03 <FLHerne> Maybe just "Ends not at the same level" ? 22:02:47 <andythenorth> it's called a bridgehead in war because that's the bit of the bridge you want to capture 22:03:00 <andythenorth> one doesn't capture the bridge middle, it's tactically poor :P 22:03:05 <FLHerne> Well, in full that's "Can't build bridge here... Ends not at the same level" no I don't like it 22:03:06 <andythenorth> it's a bridgehead 22:03:31 <andythenorth> I have often been annoyed by that message and wondered if there's a better way 22:03:38 <FLHerne> Looks like a verb wth stupid grammar, anyway 22:03:39 <andythenorth> I didn't think of one 22:04:06 <FLHerne> "Bridges must be level"? 22:04:18 <FLHerne> No 22:04:24 <andythenorth> "Can't build bridge here. Start and end tiles not at same level" 22:04:31 <andythenorth> just call things what they are 22:04:33 <mcbanhas> Also, too many tooltips with the word "etc" in them 22:04:35 <andythenorth> no off-screen actors 22:04:39 <FLHerne> s/Start and//? 22:04:50 <FLHerne> No 22:05:01 <mcbanhas> andythenorth, not bad 22:05:12 <andythenorth> eliminate needless ellipses 22:05:22 <andythenorth> they are either for truncations in quotes (not here) 22:05:26 <andythenorth> or they're stylistic 22:05:30 <FLHerne> I don't love it, but it's better than "Bridge heads" 22:05:33 <andythenorth> we don't need them, we're not telling gags 22:05:57 <andythenorth> and something like the 3rd rule of screenwriting: don't refer to offscreen characters 22:05:59 <FLHerne> andythenorth: e.g. in "Can't build bridge here..." ? 22:06:05 <andythenorth> i.e. only use the concepts we're already using 22:06:27 <andythenorth> there is one exception: in suspense movies the antagonist is offscreen for most of the movie 22:06:33 <andythenorth> FLHerne yes 22:06:36 <FLHerne> IMO those should be colons 22:06:44 <andythenorth> yes 22:06:45 <FLHerne> Except I think that causes problems? 22:06:49 <mcbanhas> I rewrote the tunnel description in similar way: 22:06:58 <andythenorth> I would use an em-dash because I have unusual style choices 22:06:58 <mcbanhas> {BLACK}Build railway tunnel:{}Underground passage for rail vehicles. Tunnel entryways can only be placed on sloped land at the same height level. A preview will be displayed if a trajectory is possible. Shift+Click shows estimated cost without purchase 22:06:58 <FLHerne> Because in some cases the second line may not always exist 22:07:01 <milek7> actually, 'at the same level' is misleading too 22:07:16 <FLHerne> And you can't end a sentence with a colon :P 22:07:17 <milek7> slope is allowed 22:07:28 <andythenorth> oh we do the 'caps after colon thing' 22:07:35 <andythenorth> I might have to leave and go to bed :P 22:07:41 <andythenorth> that makes me twitch so much 22:07:52 <andythenorth> not my ditch to die in though 22:08:06 <FLHerne> mcbanhas: Drop the "a preview will be displayed" bit, IMO 22:08:37 <mcbanhas> FLHerne, it's sort of important though. 22:08:39 <FLHerne> It's obvious when you use the tool 22:08:48 <mcbanhas> Not so much I think 22:08:56 <FLHerne> Also, "entryways" and possibly "trajectory" aren't the right word 22:09:20 <mcbanhas> path could work instead of trajectory 22:09:47 <Yexo> Tunnel entryways can only be placed on sloped land at the same height level <- same height level as what? (I understand the intend, but that could be written better) 22:09:56 <FLHerne> entryways -> entrances, and I still don't think 'trajectory' is useful 22:10:07 <Yexo> Both tunnel exits must be on sloped land at the same height level. ? 22:10:15 <FLHerne> I think in some cases the indicated path can be impossible anyway? 22:10:33 <mcbanhas> Sort of a glass half full :p 22:10:38 <mcbanhas> I see entries, not exits 22:10:39 <FLHerne> If the other end is sloped wrong, or one corner of an intermediate tile is too low 22:10:57 <FLHerne> Definitely "entrances" 22:11:29 <mcbanhas> entryways is a bit more specific for a tunnel though, don't you think? 22:11:37 <FLHerne> We're on the outside, so it's not an exit, and 'entries' is just wrong 22:11:51 <FLHerne> No, it's wrong 22:12:00 <FLHerne> A tunnel can *be* an entryway 22:12:06 <FLHerne> To something 22:12:16 <FLHerne> But the entrances of a tunnel aren't entryways 22:13:26 <mcbanhas> that's fair enough. 22:14:27 <FLHerne> Hm, if we spend this long bikeshedding each string, we'll be done just after the mandatory re-education to speak Chinese 22:14:37 <FLHerne> Oh well 22:14:59 <mcbanhas> It will be faster on the submission itself 22:15:06 <mcbanhas> strings can be commented for that purpose 22:15:31 <mcbanhas> Moreover, I would like you specifically to do a full review before I even submit a final version. 22:15:46 <FLHerne> Anyway, it's kind of late, so I'll sleep in a minute 22:17:40 <mcbanhas> Yexo, I'll send a reply to your questions in a moment. 22:18:38 <mcbanhas> you want string examples too? 22:20:42 <Yexo> if you have them without too much work, that would be nice 22:22:05 <FLHerne> https://i.imgur.com/KCrBdXr.png 22:22:07 <FLHerne> [sleep] 22:22:10 <FLHerne> Goodnight 22:23:26 *** andythenorth has left #openttd 22:25:30 <mcbanhas> Yexo, what I've been trying to say for a long time is that reviewing strings is actually fairly easy, and with a style guide, it shouldn't take more than 2 hours to do the whole thing, even in a rickety .txt file :p 22:25:38 <mcbanhas> Large commits only seem scary if they're code. 22:26:06 <mcbanhas> I'll fish some examples easily 22:27:22 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 commented on pull request #8130: Fix #8119: Update docking area when clearing a shore rail tile https://git.io/JfWkv 22:28:52 <Yexo> mcbanhas: You've been very clear in that, I simply disagree. The literal size is almost completely unimportant (for both text and code). The 'semantic diff size' matters way more. 22:29:19 <Yexo> Some 1-line changes (for both text and code) can take a very long time to review/discuss, while other massive (measures in lines) changes can be trivial to review 22:29:32 <mcbanhas> That is true. 22:29:47 *** Wolf01 has quit IRC 22:29:50 <Yexo> Make sure all tooltips end in a dot for example might be a very large change, but trivial to review. For that kind of change I don't object to size at all 22:30:31 <mcbanhas> The problem is combining that with a full string re-write simultaneously. 22:30:39 <Yexo> Removing all gender bias from existing strings might lead to much more discussion on the proper term to use in various strings. That's something I don't want to rush through reviewing 22:30:52 <mcbanhas> There's little to no gender bias actually 22:30:56 <mcbanhas> Only 1 term 22:31:01 <mcbanhas> (chairman) 22:31:12 <Yexo> That's easy then :) 22:31:31 <mcbanhas> I can send you my current edit for you to have an idea 22:31:51 <Yexo> The open PR? 22:31:57 <mcbanhas> No, that's very outdated 22:32:11 <mcbanhas> I'll upload the .txt file 22:33:19 <Yexo> Not going to review that now. 22:33:55 <Yexo> Breaking it up in smaller chunks will be helpful for review anyway. I'd much rather spend 8 times 15 minutes than 1 time 2 hours, especially if there are comments in between that need resolving/another round of review 22:33:57 <mcbanhas> No need to. You can just have a look to have an idea or put the .lg in game 22:34:06 <mcbanhas> *lng 22:34:21 <mcbanhas> http://www.mediafire.com/file/m1j3j7xvrj7fplp/lang.tar.gz/file 22:35:05 *** gelignite has quit IRC 22:38:43 <milek7> know any good VCS with native support for big files? 22:39:06 <milek7> SVN is sort-of fine, but quite anachronistic 22:41:38 <LordAro> milek7: how big is big? 22:41:45 *** nielsm has joined #openttd 22:42:05 <LordAro> and if we're talking text files, i'm not sure there's any significant limit 22:42:20 <milek7> binary, around 50MiB 22:42:41 <LordAro> git-lfs? 22:42:54 <LordAro> i've not really looked into it personally 22:43:08 <LordAro> other than that, svn works fine really 22:43:08 <Yexo> Was about to suggest that 22:43:18 <milek7> I'm probably doing it wrong, but lfs seems clunky to me 22:43:38 <milek7> you have to decide which extensions store normally and which on lfs 22:44:00 <milek7> and generally a hassle if somebody commits big file without lfs 22:45:03 <Yexo> Can't say anything about the clunky, but that last situation should be preventable with some git hooks 22:45:38 <LordAro> assuming you can feasibly enforce git hooks 22:53:38 *** Guest24596 has quit IRC 22:58:02 *** frosch123 has quit IRC 23:00:54 <milek7> is there any webinterface providing pull request-like facility for SVN? 23:01:30 <mcbanhas> Yexo, https://pastebin.com/cXaSMmrD 23:01:36 <mcbanhas> I hope this answers everything 23:05:58 <Yexo> STR_COMPANY_LEAGUE_PERFORMANCE_TITLE_CHAIRMAN :Chair 23:05:58 <Yexo> <- if we're doing this we should do it properly and rename the string as well: STR_COMPANY_LEAGUE_PERFORMANCE_TITLE_CHAIR 23:06:29 <Yexo> Thanks a lot for your (very extensive!) answers 23:07:28 <mcbanhas> renaming strings would definitely break translations, I wouldn't recommend that. 23:07:37 <Yexo> I'm not sure I like the "future proofing" sections, since extra rules is extra overhead when translating, and if they're not used this overhead is wasted. Then again, I won't object to them 23:07:47 <Yexo> mcbanhas: We can rename the string in all languages without translators having to do anything 23:07:57 <mcbanhas> Oh that's lovely then 23:08:18 <mcbanhas> There would be some more renames required as p/ my current edits though 23:08:34 <mcbanhas> some tools I rewrote or simplified the name which differs from the string 23:08:40 <mcbanhas> I can give you an example 23:09:01 <Yexo> Definitely don't do string renames at the same time, we can do them afterwards or first 23:09:22 <mcbanhas> orig: STR_TOOLTIP_WINDOW_TITLE_DRAG_THIS :{BLACK}Window title - drag this to move window 23:09:50 <mcbanhas> change: STR_TOOLTIP_WINDOW_TITLE_DRAG_THIS :{BLACK}Drag window 23:10:47 <Yexo> For a case like that I think it's less relevant to rename the string 23:10:59 <Yexo> We can do so, but even if we don't the name is still clear enough 23:11:58 <mcbanhas> This seems a bit more obvious in context https://imgur.com/a/Z3YorVd 23:18:10 <mcbanhas> Also so you have an idea on how capitalization will be affected https://i.imgur.com/4A1JwZv.png 23:35:35 <mcbanhas> Yexo anything else you would like to ask me? 23:36:06 <Yexo> Not now, thanks. Maybe later when reviewing your changes, but so far this looks good 23:38:02 <mcbanhas> Ok glad to know, I'm assuming you have reviewing privileges yourself then? Would you be fine if where to do a partial submission as suggested by niels? 23:38:20 <mcbanhas> Would you have a volume or segment in mind? 23:40:02 <Yexo> I do, and I'm happy to review if I have the time. Having said that, I explicitly do not want to commit to this now since I have no clue how much time I'll have over the next few weeks 23:40:37 <mcbanhas> Alright, that is fair enough. 23:42:05 <Yexo> As for volume: I'd suggest to start with a batch of max 100 strings or so. 23:42:26 <Yexo> That should give a decent indication how much work it is 23:42:48 <Yexo> If you only have everything in one large file, it can be as simple as only taking the first 100 changes lines