Back to Home / #openttd / 2021 / 01 / Prev Day | Next Day
#openttd IRC Logs for 2021-01-17

---Logopened Sun Jan 17 00:00:58 2021
00:18<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on issue #8582: Content Downloading does not work
00:30<@DorpsGek>[OpenTTD/OpenTTD] Matias-Barrios commented on issue #8582: Content Downloading does not work
00:57-!-Gustavo6046_ [~Gustavo60@] has joined #openttd
00:57-!-Gustavo6046_ is "Gustavo Rehermann <>" on #openttd #llvm
00:59-!-Gustavo6046 [~Gustavo60@] has quit [Ping timeout: 480 seconds]
00:59-!-Gustavo6046_ is now known as Gustavo6046
01:07-!-heffer_ [] has joined #openttd
01:07-!-heffer_ is "Felix Kaechele" on #openttd
01:14-!-heffer [] has quit [Ping timeout: 480 seconds]
01:43-!-heffer_ is now known as heffer
01:48-!-crem [~crem@2a02:169:160a:2:4fbc:9f48:dab0:d1f0] has quit [Ping timeout: 480 seconds]
02:02-!-WormnestAndroid [~WormnestA@] has quit [Remote host closed the connection]
02:02-!-WormnestAndroid [~WormnestA@] has joined #openttd
02:02-!-WormnestAndroid is "WormnestAndroid" on #openttd
02:59-!-snail_UES_ [] has quit [Quit: snail_UES_]
03:10-!-jottyfan [] has joined #openttd
03:10-!-jottyfan is "jottyfan" on #openttd
03:12-!-andythenorth [] has joined #openttd
03:12-!-andythenorth is "andythenorth" on #openttd
03:28<_dp_>oh, nice signal autoremoval got merged
03:29<_dp_>I totally forgot I wanted to review it xD
03:29<andythenorth>signals on bridges next?
03:31<_dp_>and gj JGR for spotting the settings category issue
03:32<_dp_>though it's still in company category in the gui, should it mb moved to GUI->Construction to not make company any more of a mess with non-company setting?
03:34<_dp_>andythenorth, how does that even work? by storing signal interval on bridge head?
03:34<andythenorth>no idea
03:34<andythenorth>I haven't tried it in JGR
03:35*andythenorth tests
03:36<andythenorth>oops, my map settings were 4096x4096
03:37<andythenorth>can't use that on this mac, performance fail
03:39<andythenorth>_dp_ I'm trying it, don't really understand it
03:39<andythenorth>I'll ask discord later how to use it
03:39-!-sla_ro|master [slamaster@] has joined #openttd
03:39-!-sla_ro|master is "slamaster" on @#sla #openttd
03:51-!-Progman [] has joined #openttd
03:51-!-Progman is "Peter Henschel" on #openttd
03:56<_dp_>I suddenly realized that citymania server patch become so non-intrusive that I can probably merge it into jgrpp without much trouble...
03:59<_dp_>oh, but merging cmclient would be a royal pita, so no jgrpp on citymaina any time soon I guess xD
04:06-!-crem [~crem@] has joined #openttd
04:06-!-crem is "crem" on #openttd
04:09<@DorpsGek>[OpenTTD/team] Leven-mok opened issue #127: [zh_TW] Translator access request
04:11<@DorpsGek>TrueBrain: OpenTTD uses TCP and UDP port 3979 for server <-> client communication, UDP port 3978 for masterserver (advertise) communication (outbound), and TCP port 3978 for content service, a.k.a. BaNaNaS (outbound)
04:22<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on issue #8582: Content Downloading does not work
04:23<TrueBrain>_dp_: how could you not have seen we merged auto-signal-remove .. you are the reason I merged it to start with! :P
04:28<_dp_>TrueBrain, I was away for just 2 weeks but with this crazy developement I'm still getting surprised on what I missed xD
04:28<_dp_>TrueBrain, also it was "candidate: probably not" when I last saw it :p
04:29<TrueBrain>yeah, I still think it is a bullshit functionality
04:29<TrueBrain>but you were clear it wasn't, so meh, what do I care :P
04:32<andythenorth>it's 'fine'
04:33<TrueBrain>it works as advertised and doesn't hurt new players, check!
04:35<_dp_>it's a matter of a playstyle I guess, some see building stuff as entirety of the game while some prefer strategic part and see building as a bit of a nuisance
04:36*andythenorth tests it
04:36<andythenorth>Best Feature of 2021
04:36<andythenorth>so far
04:36<TrueBrain>_dp_: nah; it has more to do that this does something without letting you know explicitly. Those are often bad game designs
04:36<TrueBrain>if there was some indication it did this, or that it is about to do so
04:36<TrueBrain>that would be a lot more acceptable
04:37<TrueBrain>just this magic POEF now your signals are gone
04:37<TrueBrain>is a recipe for disaster (literally :D)
04:37<andythenorth>yes, trains will crash
04:37<andythenorth>but I explicitly chose to build
04:37<andythenorth>the intent is signalled by clicking 'build track'
04:37<andythenorth>ok, everyone gets cookies
04:37<andythenorth>what next?
04:37<andythenorth>signals on bridges when?
04:38<TrueBrain>_dp_: but OpenTTD lacks other ways of informing users, so meh .. now it is a setting of: if you want to shoot yourself in the foot, it is fine :) We will see if/when people complain :)
04:39<_dp_>well, I guess it could be implemented like highlighting the singnal and removing it on a first click and bulding track on second
04:39<TrueBrain>(really, I am fine with it, to be clear; it is just a poor design, but I have nothing better :D)
04:39<_dp_>but you kinda want it removed like 100% of the time, so idk
04:39<TrueBrain>if the game would indicate junctions better, would already help, for example
04:39<TrueBrain>or don't allow it if the signal is within reserved path
04:39<TrueBrain>or .. I dunno :)
04:40<TrueBrain>this is a typical "well tested" patch :) I am fine with it, I just also expect some complaints about it :) (which is also fine :P)
04:41<_dp_>imo that's just details and it's kinda hard to get all the nuances right without excessive playtesting anyway
04:41<_dp_>but it's a patch with a right intention since signals are a real nuisance when building
04:42<TrueBrain>and those that want this functionality, are never going to do that excessive playtesting :)
04:42<TrueBrain>as their focus is what you describe
04:42<TrueBrain>not how anyone else might (wrongly) use it :D
04:42<TrueBrain>one of the more common issues with OpenTTD :P
04:42*andythenorth testing signals on bridges currently
04:42<_dp_>it's quite hard to playtest stuff like that properly without it being actually merged
04:43<TrueBrain>but once merged, it is hard to pick another solution :D
04:43<TrueBrain>chicken-egg? :)
04:43<_dp_>like, for me I need to merge it into cmclient and cmserver first and play some cb game to see how it works in a real game
04:44<_dp_>also mb get used to it first, so it's not like it's just a single game is enough
04:45<_dp_>normaly I do stuff like that in cmclient first with a network-compatible patch
04:46<_dp_>but it wasn't my patch... also there is rarely a "second" after that since it takes rewriting stuff from scratch
04:47<TrueBrain>so now it is in vanilla :P
04:47<TrueBrain>and any complaints and I just tell them this story :D :D :)
04:47<TrueBrain>(no, I am not :D)
04:47<TrueBrain>if we paid people to develop this, I would tell them to come up with a new-player-friendly design for it
04:47<TrueBrain>we don't
04:47<TrueBrain>so here we are :D
04:47<TrueBrain>YOLO! :)
04:48-!-nielsm [] has joined #openttd
04:48-!-nielsm is "Niels Martin Hansen" on #openttd
04:49-!-gnu_jj [] has joined #openttd
04:49-!-gnu_jj is "jj" on #ceph #ceph-devel #openttd
04:49<TrueBrain>it is just a fun example why OpenSource development is tricky. Everyone understand this is a good idea for advanced players, but everyone also understands it is not really "fun" for new players :)
04:49<andythenorth>pay TrueBrain
04:49<andythenorth>TrueBrain send TrueBrain a job offer
04:50<TrueBrain>pretty sure OpenTTD cant pay me :D
04:50<_dp_>TrueBrain, well... it's an option anyway :p
04:50<_dp_>... and settings gui is a long lost cause already :p
04:51<TrueBrain>it really is
04:51<TrueBrain>I wouldn't mind a PR btw to move it from one category to the other; I honestly did not validate that
04:51<TrueBrain>didn't even think about what a good place for it would be :)
04:58-!-gnu_jj [] has quit [Ping timeout: 480 seconds]
05:04<_dp_>well, at this point may as well kick all other non-company settings out of that category
05:06<_dp_>btw, there are other similar "risky" improvements that can be done like building under vehicles for example
05:06<_dp_>though for road vehicles it's probably safe
05:06<_dp_>and those are the most annoying
05:12<orudge>Hurrah, arm64 Windows build working now too
05:12<orudge>Need to check the installer but I should have a PR for this soon too
05:13<TrueBrain>nice :D Any word from the CA about the cert?
05:14<orudge>Not so far
05:14<orudge>Seems to be a very slow process
05:14<TrueBrain>yeah .. people on the interwebz already said as much :(
05:14<orudge>If there's nothing by the end of tomorrow I'll contact them again
05:15-!-muffindrake [] has joined #openttd
05:15-!-muffindrake is "muffindrake" on #openttd
05:18-!-Flygon_ [] has joined #openttd
05:18-!-Flygon_ is "Flygon" on #openttd
05:20-!-Flygon [~Flygon@2001:44b8:411e:4e00:d83e:fbd6:827f:4965] has quit [Ping timeout: 480 seconds]
05:41-!-gelignite [] has joined #openttd
05:41-!-gelignite is "realname" on #llvm #openttd
05:49-!-jottyfan [] has quit [Quit: jottyfan]
05:56-!-Samu [] has joined #openttd
05:56-!-Samu is "realname" on #openttd
06:12<_dp_>hm... how should I handle ip bans... show them nice kick message with reason and duration or just crash their client... xD
06:15<_dp_>second option has an enticing advantage that using vpn may not be their first thought afterwards :p
06:15<TrueBrain>does result in more bug-reports ;)
06:16<_dp_>it's already reported so just close as dupe :p
06:20<TrueBrain>glx was not wrong when he said that the NewGRF loading window is faster with OpenGL
06:20<TrueBrain>which is really odd :P
06:21<TrueBrain>like 5s vs 2s
06:22<Samu>i found a bug in OrthogonalTileArea &OrthogonalTileArea::Expand(int rad)
06:22<Samu>Expand a tile area by rad tiles in each direction
06:23<Samu>it's not doing that correctly
06:23<Samu>if i have tile 64,64 and i expand 6 in each direction, i get tile 58,58 and 70,70
06:24<Samu>this->w = 70 - 58 = 12 and this->h = 70-58
06:24<Samu>becomes 12, should be 13
06:25<_dp_>Samu, do you have an empty area?
06:25<TrueBrain>58 .. 70 == 13 tiles
06:25<Samu>the last tile area in the iterator is tile 69,69
06:25<Samu>the last tile in the tile area iterator is tile 69,69
06:27<Samu>should be 70
06:28<Samu>looks like this Expand function is only used for industries
06:28<_dp_>Samu, what's your area before expansion?
06:29<_dp_>if it's empty (w=h=0) that's correct
06:29<Samu>it's empty
06:29<Samu>or should be w=1, h=1
06:29<_dp_>if it's one tile area should be 1,1 ofc
06:29<Samu>let me test with that size, brb
06:32<Samu>interesting, it's working correctly now
06:32<Samu>so I misused the function apparently
06:32<TrueBrain>yippie, finally managed to clean up the palette mess in SDL :D Now I need to make commits out of this .. always a bit tricky :D
06:32<Samu>58,58 to 71,71
06:32<Samu>this->w = 71-58 = 13
06:33<Samu>last tile is 70,70, first tile is 58,58
06:33<Samu>thx _dp_
06:36-!-frosch123 [] has joined #openttd
06:36-!-frosch123 is "frosch" on #openttd
06:55<TrueBrain>hmm ... I start to prefer the SDL driver for Windows :D
06:55<TrueBrain>it seems to be running my mouse at 144Hz instead of 30Hz or something
06:56<Samu>I'm trying to make desert/rainforest convertion tiles to be scalable by map size
06:57<Samu>deprecating the need for "genland.h"
06:58<Samu>i've never made a change where I need to delete a file, may need help
06:58<Samu>how to properly "eliminate" the file from the build
07:02<nielsm>remove all references to the file from the project files, remove all #include uses of it from the source code, then delete the file
07:05<andythenorth>does cb 39 run in context of cargo or station?
07:05*andythenorth could work that out, oops
07:07<TrueBrain>michi_cc: found a nice difference between SDL and Win32 .. totally not related to our work btw. The Sleep() in the GameLoop slows down calls to DrawMouseCursor a lot more on Win32 than on SDL. In result, on Win32 my mouse moves at .. 30 fps? On SDL a lot quicker. The benefit? On SDL it reaches my 144Hz of my monitors
07:07<TrueBrain>making it all look a lot smoother
07:07<TrueBrain>if I disable the Sleep(), I get the same result on Win32 :)
07:07<TrueBrain>(but that is bad for a lot of different reasons :D)
07:08<TrueBrain>not sure why a 1ms sleep takes longer on Win32 over SDL
07:09<nielsm>SDL probably uses a multimedia timer while the win32 driver may use the plain system sleep
07:09<TrueBrain>I called CSleep in both cases, to be sure
07:09<TrueBrain>same difference
07:09<TrueBrain>is what CSleep does
07:09<TrueBrain>same compiler
07:10<nielsm>something with timer resolutions possibly, which may be a per thread thing
07:10<nielsm>in case SDL modifies something about that
07:10<TrueBrain>I will have to debug it more in depth to get some more factuals
07:10<TrueBrain>just a fun difference :D
07:11<Samu>daium, a radious of 96 is super slow in 4096x4096
07:14<Samu>there goes my scaling idea :(
07:17<TrueBrain>I added TIC/TOC around CSleep .. Win32: 47,272,059 on average, SDL: 5,989,384 on average
07:17<TrueBrain>that is a pretty high difference there :)
07:17<TrueBrain>so yeah, something to do with timer resolution it seems like indeed :)
07:19<_dp_>even I remember windows being weird with sleeps
07:19<_dp_>and that's like 20 years ago I last touched any of it
07:22<TrueBrain>I am comparing the SDL driver with Win32 driver, and you find these "fun" small differences that have no influence on the real game :)
07:22<TrueBrain>like, on Win32, InteractiveRandom() is called a lot more often
07:22<TrueBrain>(for every event, instead of once per loop)
07:23-!-iSoSyS [] has joined #openttd
07:23-!-iSoSyS is "realname" on #/r/openttd #openttd
07:23<TrueBrain>code-wise, the SDL can get stuck in FF if you are FF-ing from a multiplayer game (is that possible?) and dropped in another game (very unlikely)
07:23<TrueBrain>Win32 protects against that :P
07:26<frosch123>does that include FF-ing to catch up with server?
07:28<TrueBrain>if _fast_forward is on; it is either a case someone ran into on Win32 and fixed, or just pedanticness on the Win32s authors side :P
07:28<TrueBrain>none of the other drivers have it
07:37<milek7_>TrueBrain: timeBeginPeriod(1);
07:38<milek7_>likely SDL does that
07:41<milek7_>and btw this was system-wide change until recently
07:42<orudge>OpenTTD on arm64 Windows in a VM on an M1 Mac seems to work pretty well all things considered
07:48<LordAro>orudge: is it faster than andythenorth's i9?
07:48<andythenorth>at least on a 4096x4096 map
07:48<andythenorth>it's lolz that FFWD just doesn't on a large map
07:48<andythenorth>I didn't know map size affected FPS so much
07:50<@DorpsGek>[OpenTTD/OpenTTD] orudge opened pull request #8583: Feature: Add ARM64 build for Windows
07:51<orudge>LordAro: can play around later. I suspect performance should be pretty similar to the native Mac ARM64 build. Which was considerably faster than anything Intelly I could find personally!
07:52-!-iSoSyS [] has quit []
07:52-!-arikover [] has joined #openttd
07:52-!-arikover is "arikover" on #openttd
07:52<andythenorth>iirc it's about 100x improvement in crude tests
07:52<andythenorth>child is using the M1 currently so can't test
07:55<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows
07:56<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows
07:56<TrueBrain>I like how one commit reads ARM64 the other arm64 :D
07:57<frosch123>windows on arm64? never heard of that? is that the ms tablet? "surface" or something?
07:58-!-arikover` [] has joined #openttd
07:58-!-arikover` is "arikover" on #openttd
07:58-!-arikover [] has quit [Remote host closed the connection]
07:58<TrueBrain>that is an interesting question: just because we can build it for releases, do we want to? :D
08:01<nielsm>hmm there is an edition of windows that can run on some raspberry pi systems, iirc...
08:02<frosch123>now that sounds like you want to build a binary for a system that noone has :p
08:05<milek7_>there's Surface series, but HP/Lenovo/Asus/Samsung/Huawei have some devices too
08:06<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
08:08<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
08:09<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
08:10<@DorpsGek>[OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows
08:10<TrueBrain>orudge: btw, if possible, mention which clang version it is, instead of "modern"
08:10<TrueBrain>as "modern" doesn't age well :D
08:11<orudge>That requires figuring out what version of clang supports it :D
08:11<TrueBrain>yup ... that happens when you make these kind of changes ;)
08:11<TrueBrain>we all know nobody is going to touch it for the next 5 years .. think about the future-you! :D
08:12-!-arikover` [] has quit [Quit: ERC (IRC client for Emacs 26.3)]
08:14<@DorpsGek>[OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows
08:14<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows
08:15<TrueBrain>sorry orudge , couldn't resist being a bit funny with my reply :P You can hit me in the face if you like :)
08:15<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
08:16<TrueBrain>if you have suggestions how we can make the PR template more clear, we are mostly looking for a WHY, not a WHAT, please let us know :)
08:22<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
08:25<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8583: Feature: Add ARM64 build for Windows
08:26<@DorpsGek>[OpenTTD/nml] FLHerne commented on pull request #183: Add support for recent NewGRF additions
08:39-!-sla_ro|master [slamaster@] has quit []
08:40<@DorpsGek>[OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows
08:40-!-gnu_jj [] has joined #openttd
08:40-!-gnu_jj is "jj" on #ceph #ceph-devel #openttd
08:42<TrueBrain>orudge: is that still WIP? As now I am confused .. didn't you add that for macOS? :D
08:42<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
08:43<LordAro>orudge: neon intrinsics?
08:43<orudge>TrueBrain: It should be working now :)
08:43<orudge>LordAro: rough equivalent of SSE etc on ARM
08:44<orudge>Whether there'd be much benefit, I'm not sure
08:44<TrueBrain>orudge: but we are not testing the clang statement now, are we? As in, we produce windows binaries via MSVC, right?
08:44<LordAro>ah yeah, that does sound familiar
08:44<orudge>TrueBrain: for Windows, yes, it wouldn't use the clang stuff (though if you built with clang it would I suspect). I had put in the code for Mac at the same time, since I knew it was missing.
08:44<orudge>Now I remembered why it was missing :)
08:44<orudge>But it does work in Windows on a Mac, go figure
08:45<orudge>Right, going to have to head off just now, will address any more comments later if any
08:45<TrueBrain>yeah, I leave this rdtsc part for someone else :) I am a bit confused :P
08:45<TrueBrain>reads to me it now adds code no target is using :D
08:46<TrueBrain>but this says more about me than anything else, to be clear :D
08:49<orudge>It can get used on any non-Apple clang platform
08:49<orudge>Windows or Linux basically
08:49<orudge>By default we use MSVC and gcc of course
08:49<TrueBrain>which is Linux I guess, but that already has rdtsc code :) So I am not sure how we deal with that :D
08:49<orudge>but users may not :)
08:50<orudge>If gcc could support that intrinsic too one day it'd be handy
08:51<TrueBrain>yeah .. our code used to be full of things that "might be handy" :D :D :) But okay, this is why someone else needs to look at this .. I don't understand enough to say it is good or not :)
08:55<@DorpsGek>[OpenTTD/OpenTTD] FLHerne left a comment on commit: Add: [NewGRF] Patch flag to test if inflation is on or off.
08:56<FLHerne>(sorry, deleted)
08:57<+michi_cc>TrueBrain: You assume we only have x86 Linux users? :p
08:57-!-DasPoseidon [~Thunderbi@2001:9e8:204b:5900:dd6:40f:4643:f842] has joined #openttd
08:57-!-DasPoseidon is "DasPoseidon" on #openttd
08:58<TrueBrain>michi_cc: I do?
08:59<@DorpsGek>[OpenTTD/nml] FLHerne requested changes for pull request #183: Add support for recent NewGRF additions
08:59-!-roadt_ [~roadt@] has quit [Read error: Connection timed out]
08:59<TrueBrain>michi_cc: honestly, I don't even know what you are referring to :)
08:59<FLHerne>frosch123: ^ reviewed
09:00-!-roadt_ [~roadt@] has joined #openttd
09:00-!-roadt_ is "roadt" on #openttd
09:00<+michi_cc>rdtsc code. Unless I'm missing it somewhere, we only have x86 Linux code, not generic Linux.
09:00<FLHerne>How does (should?) this interact with vehicle_is_powered?
09:00<TrueBrain>as I mentioned: I am confused, and that is a problem on my side. In result, I am going to leave this to others :)
09:01<TrueBrain>knowing what you know and what you don't know is a valuable thing :)
09:02<TrueBrain>michi_cc: #if (defined(__i386__) || defined(__x86_64__)) && !defined(RDTSC_AVAILABLE) <- that is executed on x64 isn't it? :)
09:02<+michi_cc>Yes, I was more thinking about MISC, RISC-V, SPARC or whatever :)
09:02<TrueBrain>which are indeed targets we support :P :P
09:03<orudge>I think Debian does build OpenTTD for some
09:03<orudge>of those
09:03<+michi_cc>orudge: Is OpenGL a thing on ARM Windows?
09:05<orudge>I assume so, can test
09:05<+michi_cc>Seems, yes, but not really yes:
09:06<+michi_cc>Ah, OpenGL 3.3. See, targeting 3.2 as a general baseline wasn't a bad choice :)
09:06<TrueBrain>michi_cc: :D :D
09:07<TrueBrain>they are also working on OpenGL support in WSL2 ... very curious how that is going to be :)
09:07<TrueBrain>(but also mapped to DirectX)
09:08<+michi_cc>They might even utilize the same software stack on the backend for it.
09:10<TrueBrain>honestly can't wait for them to release that .. would make working on Windows even easier
09:11<@DorpsGek>[OpenTTD/OpenTTD] Milek7 commented on pull request #8583: Feature: Add ARM64 build for Windows
09:21<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8583: Feature: Add ARM64 build for Windows
09:29<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8540: Fix eeb88e8: Trains reversed while paused do not correctly update sprite bounds
09:31-!-cyberjunkie[m] [~cyberjunk@2001:470:1af1:101::58fa] has left #openttd [User left]
09:32-!-glx [] has joined #openttd
09:32-!-glx is "Loïc GUILLOUX" on #openttd
09:32-!-mode/#openttd [+v glx] by ChanServ
09:35<TrueBrain>LordAro: \o/
09:39<milek7_>eh, it seems cross-platform nanosecond-precision timing is hard :P
09:40<milek7_>even RDTSC as used currently is not entirely correct, as it doesn't check in cpuid that TSC have constant frequency
09:41<+glx>its main use is for local comparisons
09:41<+glx>at least in openttd
09:59<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
10:02<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8583: Feature: Add ARM64 build for Windows
10:07-!-Flygon_ [] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
10:08<TrueBrain>michi_cc: pushed the first working version to my branch .. still need to check all commits and squash a few together
10:08<TrueBrain>but I think it is working :D
10:10<TrueBrain>pretty sure I forgot stuff and things break, but ... it-works-for-me :D
10:12<+michi_cc>I've got a tiny, probably windows only, fix coming in. Apparently, not setting VSync at all leads to glitches on my GPU in fullscreen.
10:12<+michi_cc>Interestingly it doesn't matter, if vsync is set to on or off, just that it is set at all.
10:13<TrueBrain>did you btw read in the backlog that Win32 CSleep takes a tiny bit long :P
10:13<TrueBrain>I will make a separate ticket for it soon
10:13<milek7_>did you see my links?
10:14<TrueBrain>I did
10:14<TrueBrain>owh, and I need to test 8bpp -> 32bpp blitter change
10:14<TrueBrain>see if that works as intended ..
10:14<+michi_cc>TrueBrain: Probably
10:14<@DorpsGek>[OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows
10:15<TrueBrain>michi_cc: sounds about right
10:15<TrueBrain>mouse feels really sluggish now
10:16<TrueBrain> might interest you btw ... I DO NOT HAVE OCD! (I keep telling myself that :D)
10:17<TrueBrain>and in good news, sdl_v.cpp no longer has globals; sdl_default_v.cpp does have a few left, but that is easily solved
10:17<@DorpsGek>[OpenTTD/OpenTTD] tpetazzoni opened issue #8584: Timetable "Start date" with shared orders setting dates in the past
10:18<TrueBrain>I still don't like that the last link I posted acts like it is a commit in OpenTTD upstream .. it is not
10:18<+michi_cc>Why the this-> change though, most code seems to use it for calling member functions?
10:18<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
10:18<TrueBrain>btw, michi_cc , I would greatly appreciate it if you can look at, that I didn't do anything stupid. It should all look really familiar to you :)
10:19<TrueBrain>michi_cc: owh, I looked it over and went for the one used least; did I miscalculate it?
10:19<TrueBrain>seems I did .. I will change it to all this-> in that case :P
10:19<TrueBrain>I really don't care which one :D
10:20<+michi_cc>The commit only removes this-> when calling the parent member function, but it is still a member function call.
10:20<TrueBrain>sorry, I don't follow?
10:21<+michi_cc>i.e. - this->VideoDriver_Win32Base::Stop(); + VideoDriver_Win32Base::Stop();
10:21<+michi_cc>But still e.g. this->DestroyContext();
10:21<TrueBrain>I just made the parent calls consistent
10:21<TrueBrain>the "do this-> or not do this->" is not a discussion I want to have :P
10:21<TrueBrain>but either all this-> or none, in my book :D
10:21<TrueBrain>so pick one, and I will make it happen :)
10:24<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8583: Feature: Add ARM64 build for Windows
10:24<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on issue #8584: Timetable "Start date" with shared orders setting dates in the past
10:25<+michi_cc>Scrolling through my win32_v, I'm only noticed one call that is missing a this->, everything else there has it. I've not look at all the other game code though right now.
10:26<LordAro>this-> should be used everywhere
10:26<LordAro>anywhere it is not is a mistake
10:26<TrueBrain>so this-> it is :)
10:27<TrueBrain>michi_cc: possibly I was just being blind :)
10:30<milek7_>TrueBrain: SDL_GetWindowSurface seems intended for getting legacy structure for software blitting (sdl example calls SDL_Surface "// even with SDL2, we can still bring ancient code back")
10:30<TrueBrain>okay, changed them all to this-> in SDL driver :)
10:30<milek7_>it might be cleaner to use SDL_GetRendererOutputSize
10:31<TrueBrain>I am a bit reluctant to change anything outside of "I am moving code", but I will put it on the list :)
10:31<TrueBrain>trying really hard to avoid regressions :D
10:34-!-jottyfan [] has joined #openttd
10:34-!-jottyfan is "jottyfan" on #openttd
10:35<milek7_>and my nitpicky-technically-illegal-API-usage screams a bit about not using SDL_Lock/UnlockSurface without checking SDL_MUSTLOCK
10:36-!-jottyfan [] has quit []
10:36<TrueBrain>we are not using SDL_Lock?
10:38<TrueBrain>as in, we are not using it .. so I do not understand at all what you just said
10:38<TrueBrain>felt like random words :D Sorry :P It needs more context if you want us to do anything with it :)
10:38<milek7_>ah, misunderstanding
10:38<TrueBrain>if we are not using SDL_Lock, why should we check SDL_MUSTLOCK :P
10:38<milek7_>we access surface directly
10:39<milek7_>and sdl docs says "Between calls to SDL_LockSurface() / SDL_UnlockSurface(), you can write to and read from surface->pixels, using the pixel format stored in surface->format. Once you are done accessing the surface, you should use SDL_UnlockSurface() to release it. "
10:39<milek7_>and "Not all surfaces require locking. If SDL_MUSTLOCK(surface) evaluates to 0, then you can read and write to the surface at any time, and the pixel format of the surface will not change. "
10:39<milek7_>but we neither use SDL_LockSurface nor check SDL_MUSTLOCK result
10:40<TrueBrain>okay, existing problems are for another PR honestly :)
10:40<TrueBrain>otherwise this will never come to any conclusion :D
10:40<TrueBrain>I just moved code around, did not change the SDL flow (or rather, it should not have changed the SDL flow if I did my work properly)
10:41<@DorpsGek>[OpenTTD/OpenTTD] J0anJosep updated pull request #8480: Multitile depots
10:42<TrueBrain>it is funny, michi_cc is now laughing, as he had the same issue with my remarks yesterday :P
10:43<+michi_cc>Give people a hand, and they will take the whole arm :D
10:43<TrueBrain>something something scope
10:45<milek7_>it's just a nitpick, doesn't really change anything on currently known sdl2 platforms ;P (but I know about it because it broke sdl1-emscripten...ugh, that wasted much time)
10:46<milek7_>anyway, about previous issue: >I am a bit reluctant to change anything outside of "I am moving code", but I will put it on the list :)
10:47<milek7_>I'm not talking about existing code here, it must use SDL_Surface anyway so it is fine
10:47<milek7_>but about opengl variant:
10:48<TrueBrain>owh, that should be SDL_GetWindowSize
10:48<milek7_>I think SDL_GetRendererOutputSize is more correct
10:49<TrueBrain>currently we use SDL_GetWindowSize on all other places for this
10:49<milek7_>or maybe SDL_GL_GetDrawableSize
10:52<TrueBrain>michi_cc: what is the best GRF to test 8bpp -> 32bpp blitter change with, any suggestions? :D
10:52<milek7_>SDL_GetWindowSize won't be correct in future when we add SDL_WINDOW_ALLOW_HIGHDPI support
10:52<TrueBrain>milek7_: that is the correct wording :) And it will break other things too, as we use SDL_GetWindowSize all over the place
10:52<TrueBrain>tnx michi_cc !
10:52<+michi_cc>Start with ogfx and switch to zbase in the options. Possibly disabling 40bpp-anim in case you really want a 32bpp blitter.
10:53<TrueBrain>hmm .. crash on finishing the download ... that doesn't sound good
10:55<TrueBrain>wow .. switching ... just worked :o
10:55<TrueBrain>I have to admit I was not really expecting that
10:56<TrueBrain>zBase has no animation?
10:57-!-Gustavo6046 [~Gustavo60@] has quit [Ping timeout: 480 seconds]
10:59<TrueBrain>hmm .. seems I am using wgl with SDL, funny :)
10:59<TrueBrain>as in, wglGetProcAddress is used
11:00<TrueBrain>did not expect that :D
11:00<milek7_>what else it could use on windows? :P
11:01<TrueBrain>owh, it is the only wgl function
11:04<@DorpsGek>[OpenTTD/OpenTTD] J0anJosep commented on pull request #8480: Multitile depots
11:06<TrueBrain>michi_cc: found my way down my list: <- was this what you were asking for?
11:06<TrueBrain>I didnt really understand your comment in the PR, honestly :)
11:06<TrueBrain>couldn't find the commit where you changed it from egl to glX :)
11:07<+michi_cc>milek7_ mentioned it. Your change is yes and technically no, as you could have SDL AND some other video driver. So if SDL_GL_GetProcAddress is required, it would have to be a video driver function.
11:08<milek7_>I meant to remove system #ifdefs from GetOGLProcAddress
11:08<milek7_>and instead use virtual method in driver
11:09<+michi_cc>Well, is SDL_GL_GetProcAddress internally doing anything special? I'm not that keen on having the OpengL backend call back into the video driver frontend.
11:09<TrueBrain>michi_cc: it worked fine with wgl, and by the tests the other day, also with the glX, so required seems to be a no :)
11:09<milek7_>I think it's just calling wgl internally
11:09<milek7_>on windows
11:10<milek7_>but I think it is bit dirty to call GetProcAddress behind SDL back, as SDL knows what API is used
11:10<+michi_cc>Yes, in the end it must call wgl, I was just wondering if it does any pre- or post-processing.
11:11<milek7_>and defining glXGetProcAddress unconditionally on unix in our code is not entirely correct
11:11<milek7_>it could fail when using pure-wayland environment
11:12<milek7_>(as it should use EGL then)
11:12<TrueBrain>michi_cc: the main difference seems to be that SDL_GL_GetProcAddress first tries wglGetProcAddress and if that fails uses GetProcAddress
11:13<TrueBrain>inside the DLL
11:13<+michi_cc>For modern Linux at least I think all functions internally end up in libglvnd, no matter if glx or egl.
11:13<+michi_cc>But okay, to be really correct, get proc needs to be a video driver callback.
11:15<TrueBrain>for X11 there are 2 flows, GL and GLES
11:15<TrueBrain>the first is what you have now
11:15<TrueBrain>the second it uses SDL_EGL_GetProcAddress
11:15<TrueBrain>which loads a DLL (lol .. think they named that poorly) and looks up the proc there
11:15<TrueBrain>the egl_dll, that is
11:16<TrueBrain>seems the latter is mostly for Android
11:16<TrueBrain>if that helps :)
11:17<milek7_>depending on driver, you can use GLES context on desktop too
11:17<TrueBrain>hence the word "mostly"
11:18<milek7_>on windows, you can use that to translate that into DX11
11:18-!-Wolf01 [] has joined #openttd
11:18-!-Wolf01 is "Wolf01" on #openttd
11:18<milek7_>I wanted to add GLES support after this is merged :)
11:19<TrueBrain>michi_cc: if you are looking into making a callback back to the driver, maybe better to let the driver give a function to the backend on init?
11:21<Samu>how do I remove a file from the project, need to see an example
11:23<TrueBrain>right, my todo list: clean up header-includes (I have too many now :D), clean up some commits ... that is something for tomorrow :D
11:27<milek7_>your branch is missing #include <condition_variable>
11:28<@DorpsGek>[OpenTTD/OpenTTD] orudge dismissed a review for pull request #8583: Feature: Add ARM64 build for Windows
11:28<milek7_>and warnings:
11:28<@DorpsGek>[OpenTTD/OpenTTD] orudge updated pull request #8583: Feature: Add ARM64 build for Windows
11:30<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8583: Feature: Add ARM64 build for Windows
11:31<Samu>how to properly remove the file.
11:31<Samu>need tips
11:33<LordAro>have you tried removing it?
11:33<andythenorth>rm -rf * .
11:33*andythenorth gets kicked
11:34<TrueBrain>andythenorth: yeah, please don't say that again ... you know there is a chance he might try ..
11:35<andythenorth>then we learn about pasting commands from the internet
11:35<andythenorth>life lessons
11:37<andythenorth>hmm have I improved my GPU performance?
11:39<andythenorth>Photoshop was allocated 4GB of VRAM
11:39<andythenorth>which is all the VRAM
11:50<+glx>Samu: just delete the file, in some cases you may need to also update CMakeList.txt (but cmake will tell you if it's required)
12:02<@DorpsGek>[OpenTTD/website] orudge opened pull request #183: Feature: List Windows ARM64 binaries correctly, autodetect ARM64 Windows
12:04<@DorpsGek>[OpenTTD/website] LordAro approved pull request #183: Feature: List Windows ARM64 binaries correctly, autodetect ARM64 Windows
12:09-!-sla_ro|master [slamaster@] has joined #openttd
12:09-!-sla_ro|master is "slamaster" on @#sla #openttd
12:14<@DorpsGek>[OpenTTD/website] orudge merged pull request #183: Feature: List Windows ARM64 binaries correctly, autodetect ARM64 Windows
12:24<Samu>i don't see any warning from cmake, but maybe I don't know where to look
12:24<@DorpsGek>[OpenTTD/website] orudge opened pull request #184: Fix: Autodetect macOS correctly
12:28-!-Gustavo6046 [~Gustavo60@] has joined #openttd
12:28-!-Gustavo6046 is "Gustavo Rehermann <>" on #openttd #llvm
12:29<@DorpsGek>[OpenTTD/OpenTTD] orudge opened pull request #8585: Fix: [Actions] Give Universal Mac packages the "universal" suffix
12:31-!-Gustavo6046 [~Gustavo60@] has quit []
12:32-!-snail_UES_ [] has joined #openttd
12:32-!-snail_UES_ is "Jacopo Coletto" on #openttd
12:41<Samu>Can you spot the differences in the desert perimeter?
12:41<Samu>they exist, but I tried my best to minimize them
12:41-!-arikover [] has joined #openttd
12:41-!-arikover is "arikover" on #openttd
12:45-!-arikover` [] has joined #openttd
12:45-!-arikover` is "arikover" on #openttd
12:46-!-Wormnest [~Wormnest@] has joined #openttd
12:46-!-Wormnest is "Wormnest" on #openttd
12:50-!-arikover [] has quit [Ping timeout: 480 seconds]
12:52<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver
12:52<+michi_cc>Okay, enough faffing around for right now.
12:53<+michi_cc>TrueBrain: There was a bug affecting fullscreen toggle in that the window size was wrong after repeated toggling. Also, callback function for GetProcAddress now.
12:53<+michi_cc>Hmm, and maybe we can reduce the size if this a tiny bit.
12:53-!-Gustavo6046 [~Gustavo60@] has joined #openttd
12:53-!-Gustavo6046 is "Gustavo Rehermann <>" on #openttd #llvm
12:54<@DorpsGek>[OpenTTD/OpenTTD] michicc opened pull request #8586: Codechange: [Win32] Window driver cleanup
12:54<+michi_cc>TrueBrain: I've picked most of your Win32 stuff. If you want, you can tack on SDL to the new PR.
13:13<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver
13:24<TrueBrain>michi_cc: will do; and this week I will PR the cleanups of SDL too, so OpenGL becomes lovely small and simple :)
13:25<+michi_cc>Now on to faffing with OSX.....
13:27<+michi_cc>Look at AllocateBackingStore and ToggleFullscreen specifically.
13:30<milek7_>btw. I'm wondering
13:30<milek7_>opengl1.1 functions are exported in windows (such as eg. glEnable) in opengl32.dll and can be linked directly
13:30<milek7_>but wglGetProcAddress docs make it clear that returned pointers are valid only for current context, because different drivers can be selected in runtime
13:30<milek7_>yet these functions linked from opengl32.dll obviously are called the same for all possible drivers
13:30<milek7_>so, how does that work?
13:35<nielsm>possibly they have a shim function exported that does something appropriate?
13:35<+michi_cc>opengl32 will call into a driver table
13:36<+michi_cc>Just like e.g. libGL on Linux. The exported function all just call into a dispatch table.
13:36<milek7_>but then what's the point of having wglGetProcAddress return context-specific pointer? they could just use the same facility for dynamic dispatch
13:37<nielsm>performance, probably, by having slightly less indirect calls
13:38<+michi_cc>If wglGetProcAddress would return context-free pointers, Windows would need to know all possible extensions that could ever exists in any driver.
13:39<@DorpsGek>[OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
13:39<@DorpsGek> - Update: Translations from eints (by translators)
13:40<+michi_cc>By directly returning pointers to the driver, new OpenGL versions and extensions can be supported without Windows updates.
13:45<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8586: Codechange: [Win32] Window driver cleanup
13:57<+michi_cc>LordAro is to blame if everything explodes :)
13:57<@DorpsGek>[OpenTTD/OpenTTD] michicc merged pull request #8540: Fix eeb88e8: Trains reversed while paused do not correctly update sprite bounds
13:57<@DorpsGek>[OpenTTD/OpenTTD] michicc merged pull request #8586: Codechange: [Win32] Window driver cleanup
14:09<TrueBrain>if something goes wrong and you are smiling, you have someone else to blame!
14:16<andythenorth>what if I just repaint the 'refit in depot' button to be 'liveries' and change the tool tips?
14:16<andythenorth>does that work?
14:17-!-iSoSyS [] has joined #openttd
14:17-!-iSoSyS is "realname" on #/r/openttd #openttd
14:27<andythenorth>this new interface is so much better
14:27<andythenorth>just removing the 'location' buttons makes everything seem simpler
15:14<Samu>what's the difference between std::list and std::map
15:17<TrueBrain>andythenorth: but but but <insert 4 pages of comments here, most related but not addressing the location button>
15:17<andythenorth>I don't know what you're referring to, no idea, no clue, not the faintest or foggiest
15:17<andythenorth>where would that ever happen?
15:18<Samu>i think std::list is slow for what I wanna do
15:19<Samu>im unsure
15:19<+michi_cc>More often than not you want std::vector anyway.
15:20<Samu>testing std::vector
15:20<Samu>i thought i couldn't use an iterator with std::vector
15:22<andythenorth>I should add to my pony list
15:22<andythenorth>cargo payment multiplier
15:22<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8578: Fix: Stopped ships shouldn't block depots
15:23*andythenorth wants shiny vehicles to pay more
15:26<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8576: Feature: Allow GameScripts to add additional text to Industry view window
15:29-!-Wormnest [~Wormnest@] has quit [Quit: Leaving]
15:30<andythenorth>sometimes the stereo mix in OpenTTD makes me smile
15:30<andythenorth>when a bunch of train whistles sound from different left / right locations
15:33<Samu>is there anything faster than std::vector?
15:33<Samu>i'm only iterating
15:42-!-mode/#openttd [+o orudge] by ChanServ
15:44<Samu>what does it mean qualified name is not allowed
15:47<Samu>nevermind, vector will do
15:58<nielsm>std::vector is the fastest there is, when you need to visit the elements in order and process most or all of them
16:00<nielsm>there's some types of manipulating the collection (inserting/removing/moving around elements) that will be more efficient in other containers, but pretty much try a vector first and if it just doesn't work out then go looking for something else
16:00-!-argoneus [] has quit [Server closed connection]
16:00-!-argoneus [] has joined #openttd
16:00-!-argoneus is "argoneus" on #openttd
16:02<Samu>couldn't tell much of a difference in release mode between std::list and std::vector
16:02<Samu>only in debug mode
16:02<Samu>they're both horribly slow in debug
16:03<Samu>but still, vector was faster
16:03<LordAro>MSVC containers are known to be horribly slow in debug mode
16:03<LordAro>but we don't care about debug mode performance (well, barely)
16:04<Samu>wanna take a peek at what I'm working on?
16:05<Samu>the vector is at line 998
16:05<nielsm>std::list is a doubly linked list, it will use much more memory per element (two pointers worth extra) and will typically be very bad for the CPU cache performance, it has some theoretical benefits in being able to insert an element into the list at any position in constant time (no need to move existing elements around in memory) but the performance loss from cold cache will often outweigh
16:06<nielsm>std::list might make sense if your individual elements in the collection are value types (not pointers) that are individually large, and you often need to insert/remove elements from the beginning or middle of the list
16:07<Samu>i don't need to remove elements
16:07<Samu>only need to insert, and it doesn't matter where it goes
16:07<Samu>will only need to iterate over them all
16:07<nielsm>then vector is by far the best choice
16:08-!-crem1 [~crem@2a02:169:160a:1:9b30:962e:76eb:4bb3] has joined #openttd
16:08-!-crem1 is "crem" on #openttd
16:09<Samu>iterators are at line 1038 and 1059
16:10<nielsm>the reason all STL containers are crazy slow in debug builds in MSVC is because the debug mode enables iterator debugging and checking, so every time you move or access an iterator it does a thorough check that you aren't violating bounds of the container and much more
16:10-!-crem [~crem@] has quit [Ping timeout: 480 seconds]
16:11<nielsm>that makes everything slow, but will catch many programming errors that might not be caught by an optimized iterator before it's far too late (and then it will probably just cause silent memory corruption or wrong looping, or if you're lucky maybe just crash the program)
16:12<andythenorth>nielsm hi :)
16:13<Samu>this is still a costly operation
16:14<Samu>I tried to make the boundaries where it checks where to place desert or rainforest, to be scallable
16:15<Samu>turns out I can't scale that much, it slows down too much
16:16<nielsm>try working out how many tiles you'll be working on in some concrete cases
16:16<nielsm>and compare
16:16<Samu>looking at the genland.h data, it had a look of a circumference of about 6 tiles radius around the center
16:17<nielsm>if you're just scaling up by map size, then remember that a 4096x4096 map has 16x as many tiles as a 256x256 map
16:17<TrueBrain>@calc 4096*4096/256/256
16:17<@DorpsGek>TrueBrain: 256
16:17<Samu>for every tile in the map, it looks into the tiles inside the circumference
16:17<TrueBrain>I was about to say, that can't be right :D
16:18<nielsm>hmm.. yeah that's 16x on *one* edge, forgot to square
16:18<Samu>becomes costly if the radius is too large
16:19<Samu>this is the radius I went with: uint radius = std::min(MapLogX(), MapLogY()) - 1;
16:19<Samu>ScaleByMapSize1D was horribly slow
16:20<nielsm>yes, and area of a circle scaled by square of the radius, so if you double the radius you get four times as much area, and if you make the radius 16 times larger you get 256 times as much area
16:20<nielsm>any geometric shape you scale will behave like that
16:22<nielsm>I have no idea what exactly you're doing, and I don't have any intention of putting time into looking into it, but you probably need to find some more efficient algorithms that scale better
16:24-!-sla_ro|master [slamaster@] has quit []
16:27<Samu>I'm making circumferences that scale :p
16:31<Samu>I'll show you, let me take a screenshot
16:31<nielsm>I'm not going to look at it
16:31<nielsm>in fact I'm going to bed now, good night
16:31<Samu>ok gn
16:31<TrueBrain>sleep well nielsm :)
16:36<Samu>the distance between sea and desert is this "scalable radius" I worked upon:
16:38-!-WormnestAndroid [~WormnestA@] has quit [Ping timeout: 480 seconds]
16:38-!-WormnestAndroid [~WormnestA@] has joined #openttd
16:38-!-WormnestAndroid is "WormnestAndroid" on #openttd
16:39<@DorpsGek>[OpenTTD/OpenTTD] Matias-Barrios commented on issue #8582: Content Downloading does not work
16:39-!-nielsm [] has quit [Ping timeout: 480 seconds]
16:39<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain closed issue #8582: Content Downloading does not work
16:41<Samu>thicker green borders
16:45-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
16:48-!-arikover` [] has quit [Quit: ERC (IRC client for Emacs 26.3)]
16:54-!-Samu [] has quit [Quit: Leaving]
16:55-!-Markk_ is now known as Mark
17:03-!-Mark is now known as markk
17:03-!-markk is now known as Markk
17:03-!-WormnestAndroid [~WormnestA@] has quit [Ping timeout: 480 seconds]
17:04-!-WormnestAndroid [~WormnestA@] has joined #openttd
17:04-!-WormnestAndroid is "WormnestAndroid" on #openttd
17:07-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
17:19<@DorpsGek>[OpenTTD/OpenTTD] LC-Zorg commented on pull request #8566: Move "town name" selection into map generator GUI
17:20-!-iSoSyS [] has quit []
17:22-!-Progman [] has quit [Remote host closed the connection]
17:46-!-andythenorth [] has quit [Quit: andythenorth]
17:48<TrueBrain>hadn't seen frosch123 made another awesome PR :D
17:54<TrueBrain>seems he has new ambition :D
18:05-!-supermop_Home_ [] has joined #openttd
18:05-!-supermop_Home_ is "Guest" on #openttd
18:10<+michi_cc>Removing "re
18:10<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver
18:10<+michi_cc>dundant" commits :)
18:13-!-tokai [] has joined #openttd
18:13-!-tokai is "Christian Rosentreter" on #openttd
18:13-!-mode/#openttd [+v tokai] by ChanServ
18:19-!-tokai|noir [] has quit [Ping timeout: 480 seconds]
19:02-!-DasPoseidon [~Thunderbi@2001:9e8:204b:5900:dd6:40f:4643:f842] has quit [Quit: DasPoseidon]
19:16<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8585: Fix: [Actions] Give Universal Mac packages the "universal" suffix
19:16<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8583: Feature: Add ARM64 build for Windows
19:44-!-Flygon [~Flygon@2001:44b8:411e:4e00:f4a9:ce58:a512:bcc8] has joined #openttd
19:44-!-Flygon is "Flygon" on #openttd
19:45<@DorpsGek>[OpenTTD/team] Wuzzy2 opened issue #128: [de_DE] Translator access request
19:50-!-Gustavo6046_ [~Gustavo60@] has joined #openttd
19:50-!-Gustavo6046_ is "Gustavo Rehermann <>" on #openttd #llvm
19:51-!-Gustavo6046 [~Gustavo60@] has quit [Read error: Connection reset by peer]
19:51-!-Gustavo6046_ is now known as Gustavo6046
19:52-!-gelignite [] has quit [Quit: Stay safe!]
19:56-!-Gustavo6046_ [~Gustavo60@] has joined #openttd
19:56-!-Gustavo6046_ is "Gustavo Rehermann <>" on #openttd #llvm
19:59-!-Gustavo6046 [~Gustavo60@] has quit [Ping timeout: 480 seconds]
19:59-!-Gustavo6046_ is now known as Gustavo6046
20:11-!-WormnestAndroid [~WormnestA@] has quit [Remote host closed the connection]
20:12-!-WormnestAndroid [~WormnestA@] has joined #openttd
20:12-!-WormnestAndroid is "WormnestAndroid" on #openttd
22:17-!-muffindrake1 [] has joined #openttd
22:17-!-muffindrake1 is "muffindrake" on #debian-next #openttd
22:18<@DorpsGek>[OpenTTD/team] RobertNP opened issue #129: [ro_RO] Translator access request
22:19-!-muffindrake [] has quit [Ping timeout: 480 seconds]
22:32<@DorpsGek>[OpenTTD/nml] Gadg8eer opened issue #184: NewGRF Town Names no longer compile after unknown changes
22:41-!-WormnestAndroid [~WormnestA@] has quit [Ping timeout: 480 seconds]
22:41-!-WormnestAndroid [~WormnestA@] has joined #openttd
22:41-!-WormnestAndroid is "WormnestAndroid" on #openttd
23:00-!-glx [] has quit []
23:02-!-debdog [~debdog@2a00:79c0:63a:fa00:7a24:afff:fe8a:d04d] has joined #openttd
23:02-!-debdog is "Wowbagger" on #openttd
23:06-!-WormnestAndroid [~WormnestA@] has quit [Ping timeout: 480 seconds]
23:06-!-D-HUND [~debdog@2a00:79c0:666:3900:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
23:06-!-WormnestAndroid [~WormnestA@] has joined #openttd
23:06-!-WormnestAndroid is "WormnestAndroid" on #openttd
23:40<@DorpsGek>[OpenTTD/nml] Gadg8eer closed issue #184: NewGRF Town Names no longer compile after unknown changes
23:40<@DorpsGek>[OpenTTD/nml] Gadg8eer reopened issue #184: NewGRF Town Names no longer compile after unknown changes
23:40<@DorpsGek>[OpenTTD/nml] Gadg8eer commented on issue #184: NewGRF Town Names no longer compile after unknown changes
---Logclosed Mon Jan 18 00:00:59 2021