Back to Home / #openttd / 2021 / 02 / Prev Day | Next Day
#openttd IRC Logs for 2021-02-15

---Logopened Mon Feb 15 00:00:39 2021
00:22-!-WormnestAndroid [~WormnestA@] has quit [Remote host closed the connection]
00:24-!-WormnestAndroid [~WormnestA@] has joined #openttd
00:24-!-WormnestAndroid is "WormnestAndroid" on #openttd
02:19-!-snail_UES_ [] has quit [Quit: snail_UES_]
02:30-!-andythenorth [] has joined #openttd
02:30-!-andythenorth is "andythenorth" on #openttd
02:36-!-Wolf01 [] has joined #openttd
02:36-!-Wolf01 is "Wolf01" on #openttd
02:55-!-sla_ro|master [] has joined #openttd
02:55-!-sla_ro|master is "slamaster" on @#sla #openttd
03:06-!-HerzogDeXtEr [] has joined #openttd
03:06-!-HerzogDeXtEr is "purple" on #openttd
03:24-!-heffer [] has quit [Quit: heffer]
03:24-!-heffer [] has joined #openttd
03:24-!-heffer is "Felix Kaechele" on #openttd
04:05-!-jottyfan [] has joined #openttd
04:05-!-jottyfan is "jottyfan" on #openttd
04:09-!-jottyfan [] has quit []
04:10-!-jottyfan [] has joined #openttd
04:10-!-jottyfan is "jottyfan" on #openttd
04:26-!-jottyfan [] has quit [Quit: jottyfan]
04:40-!-Eddi|zuHause2 is now known as Eddi|zuHause
05:08-!-jottyfan [] has joined #openttd
05:08-!-jottyfan is "jottyfan" on #openttd
06:08-!-Samu [] has joined #openttd
06:08-!-Samu is "realname" on #openttd
06:51<@DorpsGek>[OpenTTD/OpenTTD] orudge opened pull request #8675: Fix: [Actions] Use vcpkg to provide libpng on macOS
06:52<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8675: Fix: [Actions] Use vcpkg to provide libpng on macOS
07:04-!-virtualrandomnumber [] has joined #openttd
07:04-!-virtualrandomnumber is "virtualrandomnumber" on #openttd #/r/openttd
07:04-!-virtualrandomnumber [] has quit []
07:07-!-jottyfan [] has quit [Quit: jottyfan]
07:10<@DorpsGek>[OpenTTD/OpenTTD] orudge merged pull request #8675: Fix: [Actions] Use vcpkg to provide libpng on macOS
07:27-!-Samu [] has quit [Read error: Connection reset by peer]
07:28-!-Samu [] has joined #openttd
07:28-!-Samu is "realname" on #openttd
07:38<@DorpsGek>[OpenTTD/OpenTTD] grossws commented on pull request #7851: Change: add support for next/previous railtype global hotkeys
07:55<@DorpsGek>[OpenTTD/OpenTTD] grossws updated pull request #7851: Change: add support for next/previous railtype global hotkeys
07:56<@DorpsGek>[OpenTTD/OpenTTD] grossws commented on pull request #7851: Change: add support for next/previous railtype global hotkeys
07:56-!-roadt__ [~roadt@] has joined #openttd
07:56-!-roadt__ is "roadt" on #openttd
08:03-!-roadt_ [~roadt@] has quit [Ping timeout: 480 seconds]
08:05-!-WormnestAndroid [~WormnestA@] has quit [Read error: Connection reset by peer]
08:05-!-WormnestAndroid [~WormnestA@] has joined #openttd
08:05-!-WormnestAndroid is "WormnestAndroid" on #openttd
08:07<_dp_>hm, I just found that HQ produces way less cargo than it was supposed to
08:07<_dp_>or who the hell knows actually since it seems hq was supposed to produce as 256 pop house but houses weren't supposed to produce quadratic amounts
08:08<_dp_>anyway, looks like CS bug so call in a feature :p
08:10<_dp_>basically houses produce as population**2 but hq as 4*((population /4)**2) xD
08:11<Eddi|zuHause>and where do you take the 256 figure from?
08:12<_dp_>comment was added later ofc but it seems to match the intention
08:18<_dp_>though I've no idea how comments in r975 come to be
08:24<Eddi|zuHause>so what was meant was that since it's 4 tiles, each tile adds 1/4th of the total, and the "wrong" part is the **2-ness of the formula
08:25<Eddi|zuHause>but how does that compare to regular 2x2 houses?
08:26<_dp_>regular houses only produce from one tile
08:27<Eddi|zuHause>anyway, the whole thing seems fine, except it should apply the same linearization as was done with houses, and "amt = (amt + 1) >> 1" should do "/2" instead of ">>1"
08:28<Eddi|zuHause>_dp_: are you sure? the tileloop will hit each tile of the 2x2 house at different points
08:28<_dp_>pretty sure, one one part of house has population iirc
08:30<_dp_>yeah, you can even inspect that in game
08:31<_dp_>newgrf callback though gets called for each tile so everything is possible
08:32<_dp_>* one one -> only one xD
08:33-!-sla_ro|master [] has quit []
08:34<Eddi|zuHause>yeah, src/table/town_land.h lists the tiles individually with 3 tiles as 0 population
08:35<Eddi|zuHause>but that's just a specific implementation detail of the original houses
08:35<Eddi|zuHause>not a general spec thing
08:36<Eddi|zuHause>so even without callback, newgrf houses can just set non-zero population for each house part
08:37<_dp_>well, yeah, but it's kind of irrelevant here
08:37<_dp_>I doubt hq was supposed to produce as 128+128 house or smth :p
08:38<_dp_>well, 64x4 in this case
08:38<Eddi|zuHause>well, if the formula had been linear in the first place, that would be equivalent
08:38<Eddi|zuHause>and possibly easier than trying to figure out which part of the HQ you hit
08:39<Eddi|zuHause>"if (o->location.tile == tile)" <-- well, it might actually be easy enough :p
08:40<_dp_>oh, and btw, recession does nothing to hq production except for the highest level one xD
08:40<_dp_>because (1+1)/2 == 1
08:40<Eddi|zuHause>why would lower levels only produce 1?
08:41<_dp_>coz... math? :p
08:41<_dp_>only highest have production of 2
08:41<Eddi|zuHause>i think your math is off
08:42<_dp_>look carefully, amt is always <= 1 if level != 5
08:42<_dp_>it only enters if on small numbers and then divides it to 0
08:42<Eddi|zuHause>i think your math is off
08:43<Eddi|zuHause>r is between 0 and 255
08:43<_dp_>if (x<32) amt = x/32
08:43<Eddi|zuHause>you check r against 256/4/6
08:43<Eddi|zuHause>and then set amt = r/8/4
08:45<Eddi|zuHause>actually, /5 because minimum level appears to be 1
08:45<_dp_>whatever, even 256/4/2 is already 32 :p
08:48<Eddi|zuHause>ok, that is a bit weird
08:53<Eddi|zuHause>anyway, that's a side effect of passengers trickling in by individual tiles in general, instead of industries which deliver in large chunks
08:53<Eddi|zuHause>nothing to really worry about
08:54<Eddi|zuHause>just means in a recession people still need to go places :)
09:24-!-andythenorth [] has quit [Quit: andythenorth]
09:29-!-supermop_Home [] has joined #openttd
09:29-!-supermop_Home is "Guest" on #openttd
09:31-!-nielsm [] has joined #openttd
09:31-!-nielsm is "Niels Martin Hansen" on #openttd
09:53-!-Wuzzy [] has joined #openttd
09:53-!-Wuzzy is "Wuzzy" on #openttd
09:57-!-andythenorth [] has joined #openttd
09:57-!-andythenorth is "andythenorth" on #openttd
10:03<@DorpsGek>[OpenTTD/OpenSFX] Wuzzy2 commented on pull request #19: Replace Mercurial code with Git code
10:05<Wuzzy>OpenSFX PR awaiting review:
10:05<Wuzzy>Spreaking of OpenSFX...
10:05<Wuzzy>when #14 is merged, the official description of OpenSFX will change as well. however, it is translated (lang/ directory)
10:06<Wuzzy>the question is... what to do with all the translations then?
10:11<Eddi|zuHause>i think i said this yesterday: discard the translations, and announce at the forums that new ones are needed
10:16<Eddi|zuHause>i don't think eints integration would be particularly desirable
10:28-!-Progman [] has joined #openttd
10:28-!-Progman is "Peter Henschel" on #openttd
10:33-!-Flygon [~Flygon@2001:44b8:411e:4e00:fcb4:db6:cb31:4dd5] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
10:34<Wuzzy>yeah, i had the same idea. sounds the most reasonable
10:51-!-gelignite [] has joined #openttd
10:51-!-gelignite is "realname" on #llvm #openttd
11:17<Wolf01>So, yesterday I think I removed too much, but it shouldn't be a problem, the min .net version I still have installed is 4.6.1 and all the stuff seem to work fine, I just needed to update a project which referenced 4.5
11:18<Wolf01>At least now I added ~20GB to the free space :P
11:20-!-glx [] has joined #openttd
11:20-!-glx is "Loïc GUILLOUX" on #openttd
11:20-!-mode/#openttd [+v glx] by ChanServ
11:20<Wolf01>Too bad I can't remove VS2017 too... 2019 doesn't support at all the windows mobile platform
11:23-!-Speeder [~Speeder@2804:14d:ac83:45aa:9ca1:e75b:459b:2aa4] has joined #openttd
11:23-!-Speeder is "realname" on #openttd
11:26<+glx>for openttd both should work
11:29<Wolf01>Oh damn... still errors even with VS2019... can't find embed.manifest
11:30<+glx>hmm current master ?
11:30<Wolf01>No, I need to pull
11:31<Wolf01>Btw, why cmake compiles on my user folder instead of using the other HDD with a lot of free space?
11:32<+glx>I guess you somehow did a clean/rebuild and use source from before 99448eedc (10 days ago)
11:33<+glx>cmake defaults to user folder, but it's all configurable
11:33<+glx>via GUI or CMakeSettings.json
11:34<+glx>until you update source to recent, you can just restore os/windows/openttd.manifest
11:34<+glx>cmake deletes it on clean due to a mistake
11:35<Wolf01>Ok, it compiled now and started
11:36<Wolf01><glx> via GUI or CMakeSettings.json <- I found the folder path (which doesn't even exists) but no other configs related to the compile path
11:38<+glx>'buildRoot' in json
11:38-!-gelignite [] has quit [Quit: Stay safe!]
11:38<+glx>I set it to ${projectDir}/out/build/${name}
11:40<Wolf01>Oh right, it's everything under "manage configurations" now
11:42<+glx>yeah and default configuration is debug
11:42<Wolf01>Yes, I only have that one
11:43<+glx>you can clone it and change build type to RelWithDebInfo
11:44<Wolf01>Nah, debug is fine for me :P
11:44<+glx>debug runs slow
11:44<Wolf01>I don't need to benchmark the game, there is Samu for that :P
11:44<+glx>I have 17 configurations ;)
11:45<+glx>basic x64 and x86 (both debug and release), then another 4 using clang
11:46<+glx>mingw64 debug and release, arm64 debug and release
11:46<+glx>a debug x64 using vs2017 toolchain
11:47<Wolf01>Not bad
11:47<+glx>and x64 non static debug and release
11:47<+glx>but I mostly use x64-debug
11:58-!-sla_ro|master [] has joined #openttd
11:58-!-sla_ro|master is "slamaster" on @#sla #openttd
12:02-!-smoke_fumus [~smoke_fum@] has joined #openttd
12:02-!-smoke_fumus is "KVIrc 5.0.0 Aria" on #qemu #oolite #openttd
12:25-!-frosch123 [] has joined #openttd
12:25-!-frosch123 is "frosch" on #openttd
12:33-!-gelignite [] has joined #openttd
12:33-!-gelignite is "realname" on #llvm #openttd
12:36-!-Wormnest [~Wormnest@] has joined #openttd
12:36-!-Wormnest is "Wormnest" on #openttd
12:39-!-snail_UES_ [] has joined #openttd
12:39-!-snail_UES_ is "Jacopo Coletto" on #openttd
13:01-!-Wormnest_ [~Wormnest@] has joined #openttd
13:01-!-Wormnest_ is "Wormnest" on #openttd
13:08-!-Wormnest [~Wormnest@] has quit [Ping timeout: 480 seconds]
13:11-!-Wormnest [~Wormnest@] has joined #openttd
13:11-!-Wormnest is "Wormnest" on #openttd
13:15-!-Cursarion [] has quit [Ping timeout: 480 seconds]
13:17-!-Cursarion [] has joined #openttd
13:17-!-Cursarion is "R.K." on #openttd
13:18-!-Wormnest_ [~Wormnest@] has quit [Ping timeout: 480 seconds]
13:43-!-Wuzzy [] has quit [Read error: Connection reset by peer]
13:47-!-Wormnest_ [~Wormnest@] has joined #openttd
13:47-!-Wormnest_ is "Wormnest" on #openttd
13:52-!-Wormnest [~Wormnest@] has quit [Ping timeout: 480 seconds]
14:02<@DorpsGek>[OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
14:02<@DorpsGek> - Update: Translations from eints (by translators)
15:44<@DorpsGek>[OpenTTD/OpenTTD] Ufiby opened issue #8676: Unable to open the setting
15:45<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on issue #8676: Unable to open the setting
15:46<Wolf01>Yup, it asserts
15:46<+glx>let's check
15:47<LordAro>must be a recent change
15:48<LordAro>possibly the world gen reorganise?
15:48<+glx>probably yes
15:48<+glx>starting the exe to trigger it
15:49<@DorpsGek>[OpenTTD/OpenTTD] Ufiby commented on issue #8676: Unable to open the setting
15:51<+glx>confirmed assert
15:52<+glx>related to gui.zoom_min
15:52<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on issue #8676: Unable to open the setting
15:54<+glx>let's add some breakpoints
15:59<@DorpsGek>[OpenTTD/OpenTTD] Ufiby commented on issue #8676: Unable to open the setting
15:59<+glx>oh setting changed name
16:03<+glx>ah no they moved
16:03<+glx>should not be an issue in theory
16:04<Wolf01>Maybe it doesn't create the default?
16:04<LordAro>be nicer if you could get something to warn/error at compile time
16:04<Wolf01>Looking at the comments it doesn't work even with a fresh config
16:04<+glx>it doesn't find the setting
16:05<FLHerne>Wolf01: I'm not sure if that comment is "I tried and it didn't work" or "I'm sure it won't work"
16:05<+glx>I think I know which commit breaks, checking
16:05<LordAro>it indeed makes no difference though
16:06<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on issue #8676: Unable to open the setting
16:07<+glx>probably but I need to confirm
16:08<Wolf01>Il looks there is something weird on that setting
16:09<Wolf01>Like $var in place of $name and missing $var parameter
16:09<Wolf01>Oh different setting type
16:11<+glx>commit in itself looks good, other parts of the code except settings window work
16:11<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on issue #8676: Unable to open the setting
16:11<andythenorth>nice issue title :)
16:12<LordAro>andythenorth: settings causes accident!
16:12<andythenorth>goes it throw out
16:13<+glx>f5555a6d2 works
16:14<LordAro>so what's been forgotten?
16:15<LordAro>what makes a setting "early load"?
16:16<frosch123>"early load" are settings in misc_settings
16:17<frosch123>they are loaded before grfscan
16:17<frosch123>i.e. needed to display the basic intro screen
16:17<frosch123>and probably bootstrap
16:17<+glx>confirmed it's a2c3197f424
16:18<frosch123>the zoom settings are the first SDTC_ in misc_Settings
16:19<frosch123>everything else in misc_setting are global variables outside the settings struct
16:19<+glx>yup seems they are not in _settings
16:20<frosch123>ah, the crash is because there is no "name="
16:20<frosch123>so much magic :p
16:21<+glx>well name is replaced by var in the macro
16:25<+glx>of course they are in _misc_settings[] now
16:25<+glx>and not in _settings[]
16:26<frosch123>so none of misc_settings work in console or in the tree?
16:27<+glx>hmm something looks wrong in setting table
16:27<+glx>let's try a modification in .ini
16:28<frosch123>i see in the debugger, that there is a "gui.zoom_min" in _misc_settings
16:28<frosch123>but GetSettingFromName and friends only care about _settings
16:29<frosch123>so neither console nor tree work for _misc_settings
16:30<frosch123>and i have no idea whether they were intentionally left out :)
16:30<+glx>I think it's intentionnal, based on the settings in misc
16:32<frosch123>this looks difficult to me :p
16:33<frosch123>i would now try to merge _misc_settings into _settings
16:33<frosch123>or similar
16:33<+glx>and it's the first non global put in misc
16:34<+glx>I wonder if it even save/load correctly from cfg
16:35<frosch123>the ini load/save is the only place that uses _misc_settings
16:35<frosch123>what would break if we move all _misc_settings into _settings as client settings?
16:35<frosch123>and add some gui_flag or similar for the early-load
16:43<frosch123>i think that's the best solution. other ideas?
16:43<frosch123>remove misc_settings, put all of them into _settings. add some flag for early load
16:44<frosch123>that way GetSettingFromName can return a index into _settings for them
16:44<frosch123>and SetSettingValue and IConsoleSetSetting work
16:45<frosch123>there are probably some traps with settings like "graphicsset", which have string data
16:45<frosch123>i believe no other settings have string data
16:46<+glx>there's also _gameopt_settings with SC_ category while they are not in the settings window
16:47<frosch123>i think we added SC_ to everything, no matter whether in tree or not
16:47<frosch123>second suggestion: keep _misc_settings, but add an early-load flag to _settings nevertheless, and them move the zoom settings back to _settings
16:48<frosch123>less risky
16:49<+glx>I'm quite sure the value in [gui] section are not loaded anyway, as misc_settings should read only [misc] section
16:54-!-Samu [] has quit [Quit: Leaving]
16:55<frosch123>no, "misc" is just the default for settings without a "." in their name
16:55<+glx>ah yes (looking at the code)
16:56<frosch123>that's where i got the info from :p
16:56<+glx>yeah I was in the loading code when you mentioned the "."
17:01<+glx>second suggestion looks sane
17:02<+glx>and replacing basic_setting and other settings in HandleSettingDescs with a bool parameter in loading proc
17:03<frosch123>do you remember a setting that requires late loading?
17:03<frosch123>except for the obvious GRFLoadConfig, AILoadConfig and GameLoadConfig
17:05<frosch123>so, third solution: load all _settings early?
17:06<+glx>looking at all LoadFromConfig() calls
17:06<frosch123>those in 1755-1771 i understand
17:06<frosch123>but no idea why HandleSettingDescs makes such a deal of loading some settings late
17:07<+glx>yeah I think it could always load all, except misc, unless at startup
17:08<+glx>as anyway they will be reloaded after grf scan
17:08<frosch123>you probably are only allowed to load them once. but i think you can load all of them early
17:08<frosch123>there are some comments about custom currency and other weird things
17:09<+glx>I see 3 calls, one in main (the early load), one after grf scan, and a last one for servers
17:10<+glx>so basically even the early load could load everything
17:12<+glx>it was probably some kind of optimisation to not reload multiple times the same thing
17:13<frosch123>but does it need reloading? can HandleSettingDescs just only run for "minimal"?
17:19<frosch123>night, and good luck :)
17:19-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
17:20<+michi_cc>Lots of changed lines for what should be the second suggestion:
17:21<+glx>oh I think we can always load them,
17:21<+glx>minimal or not
17:23<+glx>still compiling (and not tested yet) but should work
17:24<+glx>and probably all other !minimal settings could be always loaded too
17:24<+michi_cc>Probably. In the end, what bad is supposed to happen when loading an integer value twice?
17:25<+glx>in workflow I can see load minimal, scan newgrf, load other
17:25<+glx>and load other happen after each newgrf scan
17:26<+glx>so maybe we just need to take care to not overwrite these 2 gui. value, like we do for newgrf count
17:31-!-nielsm [] has quit [Ping timeout: 480 seconds]
17:32<+michi_cc>Do you expect the cfg value to change somehow? Otherwise overwriting an integer with itself is totally fine.
17:32<+glx>not the cfg, but if user changed the setting before downloading a newgrf
17:33<+glx>well it's like other settings in this case I guess
17:42-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
17:45<+glx>oh config is always saved on setting change once at least a newgrf scan is done
17:45<+glx>so we should be safe
17:58-!-smoke_fumus [~smoke_fum@] has quit [Quit: KVIrc 5.0.0 Aria]
18:02<+glx>hmm it seems moving UpdateGUI() call in ottd_main after grf scan could be enough to not require early loading
18:03<+glx>but I guess it's before so the progress bar is properly scaled
18:05<+michi_cc>Yeah, if you do it then the grf scan bar will not be scaled and the title game zoom might jump after the scan.
18:09-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
18:11<@DorpsGek>[OpenTTD/OpenTTD] glx22 opened pull request #8677: Fix #8676: Revert a2c3197f4 and unconditionally load settings "early"
18:12-!-sla_ro|master [] has quit []
18:13<+michi_cc>Just in case there is a problem with the load early: would keep the current beaviour I think.
18:17<+glx>I like your version too
18:18-!-Progman [] has quit [Remote host closed the connection]
18:20<@DorpsGek>[OpenTTD/OpenTTD] glx22 commented on pull request #8677: Fix #8676: Revert a2c3197f4 and unconditionally load settings "early"
18:22-!-gelignite [] has quit [Quit: Stay safe!]
18:24<@DorpsGek>[OpenTTD/OpenTTD] michicc opened pull request #8678: Fix #8676: GUI-visible settings may not be part of misc settings.
18:24<+michi_cc>Well, I let somebody else battle this out :p
18:24<+glx>we provide options :)
18:25<+michi_cc>Also night :)
18:31<@DorpsGek>[OpenTTD/OpenTTD] glx22 commented on pull request #8678: Fix #8676: GUI-visible settings may not be part of misc settings.
18:49-!-azubieta [] has quit [Quit: The Lounge -]
18:50-!-azubieta is "azubieta" on #debian
18:50-!-azubieta [] has joined #openttd
18:53-!-glx [] has quit []
19:09-!-andythenorth [] has quit [Quit: andythenorth]
19:23<@DorpsGek>[OpenTTD/OpenTTD] LC-Zorg commented on issue #8594: NRT - Pathfinder doesn't consider speed limits when calculating a route
19:34<supermop_Home>that looks complicated
19:35<supermop_Home>i'll be down for any system that enforces a low speedlimit for dirt roads - except for rally cars which get to go 100mph
20:14-!-Wormnest_ [~Wormnest@] has quit [Quit: Leaving]
21:15-!-TrueBrain [] has quit [Ping timeout: 480 seconds]
21:16-!-TrueBrain [] has joined #openttd
21:16-!-TrueBrain is "" on #dorpsgek-test #openttd #dorpsgek
21:17<@DorpsGek>[OpenTTD/OpenTTD] perezdidac updated pull request #8603: Feature: Object class selection string filtering
21:18<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering
21:19<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering
21:19<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering
21:19<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering
21:19<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering
21:20<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering
21:20<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering
21:20<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8603: Feature: Object class selection string filtering
21:32-!-Flygon [~Flygon@2001:44b8:411e:4e00:edcd:e819:4285:25e8] has joined #openttd
21:32-!-Flygon is "Flygon" on #openttd
21:32<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on pull request #8603: Feature: Object class selection string filtering
22:24<@DorpsGek>[OpenTTD/OpenTTD] joestringer opened pull request #8679: Fix: [Cygwin] Fix missing uint definition
22:31-!-D-HUND [~debdog@2a00:79c0:602:f700:7a24:afff:fe8a:d04d] has joined #openttd
22:31-!-D-HUND is "Wowbagger" on #openttd
22:34-!-debdog [~debdog@2a00:79c0:62d:c900:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:37<@DorpsGek>[OpenTTD/OpenTTD] joestringer updated pull request #8679: Fix: [Cygwin] Fix missing uint definition
23:57-!-D-HUND is now known as debdog
---Logclosed Tue Feb 16 00:00:41 2021