IRC logs for #openttd on OFTC at 2020-05-09
⏴ go to previous day
00:02:21 <DorpsGek_III> [OpenTTD/nml] FLHerne commented on pull request #118: Fix: Allow calculation for palette in spritelayout https://git.io/JfCJN
00:25:42 <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #118: Fix: Allow calculation for palette in spritelayout https://git.io/JfZi5
00:26:30 <glx> and I can merge 2 commits I think
00:31:27 <FLHerne> glx: That mess with the BinOps reminds me why I wrote #70 :P
00:32:02 <FLHerne> I guess the megachange should wait until after 0.5.1
00:32:18 <FLHerne> (no stable branches?)
00:33:08 <glx> I think stable branch is created when master is not compatible with previous version
00:33:42 <frosch123> it was only done once for 0.2
00:33:59 <frosch123> but essentially releases are only for distros
00:34:15 <frosch123> newgrf are either fine with ancient versions, or they need the latest greatest
00:34:43 <frosch123> do we have nightly builds?
00:35:15 <FLHerne> It might be worth having a fixes-only 0.5.2 whenever more NRT/industry bugs show up
00:35:28 <glx> no, but we could, pyinstaller should work for all os I think
00:36:26 <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #118: Fix: Allow calculation for palette in spritelayout https://git.io/JfZi5
00:38:51 <FLHerne> glx: In the first commit message, should mention it adds the shift?
00:38:57 <FLHerne> Doesn't just simplify
00:40:02 <glx> the shift was there for the constant version, and missing for the BinOp, now they are merged
00:46:31 <FLHerne> glx: I know, I mean that just "simplify Action2LayoutSprite.get_sprite_number" implies no behaviour change to me
00:47:29 <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #118: Fix: Allow calculation for palette in spritelayout https://git.io/JfZi5
00:52:02 <glx> I add the "fix" in the message
01:05:15 <FLHerne> I don't think I understand this well enough to be sure it works...
01:26:21 <spnda> Are numbers allowed in string literals in NML?
01:29:29 <spnda> Ok thanks. Someone I know has had the assertion in string_literal.py, line 37 trigger for some reason recently.
01:29:37 <FLHerne> spnda: In fact, they're required if you want to reference things like the standard "3RDR" label for 3rd-rail railtypes
01:30:06 <spnda> So it might have been numbers. But what is that assertion for? To see if the value of the string equals the length of the string?
01:32:01 <FLHerne> spnda: String literals are, in most cases, written directly as bytes into the NFO/grf
01:32:02 <glx> use -s flag for more context
01:32:29 <FLHerne> i.e. a 4-character string is four bytes of output
01:32:47 * FLHerne wonders if that assert is correct for unicode chars
01:33:24 <FLHerne> No, but force_ascii is true so there can't be any :P
01:33:56 <glx> unicode is only allowed in strings
01:36:32 <FLHerne> glx: print_string() handles unicode unless the caller specifically sets force_ascii=False?
01:36:56 <FLHerne> It's used for town names and things
01:38:19 <spnda> roadtype being the label?
01:39:26 <FLHerne> spnda: Easiest if you just post the nml source somewhere
01:39:29 <FLHerne> Unless it's secret :P
01:39:58 <glx> but at least in asserts when writing a roadtype label
01:44:25 <FLHerne> Oh, I think I know what's wrong
01:49:48 <spnda> Ah yes, found it, thanks a lot
01:49:52 <glx> but I think that should be checked earlier
01:50:23 <glx> assert should be a last resort failure :)
01:56:05 <spnda> It does, but the checking might have some issue about it being a multi line definition
01:57:13 <glx> I don't see where it's checked
01:58:28 <spnda> glx: Look at parameter.py, line 89. On line 100 it throws an error if the string length is not 4.
02:00:12 <glx> hmm but I don't think this one is called
02:02:16 <glx> XXXtype_list() functions in action0properties.py
02:03:34 <glx> only checks it's an array of litterals, but doesn't check the length of the litterals
02:06:58 <FLHerne> Yuck, more copy-pasting
02:09:32 <FLHerne> Also, I don't see why it shouldn't take identifiers, like railtypetable?
02:12:18 <glx> without any validation because these labels could be defined by other grfs
02:14:28 <FLHerne> That's equally true of railtypetable entries, no?
02:14:37 <FLHerne> It's just a list of 4-character labels
02:15:10 <glx> it's just nobody ever though to check the length :)
02:15:32 <glx> and factorise the 3 things
02:16:23 <FLHerne> I wrote a patch that factorized most of the other 3 things
02:16:37 <FLHerne> Unless you've started
02:16:50 <glx> no I'm just reading the code :)
02:17:12 <FLHerne> Seriously, the entire implementation of NRT was this copy-pasted-in-triplicate nonsense
02:17:14 <glx> but the 3 ListProp are exaclty the same
02:52:32 <DorpsGek_III> [OpenTTD/nml] FLHerne opened pull request #132: Cleanup: Tidy tracktype properties and check label length https://git.io/JfCqU
08:19:11 *** andythenorth has joined #openttd
08:52:22 *** Progman has joined #openttd
09:24:32 *** sla_ro|master has joined #openttd
09:41:57 <DorpsGek_III> [OpenTTD/nml] LordAro commented on pull request #125: Codechange: Build examples in regression testing https://git.io/JfC02
09: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
09:44:36 <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #123: Doc: Add a use of `roadtype()` to the examples. https://git.io/JfC0M
09: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
09:47:36 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro closed issue #8116: Old patchpack savegame versions will soon overlap https://git.io/JfZsT
09:47:36 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on issue #8116: Old patchpack savegame versions will soon overlap https://git.io/JfZsT
10:05:08 <DorpsGek_III> [OpenTTD/nml] FLHerne merged pull request #123: Doc: Add a use of `roadtype()` to the examples. https://git.io/Jfc2O
10:08:27 <FLHerne> LordAro: That's from copying the equivalent command for the current regression tests, which is also -u
10:09:19 <FLHerne> As you say, I can't imagine a good reason for it though
10:16:40 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests. https://git.io/JfcjU
10:28:38 <FLHerne> LordAro: It actually makes zero difference, since it just prints "Binary files * and * differ" anyway
10:30:04 *** WormnestAndroid has quit IRC
10:30:17 *** WormnestAndroid has joined #openttd
10:33:55 *** WormnestAndroid has quit IRC
10:34:08 *** WormnestAndroid has joined #openttd
10:47:36 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #125: Codechange: Build examples in regression testing https://git.io/JfcXX
10:49:27 <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests. https://git.io/JfCzp
10:49:34 <DorpsGek_III> [OpenTTD/nml] LordAro merged pull request #131: Add: [Actions] Include pypy3 on Ubuntu for regression tests. https://git.io/JfcjU
10:57:40 <andythenorth> looks suicide, probably fine
11:05:32 <DorpsGek_III> [OpenTTD/OpenTTD] ldpl commented on issue #8116: Old patchpack savegame versions will soon overlap https://git.io/JfZsT
11:07:33 *** matt21347 has joined #openttd
11:20:39 <nielsm> definitely an oversized transport
11:25:27 <_dp_> I wonder how much will it glitch if done in openttd
11: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
13:21:53 <FLHerne> nielsm: Do you remember what the general intention of the industry example was meant to be? Some sort of stockpiling mechanic?
13:23:29 <nielsm> I don't think there was any functional purpose of it other than showing valid syntax
13:23:43 <nielsm> the example in the wiki documentation is more complete
13:51:41 <andythenorth> I was considering maybe 4 example industries
13:51:52 <andythenorth> primary, secondary, town black hole, water based
13:52:03 <andythenorth> I'm having a few days off writing any code though :)
13:52:07 <andythenorth> so feel free to ignore me
14:02:26 <FLHerne> I don't think I'll try writing an example, I don't know how to do it :P
14:04:49 <Samu> i rebased and it seems to have failed
14:08:29 <LordAro> must be a github/azure thing
14:08:33 <LordAro> can't imagine what else it would be
14:13:48 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro opened pull request #8127: Add: [AzurePipelines] Ubuntu Focal (20.04) build for releases https://git.io/JfCiG
14:16:30 <LordAro> trains have always stopped at stations they pass through, unless a non-stop order is explicitly specified, right?
14:16:54 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #8126: Stations being visited against instructions. https://git.io/JfCiO
14: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
14:20:38 <nielsm> also the network construction in that save is really weird and it will give the player countless headaches
14:21:53 <FLHerne> I do find it weird that implicit orders are the default
14:22:11 <FLHerne> Very few people intentionally use them, and they cause a lot of confusion
14:22:48 <FLHerne> (tbh, I find it weird that implicit orders /exist/, what problem do they solve?)
14:23:04 <FLHerne> Except for the SRNW people
14:24:11 <DorpsGek_III> [OpenTTD/nml] TrueBrain commented on pull request #115: Fix #112: use setuptools_scm to determine version https://git.io/JfCiV
14:26:48 <FLHerne> glx: Looking at ^, I don't really see what setuptools_scm helps with :-/
14:27:32 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro commented on pull request #8127: Add: [AzurePipelines] Ubuntu Focal (20.04) build for releases https://git.io/JfCiM
14:27:46 <FLHerne> I guess it saves having our own git-version code, but that's already written
14:28:10 <TrueBrain> LordAro: last time you did it right :D Seems you are getting old my friend :)
14:30:06 <LordAro> i did pass 1/4 century a few days ago
14:30:48 <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #133: Doc: Remove broken code from industry example. https://git.io/JfCi5
14:32:32 <TrueBrain> good luck with these new errors :D
14:32:40 <TrueBrain> cannot utime .. really .. wth
14:38:12 *** plastic has joined #openttd
14:38:57 <andythenorth> 1/4 century is so far in my past :(
14:40:31 <TrueBrain> I did not want to highlight that part andythenorth ; we are just silently letting that slip ;)
14:40:34 *** frosch123 has joined #openttd
14:43:29 <DorpsGek_III> [OpenTTD/nml] glx22 approved pull request #132: Cleanup: Tidy tracktype properties and check label length https://git.io/JfCP9
14:45:28 <LordAro> TrueBrain: something to do with parent directory ownership, i think?
14:45:38 <TrueBrain> I really and honestly don't know
14:45:42 <TrueBrain> never seen that error
14:46:04 <glx> it's really weird, maybe an hardware issue
14:46:31 *** ChanServ sets mode: +o Yexo
14:47:43 <LordAro> glx: it's suspicious that it only happened for the 32 bit focal image though
14:50:18 <glx> but I see no trace of libc in 64 bit log
14:50:36 <LordAro> well yes, because that would be already installed
14:50:46 <LordAro> this is it trying to install libc:i386 on a 64bit system
14:51:13 <glx> is there a 32 bit focal ?
14:51:48 <LordAro> i thought there was...
14:52:45 <LordAro> error message is weird, anyway
14:53:01 <TrueBrain> maybe also drop i386 for focal? Sounds about time to do so ;)
14:54:35 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro updated pull request #8127: Add: [AzurePipelines] Ubuntu Focal (20.04) build for releases https://git.io/JfCiG
14:54:36 <LordAro> glx: but it always has been
14:55:59 <TrueBrain> know that the docker URL for i386 and amd64 are widely different
14:56:12 <TrueBrain> I believe i386 is even not done by upstream maintainers, but by some random people :)
14:56:17 <TrueBrain> anyway, i386 is silly in 2020, tbfh
14:58:42 <LordAro> "Maintained by: Canonical and Tianon (Debian Developer)"
14:58:46 <LordAro> well, not entirely random
15: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. "
15: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
15: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 :)
15:41:07 <DorpsGek_III> [OpenTTD/OpenTTD] Mysteron347 commented on issue #8126: Stations being visited against instructions. https://git.io/JfCiO
15:45:32 <FLHerne> Hm, the behaviour in that save does seem a bit odd
15:46:01 <Yexo> Reversing the train makes a pbs reservation, which increases the cost for the other train enough so it goes around
15: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
15:46:58 <Yexo> Don't trains automatically reverse at some point? Or am I misremembering that?
15:47:38 <FLHerne> There's a setting for it
15:47:40 <Yexo> Oh, "Automatic reversing at signals" is off by default
15:47:44 <Yexo> and also off in that savegame
15:47:55 <FLHerne> I'm sure this doesn't normally happen
15:48:18 <FLHerne> Even if I change the "passing loops" so they're almost the same length, they still wait
15: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
15:48:56 <FLHerne> *exactly* the same length (with offset ends) works
15:49:15 <FLHerne> And yes, it's not a very sensible design
15:49:32 <FLHerne> But it seems that the train in the loop has no pathfinder cost at all
15:49:47 <FLHerne> Or not enough to outweigh two tiles of empty plain track
15:50:03 <FLHerne> Which doesn't seem right
15:50:10 <Yexo> I don't think trains have a pathfinder cost, only the pbs-reserved rails have
15:50:23 <FLHerne> Hm, and because they're really short...?
15: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
15:50:48 <Yexo> Yes, the really short length makes this worse here
15:55:55 <DorpsGek_III> [OpenTTD/nml] FLHerne merged pull request #132: Cleanup: Tidy tracktype properties and check label length https://git.io/JfCqU
16: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
16:05:31 <FLHerne> Yexo: It looks like no-one spotted that since you typed it 9 years ago :P
16:06:46 <FLHerne> LordAro: What does the "testing" GH action actually do?
16: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
16:08:14 <LordAro> FLHerne: pretty sure it does something
16:08:17 <LordAro> can't remember what :p
16:08:32 <Yexo> Looks like a no-op on ubuntu/macOS. On windows it builds a standalone executable
16:08:38 <Yexo> If the logs are to be believed anyway
16:08:46 <LordAro> it does pylint & black checks after my reformatting PR is merged :p
16:10:09 <FLHerne> LordAro: I see on Windows it does pyinstaller, but the other jobs seem like duplicates of eh Yexo typed this already
16:10:44 <LordAro> "Testing" isn't a great name
16:11:16 <FLHerne> If we want to get the bugfix time below 7 minutes, the tests need to run faster :P
16:13:15 <LordAro> be a lot faster if we didn't have to install dependencies over and over
16:15:16 <glx> well they are cached (when caching works)
16:17:20 <FLHerne> 'PALETTE_IDENTITY' : 775,
16:17:22 <FLHerne> 'PALETTE_CC_FIRST' : 775,
16:17:23 <FLHerne> 'PALETTE_CC_DARK_BLUE' : 775, # = first
16:17:25 <FLHerne> 'PALETTE_CC_PALE_GREEN' : 776,
16:17:56 <FLHerne> That doesn't seem right, but there aren't enough other numbers to be a typo
16:18:14 <FLHerne> Oh, wiki's the same there
16:18:31 <glx> 775 is dark blue and the first cc palette
16:29:52 <andythenorth> wtf? why do we require Aaux Pro Medium font?
16:32:16 <michi_cc> andythenorth: First font on the list that starts with a :p He said "missing A font".
16:32:33 <michi_cc> More like total bogus.
16:33:42 <andythenorth> is it just spam?
16:33:57 <andythenorth> seems like quite a detailed way to spam to advertise a font
17: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 "
17:19:20 *** supermop_Home_ has joined #openttd
17:19:25 <FLHerne> andythenorth keeps complaining that it doesn't :P
17:20:05 <andythenorth> maybe it rapidly closes and opens the stockpile alternately?
17:20:55 <frosch123> i think there are two things to that
17: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
17:21:52 <frosch123> afaik 1.10 changed for cargo is distributed, from everything to one, to a bit to everyone
17:22:31 <frosch123> but the latter is very "afaik", i don't know how it really works
17:22:43 <andythenorth> I missed that :)
17:23:08 <frosch123> anyway, the complaint about stockpiles was always when there is no "next one"
17:23:31 <frosch123> then cargo will stay in the train, and mess everything up
17:25:45 *** mcbanhas has joined #openttd
17:38:51 <supermop_Home_> ooh open gfx+ stations
17:53:59 <glx> finally found a way to workaround my encoding issue in python
18:10:16 <mcbanhas> I haven't fixed the images yet, but I will do so soon
18:19:20 <FLHerne> mcbanhas: Looks like you fixed most of the things I complained about before :-)
18:19:38 <FLHerne> Worth adding a 'correct' order for shortcuts?
18:20:03 <mcbanhas> What do you mean? Correct order?
18:20:22 <FLHerne> Empirically, that seems to be Ctrl+Click, then Shift+Click
18:20:49 <FLHerne> Maybe it's just obvious
18:21:18 <mcbanhas> Ah, that's not a bad idea
18:21:27 <FLHerne> Hm, I disagree with "When writing additional shorcuts, always use one sentence per function."
18:21:38 <_dp_> if (ofs.load != (enum OrderLoadFlags)-1)
18:21:53 <FLHerne> "Ctrl+Click+Drag selects an area, and Shift+Click shows price preview." is more readable than the two-sentence version IMO
18:22:59 <Yexo> _dp_: where did you find that?
18:23:21 <mcbanhas> I'm trying really hard to avoid coordinating conjunctions when it's technical stuff like shortcuts.
18:23:21 <_dp_> Yexo, order hotkeys patch
18: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 :)
18:23:41 <frosch123> mcbanhas: about tooltips, we have a rule to join them with "+". good: Ctrl+Click, bad: Ctrl-Click
18:23:58 <nielsm> writing "between five and 12" just looks terrible
18: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
18:24:41 <_dp_> Yexo, I don't even know how to google what that does %)
18:24:46 <FLHerne> frosch123: Ah, we had this the other day
18:24:56 <mcbanhas> Ahah, no problem. I'm just future-proofing here.
18: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
18: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"?
18: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
18: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.
18:26:09 <mcbanhas> By people I mean FLHerne and LordAro which are both natives. :p
18:26:25 <_dp_> Yexo, oooh right, I didn't notice that's an explicit cast
18:26:32 <frosch123> mcbanhas: i doubt anyone will accept changing 90% of strings in ottd :)
18:26:39 <frosch123> so you have to stick to the existing style
18: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
18:26:59 <FLHerne> frosch123: Did you miss the PR changing, like, 90% of strings in OTTD?
18:27:05 <nielsm> I wonder if I still have it somewhere...
18:27:07 <FLHerne> (exaggerating, probably)
18:27:33 <mcbanhas> frosch123, changing most of the tooltips is why I wrote this guide.
18:27:58 <mcbanhas> So people can have a tool for reviewing and have the rules explicitly written.
18:28:51 <mcbanhas> nielsm, give me a moment, I'll look into it. :)
18:28:52 <FLHerne> frosch123: So far, most people's opinion seems to be "well, okay, that sounds good in principle" ;-)
18:29:11 <FLHerne> I imagine the translators to other languages might find it annoying?
18: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
18: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.
18:30:17 <mcbanhas> In fact that's why I started this whole thing.
18:30:27 <mcbanhas> I wanted to retranslate OTTD to Portuguese.
18:30:50 <mcbanhas> But I found so many issues with the original that I thought it might be best to fix English beforehand.
18: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.
18:35:16 <mcbanhas> And if you have any additional ideas for expansion, I can add them in too.
18:35:52 <nielsm> some specific glossary might be a good addition along the way
18: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)
18:37:24 <mcbanhas> Yeah a glossary would be something for the future, definitely, very useful tool for translators.
18: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?
19:21:24 <Samu> are there ships, docks or so in the map?
19:22:13 <Yexo> Is that in a non-patched version?
19:24:50 *** andythenorth has joined #openttd
19: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
19:26:23 <Yexo> If there is a difference, the original st->docking_station was wrong. Most likely an update to it was forgotten somewhere
19:26:55 <Samu> it doesn't require a server and a client?
19:31:42 <Samu> I'm trying to remember of a fix related to client renaming...
19:31:51 <Samu> closing the building tools
19:32:21 <Samu> wondering if that could be related to desync
19:36:14 <Yexo> _dp_: where you the only one that got desynced?
19:37:03 <_dp_> though later someone desynced with similar log
19:37:41 <Yexo> Can you upload that as well?
19:37:53 <Yexo> No guarantees that it'll help, I'm simply trying to spot patterns at this opint
19:39:25 <_dp_> he did a lot of stuff with vehicles though so could be a known desync
19:39:44 <Samu> Company 18 is a game script
19:41:12 <_dp_> Samu, where did you find it? I filtered out GS command spammage
19:41:17 <Yexo> Are there known desyncs (apart from the ship-based one that'll desync immediately after joining)?
19:41:49 <Yexo> Also in your first pastebin: 789203 9 1 GOAL_QUESTION_ANSWER (88) 32850 1 0
19:42:15 <Samu> I remember a fix regarding goals
19:42:19 <Yexo> Can you upload the unfiltered ones as well?
19:43:51 <Samu> ah, it was _dp_ who created it
19:45:51 <DorpsGek_III> - Update: Translations from eints (by translators)
19:46:05 <_dp_> not going to run master on a public server xD
19:46:28 <glx> yeah, but could be an already fixed desync
19:47:05 <Yexo> Time for 1.10.2 so we can be sure any new desyncs are not the known ones?
19:47:11 <_dp_> glx, second one yes, but first one doesn't match afaict
19:47:27 <Samu> my PR needs merging first
19:47:41 <glx> yeah second one is a good candidate for the refit desync
19:47:43 <Samu> or tested first, then merged or however u do it
19:47:44 <_dp_> yeah, I guess 1.10.2 will help a bit
19:47:52 <_dp_> can always do 1.10.3 later xD
19:48:24 <glx> just playing in the build vehicle gui without even building one can trigger it
19: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?
19:52:16 <_dp_> glx, how? by changing cargo type filter? don't think I did that
19:52:28 <_dp_> Yexo, no, unfortunately not
19:56:30 *** tokai|noir has joined #openttd
19:56:30 *** ChanServ sets mode: +v tokai|noir
20:05:27 <_dp_> btw, just noticed you can estimate cost of dragging orders
20:13:28 <_dp_> these non-standard types are driving me crazy, why not just typedef it all to std::(u)int*_t ??
20:15:00 <nielsm> visual c++ 2005 didn't have stdint.h and that was an important target at one point
20:15:16 <nielsm> I don't remember if it was added in 2008 or only 2010
20:16:33 <_dp_> at least define them differently for those exceptions only
20:16:42 <_dp_> just to be sure that most platforms have it the same
20:16:57 <milek7> it won't compile on ancient toolchains anyway
20: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 %)
20: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
20:18:25 <_dp_> Yexo, I know, but there already was a big shift to c++11
20:19:36 <_dp_> also it doesn't have to a huge update, just changing stdafx.h will do a lot
20:21:18 <_dp_> Yexo, do you have a mac by any chance btw?
20:21:50 <_dp_> macs seem to be much more consistent at getting desynced for some reason
20:23:13 <Yexo> Compared to windows or also to linux?
20:24:05 <_dp_> If we're talking about that instant desync it's so far only known to happen on mac and win7
20:24:14 <_dp_> I can't get linux to desync no matter what I try
20: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
20:41:32 <Samu> wow, elitegameservers are really slow
20:41:44 <Samu> joined one of the advertisements game
20:44:11 <Samu> used the ship track thing
20:45:04 <Yexo> Please don't do that on purpose on multiplayer servers
20:45:22 <_dp_> those are basically scammers
20:45:38 <Samu> their game runs at 0.75x speed
20:45:46 <Samu> and it's an advertising game
20:45:54 <_dp_> spamming server list with adv for payed servers that don't even work properly
20:46:11 <Yexo> So propose a policy against advertising in the server list, so we can ban them from there (after sufficient warning)
20: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."
20:48:39 <Samu> well, there are 15 companies in them
20:49:47 <Yexo> Soemthing like that, yes. But why ban in-game advertisements as well? Are there any problematic examples of those?
20:50:28 <nielsm> not sure really... mainly just to cover servers that spam the console with "go buy our services" constantly
20: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
20:51:19 <Yexo> And I'd drop the "game server" from the first sentence. All advertising there is most likely problematic
20:51:20 <nielsm> as _dp_ says, they seem to be running on shoestring
20:51:58 <nielsm> or at least not want to spend budget on actual service quality
20:52:09 <_dp_> idk if there is any good policy to establish here tbh
20:52:18 <Yexo> Maybe, or maybe they only did a quick test, saw the game was running and left it at that
20: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
20: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?
20:53:20 <_dp_> not that I plan on doing that any time soon
20:54:47 <Yexo> Could allow advertisements as long as the server itself is playable to cover that
20:55:02 <_dp_> every server is playable.. kinda :p
20: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
20:57:03 <_dp_> make servers report tick rate and delist the slow ones xD
20:57:33 <Yexo> List tickrate (in a more userfriendly way) in the server list
20:57:46 <Yexo> Let's users see quickly if a server is fast enough to play
20:57:48 <_dp_> but that doesn't rly matter, even if they were perfectly fine servers it's still annoying to have that spam
21:00:04 <Yexo> Allow url, but not direct advertising like "get your server". I think that should solve the citymania example as well
21: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?
21:07:21 <mcbanhas> frosch123, I'll keep these in mind. Thanks.
21: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 :)
21: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
21:10:10 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8119: Desync after building diagonal track next to dock end https://git.io/JfnI2
21:10:35 <nielsm> maybe "that act purely as advertisement"
21:11:24 <nielsm> which would cover flooding the list, but not reasonable numbers
21:11:48 <Yexo> For this specific case: would we be fine with a single server?
21:12:09 <Yexo> If so, we should probably send them an email first before doing anything more. Seems like a much simpler solution
21: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
21:14:45 <_dp_> nielsm, all default servers are reasonably the same if you ask me :p
21:15:04 <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
21: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
21: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
21:29:24 *** gelignite has joined #openttd
21: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"
21:32:08 <frosch123> so, case by case basis
21:32:18 <Yexo> Thanks, the outcome wasn't immediately obvious (didn't read all of the thread)
21:32:21 <frosch123> it doesn't happen that often :)
21:33:39 <frosch123> Yexo: from out pov it comes down to "remove without stating any reasons, and just referring a convoluted discussion"
21:33:55 <frosch123> which leaves no space for argueing or reference for future cases :)
21:34:35 <frosch123> essentially it puts the task of "figureing out what is the policy" to whoever disagrees with what happened
21: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
21:37:02 <Yexo> Randomly looking at 2 of the servers, it seems like people actually play(ed) on them
21: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
21: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
21:37:53 <frosch123> Yexo: did you join them as spectator?
21:38:36 <frosch123> i only looked at the server list, and 2 clients for 15 companies is rather wtf
21:39:15 <frosch123> i guess 15 companies is the default, so they only bothered to decrease the client limit
21: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
21:39:46 <Yexo> Yes, limit of 2 is absolutely bogus for this kind of server
21:40:20 <glx> this->status_height = FindWindowById(WC_STATUS_BAR, 0)->height; <-- FindWindowById() return nullptr
21:40:31 <glx> I don't see how that can happen
21:42:05 <frosch123> yeah, never heard of statusbars vanishing in-game :)
21:42:18 <LordAro> in the menu, perhaps?
21:43:04 <glx> the trace shows a normal running game,
21:43:14 <_dp_> is that a network game, do you know?
21:43:44 <frosch123> NetworkGameLoop is in the stack
21:44:07 <_dp_> there is some weird thing going with game states sometimes
21:44:16 <_dp_> may enter some broken state
21:44:31 <_dp_> like half-exited to menu :)
21:45:07 <_dp_> though for what I saw status bar stayed
21:45:32 <frosch123> wow, crash.png shows the "tycoon of century" newspaper
21:45:42 <frosch123> that's not supposed to show in multiplayer
21:46:05 <LordAro> that is the other time when there's no statusbar though
21:46:11 <frosch123> though i don't think that removes the statusbar, it just hides it
21:46:21 <glx> oh I didn't check the screenshot
21:47:42 <_dp_> try to repro with #6598 methods
21:48:15 <frosch123> hmm, or does it show in multiplayer?
21:48:58 <nielsm> show both newspaper and scoreboard
21:49:57 <frosch123> ok, end-game screen *does* delete the statusbar and main toolbar
21:50:29 <frosch123> if (!_networking) DoCommandP(0, PM_PAUSED_NORMAL, 1, CMD_PAUSE); <- it pauses the game in singleplayer
21:50:37 <frosch123> but in multiplayer it crashes on the next news, nice :)
21:51:19 <_dp_> lol, guess I was right to start servers in 2060 xD
21:51:22 <nielsm> should we turn the end game screen into a regular pop-up window in multi? :)
21:51:58 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 commented on issue #8129: OpenTTD is crashed after hours of playing https://git.io/JfCAR
21:52:26 <_dp_> does mp even need that end game screen?
21:52:40 <frosch123> to me it looks like this bug existed forever, so no idea why noone noticed
21:52:52 <frosch123> _dp_: does singleplayer even need that end game screen?
21:53:17 <glx> many server have an autorestart system maybe
21: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)
21:54:12 <nielsm> and even then the performance rating isn't that difficult to max when you know how
21:54:15 <_dp_> frosch123, for me singleplayer exists only to test stuff so I've no opinion what it needs :p
21:54:16 <frosch123> nielsm: we deleted easy/medium/hard years ago :p
21:54:34 <nielsm> frosch123 yes that just makes it more pointless
21:54:58 <frosch123> so, i guess "do not show endgame thingie in multiplayer" is the solution?
21:55:50 <LordAro> be a shame to lose it entirely
21:56:21 <frosch123> i have no opinion on single player either :) i think i never reached 2050
21:56:26 <LordAro> are there any other TTD sprites that are no longer used at all?
21:56:43 <frosch123> i only learned that there are two different end-game screens, when andy was fixing the animated pixels in opengfx
21:57:06 <frosch123> LordAro: yes, multiple
21:57:37 <frosch123> but they are not as prominent
21: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
22:02:47 <frosch123> nielsm: actually, since they backgrounds are only 640x480, a simple window would be nice, the fullscreen looks bad anyway
22:03:12 <LordAro> nah, forcibly resize the game window
22:03:15 <frosch123> LordAro: when V made a baseset, he found alternative sprites for the rough land
22:03:23 <nielsm> well someone _might_ be playing on 640x480 ?? or 1280x960 at 2x scale
22:03:24 <frosch123> and we added support for it
22: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
22:05:03 <frosch123> so, i probably would not have added it, if i knew that first :p
22: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
22:07:35 <frosch123> ah, another of those "someone requested your review" :) that generally gets lost in the notification spam :)
22:09:09 <_dp_> is there some way to protect game state in general I wonder
22:09:16 <_dp_> so it wouldn't even compile ideally
22:10:43 <_dp_> not without rewriting half of the game I guess :(
22:11:10 <nielsm> storing all game state in transactional memory that could be chekcpointed and rolled back would be very convenient
22:11:25 <LordAro> i suspect to do it in sufficient detail would run into halting problem difficulties
22:11:43 <LordAro> with the current architecture, anyway
22: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
22:12:04 <_dp_> persistent structures huh?
22:20:18 <glx> but this one won't be in 1.10 branch
22:21:36 <_dp_> hm, I though there were bumps between minor versions before
22:21:51 <frosch123> _dp_: only once, because of a major bug
22:22:40 <glx> Yexo: if checks tab is ok it's mergeable
22:23:30 <Yexo> ah, it shows it succeeded in that tab, but the merge button is disabled for me
22:23:40 <Yexo> If anyone else can merge it, please go ahead
22:23:52 <glx> oh, I quickly run check it and I'll merge
22: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
22:25:54 <Yexo> It's easy enough to reproduce for me: stripping out the vehicle PerformanceAccumulator gives me a ~5% performance improvement
22:26:26 <LordAro> needs peter/someone else to pick it back up, really
22: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...
22: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.
22: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
22:27:09 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 closed issue #8119: Desync after building diagonal track next to dock end https://git.io/JfnI2
22:28:06 <glx> hmm I should probably reopen 8119 and add CmdClearArea :)
22:28:32 * _dp_ starts campaign for 1.11 "It's just an anagram"
22:29:01 <LordAro> wouldn't bet on it :p
22:32:52 <frosch123> in the settings tree the period looked worse
22:33:10 <mcbanhas> what's the settings tree?
22:33:13 <frosch123> since there were multiple "key: value" pairs, and only some having a period was weird
22:33:17 <_dp_> wow, I though #7248 was long fixed
22:33:31 <frosch123> mcbanhas: the settings window with the tree :)
22:34:34 <mcbanhas> frosch123, I will not apply periods on those.
22:34:54 <mcbanhas> I think the settings window needs special rules. tbh I haven't touched it yet
22:35:19 <mcbanhas> But I can tell from the start I don't see putting periods on every option either
22:35:50 <mcbanhas> Oh besides, these technically qualify as UI labels, not descriptive texts
22: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 :)
22:36:29 <frosch123> but tooltips are isolated, so safe
22:36:47 <frosch123> errors messages and "key: value" lists are not safe
22:36:47 <mcbanhas> frosch123, I've covered that on the rules too :p
22: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."
22:37:33 <frosch123> mcbanhas: that's the opposite of what i mean
22:37:49 <frosch123> there are windows where texts from ottd are shown next to texts from addons
22:37:58 <frosch123> if you change the style for ottd, the addon will look bad
22:38:22 <frosch123> and different addons following styles from different eras make it even worse
22: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.
22:39:01 <mcbanhas> If a modder decides to capitalize or not capitalize all the new vehicles in his mod by accident
22:39:15 <frosch123> it does not happen if you do not change stuff that was consistent before
22:39:27 <mcbanhas> But stuff is not consistent right now
22:39:33 <frosch123> but some things are
22:39:40 <mcbanhas> That's a bad argument
22:39:41 <frosch123> take the vehicle purchase list
22:39:52 <frosch123> it has a panel with properties at the bottom (speed etc)
22:40:01 <frosch123> various newgrf extend that "key: value" list
22: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
22:40:57 <FLHerne> I wonder if the "Ctrl+Click" could be highlighted in a different colour or something
22: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.
22:41:18 <FLHerne> The ones with several of those (like the signals) are hard to scan atm
22:41:43 <mcbanhas> There are compromises that can be made, but there are limits to that too.
22:41:53 <FLHerne> mcbanhas: There are a *lot* of grfs in existence
22:41:58 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on issue #8119: Desync related to diagonal track next to dock end https://git.io/JfnI2
22:41:58 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 reopened issue #8119: Desync related to diagonal track next to dock end https://git.io/JfnI2
22: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
22:42:28 <LordAro> see also: Linus' "never break userland" rant
22:42:34 <glx> easier to track the test savegame
22:42:37 <mcbanhas> I disagree with that.
22:43:36 <FLHerne> frosch123, mcbanhas: Do either of you have an example of what exactly you're arguing about? :P
22:44:06 <FLHerne> I don't see how any of the currently-proposed changes would be a problem
22:44:09 <frosch123> FLHerne: i specifically refer to the purchase list, and to error messaged like "cannot place industry ... \n ... because"
22:44:21 <mcbanhas> One moment let me demonstrate.
22:44:42 <frosch123> FLHerne: i have no objection against tooltips, since none of them interact with addon, afaik
22:45:14 <mcbanhas> By the purchase list you mean vehicle names?
22: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
22: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
22:46:32 <mcbanhas> Sorry, but linus is terrible at community management hahaha
22:46:42 <FLHerne> frosch123: I understand the *scope*, I don't see what proposed changes actually affect that
22:47:10 <frosch123> FLHerne: i do not know either. i did not understand the proposed changed to punctuation :)
22:47:15 <FLHerne> The periods at the end?
22:47:24 <mcbanhas> frosch123, I don't think the changes i'm proposing interfere with the settings tree at all
22:47:48 <FLHerne> TBH, for me the missing periods are so painful I'd prefer any resulting inconsistency from using them :P
22:48:01 <frosch123> FLHerne: i assumed the proposal is all lines shall end with a ".", while you only seem to mention tooltips
22:48:05 <mcbanhas> They're all UI labels in sentence capitalization. It's literally the rule I'm proposing
22:48:26 <mcbanhas> frosch123, it's only for tooltips
22:49:12 <FLHerne> Well, I think it should apply to multi-sentence popup windows and things too at some point
22:49:31 <FLHerne> Which could indeed cause some inconsistency where grfs provide the text
22: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?"
22:51:24 <andythenorth> way too close too my day job
22:51:43 <andythenorth> except in my day job, I just decide how we're capitalising and stuff
22:51:52 <andythenorth> and then people subtly undermine it by ignoring me
22: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.
22:52:55 <mcbanhas> andythenorth, haha I was a textual reviewer so I understand what you mean.
22:53:01 <andythenorth> so after the raging success of NRT
22:53:03 <LordAro> of course it's obviously not as serious as gamebreaking - it's not breaking newgrf compatibility or anything
22:53:05 <andythenorth> can we do pipelines / belts?
22:53:11 <LordAro> but the similarities are there, imo
22:53:43 <FLHerne> mcbanhas: Does "descriptive texts" not include the "Can't build industry here" things frosch mentioned?
22:54:04 <FLHerne> That's the same kind of window as the exit confirmation
22: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)
22:54:17 * _dp_ thinks any capitalization is fine as long as it's not a camelCase
22:54:27 <Yexo> Getting the first 95% out of the way makes it a lot easier to discuss the remaining few items
22:54:53 <mcbanhas> Yexo, not at all. Capitalization is changing completely for one.
22:54:53 <FLHerne> _dp_: WhAt AbOuT BaNaNaS CaSe?
22:55:18 * _dp_ urgently needs an exorcist
22:55:25 <mcbanhas> Because it's totally bonkers right now, and most people around here say they preferred sentence capitalization
22:55:42 <FLHerne> We ShOuLd MaKe AlL StRiNgS In OpEnTtD MaTcH It
22: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
22: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
22:57:08 <Yexo> The change you want to make now is way too big, which makes it very hard to get to a consensus
22:57:37 <mcbanhas> Yes but it's impossible to review text on individual commits like that.
22:57:58 <Yexo> I'm specifically not talking about the commits, but about the style page document
22:58:13 <FLHerne> mcbanhas: Ok, so now we just need to review the rules as separate 'commits' ;-)
22:58:23 <FLHerne> Which is more workable
22: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.
22:59:30 <mcbanhas> There are irregular instances of sentence and title capitalization
22: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
23:00:19 <mcbanhas> The best way would be by comparing the PR I am finishing with all these changes
23:00:39 <mcbanhas> You will the see rules put in practice
23:00:50 <LordAro> you are ignoring what we are telling you
23:00:51 <mcbanhas> and all the changes highlighted on github
23:01:05 <LordAro> a big massive blob of a document/PR/whatever will get ignored or closed
23:01:10 <LordAro> no one will review it
23:01:33 <LordAro> one change/consistency fix/new rule at a time
23:01:48 <mcbanhas> But why not? It's text, not code. With a manual of style this takes about 2 hours max to review
23: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
23:02:43 <mcbanhas> Yexo you are forgetting upgrading a text also implies re-writing it. It's not possible to separate rewrites from reformatting.
23: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.
23:02:57 *** Eddi|zuHause has joined #openttd
23:03:05 <LordAro> of course it's possible
23:03:19 <LordAro> it might mean changing the same string multiple times, but that's still much easier to review
23:03:52 <mcbanhas> LordAro, that's a nightmare of a commit.
23: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
23:04:29 <mcbanhas> I would have to do various separate lang files
23:04:39 <mcbanhas> one with all the rewritten text
23:04:44 <mcbanhas> one with all the capitalization
23:04:50 <mcbanhas> one with all the punctuation
23: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)
23:04:56 <mcbanhas> and overlapping variants for each
23:05:05 <mcbanhas> it's an impossible standard to apply to text.
23:05:08 <FLHerne> Yexo: To be fair, that's because there never has been a proper base version
23:05:15 <LordAro> mcbanhas: this is what individual commits are for
23:05:40 <LordAro> you can flip between them and make intermediate changes if needed
23: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
23:05:50 <FLHerne> LordAro: That does sound like a pain to edit
23:06:00 <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.
23:06:08 <FLHerne> I don't see how it makes sense to do the actual changes that way
23:06:10 <mcbanhas> It means I would have to rewrite thing 4 or 5 times
23:06:19 <mcbanhas> especially when there are no rules right now
23:06:22 <LordAro> that's precisely what i've been asking you to do for the last 6 months
23:06:33 <mcbanhas> what you are asking me would make sense if there were rules prior
23:06:40 <mcbanhas> but there are no rules right now
23:06:50 <Yexo> There are, they're just not written down
23:07:22 <mcbanhas> You guys are putting me through a bureaucracy nightmare for little reason here.
23: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"
23:08:08 <LordAro> mcbanhas: welcome to software development
23:08:29 <mcbanhas> LordAro, it's sort of bad practice to apply code standards to text.
23:08:40 <mcbanhas> Can we reach a commitment here?
23:08:51 <mcbanhas> I can provide examples with pictures of the things that I am changing.
23:09:07 <mcbanhas> How does it affect the current text.
23:09:09 <LordAro> please stop trying to come up with workarounds
23:09:10 <Yexo> Out of curiosity: what's so bad about that?
23:09:14 <LordAro> we will not budge on this
23: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.
23:10:45 <LordAro> we are trying to help you come up with a way of feasibly reviewing it
23:11:29 <mcbanhas> LordAro, I wouldn't even know how to properly write the changes to do what you are asking me.
23:11:39 <FLHerne> LordAro: I don't see how "review every string five+ times" is feasible
23: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
23:12:36 <FLHerne> Do the changes once, have a document listing the systematic changes from existing practice
23:12:45 <Yexo> I do want to review the manual properly, which I still cannot do
23:13:18 <FLHerne> Review the effects in-game *of each systematic change* carefully
23:13:28 <LordAro> manual needs to have individual changes reviewed, or the code does
23:13:33 <FLHerne> But you can do that without actually making the changes separately
23:13:51 <FLHerne> A trailing period doesn't look different because the capitalization changed
23:13:55 <nielsm> how about applying the rules one by one and making gradual changes, to only a small segment of texts
23:14:15 <nielsm> like painting a corner of a room to evaluate the colour
23:14:23 <FLHerne> And yeah, definitely makes sense to review/commit changes to each general category of strings separately
23:14:29 <mcbanhas> nielsm, that's doable. I can do it for all tooltips first, for example.
23:14:30 <nielsm> and if it turns out satisfactory, do the remaining in one huge chunk
23:14:39 <nielsm> less than all tooltips I think
23:14:43 <nielsm> that's still a very large chunk
23:14:58 <mcbanhas> What about all button labels?
23:15:01 <nielsm> e.g. tooltips for the main toolbar and railroad construction only
23: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)
23:15:30 <FLHerne> nielsm: i.e. just as an example "it will look like this" before putting effort into changing the rest?
23:15:31 <LordAro> no need to review *every* string
23:15:34 <LordAro> just the changed ones
23:16:07 <nielsm> FLHerne: yeah review the approach and make a sample of it that's reviewable
23:16:38 <FLHerne> LordAro: That's what I imagined you were imagining, I still don't think it's feasible
23:16:53 <FLHerne> Each change affects many of the strings
23:17:06 <FLHerne> You just end up reviewing basically the same string multiple times
23:17:19 <mcbanhas> Yexo, these are fairly easy to answer
23:17:40 <LordAro> FLHerne: yes, but it makes it much easier to see that only what you expect has been changed
23:17:43 <mcbanhas> If you can compile a list all your doubts I can answer everything with examples easily.
23:18:38 <mcbanhas> Personally I think nielsm is the best solution.
23:18:39 <FLHerne> LordAro: It's easy to distinguish which systematic change was relevant to any issue
23:18:48 <LordAro> there's also the *massive* amount of translator churn to consider
23:19:04 <FLHerne> Yeah, I brought that up earlier :-/
23:19:24 <FLHerne> At this scale, I almost wonder if it's worth patching the translator
23:19:25 <mcbanhas> Yeah but the problem is that currently, translations are inconsistent too because the original text is inconsistent
23:19:49 <FLHerne> Add a "no semantic change" flag that doesn't force translation updates
23:20:17 <FLHerne> AAUI, none of the proposed changes affect tags or anything like that?
23: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.
23:21:20 <nielsm> mcbanhas: have you experimented with adding colour codes to the modifier keys in tooltips? was an idea I had
23:21:26 <mcbanhas> FLHerne, only on tooltips. I added a paragraph break on the tooltips that require titles
23:21:41 <mcbanhas> nielsm, I did actually. It doesn't look so good
23:21:54 <mcbanhas> the yellow background is a bit too light
23:22:20 <mcbanhas> but we can do further experimenting later :)
23:22:23 <FLHerne> nielsm: <FLHerne> I wonder if the "Ctrl+Click" could be highlighted in a different colour or something
23:22:43 <nielsm> heh right, I haven't followed the entire conversation detailed I'll admit
23:22:58 <mcbanhas> LordAro, can we compromise on nielsm's suggestion of doing only a few strings of small sections at a time?
23:23:50 <LordAro> mcbanhas: possibly, though i would rather do one *type* of change at a time
23:24:15 <LordAro> arbitrarily splitting by window or whatever doesn't really make much sense
23: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 :)
23: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.
23:32:18 <FLHerne> tbh, I think small batches are useful as a review of the review process, as much as the actual changes :D
23:32:28 *** Foveafoxy has joined #openttd
23:33:04 *** Foveafoxy is now known as Guest24596
23:34:02 <Yexo> Wiki is really a terrible format to review :(
23:35:58 <Yexo> And then I'm ignoring the consistent: "How much does this deviate from what is done now?" question.
23: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.
23:39:07 <FLHerne> mcbanhas: tbh, the formatting is what people are going to care about for review ;-)
23:39:39 <FLHerne> It's much easier to spot inconsistencies in that than the writing style
23:40:09 <FLHerne> (but do you have an example for the "broken English"? I don't remember seeing anything terribly bad
23:40:22 <FLHerne> Except maybe a couple of the setting names/descriptions
23: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
23:45:16 <andythenorth> did we agree something?
23:45:28 * andythenorth was watching a train go round in a circle
23:45:40 <andythenorth> on the trainset that 'belongs to my kids'
23:46:10 <Yexo> glx: There are several calls to SetDockingTile(t, false); Are those in general correct or would they need RemoveDockingTile as well?
23:46:50 <FLHerne> andythenorth: I think mostly we just agreed to pretend all the ideas are compatible :P
23:47:39 <andythenorth> isn't capitalisation just a text filter?
23:47:44 <andythenorth> my editor can change cases
23:47:53 <andythenorth> I mean, even css can do it now :P
23: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.
23:51:48 <mcbanhas> Also, signal tooltips are the only ones that have a paragraph break, for some arbitrary reason.
23:53:32 <FLHerne> Hm, I think "bridge heads" is closer to being right than the other two
23:54:34 <FLHerne> Yes, but that's a slightly different meaning
23:55:31 <FLHerne> No-one's invading over the bridges, so there are no bridgeheads around the bridge heads :p
23:55:56 <glx> Yexo: all the calls are in map accessors, but I'll check the context
23:56:35 <mcbanhas> Then we need the correct engineering term
23:56:51 <mcbanhas> Because I find no references to "bridge head" applied to the topic
23:57:11 <mcbanhas> and "bridge head" does not exist alone as a term
23:59:47 <milek7> 'Bridge ends not at the same level'?
continue to next day ⏵
