Log for #openttd on 9th May 2020:
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
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
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
07:43:10  <DorpsGek_III> [OpenTTD/nml] LordAro commented on pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests.
07:44:36  <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #123: Doc: Add a use of `roadtype()` to the examples.
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
07:47:36  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #8116: Old patchpack savegame versions will soon overlap
07:47:36  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on issue #8116: Old patchpack savegame versions will soon overlap
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.
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.
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
08:49:27  <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests.
08:49:34  <DorpsGek_III> [OpenTTD/nml] LordAro merged pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests.
08:56:16  <Wolf01> andythenorth: new trucks
08:56:58  <andythenorth> haha
08:57:23  <Wolf01> 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
09:07:33  *** matt21347 has joined #openttd
09:13:59  <_dp_>
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
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>
12:05:04  <Samu> LordAro,
12:06:40  <Samu> 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.
12:13:49  <DorpsGek_III> [OpenTTD/OpenTTD] LordAro opened pull request #8127: Add: [AzurePipelines] Ubuntu Focal (20.04) build for releases
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.
12:16:55  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh closed issue #8126: Stations being visited against instructions.
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
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.
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
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
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.
12:30:57  <DorpsGek_III> [OpenTTD/CompileFarm] LordAro opened pull request #43: Add: Ubuntu focal image
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
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> 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> 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>
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
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
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> 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
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.
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
14:00:16  <DorpsGek_III> [OpenTTD/nml] jrook1445 opened issue #134: nml 0.5.0 - PALETTE_CC_RED value in
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
14:05:14  <DorpsGek_III> [OpenTTD/OpenTTD] nickpan commented on issue #7623: Support for macOS Catalina.
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
14:06:03  <Yexo> Exactly. Last change was already a fix for wrong values:
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
14:07:03  <DorpsGek_III> [OpenTTD/nml] FLHerne closed issue #134: nml 0.5.0 - PALETTE_CC_RED value in
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
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?
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> 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>
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)...
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?
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
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
17:43:28  <Yexo> Thanks
17:43:51  <Samu> ah, it was _dp_ who created it
17:43:56  <Samu>
17:44:16  <glx> _dp_: still on 1.10.1 ?
17:44:43  <_dp_> Yexo, unfiltered first one looks like that
17:45:40  <_dp_> glx, what else?
17:45:51  <DorpsGek_III> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
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: <- 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
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
18:33:52  <nielsm>   (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 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
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> <- 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
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
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:
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
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
20:12:04  <_dp_> persistent structures huh?
20:19:21  <_dp_> frosch123, one more thing out of spam for you ;)
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 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 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
20:27:09  <DorpsGek_III> [OpenTTD/OpenTTD] glx22 closed issue #8119: Desync after building diagonal track next to dock end
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> Period at the end looks better for you guys?
20:31:42  <nielsm> better yes
20:32:04  <mcbanhas> Another sample
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
20:41:58  <DorpsGek_III> [OpenTTD/OpenTTD] glx22 reopened issue #8119: Desync related to diagonal track next to dock end
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>
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: 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:
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
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, 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>
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> 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>
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
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>
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,
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
23:18:10  <mcbanhas> Also so you have an idea on how capitalization will be affected
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

Powered by YARRSTE version: svn-trunk