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

Powered by YARRSTE version: svn-trunk