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

---Logopened Thu Jan 14 00:00:54 2021
00:45-!-tejanos [] has quit [Remote host closed the connection]
01:57-!-andythenorth [] has joined #openttd
01:57-!-andythenorth is "andythenorth" on #openttd
02:05<@DorpsGek>[OpenTTD/OpenTTD] andythenorth commented on pull request #8566: Move "town name" selection into map generator GUI
02:08-!-DasPoseidon [~Thunderbi@2001:9e8:2052:4000:f021:4c61:b543:1fc1] has joined #openttd
02:08-!-DasPoseidon is "DasPoseidon" on #openttd
02:10-!-DasPoseidon [~Thunderbi@2001:9e8:2052:4000:f021:4c61:b543:1fc1] has left #openttd []
02:12-!-snail_UES_ [] has quit [Quit: snail_UES_]
02:19-!-sla_ro|master [slamaster@] has joined #openttd
02:19-!-sla_ro|master is "slamaster" on @#sla #openttd
02:19-!-roadt__ [~roadt@] has joined #openttd
02:19-!-roadt__ is "roadt" on #openttd
02:26-!-roadt_ [~roadt@] has quit [Ping timeout: 480 seconds]
04:10<@DorpsGek>[OpenTTD/OpenTTD] orudge opened pull request #8569: Fix: Remove .sha256 files from macOS builds
04:15-!-andythenorth [] has quit [Quit: andythenorth]
04:19-!-supermop_Home [] has quit [Ping timeout: 480 seconds]
04:22<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8569: Fix: Remove .sha256 files from macOS builds
04:29<@DorpsGek>[OpenTTD/OpenTTD] iTKerry commented on issue #8525: Server on MacOS is not sending ADMIN_PACKET_SERVER_WELCOME packet
04:29<@DorpsGek>[OpenTTD/OpenTTD] iTKerry closed issue #8525: Server on MacOS is not sending ADMIN_PACKET_SERVER_WELCOME packet
04:30<@DorpsGek>[OpenTTD/OpenTTD] orudge merged pull request #8569: Fix: Remove .sha256 files from macOS builds
04:54<TrueBrain>aawwhhhh, people love us! How nice :)
04:55<TrueBrain>orudge: I love how Sectigo wants you to update your company details on ANY online third party database :)
04:55<@orudge>But I'm not putting my personal mobile phone number on a third party database :|
04:55<TrueBrain>no, it is a bit odd that they want to, honestly
04:55<@orudge>Might have to get a VoIP number if they're insistent on this nonsense
04:55<@orudge>but will maybe try to phone them
04:56<TrueBrain>well, my phone number was for a long time on most WHOIS records, as there was no other way back in the day
04:56<TrueBrain>but by now we learnt that never leads to great things :)
05:01<TrueBrain>orudge: anyway, did you see that the caching of vcpkg went bananas on MacOS now?
05:01<TrueBrain>seems it doesn't really like /tmp or something weird
05:08<@orudge>TrueBrain: yes, I did notice that
05:08<@orudge>I can try putting it into a different folder
05:09<@orudge>or see if I can replace the system-provided vcpkg
05:09<TrueBrain>no clue what the real problem is .. tarring with ../../ is just weird :P
05:09*orudge assumes they haven't updated the OS image yet
05:09<@orudge>Will have a look
05:09<TrueBrain>it makes builds ~8 minutes slower, that is about it :)
05:11<TrueBrain>and I see I only applied my Windows fix to the CI, not to the release ... lets fix taht :D
05:12-!-Samu [] has joined #openttd
05:12-!-Samu is "realname" on #openttd
05:13<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain opened pull request #8570: Fix: [Actions] circumvent Windows tar warning about read-only files
05:17<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8570: Fix: [Actions] circumvent Windows tar warning about read-only files
05:26<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain merged pull request #8570: Fix: [Actions] circumvent Windows tar warning about read-only files
06:09<Samu>there's still issues with sub-tropic landscape generator
06:09<Samu>if i set a too high height (255) and a 4k map, the map becomes desert for like 99%
06:11<Samu>it requires too much height for it to start placing rainforest
06:11<Samu>that CeilDiv isn't working too well
06:14<Samu>max_desert_height = CeilDiv(, 4); this is assuming the generator uses all of the 255 heights in 4k maps
06:14<Samu>it uses about 86 or 87 for max height
06:15<Samu>i think the ceildiv should be on this value instead of what the setting says
06:17<@DorpsGek>[OpenTTD/OpenTTD] orudge opened pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:21<Samu>oh, it's actually 150 now, due to the changes made
06:25<reldred>I really want the height to be set with the same variable as what's set in the UI and used for the snow line height. They in practice are used for the same purpose just with tropic you have no control and have to coax your maps into an appropriate max-height.
06:27<Samu>hmm the generator is requested to make terrain with 150 max height, but it can't even reach 80 now
06:27<Samu>this is quite so messed up
06:28<Samu>ok, the user sets 255
06:28<Samu>the table says 255? nah, 87
06:28-!-iSoSyS [] has joined #openttd
06:28-!-iSoSyS is "realname" on #/r/openttd #openttd
06:28<Samu>then there's another adjustemnt. 87? nah, 150
06:28<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:28<Samu>then the generation happens
06:29<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8568: Fix: prevent useless pathfinder run for blocked vehicles
06:29<Samu>150 for max height is what the generator should come with, but in the end the real max height is about 77, 78
06:34<Samu>oh, it's not 150, there's an adjustment again, and sets it to 78
06:34-!-iSoSyS [] has quit []
06:34<Samu>255 to 87, to 151, then to 78
06:34<Samu>it generates as requested, 78
06:36<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:38<TrueBrain>orudge: problem with such complex "rm -rf" is that they tend to break :P So I tend to look for a simpler solution that is obvious right :D
06:38<TrueBrain>either way, if you don't want to do a "sudo rm", it is clearly missing a comment to explain :D
06:39<@DorpsGek>[OpenTTD/OpenTTD] orudge updated pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:39<@orudge>TrueBrain: yes, I'd prefer to avoid an "rm -rf" myself :)
06:40<TrueBrain>well, "rm -rf" on its own is not bad, but with an xargs and an ls .... it becomes a bit more .. tricky :D But yeah, I am fine with a comment too :)
06:41<@orudge>I think I have a better solution now anway
06:42<@orudge>It seems to work in my repository, and the caching is working again
06:42<TrueBrain>you tested that quick
06:42<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:42<@orudge>well, it's executing just now
06:42<@orudge>but it's got past the vcpkg stage :)
06:43<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:43<TrueBrain>one more question for you, sorry :)
06:51<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:54<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:57<@DorpsGek>[OpenTTD/OpenTTD] orudge updated pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:58<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:58<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain approved pull request #8571: Fix: vcpkg binaries were not being cached on Mac
06:59<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
07:00<TrueBrain>LordAro asking the right questions :D
07:10<@DorpsGek>[OpenTTD/OpenTTD] orudge commented on pull request #8571: Fix: vcpkg binaries were not being cached on Mac
07:10<@DorpsGek>[OpenTTD/OpenTTD] orudge merged pull request #8571: Fix: vcpkg binaries were not being cached on Mac
07:16<@DorpsGek>[OpenTTD/OpenTTD] SamuXarick commented on pull request #8568: Fix: prevent useless pathfinder run for blocked vehicles
07:33<Eddi|zuHause>improved nfo 32 conversion script: awk '$2 ~ /png/ { printf(" %d %s 8bpp %3d %3d %3d %3d %3d %3d normal\n", $1, $2, $3, $4, $6, $5, $7, $8) } $2 !~ /png/'
07:35-!-WormnestAndroid [~WormnestA@] has quit [Remote host closed the connection]
07:35-!-WormnestAndroid [~WormnestA@] has joined #openttd
07:35-!-WormnestAndroid is "WormnestAndroid" on #openttd
07:35<Eddi|zuHause>the regexp route grew... out of hand, so i switched to awk :p
07:36<FLHerne>Next up, Perl?
07:36<Eddi|zuHause>unlikely :p
08:05-!-dih [] has joined #openttd
08:05-!-dih is "dihedral" on #openttd.noai #openttd #grapes
08:05-!-dihedral [] has quit [Read error: Connection reset by peer]
09:01-!-Smedles [] has quit [Ping timeout: 480 seconds]
09:06-!-Smedles [] has joined #openttd
09:06-!-Smedles is "Paul Smedley" on #openttd
09:22<@orudge>TrueBrain / other interested parties: wondering what your reaction might be to this:
09:22<@orudge>Takes about 14 minutes versus 8 minutes for Windows (when vcpkg is cached)
09:23<@orudge>Building the two platforms separately would involve more duplication and glue since we need to merge the binaries before running cpack
09:23<TrueBrain>as I said a few times already: build-time I don't care about, but the size of the package is what annoys me; we pay twice the bandwidth for a single download, where the user could also just have picked the right one :)
09:24<@orudge>Resulting .dmg size is 9.5MB versus 6.3MB for arm64 or 6.8MB for x64
09:24<TrueBrain>well, okay, 50% extra, fine :P
09:24<TrueBrain>I would think updating the javascript to auto-select the right download on our website is easier/better :)
09:24<@orudge>I just wonder how many users will look at the web site, see "macOS 11", say, "oh, hey, I have that", then download the M1 build when they're on Intel :P
09:25<TrueBrain>we have similar with Windows, but long solved :P
09:25<LordAro>maybe wait until the first bug report? :p
09:25<@orudge>Ah, yeah, there's a separate combo box for Windows
09:25<@orudge>well, maybe I'll poke around with that
09:25<TrueBrain>well, we do need to fix the website .. otherwise people will run into this issue for sure :D
09:26<TrueBrain>anyway, nothing against universal builds or the way you solved it; I just think it is the wrong solution (promoted by Apple) :P
09:26<@orudge>but that will have to wait for today, need to get back to some other work :P
09:26<TrueBrain>ps: you forgot a \ before # EOF again :D :D :D
09:26<TrueBrain>sorry, it triggered me :D
09:27<TrueBrain>if you are going to give it a go: needs to be updated to latest, I think, before you can get it to work :) It is a git-submodule
09:27<@orudge>Will see what I can do, when I get a chance
09:27<TrueBrain>and we are finding the best match
09:31-!-Smedles [] has quit [Ping timeout: 480 seconds]
09:32<@DorpsGek>[OpenTTD/OpenTTD] mattkimber updated pull request #8540: Fix eeb88e8: Trains reversed while paused do not correctly update sprite bounds
09:36-!-nielsm [] has joined #openttd
09:36-!-nielsm is "Niels Martin Hansen" on #openttd
09:37<TrueBrain>owh, right, AppImage, for "generic" linux binaries ... biggest issue: 40MB of data-files for MIDI support which people are unlikely to use :P
09:37<TrueBrain>still not sure what to do with that ..
09:41<LordAro>istr nielsm saying that the midi data files could be cut down quite significantly
09:41<LordAro>i seem to recall
09:42<TrueBrain>we did have a talk about it, but I remember it as: it could, but MIDI is a mess, so yeah :P
09:42<TrueBrain>converting to ogg was the proper solution, I believe :P
09:44-!-snail_UES_ [] has joined #openttd
09:44-!-snail_UES_ is "Jacopo Coletto" on #openttd
09:47<@DorpsGek>[OpenTTD/OpenTTD] mattkimber commented on pull request #8540: Fix eeb88e8: Trains reversed while paused do not correctly update sprite bounds
09:47<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8329: Build AppImage
09:48<TrueBrain>right, at least I now wrote it down, what I think the status is
09:48<TrueBrain>hopefully that triggers someone to figure out what our options are :)
09:50<nielsm>yeah the midi synth library could use a significantly smaller patchset and still be good
09:50<TrueBrain>so we "just" need someone bored enough to figure out what that is exactly :P
09:51<Samu>wow, #8551 was abruptly closed
09:51<nielsm>well that, or just find a smaller patchset that must exist somewhere
09:52<milek7_>I don't think you can do that, bananas also contains midi files
09:52<nielsm>I mean sample-based midi synths in the early 1990's had something like 512k to 2M sample banks
09:53<nielsm>the midi files themselves are small, it's the support data in the form of soundfont/sample bank for the midi synth used that takes up ther space, and that's part of the software not the music data
09:53<Eddi|zuHause>my sound blaster awe32 card had 512k memory for the samples
09:53<LordAro>just find a really old version? :D
09:54<TrueBrain>nielsm: and can a MIDI select such sample bank, or do you allocate one as user? (does it show I really don't know anything about this? :D)
09:54<milek7_>I mean, you cannot prune soundfont based on what openmsx contains because user can download different midi
09:54<Eddi|zuHause>TrueBrain: the program/user defines the soundfont, the midi has no real choice
09:55<TrueBrain>so, if we would be really opinionated, and pick a single soundfont, all MIDI would still play?
09:55<TrueBrain>(just to user cannot change how it .. "looks" :P)
09:56<TrueBrain>this is how I remember MIDI btw .. when I plugged in a different audio-card, it was all different :P
09:56<Timberwolf>Heh, this is a fun thing with trying to play '90s games, particularly adventures. Working out what the MIDI soundtrack was scored for, and then how to emulate it.
09:56<TrueBrain>just never looked into what is causing it :D
09:56<Eddi|zuHause>do we even ship a soundfont at all? i thought we rely on the OS to provide those
09:56<TrueBrain>Eddi|zuHause: welcome in the game: read the context :) It is about AppImage :)
09:57<nielsm>yeah as long as the soundfont is General MIDI compliant all the music should still play
09:57<TrueBrain>(you fell in the middle of the conversation Eddi|zuHause :P AppImage was what triggered the question)
09:57<TrueBrain>nielsm: okay, and those are indeed a lot smaller :P
09:58<Eddi|zuHause>TrueBrain: i got that. just i don't really know what an AppImage is actually :)
09:58<TrueBrain>a single package with EVERYTHING in there
09:58<TrueBrain>so your OS only needs to handle syscalls, I guess :P
09:58<TrueBrain>so like snap, flatpack, ....
09:59<Eddi|zuHause>i'm not really a fan of those...
09:59<Eddi|zuHause>seems incredibly wasteful
10:00<TrueBrain>that is a completely different discussion; we were talking about them now being huge, and if they can be slimmed down :)
10:00<Eddi|zuHause>"we solve dll hell by installing more dlls"
10:00<milek7_>maybe that's bit smaller?
10:00<TrueBrain>still 25 MiB, but smaller :)
10:01<TrueBrain>freepats is 33 MiB
10:01<Eddi|zuHause>should i look for my SB AWE32 install disks and find a 512k soundfont? :p
10:01<Eddi|zuHause>(we probably can't use those, anyway :p )
10:01<TrueBrain>it would properly fit better with the theme of OpenTTD for sure :P
10:01<milek7_>that one from 2006? it is incomplete anyway
10:02<TrueBrain>:o :o
10:03<LordAro> this one is small
10:03-!-_2TallTyler [~oftc-webi@] has joined #openttd
10:03-!-_2TallTyler is "OFTC WebIRC Client" on #openttd
10:03<Timberwolf>At that point you may as well just play the soundtrack live and FLAC-encode it!
10:04<TrueBrain>owh, AppImage is 62MiB atm
10:04<TrueBrain>even worse than I thought :P
10:05<TrueBrain>133 MiB after decompression, of which 33 MiB is freepats
10:05<Eddi|zuHause>so i'm gathering that an AppImage is effectively a complete chroot-OS sans kernel
10:05<TrueBrain>so there are other things to .. "cut" too :)
10:05<TrueBrain>I am very tempted to compare it with a docker image :P
10:06<nielsm> lol
10:07<TrueBrain>lol, it currently contains all the gconv files :) Not sure how relevant they all are :P
10:07<Eddi|zuHause>"It weighs in at just over 300MB on disk when uncompressed. While not the largest SF2 out there, as the name suggests, keeping the size light was not of particular concern."
10:07<nielsm> haven't checked license but this has a 6 MB one
10:08<TrueBrain>27M Mar 17 2020 <- lol .. I forgot how big the full icu data was :)
10:08<LordAro>not particularly difficult to compile AppImage OTTD without ICU
10:09<TrueBrain>well, ICU normally also offers to only use parts of their data
10:09<TrueBrain>as not everything is always needed
10:09<TrueBrain>we did that for openttd-useful for years
10:09<TrueBrain>it stripped out all the data stuff we really were not going to use :)
10:10<@DorpsGek>[OpenTTD/OpenTTD] azubieta commented on pull request #8329: Build AppImage
10:14<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8329: Build AppImage
10:14<TrueBrain>okay, so I blamed freepats as people told me that was the issue .. but it isn't
10:18<milek7_>btw, music doesn't work for me in that appimage
10:18-!-andythenorth [] has joined #openttd
10:18-!-andythenorth is "andythenorth" on #openttd
10:20<@DorpsGek>[OpenTTD/OpenTTD] azubieta commented on pull request #8329: Build AppImage
10:20<azubieta>TrueBrain freepaths is only part of the issue
10:21<TrueBrain>I just wrote that, yes :P
10:22<TrueBrain>I WAS MISLEAD BY PEOPLE! The horror :D
10:22<TrueBrain>ghehe :)
10:22<azubieta>I could keep making OpenTTD AppImages but what if tomorrow I become a mean person and start putting malware in your game ?
10:23<azubieta>I would prefer not to be blamed for that, hahahaha
10:23<TrueBrain>that is true for any and all 3rd-party releases
10:23<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8329: Build AppImage
10:23<TrueBrain>it is also the reason we do not publish any third-party places to download the game :)
10:23<azubieta>that's why I insist in having the appimages built as part of your ci workflow
10:24<TrueBrain>I see where you are coming from, but it seems that is not likely in the short future :(
10:24<TrueBrain>you know I am a fan of your work btw, just to be clear :D
10:26<TrueBrain>okay, I think we have to shelve this for now, and revisit it again in a while .. meh :)
10:26<azubieta>let me know if you want to do some modifications, I would gladly help :)
10:27<TrueBrain>I might, just out of pure boredom on my end, write something that purges all files that really really are not going to be useful :P
10:27<TrueBrain>just to scratch my own itch there :)
10:27<TrueBrain>and tnx azubieta , it is appreciated :)
10:28<azubieta>name the files, they will be gone, the tool already support globing expressions to remove files
10:28<TrueBrain>I will toy with it a bit soon :)
10:29-!-andythenorth [] has left #openttd []
10:29<TrueBrain>just completely outside of OpenTTD, I wonder: you base on Ubuntu in this case .. can it also be based on alpine for example?
10:30<azubieta>sadly we still not support muslc, so no Alpine yet
10:30<TrueBrain>what is the issue there?
10:31<azubieta>First, I haven't did that enough. But I suspect that mixing binaries that depend on glibc with others that depend on muslc at runtime will cause a major crash
10:32<TrueBrain>ah, so it is not that it doesn't work, or can't work, just that it is not supported :D Gotcha!
10:32<TrueBrain>now I just want to know how small it gets from it :P
10:32<TrueBrain>curiosity :D
10:33<azubieta>AppImages are not 100% self contained, they still need to use libGL and other "drivers" from the systems se we always have to mix up things
10:33<TrueBrain>ah, I see :)
10:46<Samu>remember the determine snow line height patch? I just realised I can use that code logic to determine max_desert_height too
10:48<Eddi|zuHause>is there an equivalent to "sources.list" where i need to put the png file so cmake recognizes it?
10:49<Samu>the advantage here is that this max_desert_height variable is not defined by the player
10:59<Eddi|zuHause>also, i had a bug in my nfo 32 conversion script: awk '$2 ~ /png/ { printf(" %d %s 8bpp %3d %3d %3d %3d %3d %3d normal\n", $1, $2, $3, $4, $7, $6, $8, $9) } $2 !~ /png/'
11:00<@DorpsGek>[OpenTTD/OpenTTD] Eddi-z updated pull request #8556: Feature: Allow diagonal tracks on level crossings
11:07<@DorpsGek>[OpenTTD/OpenTTD] Eddi-z commented on pull request #8556: Feature: Allow diagonal tracks on level crossings
11:10<Samu>the way this was posted, sounds very unprofessional
11:10<LordAro>Samu: the conversation was getting off track
11:10<Samu>feels like andy didn't read past the initial pr
11:11<LordAro>there was no actual bug, only quibbling over semantics
11:14<Samu>the recent changes to arctic and tropic generation are okay, but it feels like... something is amiss
11:16<Samu>larger tropic maps look bad yet, not sure if they were that bad before, I suppose they were
11:16<_dp_>found this after reading yet another article on c++ templates:
11:17<TrueBrain>_dp_: haha :D
11:17<Eddi|zuHause>well, i think the has a point :p
11:22<_dp_>apparently it takes like 1000 lines of code to convert struct into a tuple automatically with templates...
11:22<TrueBrain>why .... how ... wuth?!
11:23<Eddi|zuHause>_dp_: that sounds like nonsense
11:23<TrueBrain>it would take LordAro only 999 lines! Pfft :P
11:24<_dp_>it's pretty much all does
11:24<_dp_>but I gave up trying too understand how
11:24<Eddi|zuHause>i mean, there were people observed that took 6000 lines to convert a decimal into hexadecimal
11:27<Eddi|zuHause>hm, webster logs are broken when i write $1
11:29<LordAro>TrueBrain: in no way can i compete with boost :p
11:30<Samu>I'm cooking up my next PR, something about sub-tropical max_desert_line
11:32<Samu> - this assumes the max height of the generated map is that, but it's not always the case
11:32<Samu>so my work starts from there
11:33-!-Flygon [~Flygon@2001:44b8:411e:4e00:6538:ff81:3815:e625] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
12:10-!-tokai|noir [] has joined #openttd
12:10-!-tokai|noir is "Christian Rosentreter" on #openttd
12:10-!-mode/#openttd [+v tokai|noir] by ChanServ
12:17-!-tokai [] has quit [Ping timeout: 480 seconds]
12:18-!-tejanos [] has joined #openttd
12:18-!-tejanos is "OFTC WebIRC Client" on #openttd
12:19-!-glx [] has joined #openttd
12:19-!-glx is "Loïc GUILLOUX" on #openttd
12:19-!-mode/#openttd [+v glx] by ChanServ
12:20-!-Wormnest [~Wormnest@] has joined #openttd
12:20-!-Wormnest is "Wormnest" on #openttd
12:23-!-Progman [] has joined #openttd
12:23-!-Progman is "Peter Henschel" on #openttd
12:28<Samu>my english skills are so terrible
12:31<+glx>Samu: you made me check all VehicleEnter_XXX() functions, only case I can find (by just reading the code) is trying to enter to an occupied station, and in this case the pathfinder run, even if discarded and continuously reran, should be unnoticable
12:33<+glx>as it will almost immediately find the tile we just tried to enter
12:33<Eddi|zuHause>is that just me or did the CI not run on #8556 ?
12:34<LordAro>seems not
12:34<+glx>blocked vehicle was a real issue because it was lost, without any existing path to the destination, and that is very expensive to pathfind
12:35-!-Wolf01 [] has joined #openttd
12:35-!-Wolf01 is "Wolf01" on #openttd
12:36<+glx>I think it's because there's a conflict Eddi|zuHause
12:38-!-supermop_Home_ [] has joined #openttd
12:38-!-supermop_Home_ is "Guest" on #openttd
12:40<+glx>just rebase, openttd.grf changed recently (with the new icons for rename and move view)
12:41<@DorpsGek>[OpenTTD/OpenTTD] glx22 closed issue #7670: Road vehicle pathing cache does not always pick up changes in road network
12:41<@DorpsGek>[OpenTTD/OpenTTD] glx22 merged pull request #8568: Fix: prevent useless pathfinder run for blocked vehicles
12:41<@DorpsGek>[OpenTTD/OpenTTD] Eddi-z updated pull request #8556: Feature: Allow diagonal tracks on level crossings
12:42<@DorpsGek>[OpenTTD/OpenTTD] glx22 commented on pull request #7822: Fix #7670: Cache the origin tile to prevent recurring calls to the road pathfinder when a vehicle is blocked by another
12:42<@DorpsGek>[OpenTTD/OpenTTD] glx22 closed pull request #7822: Fix #7670: Cache the origin tile to prevent recurring calls to the road pathfinder when a vehicle is blocked by another
12:42<Eddi|zuHause>glx: ok, even if that's it, it should probably output an error instead of being stuck at "waiting for results"
12:43<+glx>it says there's a conflict :)
12:43<+glx>CI runs on merge of PR onto master
12:44<Eddi|zuHause>yes. but it doesn't say that the CI failed because of the conflict
12:44<+glx>github doesn't start CI if there's a conflict
12:45<+glx>so it doesn't fail ;)
12:45<Eddi|zuHause>then it should say "skipped" or something
12:46<+glx>but it's funny preview could run :)
12:46<+glx>probably because preview don't do any merge
12:48<Eddi|zuHause>on that note, how do i synchronize master from origin/master without checking out master?
12:49<+glx>you can fetch it
12:49<Eddi|zuHause>i did "git fetch origin master"
12:49<Eddi|zuHause>but that updated only origin/master
12:49<Eddi|zuHause>not master
12:50-!-grossing [] has quit [Read error: Connection reset by peer]
12:51-!-grossing [] has joined #openttd
12:51-!-grossing is "Florian Gross" on #openttd #centos #oftc #kaschemme #osm-de-ot
12:51<+glx>I have in my gif global config rb = "!f() { git fetch upstream && git rebase upstream/master; }; f"
12:51<+glx>so fetch upstream :)
12:51<Eddi|zuHause>yeah, your upstream is my origin
12:52<+glx>origin is your fork
12:52<Eddi|zuHause>but you also "git rebase upstream/master", not "git rebase master"
12:52<Eddi|zuHause>well, i'm not usual :p
12:53<Eddi|zuHause>so your "master" and "upstream/master" stay unsynchronized, just you don't notice it
12:54<+glx>I rebase and push my master the same way
12:54<+glx>so when I need to start a branch I just checkout -b
12:55<+glx>from my master
12:55-!-Tirili [~Tirili@2a02:8108:96bf:8438:260:6eff:fe42:7728] has joined #openttd
12:55-!-Tirili is "realname" on #openttd
12:56-!-andythenorth [] has joined #openttd
12:56-!-andythenorth is "andythenorth" on #openttd
12:57<Eddi|zuHause>yes. but if i'm already in a branch, it doesn't automatically rebase master
12:58<+glx>no it rebase only the current branch
12:58<Eddi|zuHause>so when i go back to master, i will forget to update
12:58<+glx>you need to switch branch to update another one
12:58<Eddi|zuHause>so i want to update master, but i don't want to switch out of my branch
13:00-!-jottyfan [] has joined #openttd
13:00-!-jottyfan is "jottyfan" on #openttd
13:02<TrueBrain>glx: preview indeed runs on the HEAD of the PR (with the workflow of "master") :) This because it checks out the sha :)
13:02<+glx>"git rebase upstream/master master" will update master, but it will switch to master too
13:03<+glx>I don't think it's possible to update any branch without switching
13:03-!-Progman [] has quit [Remote host closed the connection]
13:03<Samu>there is "stash" feature
13:04<Samu>stash current changes on the branch and let's you switch to another
13:04<+glx>that's to store uncommited garbage
13:05-!-frosch123 [] has joined #openttd
13:05-!-frosch123 is "frosch" on #openttd
13:05<Eddi|zuHause>stackoverflow says "git fetch <remote> <srcBranch>:<destBranch>"
13:05<+glx>it's often possible to checkout another branch without stashing, but rebasing will be rejected
13:07<+glx>and if uncommited stuff is actually WIP I usually do a quick WIP commit
13:07<Eddi|zuHause>so in my case that would be "git fetch origin master:master"
13:07<Eddi|zuHause>where you would replace "origin" with "upstream"
13:10<+glx>ah yes seems to work
13:10<Samu>this code may look familiar:
13:10<Samu>repurposed it to be more "customizable"
13:11<+glx>comes from you auto snow height
13:12<Samu>auto desert now
13:13<andythenorth>disturbs me greatly
13:13<andythenorth>goes it throw out?
13:13<andythenorth>sorry :P
13:14<+glx>hmm I could update my rb command to also always update master
13:15<Samu>4 * 255 / 5 means "80%"
13:15<TrueBrain>glx: one thing I never understood, why update the master of your origin, like, ever? :D
13:15-!-jottyfan [] has quit [Quit: jottyfan]
13:15<TrueBrain>I wish GitHub forks were more lightweight .. just an empty git basically :)
13:15<Samu>i start new work based on the origin/master
13:16<Samu>so i prefer it to be updated
13:16<+glx>to have a clean version of master to test stuff
13:16<frosch123>TrueBrain: to test issue/pr templates and other gh stuff that only works in "master"
13:16<TrueBrain>glx: but you have upstream/master for that
13:16<TrueBrain>well, I meant origin/master btw, not master :)
13:16<Eddi|zuHause>TrueBrain: this is not about the master of your origin (the one on your personal github), but your local master
13:16<TrueBrain>frosch123: sure, we have those few edge-cases where we need it :) My only pushed to origin/master is to test that stuff, like the Preview stuff etc :)
13:17<TrueBrain>glx: owh, I misread you, you said master .. somehow I read origin/master :D
13:18<+glx>well usually I push it to origin/master ;)
13:18<TrueBrain>I see a lot of people doing that, and I cannot understand why :)
13:18*LordAro uses origin & fork, rather than upstream & origin
13:18<TrueBrain>hence me asking :)
13:18<Eddi|zuHause>TrueBrain: i said "origin", but that's because i'm weird
13:18<LordAro>saves pushing mistakes
13:18<TrueBrain>Eddi|zuHause: I was not talking about what-ever you were doing ;)
13:18<+glx>I use upstream for rebase only, so all push go to origin by default
13:19<TrueBrain>LordAro: I have the pretty much the other way around :P Pushing anything in origin is fine, which it tries by default ... makes sure I don't overwrite master on upstream for what-ever reason :D :D
13:19<+glx>especially push of master ;)
13:19<TrueBrain>but I guess it is also the reason I simply stopped pushing master, unless I have to work on those edge-cases
13:19<TrueBrain>most docs still write to push origin/master
13:19<TrueBrain>but never say why
13:19<TrueBrain>and for the life out of me, I cannot figure out why you would want to :)
13:20<TrueBrain>(again, besides for testing GitHub workflows etc :P)
13:20<LordAro>TrueBrain: hmm, yes
13:20<LordAro>i definitely made a conscious effort to switch from upstream/origin to origin/fork at some point
13:20<LordAro>it definitely solved some problem
13:20<LordAro>i'm sure of it
13:21<Eddi|zuHause>LordAro: yeah, that sounds more like what i'm doing
13:21<TrueBrain>what-ever works for you, I mean .. I have seen the strangest setups :P
13:21<TrueBrain>mostly why I ask about origin/master, is because we talked the other day it triggers CI runs
13:21<TrueBrain>but I still don't know why docs say you should push there :)
13:21<TrueBrain>feels like this pedantic thing everyone was thought to do, but nobody knows why :D
13:22<Eddi|zuHause>LordAro: i think for me that's mostly because i started out from the original checkout, where "origin" was already established, and added my fork on top of it later
13:22<TrueBrain>like, "clean up your room" :D
13:22<+glx>probably to allow forks of forks
13:22<TrueBrain>glx: yeah, that is fair
13:23<TrueBrain>with an active upstream, confusing, but I can see that as a reason
13:26<TrueBrain>hopefully GitHub continues there "disable workflows on forks" :D
13:26<TrueBrain>so much CPU time is fasted because of that
13:26<TrueBrain>fasted? wasted!
13:27<TrueBrain>still happy I found out I don't need a remote to fetch forks :D Saves adding a lot of remotes :D
13:32-!-tejanos [] has quit [Remote host closed the connection]
13:33<Samu>max desert height in action comparison
13:35<+glx>hmm I have too many remotes
13:35<Samu>1.10.3 sets it too high, resulting in less rainforest
13:36<Samu>notice Maximum map height: I put 255 there
13:36<Samu>now let me try 15
13:38-!-_2TallTyler [~oftc-webi@] has quit [Remote host closed the connection]
13:38<TrueBrain>glx: I had too till a few weeks ago .. was just randomly trying shit out, and found out it is not needed :P git can be very useful ... :D
13:41<Samu>interesting, there's much more desert on my intervention
13:42<TrueBrain>JGRPP is, compared to our master: 80k additions, 9k deletions :D
13:42<TrueBrain>in the last month we did in our master 10k additions and 10k delietions
13:43<TrueBrain>lot of the additions are because of 3rdparty libs btw
13:44<TrueBrain>well, "a lot" .. 6k :)
13:44<@DorpsGek>[OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
13:44<@DorpsGek> - Update: Translations from eints (by translators)
13:45<TrueBrain>wow, eints run on a moment we would like it to run .. sadly, that was not because we asked it to run at that time :P
13:45<TrueBrain>it only took 60 minutes between request and execution :D
13:45<TrueBrain>schedules are getting more and more out of hand :P
13:46<Samu>i need to compare this to current master, and not 1.10.3
13:47<Samu>still, "80%" might be too much desert
13:47<TrueBrain>JGRPP addss 67 new DoCommands :D
13:52<_dp_>hm... cmclient diff is +6149/-857
13:52<TrueBrain>1/10th :P
13:53<_dp_>the best 1/10th :p
13:53<TrueBrain>owh, another 4k in language difference
13:53<TrueBrain>still, massive amount of changes; most around a few features, by the looks of it
13:59<andythenorth>venn diagram!
13:59*andythenorth likes a venn diagram
13:59<andythenorth>especially a funny one
14:00<TrueBrain>_dp_: your last merge is weird to me; it says merge from upstream, but both sides are local changes :P
14:01<_dp_>TrueBrain, what are you even talking about?
14:02<TrueBrain>_dp_: I was looking in cmclient :)
14:02<TrueBrain>but it seems you make single commits to update the an upstream ref? (no judgement, just trying to understand :D)
14:03<_dp_>I'm not very good with git so I just do whatever xD
14:03<_dp_>also recently switched from hg so may be artifacts
14:03<_dp_>also upstream is
14:03<TrueBrain>I read "Merge remote-tracking branch 'upstream/master'", so I assumed that was merging in upstream, as in, us :)
14:04<TrueBrain>but that was clearly a wrong assumption :P
14:04<TrueBrain>how do cmbase and cmclient differ?
14:04<_dp_>cmbase is common code between cmclient and cmserver
14:04<TrueBrain>ah, they live in different repos
14:05<_dp_>yep, also there was no common code at all untill recently xD
14:05<TrueBrain>okay, I now understand why git was confused .. there is no common commit between us and your code :)
14:05<_dp_>it's also not a proper fork of openttd repo because I've no idea how to fork releases only
14:07<_dp_>so I just end up dumping every new release to and merging it from there
14:07<TrueBrain>if it works, it works!
14:08<TrueBrain>just confuses the fuck out of git, but .. who cares :P
14:08<TrueBrain>your repo is faster to check out ;)
14:16-!-DasPoseidon [~Thunderbi@2001:9e8:2052:4000:1d01:b0ce:2930:dd82] has joined #openttd
14:16-!-DasPoseidon is "DasPoseidon" on #openttd
14:40*andythenorth waves
14:40<andythenorth>from under a big pile of work
14:40<andythenorth>8am-midnight yesterday, 6am-10pm today probs
14:41<TrueBrain>good luck there
14:42<andythenorth>living my dream
14:42<andythenorth>at least I can't ask anyone to look at my newgrf spec eh :D
14:48<frosch123>i found two files from 2009 on my disk: they are examples of what is now action14, but using .ini and .xml
14:50<andythenorth>no .json?
14:50<andythenorth>or .yaml?
14:51<frosch123>i don't think i knew about yaml in 2009
14:51<andythenorth>I made a version of FISH using .cfg files
14:51<andythenorth>parsing that was so boring
14:51<frosch123>the other day some coworker claimed: json is only good for communication, persistent storage requires xml
14:52<andythenorth>I have heard the same argument actually
14:52<andythenorth>someone somewhere wrote something about it
14:52<frosch123>no idea, i just moved on :)
14:52<andythenorth>something something json is just a messaging format
14:52*andythenorth ignored
14:53<frosch123>making a distinction between messaging and storage is already religious
14:54<frosch123>space and time and so
14:54<andythenorth>April 1: 'nmlc is now xmlc'
14:54<frosch123>is the next live stream about nml?
14:54<frosch123>maybe we can fill 2 minutes with it :p
14:58<andythenorth>the rest can be Timberwolf explaining GoRender and multi-part vehicles :P
15:01<Timberwolf>"Start by wandering down to the crossroads where all the blues musicians are talking to the devil. Take the elevator down from there."
15:02<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8536: Feature: Choose a sensible window size on a fresh OTTD config file.
15:03-!-Tirili [~Tirili@2a02:8108:96bf:8438:260:6eff:fe42:7728] has quit [Quit: Leaving]
15:04<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8536: Feature: Choose a sensible window size on a fresh OTTD config file.
15:12-!-roadt__ [~roadt@] has quit [Ping timeout: 480 seconds]
15:13<frosch123>did openttd ever save the window position to restore it on next start? or did i dream that?
15:16<frosch123>no code for that in sdl1
15:16<Eddi|zuHause>i don't think that was ever a thing
15:17-!-roadt [~roadt@] has joined #openttd
15:17-!-roadt is "roadt" on #openttd #qemu
15:17<frosch123>ottd is annoying me for some time that it always opens on screen 0
15:18<frosch123>maybe sdl1 or some old wm behaved differently, and opened windows on the screen where the mouse is, who knows ...
15:18<frosch123>yeah, that's it. other applciations behave like that
15:19<frosch123>so, something in sdl2 forces it onto screeen 0
15:20<Eddi|zuHause>my observation is that almost all games open on screen 0, and almost all other programs open on wherever the mouse is
15:21<frosch123>factorio has a setting or command line option to set the start-up screen
15:31<@DorpsGek>[OpenTTD/OpenTTD] SamuXarick updated pull request #7918: Fix 3c047b1: AIGroup.GetProfitLastYear could get values different than those displayed in gui
15:33<Samu>i just noticed maximum initial loan can be set to £0
15:33<Samu>whoever thought that was a good idea?
15:35<frosch123>reimplemented that behavior in sdl2
15:35<frosch123>how do osx/windows behave?
15:35<frosch123>what screen do they pick?
15:35<+glx>can't say, I only have 1 screen
15:37<frosch123>LordAro: do we already have feature freeze? or can i approve 8536?
15:38<+glx>beta are just promoted nightlies IIRC
15:38<Eddi|zuHause>do we have a beta?
15:38<+glx>there's a draft PR :)
15:43<LordAro>frosch123: do what you like :p
15:43<LordAro>i'm not your mum
15:44<@DorpsGek>[OpenTTD/OpenTTD] frosch123 approved pull request #8536: Feature: Choose a sensible window size on a fresh OTTD config file.
15:46<TrueBrain>Lol @ LordAro :D
15:46-!-jottyfan [] has joined #openttd
15:46-!-jottyfan is "jottyfan" on #openttd
15:47<frosch123>no worries, i do not commit when drunk
15:47<TrueBrain>Its not even Friday!
15:48<frosch123>today was end of sprint. i only have to show new results in 4 weeks
15:48-!-DasPoseidon [~Thunderbi@2001:9e8:2052:4000:1d01:b0ce:2930:dd82] has quit [Remote host closed the connection]
15:49-!-jottyfan [] has quit []
15:51<Samu>what is the point of a max initial loan of £0?
15:51<frosch123>you don't approve scheduled procrastination?
15:51<Samu>game starts, companies have £0, can't build, only bankrupt?
15:53<Timberwolf>Only useful if you have some GS managing things.
15:53<+glx>Samu: game scripts yes
15:53<@DorpsGek>[OpenTTD/OpenTTD] michicc merged pull request #8536: Feature: Choose a sensible window size on a fresh OTTD config file.
15:53<+michi_cc>frosch123: Thanks
15:53<Samu>looks really weird to allow £0
15:53<Samu>but oka
15:54<TrueBrain>frosch123: in fact, fully approve :D
15:56<+michi_cc>How about #8537, BTW? I'd cull the OSX bit as there's no consensus on that part yet. Also, anyone know how the get DPI on SDL2?
15:58-!-gelignite [] has joined #openttd
15:58-!-gelignite is "realname" on #llvm #openttd
16:00<LordAro>michi_cc: needs andythenorth or orudge to test the osx ones
16:01<+michi_cc>OSX on #8537 works. It just doesn't make sense without #8519. I'm more interested in feedback about the principal itself.
16:04<TrueBrain>I think it is a very sensible thing to do
16:04<TrueBrain>And our users will let us know soon enough if I am wrong about that if we merge :p
16:06<+michi_cc>The mergable part is Windows, that works as I can properly test that myself. OSX would work as well, but is pointless without #8519.
16:08<+michi_cc>I don't know about SDL2. Apparently we don't even pass SDL_WINDOW_ALLOW_HIGHDPI to SDL_CreateWindow. Anybody running Linux with HiDPI scaling who can tell me what that pixel size results from that? There is SDL_GetDisplayDPI, but again makes only sense if OTTD is indeed running in native resolution.
16:09<TrueBrain>It might be best to do as you suggest, PR per OS
16:09<TrueBrain>Easy to merge, and we van figure out SDL when we found someone with high DPI :l
16:09<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8537: Feature: Automatic UI and font zoom levels.
16:09<TrueBrain>:p, not :l
16:09<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8537: Feature: Automatic UI and font zoom levels.
16:10<milek7_>michi_cc: I doubt SDL_WINDOW_ALLOW_HIGHDPI does anything on linux
16:11<milek7_>it sounds like something for macos/windows
16:11<+michi_cc>Still, is OpenTTD rendered at native resolution right now or not?
16:11<milek7_>it is
16:13<@DorpsGek>[OpenTTD/OpenTTD] frosch123 commented on pull request #8537: Feature: Automatic UI and font zoom levels.
16:14<milek7_>as far I know there it isn't anything like on windows/mac that OS can scale your app, it just always runs native
16:15<andythenorth>the downside of 8519 is that it further reduces mac performance on intel :)
16:15<andythenorth>I haven't tested it on ARM yet
16:16<andythenorth>mac intel is a dead platform though
16:17<andythenorth>we get a lot of free performance by telling mac users to save their pennies and upgrade
16:18<andythenorth> hoping for a 10-20x performance improvement when an M2 mac appears that I can buy
16:19<milek7_>michi_cc: hmm, looking at sdl sources apparently that flag changes something on Wayland
16:19<andythenorth>on my i9, 8519 reduces performance by about 50% using FFWD as the measure
16:20<andythenorth>with 8519, on a new map, no vehicles, FFWD is about 2.5x
16:21<andythenorth>1.10.2, new map, FFWD is about 5.5x
16:22<andythenorth>I can't be bothered to install build toolchain on M1 tonight, but the nightly build runs about 30x in FFWD
16:23<andythenorth>I guess 8519 will run about 15x, but eh, pure guessing
16:23<andythenorth>given that my i9 is the fastest non-M1 mac laptop available, many users might get worse performance with 8519
16:23<andythenorth>FFWD might...stop
16:24<+glx>I think we can trigger a release build for 8519 if needed
16:25<TrueBrain>Guess it renders 4 times more pixels, so isn't a slowdown to be expected?
16:26<+glx>of course it is :)
16:27<andythenorth>the game is really sharp when zoomed out
16:27<andythenorth>which is nice
16:27<andythenorth>but I don't know if players play much zoomed out
16:27<andythenorth> looks sick :)
16:28<TrueBrain>The other PR zooms it in again I guess? Does that balance performance again? If you go to 2x zoom?
16:29<+glx>only GUI is impacted I think, not the viwports
16:30<andythenorth>the 2x zoom appearance is identical to 10.x releases
16:30<TrueBrain>Performance too?
16:30<andythenorth>oh but the zoom levels don't quite translate
16:30<andythenorth>no performance is nerfed
16:30<andythenorth>4x on 8519 is same size on screen as 2x on 1.10.2
16:31<andythenorth>due to doubling of resolution I assume
16:31<TrueBrain>That is expected :)
16:31<TrueBrain>2x zoom draws 4x more pixels :p
16:32<andythenorth>the performance nerf is very subjective to the amount of sea on screen, currently testing both with full animation
16:32<andythenorth>if the screen is all sea, 8519 FFWD is about 1.5x
16:32<TrueBrain>With same amount of tiles on screen?
16:33<TrueBrain>(So one is zoomed in more than the other, in the settings)
16:35<andythenorth>I'm testing with full animation off now, which is around 100x faster
16:35<andythenorth>but highly variable
16:36-!-nielsm [] has quit [Remote host closed the connection]
16:37<andythenorth>the results between 1.10.2 and 8519 with full animation off are too variable to mean anything
16:38<andythenorth>both builds bounce around on FFWD between 70x and 700x game speed factor
16:38<andythenorth>no stability
16:38<Eddi|zuHause>i've no clue why, but my game speeds are more like 0.6x
16:38<@DorpsGek>[OpenTTD/OpenTTD] frosch123 opened pull request #8572: [SDL2] Start OpenTTD on the display where the mouse cursor is
16:38<TrueBrain>Disable AIs and GSes :p
16:39<Eddi|zuHause>it seems to be mostly display stuff
16:39<andythenorth>buy a mac :P
16:39<andythenorth>for the 'performance'
16:39<frosch123>cool, i get a 404 on submit, but when dorpsgek is happy, i am as well
16:39<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8537: Feature: Automatic UI and font zoom levels.
16:39*andythenorth imagines hell freezing over
16:39<frosch123>lol, "create PR" redirected me to an "/issues/" URL
16:40<andythenorth>anyway if 8519 comes with a hidden 'turn it off' switch maybe it should go in, dunno
16:40<+michi_cc>Will CI break if I push right again?
16:40<andythenorth>the other mac games I play tend to not be hidpi
16:40<milek7_>is this a bug in fps counter? :P
16:40<andythenorth>but they're actually using the GPU, and mac GPUs don't work
16:40<frosch123>michi_cc: i did that countless times before, nothing broke
16:40<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8537: Feature: Automatic UI and font zoom levels.
16:41<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on pull request #8537: Feature: Automatic UI and font zoom levels.
16:41<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8572: [SDL2] Start OpenTTD on the display where the mouse cursor is
16:41<TrueBrain>frosch123: I had that too the other day, was thinking it was me .. but seems GitHub has a bug :D
16:48-!-Progman [] has joined #openttd
16:48-!-Progman is "Peter Henschel" on #openttd
16:50<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8537: Feature: Automatic UI and font zoom levels.
16:52<andythenorth>nml -> m4nfo transpiler when? :)
16:52*andythenorth thinking of stations
16:53<frosch123>if i cared about nfo, i would have reimplemented grfcodec in python, using the nml sprite cache
16:56<Eddi|zuHause>andythenorth: what would be the use for that?
16:56<andythenorth>Eddi|zuHause which bit of 'stations' was ambiguous?
16:57<Eddi|zuHause>all of it
16:57<frosch123>Eddi|zuHause: it's a case of discord overdose
16:57<FLHerne>the 'm4nfo' bit :p
16:57<+michi_cc>Hmm, what is Win 32-bit doing on the CI?
16:57*andythenorth considers an artificially crafted python layer for m4nfo
17:00<@DorpsGek>[OpenTTD/OpenTTD] ldpl opened pull request #8573: Add tile parameter for GSCompany.ChangeBankBalance to show text effect if needed
17:02<Eddi|zuHause>andythenorth: whatever you're smoking, i want nothing to do with it
17:02<+glx>syntax error it says michi_cc
17:03<FLHerne>See, I *told* you Discord would be a bad influence
17:03<FLHerne>Next he'll be wanting in-game emojis
17:03<+michi_cc>Yes, but only on 32-bit it seems, which is strange as no type on that line is 64-bit specific.
17:04<+michi_cc>Hmm, it might be because we still default to a really old SDK version on 32-bit.
17:04<+michi_cc>glx: Is _MSC_VER also defined on MingW?
17:05<+glx>should not
17:05<@DorpsGek>[OpenTTD/OpenTTD] ldpl updated pull request #8573: Add tile parameter for GSCompany.ChangeBankBalance to show text effect if needed
17:06<frosch123>aw, i love the crappyness of msvc error messages
17:06<milek7_>that's just beauty of C defines :P
17:06<frosch123>usually "missing type specified - int assumed" means "missing #include"
17:07<Eddi|zuHause>what win32 version do we even compile for?
17:07<milek7_>could HMONITOR be missing from old sdk headers?
17:08<+michi_cc>Well, I'll try the same SDK version as 64-bit (which is Win XP). Current MSVC will not produce anything than runs on a lower version anyway.
17:08<frosch123>milek7_: try adding "#include <winuser.h"
17:08<+glx>I can confirm HMONITOR is not defined when trying to build x86-debug locally
17:09<frosch123>michi_cc: try adding "#include <winuser.h"
17:09<+michi_cc>milek7_: Yep, seems so. "#if(WINVER >= 0x0500)"
17:10<+michi_cc>Which is a bit strange as monitors are not really a new concept, but oh well.
17:10<frosch123> <- that says windows 2000
17:10<+glx>WINVER = 0x0400 for x86
17:10<frosch123>but win32_v.cpp does not explicitly include winuser.h
17:11<+glx>haha stdafx.h:173
17:12<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #8537: Feature: Automatic UI and font zoom levels.
17:13<+michi_cc>Not anymore. WINVER 0x0400 is stupid with MSVC 2017/2019 anyway.
17:14<+glx>frosch123: but msdn tends to lie about minimal version, everything is win2000 minimum now
17:15<+michi_cc>Maybe the HMONITOR is new and on old SDKs it was just a generic HANDLE.
17:15-!-Progman [] has quit [Remote host closed the connection]
17:16<frosch123>glx: i would hope that only applies to even older functions. or do they list stuff added in vista as available in 2000?
17:16<+glx>every thing that was available before 2000 no says minimum 2000
17:17<+glx>even if it was introduced in win85
17:19<+michi_cc>We include windows.h, and that includes winuser.h itself.
17:19<+michi_cc>Okay, bump SDK version to something proper helped.
17:19<+glx>the file is included, but HMONITOR declaration is guarded
17:22<+glx>oh we droped win9x some time ago anyway
17:22<+glx>since old mingw doesn't support recent c++
17:23<Samu>I retried doing this,
17:23<Samu>stumbled upon autoreplace again
17:28<Samu>was gonna say to test this alternative, but it requires a script
17:28<Samu>im running out of time today
17:29<Samu>when autoreplacing an old vehicle with a new one, that assert will trigger
17:29<@DorpsGek>[OpenTTD/OpenTTD] frosch123 merged pull request #8572: [SDL2] Start OpenTTD on the display where the mouse cursor is
17:29<Samu>cyas good night
17:29-!-Samu [] has quit [Quit: Leaving]
17:31<Eddi|zuHause>glx: according to a recent forum thread, 1.8 was the last release for win9x
17:31<+glx>so yes we can safely target XP as minimum
17:39<andythenorth>oof le naptime
17:39-!-andythenorth [] has quit [Quit: andythenorth]
17:42<frosch123>huh, regression_stationlist randomly failed?
17:42<frosch123>only win64
17:42<frosch123>let's assume it will vanish on its own :p
17:47-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
18:03-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:11-!-sla_ro|master [slamaster@] has quit []
18:57<@DorpsGek>[OpenTTD/OpenTTD] 2TallTyler opened pull request #8574: Feature: Ships stop to be passed by another ship
19:12<@DorpsGek>[OpenTTD/OpenTTD] 2TallTyler updated pull request #8574: Feature: Ships stop to be passed by another ship
19:12-!-Wormnest [~Wormnest@] has quit [Quit: Leaving]
19:27-!-SmatZ [] has quit [Server closed connection]
19:28-!-SmatZ [] has joined #openttd
19:28-!-SmatZ is "Zdenek Sojka" on #openttd.notice #openttd.noai #openttd
19:34-!-gelignite [] has quit [Quit: Stay safe!]
19:37-!-kevin [~oftc-webi@] has joined #openttd
19:37-!-kevin is "OFTC WebIRC Client" on #openttd
19:37-!-kevin is now known as Guest10484
19:40-!-Guest10484 [~oftc-webi@] has left #openttd []
19:41-!-kevin_ [~oftc-webi@] has joined #openttd
19:41-!-kevin_ is "OFTC WebIRC Client" on #openttd
20:16-!-kevin_ [~oftc-webi@] has quit [Quit: Page closed]
20:33-!-Lejving_ [] has joined #openttd
20:33-!-Lejving_ is "realname" on #openttd #/r/openttd #factoriocoop #openttdcoop.pz
20:36-!-Lejving [] has quit [Ping timeout: 480 seconds]
21:01-!-aliasbkilgrinhu[m] [~bkilmatri@2001:470:1af1:101::6529] has joined #openttd
21:01-!-aliasbkilgrinhu[m] is "" on #openttd #friendica #C
21:09-!-Flygon [~Flygon@2001:44b8:411e:4e00:d84b:5c74:a18f:1f13] has joined #openttd
21:09-!-Flygon is "Flygon" on #openttd
21:52-!-orudge [] has quit [Server closed connection]
21:52-!-orudge [] has joined #openttd
21:52-!-orudge is "Owen Rudge" on @#thesinner @#bukkit @#jontylog @#tycoonexiles @#z.aud @#locomotion @#transportempire #openttd
22:08-!-debdog [~debdog@2a00:79c0:600:bf00:7a24:afff:fe8a:d04d] has joined #openttd
22:08-!-debdog is "Wowbagger" on #openttd
22:12-!-D-HUND [~debdog@2a00:79c0:62a:6600:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:25-!-heffer [] has quit [Quit: heffer]
22:25-!-heffer [] has joined #openttd
22:25-!-heffer is "Felix Kaechele" on #openttd
22:51-!-glx [] has quit []
22:58-!-berndj [] has quit [Server closed connection]
22:59-!-berndj [] has joined #openttd
22:59-!-berndj is "Bernd Jendrissek" on #osm-za #openttd #oftc
23:37-!-SpComb [] has quit [Server closed connection]
23:37-!-SpComb [] has joined #openttd
23:37-!-SpComb is "Tero Marttila" on #oftc #bitlbee #openttd
23:42-!-supermop_Home_ [] has quit [Remote host closed the connection]
---Logclosed Fri Jan 15 00:00:55 2021