IRC logs for #openttd on OFTC at 2020-05-19
⏴ go to previous day
00:17:55 <spnda> Hey guys, anyone know where sprite 681 is used?
00:18:01 *** matt21347 has joined #openttd
00:20:50 <FLHerne> spnda: Be aware the answer might be "nowhere", a few sprites in the baseset aren't
00:21:38 <spnda> yeah i think thats whats happening
00:22:35 <FLHerne> spnda: Hm, 681 is a Ç ?
00:22:44 <FLHerne> Or am I looking in the wrong file?
00:23:41 <spnda> I don't see it referenced in sprites.h, so it might be just completely unused
00:25:05 <FLHerne> In what file is 681 a trash can?
00:26:12 <spnda> if you look it up in the sprite aligner tool inside openttd and go to sprite 681, thats what comes up
00:26:16 <FLHerne> Searching OpenGFX source I get a large-font 'Ç' and a Toyland RV, neither of which are that
00:27:24 <FLHerne> Ok, I see it in-game, perhaps I'm searching wrong
00:29:43 <FLHerne> Can't think of ever seeing that anywhere
00:31:41 <FLHerne> I wondered if it might be in the scenario editor, that has a few different UI elements
00:31:51 <FLHerne> But I can't see it there either
00:44:09 <supermop_Home> it's a cute trash can
00:47:28 <orudge> So, pleasingly, desktop OpenTTD cross-compiles to ARM64 then runs absolutely fine on an ARM64 Windows 10 device (well, QEMU'd ARM64 device at present). And performance of OpenTTD itself is surprisingly decent in QEMU, admittedly on a 64x64 map!
00:47:35 <orudge> Trying it out on a Raspberry Pi 4 might be more fun though
00:48:23 <TrueBrain> do I dare to ask the big question.... why?!
00:48:32 <TrueBrain> you bored because of the corona shit? :D
00:48:43 <orudge> I've also been resuccitating the OS/2 port with CMake support...
00:49:00 <TrueBrain> but I like crazy :D
00:49:34 <TrueBrain> off to bed now :) Sleep well all
00:50:12 <orudge> To be fair, the ARM64 Windows port was just a case of installing packages with vcpkg, adding a new target in the VC project, and fixing one bug in a .cpp file. I'll submit a pull request once the cmake changes are in.
01:01:26 <FLHerne> orudge: Can you make it run on MacOS 7? :D
01:01:56 <FLHerne> I got it to run on my Powerbook with Linux installed, but the nubus-pmac kernel fork seems dead for years now
01:03:22 <FLHerne> Perhaps I should try and get that thing working again
01:03:39 <FLHerne> I think the power supply died
01:22:10 *** tokai|noir has joined #openttd
01:22:10 *** ChanServ sets mode: +v tokai|noir
01:25:54 <Speeder__> see if I got it right: coordinate 0, 0 IS present ingame, but represents a vertex, not a tile?
01:26:15 <Eddi|zuHause> Speeder__: that depends
01:27:08 <Eddi|zuHause> on whether you view vertexes (like the terraform tool) or tiles (like the bulldozer), every tile is represented by its upper (north) corner
01:28:23 <Eddi|zuHause> also, some tiles along the map border might be "void" tiles that aren't visually on the map, but hidden markers of the border (depends on whether you have water borders or freeform borders)
01:29:13 <Speeder__> alright... so, I have a 2048x2048 map
01:29:31 <Speeder__> but in-game using the ? tool, the smallest coordinate is 1x1, and biggest is 2046x2046
01:30:03 <glx> void tiles all around the map used as safety markers IIRC
01:30:33 <Speeder__> but when I export a heightmap of a map that is just a flat square except I modified the outermost tiles (for example making them 1 level lower or higher), the exported heightmap has the border being 2 tiles thick on the "south" side, and 3 tiles thick on the "north" side
01:32:03 <Speeder__> inded, I can't use ? tool on 0x0
01:32:16 <Speeder__> but if I am using the terraform tool, I can make a slope on the first tile
01:32:26 <Speeder__> so I assume the coordinate of 0x0 IS present
01:32:39 <Speeder__> thus 0x0 exists, you just can't interact with it, except with vertex manipulation tools
01:41:26 *** Speedy` has joined #openttd
01:45:41 <Eddi|zuHause> yes-ish. if you terraform the 1x1 vertex, it modifies the slope on all adjacent tiles (1,1),(1,0),(0,1) and (0,0)
01:47:21 <Eddi|zuHause> that's one of the reasons why there needs to be a row of void tiles: so the terraform tool doesn't crash (or do weird things) when you modify the border of the map
01:48:54 <Eddi|zuHause> if you have freeform borders on, then you have 2046 tiles or 2047 vertices accessible on a 2048 map. means there is 2 inaccessible tiles and 1 inaccessible vertex
01:50:07 <Eddi|zuHause> if you have fixed water borders active, you get 1 additional tile, but you lose the ability to terraform 1 vertex
01:51:22 <Speeder__> loading heightmap I assume is always "freeform" mode?
01:53:24 <Eddi|zuHause> no, i think you can set that up
01:54:40 <Speeder__> so, in a heightmap file... pixel 0x0 is a vertex, outside the map. pixel 1x1, and pixel 2047x2047, are whole tiles, but that are "void tiles", kinda outside the map?
01:57:21 <Eddi|zuHause> pixel 0x0 is both a void tile and an "outside" vertex, 1x1 is a real tile, and 2047x2047 is a void tile, but a real vertex
01:59:44 <Eddi|zuHause> 2047x2047 must be a real vertex, because it still affects the slope on the real tile 2046x2046
02:00:28 <Eddi|zuHause> (the slope shape is not stored, but recalculated from the 4 adjacent vertices)
02:08:36 *** neofutur has joined #openttd
02:08:58 <neofutur> hi all, I m trying to download content and it comes empty
02:09:20 <neofutur> ipv6 is probably nt working with my ISP and it seems the server is not listening on ipv4
02:09:49 <neofutur> debug says : dbg: [net] [tcp] could not connect IPv6 socket: Connection timed out
02:10:17 <neofutur> and then after a long time : dbg: [net] [tcp] connected to 3.125.40.34:3978 (IPv4)
02:10:25 <neofutur> but still the content list is empty
02:10:44 <neofutur> i m on ubuntu, and it seems all ports are opened
02:10:50 <Eddi|zuHause> that means your PC is trying to connect via IPv6 and failing. you can tell your OS to not try IPv6 at all
02:11:12 <neofutur> iptables -L says ACCEPT everywhere
02:11:52 <neofutur> just me ? por the content server could have a problem ?
02:12:28 <neofutur> theres no "ipv4 only" option in openttd ?
02:12:49 <neofutur> but anyway, even after I get dbg: [net] [tcp] connected to 3.125.40.34:3978 (IPv4)
02:12:58 <neofutur> the content list stays completely empty
02:13:46 <neofutur> also if I try wget 3.125.40.34:3978
02:14:08 <neofutur> wget says : HTTP request sent, awaiting response...
02:14:13 <neofutur> and then nothing else
02:14:41 <Eddi|zuHause> well, i get a completely normally filled list
02:14:49 <neofutur> Connecting to 3.125.40.34:3978... connected.
02:14:59 <neofutur> but then receiving nothing, not even with wget
02:15:22 <Eddi|zuHause> there is somewhere a setting to use the internal protocol or http for content server, but that might be the actual download only, not filling the list
02:22:47 <neofutur> no_http_content_downloads = false
02:29:02 <neofutur> well, same problem anway if i set it to true
02:30:17 <Eddi|zuHause> like i said, try disabling ipv6 in your OS
02:30:20 <neofutur> could I download those files from somewhere else and install manually in /usr/games/openttd ?
02:30:59 <neofutur> ipv6 is just the first part of the problem, I get to ipv4 after some time .
02:31:01 <neofutur> dbg: [net] [tcp] could not connect IPv6 socket: Connection timed out
02:31:02 <neofutur> dbg: [net] [tcp] connected to 18.194.240.221:3978 (IPv4)
02:31:23 <neofutur> but even when connected by ipv4 the list stays empty
02:31:28 <Eddi|zuHause> yes, you can download them from the website.
02:31:41 <Eddi|zuHause> but you should never install anything manually in /usr
02:31:57 <Eddi|zuHause> you can in /usr/local or something, but a better idea would be in ~/.openttd
02:32:10 <neofutur> ehich website ? 3.125.40.34:3978 ?
02:32:29 <Eddi|zuHause> no, the website from the topic
02:35:00 <Eddi|zuHause> aye, it doesn't here, either
02:37:41 <neofutur> there are 9 big errors in the DNS for openttd.org
02:38:05 <neofutur> putting openttd.org in the field
02:38:22 <neofutur> thats probabl why content.openttd.org have problems
02:38:40 <Eddi|zuHause> well, nobody here right now that could fix any of that
02:39:37 <Eddi|zuHause> ping TrueBrain about the connection errors
02:41:18 <neofutur> TrueBrain: PMing you, i m pretty sure there are dns probles with Connecting to [content.openttd.org]:3978
02:52:51 <glx> I get the list without issue, and I have ipv6
02:57:43 <neofutur> 9 huge delegation errors . . .
02:58:03 <neofutur> from here : ping content.openttd.org gives :
02:58:18 <neofutur> 17 packets transmitted, 0 received, 100% packet loss, time 16360ms
03:15:31 <neofutur> at first i just wanted an ai script, since the ubuntu package comes with none
03:16:10 <neofutur> where should I put the tar file to get an AI script ?
03:17:40 <Eddi|zuHause> (or a number of other places, check the readme)
03:18:14 <glx> anyway I think it's normal to not get wget reply from content.openttd.org, it's a custom protocol
03:19:49 <neofutur> dbg: [misc] [squirrel] Failed to compile 'smalltownai-8/info.nut'
03:20:09 <neofutur> should I do something else than just tar xvf the file ?
03:21:18 <Eddi|zuHause> you don't need to unpack the tar, but the AI might miss some libraries
03:22:04 <neofutur> Your script made an error: the index doesn't exist
03:22:15 <Eddi|zuHause> openttd can read tar files (just not tar.xz or tar.gz)
03:23:53 <Eddi|zuHause> ... but at the same time, it doesn't have to be in a tar either, a regular directory will do as well
03:24:14 <Eddi|zuHause> like i said, you're probably missing some libraries
03:24:17 <neofutur> why does the ubuntu package come with no AI included ?
03:24:23 <Eddi|zuHause> those are a pain to set up with no content manager
03:25:53 <Eddi|zuHause> the AIs are not done by the core openttd developers, and there's no review process to get them included, so can only be shipped via the content download, not via the game packages
03:25:56 *** Wormnest has joined #openttd
03:26:56 <neofutur> starnge i remember having ais when i was playing openttd 10 years ago
03:27:21 <glx> that was before the scripting
03:27:27 <Eddi|zuHause> yes. those were the old AI from the 90s, it was completely ripped out for something that's actually from this century
03:28:13 <neofutur> well at least i could play :)
03:30:41 <neofutur> well i ll stop trying for now. lets hope someone can fix the DNS errors so i could use the content download
03:32:15 <Eddi|zuHause> ... only time will tell :)
03:33:14 <glx> you're the first one to have this issue
03:39:29 <neofutur> but there are huge dns errors anyway
03:39:59 <neofutur> and perhaps i m the first one to try to play this from peru with this ISP
03:40:56 <neofutur> traceroute content.openttd.org
03:41:07 <neofutur> is also awful from here
03:43:10 <neofutur> also i can reach the list of online servers, but not the content list . . .
03:45:02 <neofutur> possibly the fact that content.openttd.org is a CNAME to content.aws.openttd.org doesnt help ?
03:46:49 <neofutur> this is the exact dns poroblem i can find
03:54:14 <Eddi|zuHause> so... i actually managed to "clean up" this messy table that oberhümer left me, and got it through the generate step. with only 1117 warnings
03:54:31 <Eddi|zuHause> that's just over 1 warning per vehicle :p
03:55:27 <glx> I guess you are using your ISP's dns
03:56:23 <glx> maybe you could try with google dns
03:57:53 <neofutur> i ll try with 8.8.8.8
04:08:01 <glx> so maybe your ISP does weird things
04:08:20 <neofutur> but everything works here, including games
04:08:35 <neofutur> for months . . .only openttd have this problem
04:09:00 <glx> I guess it doesn't understand openttd content protocol and blocks it
04:12:27 <neofutur> ( but I would fix the dns before saying that :p )
04:17:24 <Speeder__> why OpenTTD heightmap converter uses luminosity formula instead of just straight using the RGB values as literal?
04:17:48 <Speeder__> many heightmap generators just assume you are not interested in luminosity or appearance and is just storing raw data...
04:23:50 <neofutur> could soeone recoend a default AI script I couls install without the content manager ?
04:24:35 <neofutur> the gae is real boring without an AI ;(
04:26:17 <Speeder__> neofutur, why without the content manager?
04:26:58 <neofutur> not working, possibly dns problem or isp blocking
04:27:45 <neofutur> and if I had a feature request for openttd it would be to come with at least one default working ai script as It did 10 years ago )
04:45:33 <Speeder__> can I somehow see the void tiles?
05:30:26 <Eddi|zuHause> "WARNING: 1 shift/reduce conflict" i don't think i have the right mindset to try to debug that right now
05:31:31 <FLHerne> Eddi|zuHause: I tried, it doesn't seem obvious
05:34:26 <Eddi|zuHause> well, they usually involve rewriting the grammar a bit
05:35:10 <Eddi|zuHause> and i'm sleep deprived, having a mild fever, and my corona test hasn't come back for 2 days now
05:35:24 <Eddi|zuHause> (it's really unlikely to be corona anyway)
06:28:38 *** neofutur has joined #openttd
06:36:37 *** WormnestAndroid has quit IRC
06:37:50 *** WormnestAndroid has joined #openttd
06:43:06 *** Extrems` has joined #openttd
06:44:28 *** Extrems` is now known as Extrems
06:51:16 <FLHerne> Ok, so I wrote an nml lexer in C using re2c
06:52:33 <FLHerne> It seems a lot faster, if I can get the Python integration to work sanely...
07:25:54 *** andythenorth has joined #openttd
07:47:46 *** Gustavo6046 is now known as Guest25533
07:47:49 *** Gustavo6046 has joined #openttd
08:17:32 *** sla_ro|master has joined #openttd
08:28:06 <LordAro> FLHerne: re2c? as in regex?
08:59:45 *** andythenorth is now known as Guest25538
09:01:05 <LordAro> tbf, section 1.4 doesn't exist anymore
09:07:09 <Flygon> Today's mistake was taking a 262k by 131k screenshot in OpenTTD.
09:11:36 <Guest25538> Documentation is super
09:11:45 *** Guest25538 is now known as andythenorth
09:11:54 <andythenorth> Goes out of date :)
09:16:15 <Flygon> Good news, screenshot saved.
09:16:32 <Flygon> Which is utterly killing Windows 10's thumb generator.
09:17:25 <TrueBrain> so I read a lot of red text that DNS is broken, yet I see the DNS resolves fine
09:17:27 <TrueBrain> this will be interesting
09:18:55 <TrueBrain> yeah, so that was high-horse blablabla
09:25:16 <TrueBrain> in general, it is safe to say if someone says: DNS is broken, here is the IP of the DNS, that DNS is not to blame :)
09:28:38 <TrueBrain> Eddi|zuHause / glx: just for your information, content.openttd.org indeed doesn't serve http :) (but you figured that out :P)
09:29:14 <TrueBrain> everything is healthy, no errors reported .. so my best bet would be something between the application and the AWS POP is blocking 3978 :)
09:50:13 *** argoneus7 has joined #openttd
09:53:46 <LordAro> also, OTTD 10 years ago didn't come with an AI
10:02:13 <LordAro> seems to be complaining about the nameservers, rather than the domain itself
10:02:22 <TrueBrain> you can safely ignore that
10:02:52 <TrueBrain> strictly seen they are correct, but it is only very strictly seen .. more towards the pedantic :)
10:02:59 <TrueBrain> it is not hindering anyone from any resolving
10:03:07 <TrueBrain> (which was apparent, by the fact IPs followed :D)
10:08:34 <TrueBrain> 1 person has uploaded nearly every day something new to BaNaNaS :)
10:08:50 <TrueBrain> these things are now more visible to me, which I like :)
10:10:01 <orudge> [00:01:28] <FLHerne> orudge: Can you make it run on MacOS 7? :D <-- I did try that in the very, very early days of OpenTTD, when it was simple C. I didn't get very far, classic MacOS was a horrible environment to develop for (IMHO). It'd be impossible now of course!
11:08:33 *** WormnestAndroid has quit IRC
11:08:46 *** WormnestAndroid has joined #openttd
12:32:42 <DorpsGek_III> [OpenTTD/OpenTTD] James103 opened issue #8162: Converting town-owned road returns ambiguous/unhelpful error message https://git.io/Jfu9j
13:09:05 <DorpsGek_III> [OpenTTD/OpenTTD] auge8472 commented on issue #8162: Converting town-owned road returns ambiguous/unhelpful error message https://git.io/Jfu9j
13:27:30 *** gelignite has joined #openttd
14:05:09 *** ChanServ sets mode: +o Yexo
15:05:52 <FLHerne> LordAro: Almost all lexers are based on regexes in one form or another, including the current one?
15:07:31 * glx likes to fix EOL issues (not)
15:09:53 *** Speeder has joined #openttd
15:15:07 <neofutur> 02:53 < LordAro> 13 years ago, maybe
15:15:26 <neofutur> probably yes, i m 47 and played ottd very long ago
15:15:46 <neofutur> 20:16 -NickServ(services@services.oftc.net)- Time registered: Sun 25 Apr 2004 03:17:49 +0000 (16y 0m
15:16:00 <neofutur> lets just say "after 2004"
15:16:45 <neofutur> 03:02 < TrueBrain> you can safely ignore that
15:16:54 <neofutur> you can ignore warnings safely, not errors
15:19:17 <neofutur> is "openttd -d net=10" the best debug i can get about this empty content list ?
15:25:20 <LordAro> "errors" as determined by some random website are not (necessarily) errors worth caring about
15:25:38 <LordAro> that's the most debug information you'll get out of openttd
15:25:48 <LordAro> there's other things you can do, like wireshark, if you really want to
15:27:07 <neofutur> so, no debug at all about the weird protocol the ISP is possibly blocking :(
15:27:39 <LordAro> it's not *that* weird
15:27:54 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 opened pull request #8163: Fix #8161, e31def197: Lang files may have LF EOL https://git.io/Jfujc
15:29:49 <neofutur> and concerning my other question , any basic AI i could install manually without using the content service ?
15:30:16 <glx> most AI use at least pathfinding library I think
15:30:55 <LordAro> Simple AI attempts to mimic the old TTD AI
15:31:00 <neofutur> could you link me to it ?
15:33:59 <glx> it depends on 2 pathfinder libraries
15:37:26 <LordAro> mm, i'm not sure if the pathfinder libraries are available anywhere
15:37:27 <neofutur> ok, Pathfinder.Rail 1 and Pathfinder.Road 4, trying that
15:37:27 <glx> haha SimpleAI 14 depends on Pathfinder.Rail 1 and Pathfinder.Road 4, Pathfinder.Rail 1 depends on Graph.Aystar 4, Pathfinder.Road 4 depends on Graph.Aystar 6, both Graph.Aystar depend on Queue.BinaryHeap 1
15:37:41 <glx> yeah libraries will be hard to find
15:38:13 <LordAro> and yes, the aystar weirdness has been a thing forever
15:38:23 <glx> I think I can make you a pack
15:38:43 <LordAro> the text on bananas does imply that you should be able to download things directly, but obviously you can't...
15:43:07 *** snail_UES_ has joined #openttd
15:48:20 <glx> contains Simple AI and the dependancies
15:57:01 *** WormnestAndroid has quit IRC
15:58:16 *** WormnestAndroid has joined #openttd
16:05:27 <neofutur> 08:25 < LordAro> there's other things you can do, like wireshark, if you really want to
16:05:38 <neofutur> yeah thought of trying with nmap
16:10:09 <glx> a vpn could be an option too
16:18:21 *** Wormnest has joined #openttd
16:20:18 *** supermop_Home has joined #openttd
16:21:41 <neofutur> glx: installed and working, thanks for the zip !
16:41:34 <Speeder> there are any way to build diagonal river?
16:47:28 <Speeder> I did some testing with the movement of the ships, and seemly they act as if diagonal rivers existed
16:47:58 <LordAro> because no one ever drew/implemented them
16:48:06 <Speeder> ie: on a river that is "ladder" shaped in the diagonal, the way you would generate a diagonal with a railway, ships move a s if they were on a railway, even shifting to the sides
16:48:20 <Speeder> I saw some diagonal canals on the forums
16:48:35 <Speeder> you mean noone finished a complete implementation for a patch?
16:48:53 <LordAro> no one's ever submitted one
16:49:24 *** gelignite has joined #openttd
16:50:20 <LordAro> a screenshot like that could easily have been modified
16:52:54 <Speeder> guy said he made the tiles and "code exists" I thought he had submitted it
16:53:00 <Speeder> and used only for himself :/
17:00:18 <TrueBrain> <neofutur> you can ignore warnings safely, not errors <- that is an opinion, not a fact. In this case, the errors are semi-bogus, and have no influence on you resolving any DNS. Which is clearly seen by the fact you resolved the DNS in every attempt fine. Is it completely correct? no. Does it hurt anyone? Also no. So let's not create a fire where there isn't any. Not helping anyone :)
17:01:39 *** arikover has joined #openttd
17:02:53 <andythenorth> shock news, DNS isn't perfect? :o
17:03:00 * andythenorth everyday, schoolday
17:14:42 <TrueBrain> would be a welcome change in news to be honest
17:14:45 <TrueBrain> all this covid here covid there
17:18:16 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo approved pull request #8163: Fix #8161, e31def197: Lang files may have LF EOL https://git.io/JfzTS
17:29:44 <Eddi|zuHause> Speeder: you can (visually) achieve diagonal rivers/canals by providing the right sprites in a NewGRF (or baseset)
17:30:04 <Eddi|zuHause> so that screenshot is entirely plausible
17:30:21 <Eddi|zuHause> just don't try building a rail on the other halftile
17:30:22 <Speeder> the code already supports it?
17:30:44 <Eddi|zuHause> it's just a different shore sprite
17:30:46 <Speeder> at least on plains...
17:30:58 <Eddi|zuHause> covering more of the water area
17:30:58 <Speeder> because I don't think you can build rivers on half-tile slopes
17:31:12 <Eddi|zuHause> just on flat land
17:31:20 <Speeder> I wanted diagonal rivers on half-tile slopes
17:31:40 <Eddi|zuHause> that doesn't work
17:32:35 <Eddi|zuHause> which is part of the reason why nobody ever did these graphics. because that would be an immediate followup demand, which wouldn't be as easy
17:42:32 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 merged pull request #8163: Fix #8161, e31def197: Lang files may have LF EOL https://git.io/Jfujc
17:43:54 <_dp_> yeah, it's one thing to throw some river sprites on green grass and another to make sure it actually works with other game elements including newgrfs
17:45:37 <_dp_> diagonal rails though never worked on same tile with anything but the rail of same type
17:51:11 <_dp_> btw, even diagonal riverbanks that are in the game have some issues that were never solved
17:56:17 <Eddi|zuHause> _dp_: well, we've had diagonal rails on ocean tiles for a while now
18:00:36 <_dp_> Eddi|zuHause, counts as slopes :p
18:02:48 <Eddi|zuHause> my screenshots switch from jagged foundations to diagonal foundations somewhere between oct 2007 and jan 2008
18:03:30 <_dp_> yeah, but you still can make full foundation on diagonal tile blocking ships
18:04:41 <DorpsGek_III> [OpenTTD/OpenTTD] michicc opened pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzLv
18:05:42 <Eddi|zuHause> yeah, but only one person in the world cares about those :)
18:05:59 <FLHerne> Speeder: "ships move a s if they were on a railway, even shifting to the sides"
18:06:42 <FLHerne> Thats because ships follow "tracks" that are exactly the same as the rail ones
18:07:08 <FLHerne> i.e. an empty water square is equivalent to a rail tile with every possible track section built
18:08:00 <Speeder> so only thing lacking to make diagonal water is the grpahics, and changing the code to allow water tiles on diagonal slopes?
18:08:35 <_dp_> it would be really nice to see some performance measurements for all that C++ upgrade stuff
18:12:12 <nielsm> uh btw while the 1.10.2 release PR is still open, we should really try to make a fix for that macos 10.12 crash
18:12:56 <glx> nielsm: yeah, but it's hard to test for most of us
18:13:19 <nielsm> glx: we can at least make a guess and hope it works? :/
18:13:31 <neofutur> well i have a working AI, thanks glx . bye all
18:13:32 <nielsm> make the CI publish a build?
18:14:33 <glx> nightlies exists for that
18:14:36 <Speeder> boats never crash into each other?
18:14:38 <TrueBrain> lol .. he left after being lovely sarcastic in private messages to me
18:15:30 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzLo
18:15:32 <TrueBrain> pretty funny .. he claimed he has been running DNS for years, so he knows better. Guess he never really looked at the DNS configuration, and the errors returning by the tools. In Dutch we have this saying: "Beste stuurlui staan aan wal". Meh.
18:15:52 <TrueBrain> guess you cannot make everyone happy :)
18:16:08 <glx> the main issue is the ISP I think
18:16:20 <TrueBrain> his issue had NOTHING to do with DNS, that is for sure :)
18:16:26 <TrueBrain> (as from moment 1, his DNS resolved)
18:17:20 <TrueBrain> but as that goes .. he found an issue with DNS, so in his mind that was the root-cause .. sadly, it isn't ..
18:17:30 <TrueBrain> still not sure why he could make a connection, but not transmit data over it
18:17:35 <FLHerne> They're still logically full tiles
18:18:00 <FLHerne> Speeder: And no, boats go through each other
18:18:01 <TrueBrain> his ISP uses CgNAT, possibly that has something to do with it, but I cannot figure out what
18:18:17 <Speeder> what is OPenGFX+ exactly?
18:18:19 <Speeder> there is a thread for it?
18:19:19 <Yexo> It's a bunch of NewGRFs that make slight improvements to the basegame without changing very much.
18:19:38 <FLHerne> Speeder: Collection of NewGRFs to do things in the general style of the base game, but taking advantage of new features
18:19:48 <nielsm> could we make ottd 1.11 use plain HTTP for all content listing and fetching? and maybe try to use a system HTTP library instead of the homegrown thing
18:20:19 <Yexo> OpenGFX+ Landscape for example allows you to use a varying snowline. OpenGFX+ Industries has some tweaks to production (and more?) to industries, OpenGFX+ Airports gives you rotatable versions of the default airports
18:20:35 <TrueBrain> nielsm: pretty sure we accept PRs :D
18:20:55 <TrueBrain> back in the day there was no real HTTP library, but things have changed :)
18:21:03 <TrueBrain> ideal, support HTTPS too ;)
18:21:11 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfztU
18:21:31 <nielsm> I'd suggest using libcurl where it exists and maybe just winhttp on windows
18:21:42 <TrueBrain> nielsm: remember that if you go the HTTP way for listing, you also need to add JSON or YAML support or something like that, I am afraid
18:22:02 <TrueBrain> so it is not a 10 minute task :)
18:22:05 <TrueBrain> but it would really help
18:22:22 <TrueBrain> and if we can make the master server HTTP too .. that would be even better :D
18:23:06 <TrueBrain> but remember, if you cannot connect to an IP, it is the DNS you should blame! (sorry, I had to let that sarcasm out .. he was not a friendly guy :D)
18:24:12 <TrueBrain> well, nielsm , if you like we can make a Rest API with CSV? :D
18:25:56 <TrueBrain> and if you seriously want to pick this up, the API for BaNaNaS is fully documented on Swagger, and as far as I know supports all the usecases EXCEPT for fetching the download URL. That one is missing :)
18:26:08 <TrueBrain> (but should be added regardless)
18:26:40 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfztG
18:26:41 <glx> hmm getting the full list in one go would make the content GUI less irresponsive I guess
18:27:06 <TrueBrain> well, it is now done content-type per content-type. Pretty sure it would still lag as fuck :P
18:27:14 <TrueBrain> (it updates every entry, instead of "when done", it seems)
18:35:00 <michi_cc> glx: Something is broken with your utf-8 change in baseset translation commit. On my laptop, it isn't writing any description entries anymore.
18:36:06 <glx> because I just fixed an issue with langfiles EOL
18:39:07 <michi_cc> glx: Github/git was being weird right now. I fetched and it said all up-to-date, then I fetched again and suddenly I got your last commit.
18:39:52 *** frosch123 has joined #openttd
18:44:34 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfztA
18:53:22 <DorpsGek_III> [OpenTTD/OpenTTD] michicc updated pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzLv
18:55:50 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/Jfzq2
19:05:12 <TrueBrain> frosch123: did you already pick up the tt-forums request from stefino_cz?
19:06:04 <frosch123> no, did that pm only go to you again?
19:08:17 <frosch123> some other dude resent their pm
19:08:23 <frosch123> so, no idea how many people only sent to you
19:08:42 <frosch123> maybe your name was first in the anouncment, and they read "or"
19:08:45 <TrueBrain> well, I made a PR :P
19:10:01 *** luaduck has joined #openttd
19:11:14 <TrueBrain> I have 2 more people who only send me one
19:11:46 <TrueBrain> you already picked up the first
19:11:48 <TrueBrain> let me check the latter
19:12:17 <frosch123> i have a branch user_ufiby89
19:12:34 <frosch123> Tue Apr 28 19:44:37 2020 +0200
19:12:41 <frosch123> does that match the pm?
19:13:33 *** sla_ro|master has joined #openttd
19:14:19 <TrueBrain> cool, checked all the others, they all have a reply from you
19:14:24 <TrueBrain> so we should be up-to-date :)
19:14:44 <frosch123> 22% packages, 9.5% authors
19:15:37 <frosch123> when does the australian guy release the next thing?
19:16:34 <andythenorth> Garry is my favourite contributor
19:16:51 <andythenorth> even though he has a brain injury he cranks out nice looking content
19:17:04 <andythenorth> with more humour and less fuss than many other people :)
19:17:06 <frosch123> possibly related :)
19:17:54 <frosch123> pikka is only 6th on the list of non-gh authors
19:21:21 <planetmaker> so... GH account is not a requirement for bananas? What is the advantage of it then? :)
19:21:33 <planetmaker> sorry, if the question is stupid :)
19:22:40 <Eddi|zuHause> i guess most of the authors who would be against github wouldn't have been on bananas in the first place
19:22:54 <frosch123> (1) no ottd account and email/password issues (2) rename stuff (3) upload big packages (4) hopefully extensible
19:23:21 <planetmaker> ok, so it's a convenience thing. That's good
19:23:42 <glx> and many already have a GH account for something else
19:24:01 <Yexo> <frosch123> it is <- planetmaker: it actually is required
19:24:05 <frosch123> planetmaker: hmm, the "it is" was refering to "gh is required", not "question is stupid" :)
19:24:24 <TrueBrain> frosch123: tnx for that correction :P I was wondering when you became Dutch :D
19:24:59 <planetmaker> :D ok... that ... gives the answer a different spin :)
19:25:44 <TrueBrain> what frosch123 was referring to with non-gh, was that we migrated the usernames to BaNaNaS v1.5, so we can migrate them easier to GitHub accounts :) Also allows us to count who migrated and who didn't :)
19:26:09 <planetmaker> I think frosch migrated mine some time ago, if I understood that right, yes?
19:26:19 <frosch123> and make spreadsheets and statistics, my favorite useless hobby, second to talking to eddi
19:26:22 <TrueBrain> he has been rather proactive, yes :)
19:26:41 <frosch123> planetmaker: yes, i resolved the groups accounts
19:27:22 <glx> oh another advantage of the github move: multiowners
19:27:24 <frosch123> though i can make the statistics nicer by force migrating zuu :p
19:27:44 <frosch123> glx: haha, no. that was better before
19:27:59 <frosch123> old bananas could set multiple users via musa, while new one can only via PR
19:28:08 <glx> but they were sharing accounts usually
19:28:23 <TrueBrain> security-wise, it improved, yes :D
19:28:48 <planetmaker> yes, the openttdcoop account existed for that very reason... before musa was around and one could add further users
19:28:53 <TrueBrain> but someone should implement author-editing, yes :) ( looks around .. yells: NOT IT ... runs away)
19:29:18 <Wolf01> So I need to migrate my account too
19:31:08 <frosch123> two scenarios, i see
19:31:20 <TrueBrain> you cannot update them anyway :P
19:31:40 <planetmaker> ah, nice. I see how that works... That's awesome :)
19:31:44 <Wolf01> No need to update them, maybe upload new ones
19:31:49 <planetmaker> The adding authors via PR
19:34:14 <TrueBrain> do I trust that GitHub ID .. hmmmmm
19:34:40 <frosch123> TrueBrain: it's so weird who gave me access to their personal repos
19:37:45 <Wolf01> Yeah, my awesome content!
19:38:22 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzYT
19:38:32 <TrueBrain> "NOTE: This is an extension that only works for Chrome browsers. You will need to click to install the plug-in to opt out of tracking." <- why does that sound ... wrong?
19:41:30 <planetmaker> lol. Yes. Very wrong
19:41:51 <glx> definitely not GDPR compliant
19:43:56 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzYO
19:47:02 <TrueBrain> it made me giggle .. you can opt-out by first doing an opt-in .. good thinking :D
19:47:45 <frosch123> TrueBrain: well, you have to remember when someone made a GDPR request :)
19:48:25 <frosch123> so the answer to "do you store any data about me" is never "no", at best it is "yes, now"
19:48:52 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzY4
19:49:00 <TrueBrain> it is also the reason the request is: give me all the data you know about me up till now :D
19:50:23 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzYR
19:52:20 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzYg
19:53:52 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzYV
19:54:21 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzYw
19:56:05 *** gelignite has joined #openttd
19:59:27 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzYP
20:00:41 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on pull request #8156: Fix #8155: Roadtype speed limit in toolbar dropdown in scenario editor was doubled. https://git.io/JfzY1
20:01:12 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo merged pull request #8156: Fix #8155: Roadtype speed limit in toolbar dropdown in scenario editor was doubled. https://git.io/JfEty
20:01:13 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo closed issue #8155: Roadtype speed limit values are doubled in scenario editor drop-down menu https://git.io/JfELR
20:02:30 <michi_cc> Yexo: I had the Ini stuff not using std::optional at first (not C++11 etc.), because I also thought that NULL and empty are interchangeable everywhere.
20:02:51 <michi_cc> Then I accidentally discovered the custom numeric formatting settings I've never seen before :p
20:03:15 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 commented on pull request #8156: Fix #8155: Roadtype speed limit in toolbar dropdown in scenario editor was doubled. https://git.io/JfzYy
20:03:26 <Yexo> I got as much from your response. Bit of a shame, but maybe we can work around that later
20:04:48 <michi_cc> Or just move to C++17 already :)
20:05:17 *** Wormnest has joined #openttd
20:06:38 <frosch123> Yexo: yes, copy&paste from railtypes :)
20:07:00 <frosch123> though i would check whether someone added a magic conversion in ottd
20:07:11 <frosch123> but otherwise i would say: same speed units for all road stuff
20:07:41 <frosch123> Yexo: ofc, next question is then, what is implemented in nml :p
20:07:50 <DorpsGek_III> [OpenTTD/OpenTTD] michicc commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzYb
20:08:46 <frosch123> nml does the same as ottd
20:09:05 <Yexo> So it's only the nfo spec that is wrong
20:11:21 *** andythenorth has joined #openttd
20:11:43 <Yexo> Also: the OpenTTD code lacks any docs about this at least when searching for "max_speed". I'll add some
20:12:54 <frosch123> Yexo: note that aircraft are special. ottd changed the internal speed units for them, so the conversion is in the newgrf loading code. trains/rv/ships still use original TTD units
20:13:44 <Yexo> For now I'm specifically looking at railtypes/roadtypes, and there doesn't seem to be any shared code for them
20:14:19 <frosch123> ground_vehicle.cpp shares stuff between rv/trains
20:14:28 <frosch123> but we have no ground_tracktype.cpp :p
20:15:00 <Yexo> Just adding a GetDisplayMaxSpeed to RoadTypeInfo/RailTypeInfo would've helped me
20:18:27 <FLHerne> frosch123: I've added a bunch of _tracktype code to nml trying to un-copy-paste the NRT stuff, perhaps OTTD needs the same
20:21:34 *** Smedles has joined #openttd
20:49:17 *** Progman has joined #openttd
21:23:57 <glx> nice I wanted to check if today's nightly was now correct, but macos build somehow didn't start, and nothing is on the cdn, luckily the bundles are available on azure
21:24:33 <nielsm> the CI is not terribly reliable it seems
21:24:52 <glx> github had issues today too it seems
21:24:57 <nielsm> it really needs some deadlock detection
21:25:51 <glx> let's try the "rerun failed job" button
21:33:50 <glx> oups rerun was not a good idea
21:35:19 <TrueBrain> Port it to Github Actions :D
21:36:17 <glx> I cancelled it, it was in infinite loop because manifest.yaml was already bundled when macos failed
21:37:51 <FLHerne> Eddi|zuHause: That means it's run out of actionD variables, I think
21:38:02 <FLHerne> and/or varaction2 ones?
21:38:19 <Eddi|zuHause> FLHerne: yeah, but i can't find an option to say where in the code that happens
21:38:44 <frosch123> yes, it only print maximum location when it succeeds
21:38:46 <Eddi|zuHause> also... i think the weird parsing failures i got earlier were from some caching problems
21:38:52 <glx> actionD as it says parameters
21:39:15 <Eddi|zuHause> as soon as i tried with -D it regenerate those, and it disappeared
21:39:23 <frosch123> Eddi|zuHause: you can comment parts of your code. when it compiles once, it tells you were it needed many parameters
21:40:21 <glx> but unless the code is really complicated it should reuse parameters and have enough
21:40:34 <Eddi|zuHause> this is the header. it's essentially one big switch referencing everything that should be globally static in the rest of the GRF
21:40:37 <FLHerne> glx: I assume this is CETS, it's really complicated :p
21:41:27 <Eddi|zuHause> it has 252 entries, split about halfway between strings and action2
21:45:04 <Eddi|zuHause> remove the 3 lines starting with "comment" to compile with stock nml
21:46:04 <Eddi|zuHause> if it's actionD that it's running out, the problem is probably lines 407 and following
21:46:18 <Eddi|zuHause> but it doesn't look like too many
21:49:07 <Eddi|zuHause> if i comment them out, it goes through, but it still uses 39 of 64 registers
21:50:22 <Eddi|zuHause> seems like the RTT also uses up registers
21:50:34 <Eddi|zuHause> that might become a problem...
21:51:13 <Eddi|zuHause> can i tell nml to shift the split for the registers? e.g. to 32/96 instead of 64/64?
21:54:39 <FLHerne> I don't think so, but the same idea occurred to me a while ago
21:54:51 <glx> nml/actions/action6.py:19
21:56:12 <glx> I think you can change the range
21:56:49 <Eddi|zuHause> i need 4 for some random stuff, 35 for the RTT, and 42 for the availability checks
21:57:24 <FLHerne> I feel like there's a lot of room to optimize this stuff
21:57:51 <Eddi|zuHause> i can save the availabilty checks by replacing them with preprocessor stuff
21:57:53 <FLHerne> e.g. every named parameter uses an actionD parameter for the entire grf
21:58:12 <glx> yeah the lower value of the range should depend on the real grf parameters
21:58:51 <Eddi|zuHause> nmlc doesn't have the concept of compile time constants
21:58:59 <FLHerne> Even if their live ranges don't overlap, or they could be folded to a constant
21:59:30 <Eddi|zuHause> ... which probably would help the RTT as well
21:59:40 <FLHerne> glx: I think that might be hard?
22:00:15 <Eddi|zuHause> FLHerne: it shouldn't be that hard, you'd just count up from both ends and fail when the counters collide
22:00:33 <Eddi|zuHause> same as now, except without the fixed division
22:01:07 <FLHerne> Eddi|zuHause: But the user code can access parameters based on a variable index, can't it?
22:01:31 <FLHerne> I guess it's easy to rule that out if they don't
22:01:56 <glx> user can only touch declared parameters (ie param blocks)
22:02:12 <glx> all other should be free to use internally
22:04:51 <FLHerne> I think named parameters are in the nml-internal range, even?
22:08:44 <Eddi|zuHause> frosch123: that might make it necessary to reserve a range for "free" use
22:09:23 <Eddi|zuHause> but, that applies even now, as there's no guarantee that any ranges are actually free
22:09:43 <Eddi|zuHause> so it would be fairly dangerous to just use them
22:11:28 <FLHerne> Eddi|zuHause: The current rule is that user code can use 0-127, and above that is nmlc's, AIUI
22:12:20 <Eddi|zuHause> there are registers 0-127, nml splits those in the middle, and uses the lower half for Action14 parameters, and the upper half for assignments and other stuff
22:13:02 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 opened pull request #8165: Fix e3511ec: [AzurePipeline] Don't loop infinitely on errors https://git.io/Jfznp
22:13:40 <Eddi|zuHause> there's no guaranteed-free user range
22:14:50 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro approved pull request #8165: Fix e3511ec: [AzurePipeline] Don't loop infinitely on errors https://git.io/Jfznj
22:15:43 <frosch123> a14 registers are better assigned manually
22:16:05 <glx> 6 months to trigger a bug in a script used almost everyday
22:16:10 <frosch123> same compatibility issue as with item ids
22:16:48 <Eddi|zuHause> anyway, my problem is that the actionD section overflows, where the A14 section is basically empty
22:17:27 <frosch123> and how many actiond parameters would you expect?
22:17:57 <frosch123> increasing something by 50% does not solve deeper issues
22:18:24 <glx> in theory we could just reserve A14 registers, and consider other free to use
22:21:14 <DorpsGek_III> [OpenTTD/OpenTTD] glx22 merged pull request #8165: Fix e3511ec: [AzurePipeline] Don't loop infinitely on errors https://git.io/Jfznp
22:22:50 <Eddi|zuHause> frosch123: i made about 3 different suggestions. 1) make the split configurable, 2) make the split dynamic, 3) implement compile time constants to save registers
22:24:24 <Eddi|zuHause> actually 1) wasn't a suggestion, it was a question whether this is already possible
22:25:04 <frosch123> hmm, so you are not using cpp
22:25:37 <frosch123> doesn't cpp solve (3) ?
22:26:15 <Eddi|zuHause> it would, for constants of the form "a = blah", but not e.g. for the RTT stuff
22:27:20 <Eddi|zuHause> and the availability calculation is not technically a constant, so moving them to CPP would have to re-evaluate them multiple times
22:27:54 <frosch123> ah, so it's about compile time constants that are not known at compile time :p
22:28:15 <frosch123> sorry, i don't get it
22:28:37 <frosch123> i have no idea why a RTT would need parameters, when a CTT doesn't
22:29:25 <Eddi|zuHause> i don't know either. i just ran this compile with it commented out, and it used less registers
22:29:46 <Eddi|zuHause> RTT stuff is weird, because it uses action 6 internally
22:30:20 <Eddi|zuHause> nml could probably release those registers after the RTT is set up
22:33:37 <FLHerne> Eddi|zuHause: Looking at the code it does, or is supposed to
22:34:15 <Eddi|zuHause> FLHerne: then i don't know what it uses those registers for
22:34:28 <FLHerne> Does it use them permanently?
22:34:46 <glx> only way is to check the NFO I guess
22:35:04 <FLHerne> If there aren't enough free to set up the table, it doesn't matter whether or not it releases them after
22:35:17 <FLHerne> It would fail when trying to acquire them
22:35:25 <glx> but maybe some temp registers are not released
22:35:38 <Eddi|zuHause> i haven't checked anything... i just ran the compile of that file with just the RTT commented out, just the availabilty assignments commented out, and both commented out
22:36:08 <Eddi|zuHause> just with everything on it runs out of IDs
22:36:12 <glx> hmm try with -s to get the trace
22:36:20 <glx> and know what it was doing
22:38:27 <glx> yeah clearly fails in the tracktypetable
22:38:48 <Eddi|zuHause> ... which is weird, because the table is before the assignments
22:42:37 <FLHerne> Possibly the assignments are handled in register_names, whereas the tracktypetable is only created in get_action_list
22:43:24 <FLHerne> `print_warning("Accessing parameters out of the range 0..63 is not supported and may lead to unexpected behaviour.", pos)` is what I was thinking of
22:44:12 <FLHerne> But yes, the auto-assigned action14 params do seem to fall in that range
22:44:16 <Eddi|zuHause> FLHerne: how does that help if the parameter equasion is not constant?
22:44:49 <FLHerne> It doesn't, but at least it helps avoid users shooting their feet? :p
22:45:10 <Eddi|zuHause> FLHerne: i don't think anyone interested in not shooting their feet is even using that :p
22:45:10 <glx> hmm maybe some debug output in nml/free_number_list.py to track usage
22:45:22 <FLHerne> Anyone using variable parameter indices ought to know what they're trying to do anyway
22:45:30 <FLHerne> (and is probably mad)
22:46:55 <Eddi|zuHause> i think we're far beyond the point where asking whether somebody is mad is even relevant :p
22:55:46 <FLHerne> What's the actual use-case for indirect parameter access?
22:55:56 <FLHerne> Presumably someone wanted to do it, but I can't imagine why
22:57:25 <glx> if you setup an array of values and select one depending on an A14 param
22:57:35 <Eddi|zuHause> i wouldn't even have thought to look up whether that exists in a language that doesn't have loops
23:08:01 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzWO
23:15:53 <glx> can I get CETS source somewhere to do tests ?
23:16:13 <Eddi|zuHause> i can push what i got currently
23:18:45 <glx> I'll add some debug stuff in nml to track parameters and try to see if there's an error somewhere
23:21:01 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 commented on pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzWa
23:21:24 <DorpsGek_III> [OpenTTD/OpenTTD] michicc updated pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzLv
23:24:46 <glx> first I need to uninstall my old mercurial
23:25:32 <glx> then I'll use pip to get the recent one
23:32:12 *** andythenorth has left #openttd
23:36:43 *** Progman has joined #openttd
23:40:11 <DorpsGek_III> [OpenTTD/OpenTTD] michicc updated pull request #8164: Change a bunch of stuff to use std::string https://git.io/JfzLv
23:42:26 <frosch123> michi_cc: was the regression issue fixed? can i press approve?
23:43:18 <DorpsGek_III> [OpenTTD/OpenTTD] LordAro left a comment on commit: Codechange: Store info about the dedicated server log file in globals with automatic destruction to simplify control flow in openttd_main. https://git.io/JfzWh
23:43:44 <michi_cc> Yes, I did push something. GH checks seem to agree with me :p
23:46:30 <DorpsGek_III> [OpenTTD/OpenTTD] michicc left a comment on commit: Codechange: Store info about the dedicated server log file in globals with automatic destruction to simplify control flow in openttd_main. https://git.io/Jfzle
23:47:10 <frosch123> i thought we are on c++14 ?
23:47:50 <michi_cc> Makefile says -std=c++11
23:48:59 <glx> in cmake IIRC MSVC is c++14, other are c++11
23:52:36 <LordAro> michi_cc: really? i thought we fixed that
23:52:48 <LordAro> there's so few changes between c++11 & 14
23:53:02 <LordAro> make_unique is the only one that matters
23:53:23 <frosch123> i remember some discussion about c++14 and gnu++14, maybe stuff was postponed for cmake?
23:53:32 <glx> Eddi|zuHause: how do I get .nml files ?
23:53:51 <michi_cc> Which is exactly the problem, next major compiler step after 11 is 17. I don't think there's many systems where you can get 14 but not 17.
continue to next day ⏵
