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

---Logopened Sun Feb 21 00:00:48 2021
01:16<@DorpsGek>[OpenTTD/OpenTTD] reldred commented on pull request #8480: Multitile depots
01:36-!-snail_UES_ [] has quit [Quit: snail_UES_]
02:02-!-muffindrake [] has joined #openttd
02:02-!-muffindrake is "muffindrake" on #openttd
02:51-!-nielsm [] has joined #openttd
02:51-!-nielsm is "Niels Martin Hansen" on #openttd
02:54-!-didac [] has quit [Remote host closed the connection]
03:14-!-Wolf01 [] has joined #openttd
03:14-!-Wolf01 is "Wolf01" on #openttd
03:16-!-andythenorth [] has joined #openttd
03:16-!-andythenorth is "andythenorth" on #openttd
03:18-!-jottyfan [] has joined #openttd
03:18-!-jottyfan is "jottyfan" on #openttd
03:24-!-jottyfan [] has quit [Quit: jottyfan]
04:00-!-jottyfan [] has joined #openttd
04:00-!-jottyfan is "jottyfan" on #openttd
04:10-!-Progman [] has joined #openttd
04:10-!-Progman is "Peter Henschel" on #openttd
04:17<TrueBrain>W00p, another reply from someone who clearly did not start the game to test :)
04:18<TrueBrain>It surprises me that seems to be the most difficult to people :p
04:18<TrueBrain>Also shows how little people really care about that climate :D
04:19-!-HerzogDeXtEr [] has joined #openttd
04:19-!-HerzogDeXtEr is "purple" on #openttd
04:20<andythenorth>TrueBrain "I've heard you're planning to kill babies"
04:20<andythenorth>"I'd just like to say that I don't agree"
04:32<TrueBrain>currently it reads more like: "I've heard you're planning to eat pancakes - I'd just like to say that I don't agree" :)
04:32<andythenorth>I don't like your socks
04:33<andythenorth>actual thing btw
04:37<TrueBrain>"Will you still be supporting BaNaNaS, or there are plans to implement the support of the Steam Workshop, try and encourage the grf creators to move there and then pull the plug on BaNaNaS for good? "
04:37<TrueBrain>I love clear questions
04:37<TrueBrain>allow for clear answers
04:38<TrueBrain> for reference
04:38*andythenorth seriously considering Iron Horse trading cards
04:39<andythenorth>make Snap! card game from
04:41<andythenorth>custom card printing is a thing
04:44<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges
04:50-!-gelignite [] has joined #openttd
04:50-!-gelignite is "realname" on #llvm #openttd
05:01<TrueBrain>ugh, I need to be able to compile OpenTTD faster ...
05:03<andythenorth>me too
05:04<andythenorth>that bisecting yesterday was painful
05:04<andythenorth>so useful though
05:05-!-Progman [] has quit [Remote host closed the connection]
05:06<LordAro>get a threadripper
05:08<andythenorth>how long do compiles take?
05:09*andythenorth can't be bothered to time one :P
05:09<andythenorth>seems like about 2 mins
05:09<TrueBrain>LordAro: I did consider it. Then I was like, maybe I should get a job first :P
05:10<TrueBrain>but mostly LTO is just annoying ..
05:15<TrueBrain>okay, space in folder works fine for Linux
05:15<nielsm>newgrf.cpp is gigantic and should be split up in some way
05:15<TrueBrain>lets test Windows ...
05:16<andythenorth>delete newgrf.cpp? :)
05:17<andythenorth>simplify lives of content authors
05:17<LordAro>nielsm: i've thought about putting all the newgrf* files in their own folder before
05:17<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain commented on issue #8687: CMake include error when building new project.
05:18<TrueBrain>adding folders in general would be lovely
05:18<TrueBrain>as the root folder is just too darn long to scroll through
05:29<andythenorth>so because you don't all read forums
05:29<andythenorth>this is really good
05:29<andythenorth>(there is a newgrf 'high speed' contest running)
05:31-!-sla_ro|master [] has joined #openttd
05:31-!-sla_ro|master is "slamaster" on @#sla #openttd
05:35<FLHerne>andythenorth: !!!
05:36<andythenorth>outstanding use of unreleased feature at the end
05:37<Wolf01>The hovercraft at the end
05:37<TrueBrain>the stuttering, aarrrghhh .. we should fix that ..
05:38<Wolf01>TB: I should check better, but I think I noticed some mouse pointer lag at the title screen, but not in game
05:39<TrueBrain>there is no render-difference between title screen and in-game
05:39<TrueBrain>so that would be a bit odd
05:39<Wolf01>In game it really disappear when I move it fast
05:39<andythenorth>I so love this stuff
05:39<TrueBrain>but make sure you test with latest master :)
05:39<andythenorth>so much fun, so much better than arguing with net-negative contributors about boring crap
05:40*Wolf01 recompiling
05:40<FLHerne>"If TrueBrain really did have graphics and code for diagonal roads back in 2012, he would have released them a few time ago at least." <-- is true? :p
05:41<TrueBrain>wtf are "diagonal roads"?
05:41<andythenorth>roads that go N-S or E-W
05:42<andythenorth>rubidium said they're impossible as they need to span multiple tiles per 'tile'
05:42<FLHerne>I was just reading forum for some reason
05:42<TrueBrain>FLHerne: yeah, I have no clue what that user was smooking
05:42<FLHerne>It's all andy's fault
05:43<TrueBrain>absolutely zero
05:43-!-Samu [] has joined #openttd
05:43-!-Samu is "realname" on #openttd
05:43<TrueBrain>the only graphics I ever did, was Lego bla
05:43<TrueBrain>so no, he is heavily confusing me who someone else
05:43<TrueBrain>who? with
05:43<FLHerne>TrueBrain: Well, if you *did* have graphics and code, you'd have released them, right?
05:43<FLHerne>So they're not actually wrong
05:43<TrueBrain>even that is not true; depends if it added value :)
05:44<TrueBrain>owh, lol, I made an image
05:44<TrueBrain>now I get it
05:44<TrueBrain>2012 .. lol
05:44<TrueBrain>sorry, context is everything
05:44<TrueBrain>but he meant the image I posted in 2012
05:44<Wolf01><TrueBrain> but make sure you test with latest master :) <- Fixed in title screen now, but lagging in game, wtf?
05:45<Wolf01>After alt-tabbing it gets better in game but the pointer disappear totally or partially when moved
05:47<TrueBrain>FLHerne: zero memories of that event ... clearly I was just having fun with andy .. some things never change :D
05:48<+michi_cc>Wolf01: This is some interesting OS/display/screen interaction. I see partial cursor clipping as well, but a screen capture is completely fine. There's some kind of problem in the way Windows gets the window contents onto the physical screen.
05:48<TrueBrain>Wolf01: try setting in your openttd.cfg under [gui] the refresh_rate to 30
05:48<TrueBrain>see what that does
05:48<TrueBrain>but yeah, it sounds like vsync trouble
05:48<TrueBrain>which is annoying, as not using WM_PAINT should kinda solve that
05:48<TrueBrain>michi_cc: just hurry up with OpenGL would you :P
05:53<@DorpsGek>[OpenTTD/OpenTTD] LordAro merged pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges
05:53<@DorpsGek>[OpenTTD/OpenTTD] LordAro closed issue #8594: NRT - Pathfinder doesn't consider speed limits when calculating a route
05:54<Wolf01><TrueBrain> Wolf01: try setting in your openttd.cfg under [gui] the refresh_rate to 30 <- it gets better, but I feel it a bit laggy
05:54<TrueBrain>the "lag" you experience is 30fps :)
05:54<TrueBrain>but yes, in that case you are seeing vsync issues
05:54<TrueBrain>from what I understand, that has always been there on Windows
05:55<TrueBrain>guess it is a bit more obvious now because on one hand you are focused on it, on the other hand making things smoother makes the non-smooth stick out more
05:55<Wolf01>It seem to be more horizontal tearing than vertical tearing
05:55<TrueBrain>if the issues happens on the horizontal axis
05:55<TrueBrain>it is vsync issue :)
05:55<TrueBrain>if it is over the vertical axis, it is our dirty-stuff acting up :)
05:55<TrueBrain>(screens are drawn from top left to top right, line by line to the bottom)
05:56<TrueBrain>so if you see horizontal striping etc, it is vsync most of the time :)
05:57<TrueBrain>(when the screen comes at the bottom right, in the old days, there was time for "vsync", meaning all horizontal lines were drawn over the vertical axis, before it continues again at the top left to start all over again)
05:57<Wolf01>I see half pointer, like only the left part only when moving it, or alternating the top and bottom parts
05:57<TrueBrain>at the end of each line is "hsync" time
05:57<TrueBrain>yeah, I guess this is what you "see" indeed
05:57<TrueBrain>and only when you move it quick, I assume?
05:57<TrueBrain>yup, vsync
05:58<Wolf01>"Quick", the usual speed :P
05:58<TrueBrain>try out 1.10.3 I would say, if it happens there too
05:58<TrueBrain>owh, and can you try starting the game with "-v win32:no_threads"
05:58<TrueBrain>does that change anything?
05:58<Wolf01>Lol, 1.10.3 crashed badly at title screen, I should not mix the configs
05:59<LordAro>it shouldn't...
06:00<Wolf01>Maybe some newgrf
06:00<Wolf01>It crashes while scanning
06:00<Wolf01>Windows store version
06:00<LordAro>would be interested in seeing the crash.log
06:05<@DorpsGek>[OpenTTD/OpenTTD] Wolfolo opened issue #8711: Microsoft store version 1.10.3 crashing at start
06:07<Wolf01>The crash screenshot is interesting
06:08<LordAro>now, how to read the dmp...
06:08<LordAro>where's glx when you want him?
06:08<TrueBrain>want? or need? :D
06:08<LordAro>0xC0000005 means a segfault though
06:09<@DorpsGek>[OpenTTD/OpenTTD] James103 commented on issue #8711: Microsoft store version 1.10.3 crashing at start
06:09<LordAro>TrueBrain: weren't you going to get dorpsgek to decode the dmps at one point?
06:09<Wolf01>I'll try to disable the automatic UI sizing, it's the only thing I changed
06:10<Wolf01>HA! It's that one
06:10<TrueBrain>LordAro: I was .. but everyone told me it was a waste of time .. so I didn't :)
06:11<+michi_cc>Hmm, min/max settings clamping is broken somehow?
06:11<@DorpsGek>[OpenTTD/OpenTTD] Wolfolo commented on issue #8711: Microsoft store version 1.10.3 crashing at start
06:12<Wolf01>Lunch time
06:17<TrueBrain>I like how you distracted him now :)
06:35<andythenorth>features are weird
06:35<andythenorth>something seems big with moving parts, then's done
06:35*andythenorth devloloper lifestyle
06:36<+michi_cc>Can anyone recalled if we did any changes to the actual "read settings from ini" code in 1.11? (Not meaning the address stuff)
06:37<+michi_cc>As far as I can see settings clamping works fine, except that for the zoom it means it clamps to maximum zoom-in. Which in turn would mean the crash is caused by maximum GUI/font zoom.
06:38<LordAro>something to do with the "bootstrap" settings?
06:39<+michi_cc>Okay, check git history, and the settings clamping part was not touched recently at all. Which indicates a problem with maximum GUI zoom, not settings loading.
06:41<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on issue #8711: Microsoft store version 1.10.3 crashing at start
07:07<FLHerne>andythenorth: I showed this video to some people and none of them comprehended it :-(
07:08<andythenorth>I think it's niche
07:08<@DorpsGek>[OpenTTD/OpenTTD] Wolfolo commented on issue #8711: Microsoft store version 1.10.3 crashing at start
07:08-!-iSoSyS [] has joined #openttd
07:08-!-iSoSyS is "realname" on #/r/openttd #openttd
07:09<andythenorth>it works for me because my kids sing the Gas Gas Gas song to my great irritation :)
07:09<FLHerne>andythenorth: How can NML not suck?
07:09<FLHerne>Perhaps this question is too open-ended
07:09<FLHerne>But it sucks
07:09<andythenorth>FLHerne it nearly doesn't
07:09-!-iSoSyS [] has quit []
07:09<FLHerne>The abstractions are all at the wrong level
07:10<andythenorth>it's proving to be a very productive tool for those of us who can (usually python) abstract it :P
07:10<andythenorth>FLHerne serious answers?
07:11<FLHerne>(I was trying to make it faster, but got fed up again because nothing works)
07:11<andythenorth>ok it sucks on multiple levels, long list follows :P
07:11<andythenorth>1. it's horrible to extend nml, because it's horrible to extend newgrf spec
07:12<andythenorth>2. it's horrible to extend nml because it's unpleasant to write docs for it
07:12<andythenorth>3. nml is (still) relatively slow to compile
07:13<andythenorth>4. nml is very forgiving of some kinds of authoring sloppiness, and completely hostile to others, which can be confusing
07:13<andythenorth>5. nobody enjoys working on nml afaict; even though it's python, I am terrified to touch it because it's way beyond my skills
07:14<andythenorth>6. it has no kind of templating
07:15<andythenorth>7. it doesn't expose entities as actual entities (e.g. 'my blue train', 'my red train') etc, everything in source is just a morass of strings to the average author
07:15<andythenorth>8. it has a cache, but can't speed it up with partial compiles because it has no concept of scopes
07:15<Wolf01>It seem that nml only needs to be more user-friendly
07:18<andythenorth>I would make a terrible language designer, but I though it should be scoped, and use a tree
07:18<andythenorth>so author declares 'train' and then all switches etc are scoped to that train, unless declared global or (global procedure)
07:19<andythenorth>oh it has a few weird pseudo-helpful things as well
07:19<andythenorth>like auto-managing vehicle IDs, which will instantly fail for savegames when more vehicles are added
07:20<andythenorth>also it seems to miss the opportunity to automatically generate basic (sparse) reference docs as html or plain text
07:20<Wolf01>It's like the IDE we are using at work, you declare a bool variable and then proceed to set the initial value to "true", the IDE autosuggests the function "trunc()", it's not even in alphabetical order, and it even returns a string
07:20<andythenorth>e.g. from the tree, it could output something similar to grf2html
07:21<TrueBrain>Wolf01: did you try if -vwin32:nothreads changes anything about the tearing?
07:21<Wolf01>TB: not yet
07:21<+michi_cc>Wolf01: Ah, you must have changed the "maximum zoom in level" some time in the past. Was this intentional?
07:21<+michi_cc>I think you can crash any old OTTD by manually editing the config to have a GUI zoom level that is outside the allowed maximum zoom.
07:22<andythenorth>FLHerne I don't have the ability to carry it off, but if I was replacing it, I would ship something more frameworky, like Iron Horse, but not programmed by me
07:22<andythenorth>and then have it read something like YAML files
07:22<Wolf01>michi_cc: I changed it from master, set to auto-detect, nothing else, I just wanted to see what it did detect and then forgot about it
07:22<andythenorth>the way Jekyll / Liquid handles templates and vars (e.g. OpenTTD website) is really neat
07:23<+michi_cc>Wolf01: I'm not talking about the GUI scale setting.
07:23<andythenorth>declaring a train, should be more like: red_train.yaml
07:23<andythenorth>and then declare which template to use
07:23<andythenorth>and then declare props
07:23<+michi_cc>Quad zoom is only disabled in the GUI dropdown if you changed the advanced setting for maximum zoom away from the default to allow all zooms.
07:24<Wolf01>Oh, the viewport, no, I didn't change it from the .ini, I set it to 2x/8x
07:25<Wolf01>It's set to those values for ages
07:25*FLHerne files answer in head
07:25<FLHerne>"which template" ?
07:25<FLHerne>I don't really know how Horse works
07:25<andythenorth>I would split properties and templating
07:25<andythenorth>my approach is very 'web publishing framework'
07:26<andythenorth>where typically you have a html template with slots or loops in it
07:26<+michi_cc>There's your problem :) OTTD it seems does not validate the GUI zoom loaded from the config against the min/max zoom. Unfortunately, I wrote the autozoom in a way that old versions interpret it as maximum zoom in.
07:26<andythenorth>then you feed it content
07:26<andythenorth>so a train would have a template, e.g. 'steam engine with tender' or whatever
07:26<andythenorth>other approaches might be better, it's just a convention I am used to
07:27<andythenorth>oh I also wondered, I suspect nml is constructing some very very elaborate advanced varact2 in places, probably over and over again
07:27<andythenorth>I wondered if procedures can replace any of that
07:28<andythenorth>procedures have been revolutionary for the way I'm writing grfs
07:28<andythenorth>so much repetition eliminated
07:28<andythenorth>so much to read and write the code
07:28<andythenorth>easier *
07:28<andythenorth>faster compiles, smaller files
07:29<@DorpsGek>[OpenTTD/OpenTTD] JGRennison opened issue #8712: Thread safety issues detected by ThreadSanitizer
07:30<Wolf01>TrueBrain: I checked with 1.10.3, the mouse cursor does not lag and does not have tearing, it behaves like the hardware pointer on windows where you see ghost ones when moving really fast, with master instead I get 2-3 ghosts and only parts of the pointer with 60fps, and a bit laggy but the same ghosting as 1.10.3
07:31<Wolf01>Now I'll try with nothreads
07:31<TrueBrain>the next thing on the list: set refresh_rate to 144 or something
07:31<@DorpsGek>[OpenTTD/OpenTTD] michicc commented on issue #8711: 1.10.3 crashing at start when interface size is set to auto-detect from master (1.11), shared config in document folder
07:32<andythenorth>FLHerne not sure if this is of use, discussion with Alberth from 2019, might be just me waffling
07:32<Wolf01>With nothreads it does not break, no ghosting but jumps
07:34-!-nielsm [] has quit [Remote host closed the connection]
07:34-!-roadt__ [~roadt@] has quit [Ping timeout: 480 seconds]
07:35<TrueBrain>that is a bit odd .. curious what a higher refresh-rate does for you
07:35<Wolf01>With 144 behaves like nothreads, 144+nothreads it's super fast, no ghosting, I can't follow it :P
07:36<+michi_cc>I might have a work-around for the mouse cursor issue, but I have to measure how much of an performance impact it is.
07:36<andythenorth>somehow I persuaded openttd to load a partially written grf without crashing
07:36<andythenorth>that was lolz
07:36<andythenorth>half the vehicles gone, that's usually an assert :)
07:36<andythenorth>I should buy a lottery ticket today
07:36<TrueBrain>Wolf01: how much Hz are your displays?
07:36<TrueBrain>michi_cc: we could do the old "trick" and use what-ever CPU time is left over the draw the mouse
07:37<TrueBrain>but it is hacky as fuck :P
07:37<Wolf01>It seem like my hardware pointer when I set the mouse resolution up to 3000
07:37<TrueBrain>I am somewhat tempted to wait and see if your OpenGL patch improves the situation
07:37<Wolf01><TrueBrain> Wolf01: how much Hz are your displays? <- 60hz
07:38-!-Tulitomaatti [] has joined #openttd
07:38-!-Tulitomaatti is "Eetu Lampsijärvi" on #openttd #ceph
07:38<TrueBrain>I would have expected the GDI to sync this correctly .. bit surprised it does not
07:38<+michi_cc>Okay, that work around is no work-around. It limits the whole game loop to screen refresh rate :(
07:38<TrueBrain>especially as we just blit the whole screen
07:38<+michi_cc>But it basically confirms that it is a GDI/DWM sync issue.
07:39<FLHerne>andythenorth: "I suspect nml is constructing some very very elaborate advanced varact2 in places, probably over and over again" <-- it is
07:39<FLHerne>Particularly for the FIRS spriteayours
07:39<TrueBrain>documentation suggests you don't have to worry about syncing
07:39<TrueBrain>which is clearly a lie :D
07:40<TrueBrain>I will fiddle with it a bit tomorrow, see if I can reproduce at least
07:40<TrueBrain>but we can also decouple mouse handling from draw-ticks
07:40<TrueBrain>so we get a mouse-tick
07:40-!-nielsm [] has joined #openttd
07:40-!-nielsm is "Niels Martin Hansen" on #openttd
07:40<TrueBrain>that runs quicker
07:40<TrueBrain>should fix it for most people
07:40<andythenorth>FLHerne pretty certain that can be proceduralised, they all check the same tile stuff
07:40<andythenorth>mostly they just want 0 and 1
07:41<+michi_cc>TrueBrain: The "magic" call to fix it is DwmFlush. But it has to be called on the main thread before signalling the draw thread and will basically look the main loop to vsync.
07:41<TrueBrain>can't it be done in the draw thread?
07:42<nielsm>okay got my visual studio updated
07:42<nielsm>let's see if I can build ottd
07:43<nielsm>the best part about the cmake change is still that building language files no longer takes forever
07:44<TrueBrain>michi_cc: what I was thinking .. with OpenGL not using threads, and not drawing in the thread solves a few things .. with OpenGL, shouldn't we just drop threaded drawing?
07:44<nielsm>oh right... debugging symbols... going to take a while to download
07:44<TrueBrain>so if people use the GDI, everything is a lot smoother
07:44-!-roadt__ [~roadt@] has joined #openttd
07:44-!-roadt__ is "roadt" on #openttd
07:45<+michi_cc>TrueBrain: I tried that, but it doesn't change anything in the draw thread. And yes, with OpenGL the problem seems to vanish.
07:45<nielsm>the purpose of threaded drawing is to avoid situations where sending the blitted picture over to the graphics memory (or window system buffer) takes a long time, and that's basically a non-problem nowadays, yes?
07:45<TrueBrain>so I see two paths: 1) put the mouse on its own tick, and run it twice as fast, 2) wait for OpenGL to land and remove threadng for drawing
07:46<TrueBrain>nielsm: not as big as it used to, for sure
07:47<nielsm>I just had a really stupid idea for ottd on windows
07:47<+michi_cc>I don't think it has anything to do with too slow mouse ticks, but simply that GDI blitting from a secondary thread is not proberly synchronized by Windows.
07:47<TrueBrain>michi_cc: I am still surprised it works at all
07:47<nielsm>remove the system title bar, put a main window title bar next to the game toolbar and add the system menu and window management buttons too
07:47<TrueBrain>it is such a bad idea :P
07:48<TrueBrain>michi_cc: I always learnt to never draw anywhere not the main thread :)
07:48<nielsm>also then totally replace the main menu with a toolbar
07:48<milek7_>would also fix wayland though :P
07:48<TrueBrain>that is why I am a bit tempted to just remove the threading code
07:48<TrueBrain>nielsm: sorry, I do not follow; make a mockup? :D
07:51<TrueBrain>michi_cc: I have also been wondering if we can't flip it around .. do drawing in main thread, but allow the gameloop in another thread to run at the same time
07:52<+michi_cc>Yes, that is definitely the more canonical way and might even allow threading on platforms like OSX.
07:52<TrueBrain>I might give that a spin tomorrow, see if that changes anything
07:52<TrueBrain>shouldn't be hard
07:52<TrueBrain>especially now that code is nearly all in a single place
07:57<TrueBrain>stuff to improve on :D
07:57-!-glx [] has joined #openttd
07:57-!-glx is "Loïc GUILLOUX" on #openttd
07:57-!-mode/#openttd [+v glx] by ChanServ
08:02<TrueBrain>now I come to think of it, flipping it around also means it works with OpenGL
08:02<TrueBrain>and if we can delay more of the drawing part, the game makes more and more use of multithreaded system
08:02<TrueBrain>so hmm .. yeah, that sounds like a good idea
08:04<+glx> <-- includes manual vcpkg and a workaround for caching on VS2017
08:04<reldred>ahahahah that's kinda goofy nielsm
08:04<TrueBrain>nielsm: next, borderless windowed fullscreen? :D
08:05<LordAro>i don't like it
08:05<nielsm>I said it was a stupid idea
08:05<+glx>what happens if you resize to minimal width ?
08:05<TrueBrain>nielsm: I am so used to playing games borderless windowed, that adding that to OpenTTD would be valuable to me :)
08:06<TrueBrain>but that can be without the blue bar
08:06<TrueBrain>glx: I think that is a lot easier to maintain
08:06<LordAro>making the toolbar disappear until you mouse over/near it might be nice
08:06<nielsm>you mean resizeable border just no title bar_
08:06<TrueBrain>than the battle what we are currently battling
08:06<TrueBrain>nielsm: like any modern game, yes
08:06<TrueBrain>well, mostly it is used in combination with fullscreen
08:06<TrueBrain>but without going to fullscreen
08:06<+glx>TrueBrain: yeah and it's finally quite simple
08:06<TrueBrain>maximized windowed borderless
08:07<nielsm>well having the system buttons and a little area to move the window around will still be nice imo
08:07<+glx>I just need to do the same for release workflow
08:07<nielsm>but also I've been thinking for a while that the open areas next to the menu bar and status bar are kind of weird, I'd rather just they span the entire width anyway
08:08<TrueBrain>had to look up how the rest of the world calls it: Borderless Windowed
08:08<TrueBrain>I always forget the weird combination of words
08:08<TrueBrain>and that is "fullscreen"
08:08<TrueBrain>what is cool about it, it allows your mouse to freely move in and out of that screen
08:08<TrueBrain>open any modern game and you will see it has this mode btw :)
08:08<TrueBrain>Dyson Sphere Program was an exception :P
08:09<+glx>there are 2 fullscreen modes in today's world
08:09<reldred>some don't implement it well and still capture the cursor
08:09<+glx>usually borderless has better support to alt-tab
08:10<+glx>but the other one may have direct access to GPU
08:11<+glx>and different resolution than desktop of course
08:11<+glx>(but ugly on LCD anyway)
08:12<nielsm>make ottd run windowed fullscreen, but the only resolutions allowed are full/1, full/2, full/3, full/4, full/6, full/8 (depending on when it becomes too small)
08:12<nielsm>i.e. whole divisors of the actual desktop resolution
08:12<TrueBrain>most games don't bother with that
08:12<TrueBrain>borderless windowed is just what-ever-your-native-resolution-is
08:13<+glx>yup borderless is a normal window, so it can only use desktop
08:13<nielsm>I've seen several that allow you to render the game in lower resolution which is then upscaled
08:13<nielsm>like rendering at 1080p then upscaling to 2160p
08:13<Xaroth>That only works with DLSS
08:13<Xaroth>and really isn't relevant for openttd.
08:16<@DorpsGek>[OpenTTD/OpenTTD] JGRennison opened issue #8713: Win32 OTTD2FS/FS2OTTD used from multiple threads but use a static buffer
08:21<nielsm>btw can we make win32 assume wchar_t everywhere instead of trying to pretend we still compile for windows 95?
08:24<Xaroth>I hear we have a volunteer
08:30<TrueBrain>nielsm: sounds like the proper fix for that issue, but that is a lot more work :P
08:32<milek7_>I think real 'fullscreen' modes are going away
08:32<nielsm>1.8 was the last successful win9x build right?
08:32<milek7_>windows even tries to do it even when application requests direct fullscreen
08:35<andythenorth>when someone fixes please send it back in time to today
08:35<andythenorth>adjusting vehicle cost balance is frigging painful
08:35<andythenorth>when the profit numbers don't update
08:36<andythenorth>k thx bai :)
08:37<LordAro>the solution is relatively easy
08:42<nielsm>hmm, this comment... "XXX: Hurray for MS only having an ANSI GetProcAddress function"
08:42<nielsm>well yes, linker symbol names are not unicode
08:42<nielsm>they are pure ascii
08:44<TrueBrain>you will find in comments that in many cases the author had no idea how stuff really worked :D :D :)
08:50<nielsm>oh nice, on windows WCHAR is 16 bit character type (alias for wchar_t) and WChar is 32 bit character type (alias for char32_t)
08:50<nielsm>okay WChar is a type of our own definition apparently
08:51<supermop_Home>ugg dropped and chipped coffee mug
08:51<supermop_Home>not quite awake
08:51<milek7_>couldn't we get rid of these silly windows widechar functions?
08:51<supermop_Home>despit it being alost 9
08:51<milek7_>and use utf8 everywhere?
08:52<milek7_>"Starting in Windows 10 build 17134 (April 2018 Update), the Universal C Runtime supports using a UTF-8 code page. This means that char strings passed to C runtime functions will expect strings in the UTF-8 encoding. To enable UTF-8 mode, use "UTF-8" as the code page when using setlocale. For example, setlocale(LC_ALL, ".utf8") will use the current default Windows ANSI code page (ACP) for the locale and UTF-8 for the code page."
08:52<TrueBrain>nielsm: so the first thing you do after setting up your IDE, is dropping in wchar hell :D I appreciate your approach :) (without sarcasm)
08:52<LordAro>milek7_: windows will always use utf16 internally, so no, not entirely
08:53<LordAro>and modifying the codepage has ...other weird results
08:53<+glx>milek7_: we still support windows before 10 1804
08:54<+glx>and yes I enabled utf8 on my windows, but it has some nasty effects with some CLI tools
08:55<milek7_>setlocale sets it per-application
08:55<milek7_>but yes, older windows is a problem
09:05<+michi_cc>Also, many of the OS functions we call are not part of the C runtime anyway.
09:07<LordAro>TrueBrain: i love how the slow dump trucks still take the wooden bridge, because the loss in speed isn't big enough to make it worth going to the faster bridge :)
09:08<TrueBrain>that is funny :)
09:09<andythenorth>LordAro that's an awesome side effect
09:10<andythenorth>pls try to retain it :)
09:10<+glx>if veh max speed is lower than bridge max speed anyway
09:10<LordAro> same thing here, though i'm less sure about the scania using the gravel road
09:10<TrueBrain>working as intended
09:10<TrueBrain>but awesome that is finally works :)
09:11<LordAro>glx: yes, but it is faster than the bridge speed (32 vs 80), just not enough slower
09:11*LordAro goes back to trying to work out why the vehicle list window is never invalidated
09:11-!-frosch123 [] has joined #openttd
09:11-!-frosch123 is "frosch" on #openttd
09:11-!-jellyknight [] has joined #openttd
09:11-!-jellyknight is "realname" on #openttd #llvm
09:12<+glx>ok implemented my changes in release workflow, let's trigger a fake release
09:12<andythenorth>LordAro well we know which commit introduced it :)
09:13<+glx>hmm but I'll wait for CI run (in case it can reuse cache)
09:13<TrueBrain>awesome work there glx :D Should be a lot less buggy and "magic" :D
09:13<LordAro>andythenorth: the issue is that there's nothing in there that should change anything about that
09:13<supermop_Home>love to see that huge mining truck on a wood bridge
09:13<TrueBrain>not unsafe AT ALL
09:13-!-magla [] has joined #openttd
09:13-!-magla is "realname" on #openttd #llvm
09:13<TrueBrain>max-weight next?
09:13<LordAro>supermop_Home: :D
09:13<+glx>I kept the GNU tar workaround in release (even if it doesn't use VS2017) so it may reuse cache from CI
09:14<+glx>(not sure it will, but...)
09:14<LordAro>TrueBrain: that was basically the rest of Zorg's comment on the original issue
09:14<LordAro>i largely ignored it
09:14<TrueBrain>it was? Haha, I was being sarcastic :D
09:14<TrueBrain>says enough :P
09:14<LordAro>i think
09:14<LordAro>i didn't read it all that closely
09:15<+glx>yeah it was about vehicle using roads they "should not"
09:15<+glx>but we don't have these limitations implemented
09:16<+glx>not even in the spec
09:17<+glx> <-- started
09:18-!-gelignite [] has quit [Ping timeout: 480 seconds]
09:20-!-jellyknight [] has quit [Ping timeout: 480 seconds]
09:21<+glx>ok it can reuse CI cache, keeping the same cache config was a good idea
09:22<+glx>hmm was too fast, not reusing cache
09:23<LordAro>you know, i'm not sure i'm a fan of the new vehicle location button
09:23<LordAro>it's very small
09:24<TrueBrain>if things are too small, it is time you change your GUI zoom factor :)
09:25<LordAro>it's a fairly standard screen
09:25<LordAro>no highdpi weirdnesses going on
09:25<TrueBrain>so you need glasses :P
09:26<LordAro>yes, but not for close-stuff :p
09:26<supermop_Home>ok I had an idea for … what if I just draw the bounding box of the RV very tall... would that help? but seems you cant really change that either
09:26<frosch123>well, that "rocket gronk" video is clearly the end-scene for the next stream :)
09:26-!-jottyfan [] has quit [Quit: jottyfan]
09:30<+glx>Warning: /Users/runner/work/OpenTTD/OpenTTD/src/video/cocoa/ warning: unused function 'GetTick' [-Wunused-function] <-- need to check recent master, my branch is not fully up to date
09:30<TrueBrain>only used in debug
09:30<TrueBrain>and even then unused really
09:31<TrueBrain>I thought I removed most of it ..
09:31<LordAro>mm, _tEvent is set, but never read
09:32-!-peter1138 [] has joined #openttd
09:32-!-peter1138 is "Peter Nelson" on #openttd #debian
09:32-!-mode/#openttd [+o peter1138] by ChanServ
09:32<TrueBrain>recent change by me
09:32<TrueBrain>there was a lot of debugging timing stuff in the OSX driver
09:32<Wolf01>Oh, hi peter1138
09:32<+glx>there was a lot of weird thing in OSX driver ;)
09:34<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain opened pull request #8714: Codechange: [OSX] remove final bits of old debugging code
09:34<TrueBrain>did not compile it myself, so lets see if the CI agrees with my change :)
09:36<+glx>building OSX release is slow (of course it's building 2 arch)
09:41<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8714: Codechange: [OSX] remove final bits of old debugging code
09:42<+glx>TrueBrain: should I also use "cmake --build ." for all ?
09:42<TrueBrain>I think we should
09:42<TrueBrain>but that is my opinion :D
09:42<+glx>does it auto use -j ?
09:43<+glx>ok I'll check the doc
09:43<TrueBrain>could always influence it by setting MAKEFLAGS ofc
09:44<TrueBrain>no, it runs -j1 it seems from a local test :)
09:44<TrueBrain>cmake --build accepts -j
09:46<+glx>yes --parallel [<jobs>], -j [<jobs>]
09:58<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain merged pull request #8714: Codechange: [OSX] remove final bits of old debugging code
10:12<@DorpsGek>[OpenTTD/OpenTTD] stormcone commented on pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges
10:13<TrueBrain>haha, someone is asking for the magic 4 :D
10:13<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges
10:14<TrueBrain>I was surprised there was no comment at the rail PF about it
10:16<LordAro>i think the tiles_skipped accounts for the bridgeheads, so it's not that
10:16<LordAro>maybe just arbitrarily increasing the cost?
10:16<TrueBrain>at least 1 of them is from the tile itself
10:16<TrueBrain>the other 3 ... shrug
10:16<TrueBrain>sounds like the cost is overestimating this way
10:16<TrueBrain>but I am sure it is not the only weird thing in the PF :)
10:21<nielsm>progress: it compiles and doesn't crash violently
10:22<nielsm>but doesn't find any language files either
10:23<nielsm>hmm another stupid idea: allow reading data files from embedded resources, so you can have a genuinely standalone openttd.exe that contains language files and baseset files even
10:27<+glx>hmm which generator ?
10:28<+glx>because language files not found is typical to "Visual Studio" cmake generators IIRC
10:30<nielsm>the same build worked before I started editing all the file handling code
10:30<+glx>then I guess you are using Ninja (default in "open folder" mode)
10:31<+glx>so yeah, your changes broke something :)
10:36-!-Flygon [~Flygon@2001:44b8:411e:4e00:f90e:6e3:c4de:f252] has quit [Quit: A toaster's basically a soldering iron designed to toast bread]
10:37<nielsm>oh now it's working
10:38<nielsm>I have no idea why... I made FS2OTTD() and OTTD2FS() return std::string and std::wstring, and in some of the places they're used calling .c_str() on the returned object gives an empty string despite the returned std::(w)string not being empty
10:38<nielsm>but if I store the return from FS2OTTD or OTTD2FS into a local variable then it works
10:39<nielsm>shouldn't the returned temporary be scoped to the scope it's returned inside?
10:39<nielsm>or is that me misunderstanding something?
10:39<+glx>ah yes I noticed things like that before
10:39<LordAro>shouldn't have an issue returning a function-local std::string
10:39<LordAro>it's a class
10:42-!-jottyfan [] has joined #openttd
10:42-!-jottyfan is "jottyfan" on #openttd
10:42<+glx>in I first tried SetDParamStr(0, (std::string(d_name) + PATHSEP).c_str()); but it was always empty
10:42<@DorpsGek>[OpenTTD/OpenTTD] LordAro opened pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed
10:43<LordAro>glx: i think there are issues with calling c_str on a temporary
10:43<LordAro>as the object is immediately destructed
10:43<LordAro>and/or goes out of scope
10:43-!-jottyfan [] has quit []
10:44<+glx>maybe it's the same for return if it's not stored anywhere
10:44<LordAro>possibly the same thing that nielsm is describing? if the std::string is going out of scope, it, and the memory returned by c_str() is freed
10:44<LordAro>c_str isn't a copy - if you haven't made your own copy, it'll disappear
10:47<nielsm>I guess it's only scoped to the statement then, the string object?
10:50<nielsm>unix.cpp also has some unsafe iconv code using a global
10:51<+glx>oups ubuntu 18.04 cmake is too old to support -j
10:54<LordAro>nielsm: glx: i think this demonstrates what's going on
10:54<@DorpsGek>[OpenTTD/OpenTTD] nielsmh commented on issue #8713: Win32 OTTD2FS/FS2OTTD used from multiple threads but use a static buffer
10:58<+michi_cc>.c_str() is basically just the internal pointer. For it to remain valid, the object must stay around, too.
10:59<nielsm>yes the question was about the lifetime of the object
11:00<+michi_cc>nielsm: :D
11:05<+michi_cc>"All temporary objects are destroyed as the last step in evaluating the full-expression that (lexically) contains the point where they were created" combined with rule 3 from would read to me that the temporary does not survive into the function body.
11:06<+michi_cc>To make that stuff more interesting, if the function argument would be of type std::string& (i.e. a reference), temporary lifetime is in fact extended.
11:09<@DorpsGek>[OpenTTD/OpenTTD] nielsmh opened pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
11:11<LordAro>ideally those changes would be separate commits
11:12<nielsm>yeah I know, that's why I made it a draft so far
11:18<@DorpsGek>[OpenTTD/OpenTTD] nielsmh updated pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
11:30<andythenorth>the mac performance improvements also yield when openttd is paused and in the background btw michi_cc
11:30<+glx>ahah looking at the diff I new some platform won't build, and it seems only macos is using iconv
11:30<andythenorth>openttd is sitting at 1.3% of one thread unit right now, it used to sit at 5-10% paused
11:30<andythenorth>was a constant tiny battery lag
11:30<TrueBrain>far less drawing :)
11:30<TrueBrain>where is my love for that?! :P
11:31<andythenorth>I disabled the emoji bar on this mac so I can play openttd
11:31<andythenorth>^ for TrueBrain
11:31<TrueBrain>now that is better!
11:31<andythenorth>emojibar support anyone? :P
11:31<andythenorth>emojibar, such a turkey
11:32<+michi_cc>Is that a codeword for touch bar, or it there some other bar?
11:32<+glx>so using cmake, ctest and cpack everywhere mostly work, except for ubuntu 18.04
11:33<andythenorth>touch bar yes
11:33<andythenorth>for adding emojis
11:33<andythenorth>and silently turning off your screen, or sound, or accidentally locking the mac
11:33<andythenorth>"it's great"
11:34<andythenorth>a totally flat surface, right next to the number keys, with no haptic or audio feedback
11:34<@DorpsGek>[OpenTTD/OpenTTD] nielsmh updated pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
11:35<+glx>--parallel/-j is 3.12+
11:37<LordAro>we can probably cope with a slightly slower compilation for 18.04 for now
11:37<LordAro>alternatively, MAKEFLAGS is universal
11:38<+glx>I can probably go with MAKEFLAGS to work around yes
11:44<+glx>oh I can also try adding -- so -j is not handled by cmake
11:44<@DorpsGek>[OpenTTD/OpenTTD] LordAro updated pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed
11:47<@DorpsGek>[OpenTTD/OpenTTD] LordAro opened pull request #8717: Fix #8349: Close depot vehicle list windows when closing the depot window
11:54<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible
11:55<LordAro>we can probably close #8300 now, right?
11:55<+glx>ah yes
11:56<+glx>andythenorth: ?
11:57<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on issue #8292: Game cutting of savefile name after charecters with diacritics.
11:57<@DorpsGek>[OpenTTD/OpenTTD] LordAro closed issue #8292: Game cutting of savefile name after charecters with diacritics.
11:59<frosch123>nielsm: the static code checker on gh found some valid issues in 8716
12:01<andythenorth>glx **** yes
12:01<andythenorth>close that *******
12:07-!-Tirili [] has joined #openttd
12:07-!-Tirili is "realname" on #openttd
12:07<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on issue #8300: Low framerate on macOS
12:07<@DorpsGek>[OpenTTD/OpenTTD] LordAro closed issue #8300: Low framerate on macOS
12:14<@DorpsGek>[OpenTTD/OpenTTD] nielsmh updated pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
12:18-!-magla [] has quit [Remote host closed the connection]
12:20<andythenorth>right what am I doing?
12:21<Eddi|zuHause>if you don't know...
12:24-!-snail_UES_ [] has joined #openttd
12:24-!-snail_UES_ is "Jacopo Coletto" on #openttd
12:24<andythenorth>finishing Restaurant Cars apparently
12:30<@DorpsGek>[OpenTTD/OpenTTD] glx22 opened pull request #8718: Change: [Actions] stop relying on external actions for trivial stuff, and rely on cmake tools to build, test and pack
12:31<Wolf01>Hmmmm, it looks like "somebody" forgot to give me an ilness certificate for covid... so I'm losing working hours (and days) like a broken pipe
12:31<andythenorth>no pay?
12:31<Wolf01>No pay
12:32<Wolf01>Also, since I'm literally ill, I should not have smart wrecked on the past days (and the next days too), even for the 1-2 hours at day I'm able to do it
12:34<@DorpsGek>[OpenTTD/OpenTTD] LordAro opened pull request #8719: Fix #8276: Crash when a NewGRF object's size was not set
12:35<@DorpsGek>[OpenTTD/OpenTTD] btzy commented on pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed
12:38<@DorpsGek>[OpenTTD/OpenTTD] JGRennison commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
12:39<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed
12:41<@DorpsGek>[OpenTTD/OpenTTD] btzy commented on pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed
12:49<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8706: Feature: rail station class name filtering
12:50<@DorpsGek>[OpenTTD/OpenTTD] nielsmh commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
12:51-!-jottyfan [] has joined #openttd
12:51-!-jottyfan is "jottyfan" on #openttd
12:55<@DorpsGek>[OpenTTD/OpenTTD] glx22 approved pull request #8717: Fix #8349: Close depot vehicle list windows when closing the depot window
12:55<@DorpsGek>[OpenTTD/OpenTTD] stormcone commented on pull request #8706: Feature: rail station class name filtering
12:57<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
12:58<@DorpsGek>[OpenTTD/OpenTTD] LordAro merged pull request #8717: Fix #8349: Close depot vehicle list windows when closing the depot window
12:58<@DorpsGek>[OpenTTD/OpenTTD] LordAro closed issue #8349: Minor inconsistency in Depot List Window behaviour
12:58-!-Wuzzy [] has joined #openttd
12:58-!-Wuzzy is "Wuzzy" on #openttd
12:58<Wolf01>Btw, today I played the first entire game on OpenTTD since years, it was on fast forward and lasted for 3 minutes, but I enjoyed it :P
12:59<Eddi|zuHause>did you reach 1000 rating?
12:59<Eddi|zuHause>or 100% coverage?
13:00<Wolf01>I did not bankrupt until 2050, that's all, and I played with some different NRT roads too
13:01<Wolf01>Just a wood chain to try the performance :P
13:01<@DorpsGek>[OpenTTD/OpenSFX] LordAro approved pull request #14: Change readme, license, descriptions
13:04-!-jottyfan [] has quit [Quit: jottyfan]
13:09<frosch123>ahahahaha, timberwolf submitted a titlegame entry showing the new terrain generator
13:10<Wolf01>New terrain generator?
13:10<frosch123>desert at tile height > 4
13:10<frosch123>i think that is new, isn't it?
13:10<@DorpsGek>[OpenTTD/OpenTTD] glx22 approved pull request #8719: Fix #8276: Crash when a NewGRF object's size was not set
13:11<LordAro>ooh that is nice too
13:11<frosch123>hmm, otoh, i think that map was made with scenario eidtor
13:11<Wolf01>Yup, it's really nice
13:11<frosch123>desert is not close to the ocean otherwise
13:14-!-Wormnest [~Wormnest@] has joined #openttd
13:14-!-Wormnest is "Wormnest" on #openttd
13:15<@DorpsGek>[OpenTTD/OpenTTD] frosch123 approved pull request #8719: Fix #8276: Crash when a NewGRF object's size was not set
13:16<@DorpsGek>[OpenTTD/OpenTTD] LordAro merged pull request #8719: Fix #8276: Crash when a NewGRF object's size was not set
13:16<@DorpsGek>[OpenTTD/OpenTTD] LordAro closed issue #8276: Crash when trying to use a newgrf object
13:17<@DorpsGek>[OpenTTD/nml] LordAro opened issue #191: Does not error when defining an object without a size
13:17-!-Progman [] has joined #openttd
13:17-!-Progman is "Peter Henschel" on #openttd
13:24<@DorpsGek>[OpenTTD/OpenTTD] nielsmh commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
13:33<@DorpsGek>[OpenTTD/OpenTTD] nielsmh updated pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
13:34<nielsm>OS/2 CI when?
13:34<TrueBrain>I so hope the correct answer is: nevah!
13:39<@DorpsGek>[OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering
13:43-!-qwebirc21041 [] has joined #openttd
13:43-!-qwebirc21041 is "OFTC WebIRC Client" on #openttd
13:45<nielsm>hmm okay I think there's 3 separate changes in that PR, I need to separate out
13:46<nielsm>there's some stuff in crashlog_win32.cpp changing how allocations are done, that's mostly stand-alone (removes dependency on OTTD2FS)
13:46<nielsm>then there's simplifying win32 by always assuming UNICODE
13:46<nielsm>and then the actual changing OTTD2FS and FS2OTTD
13:57<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8706: Feature: rail station class name filtering
13:57-!-qwebirc21041 [] has quit [Remote host closed the connection]
14:00<@DorpsGek>[OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
14:00<@DorpsGek> - Update: Translations from eints (by translators)
14:01-!-jottyfan [] has joined #openttd
14:01-!-jottyfan is "jottyfan" on #openttd
14:35-!-gelignite [] has joined #openttd
14:35-!-gelignite is "realname" on #llvm #openttd
14:45<@DorpsGek>[OpenTTD/OpenTTD] SamuXarick updated pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible
14:49<@DorpsGek>[OpenTTD/OpenTTD] SamuXarick commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible
14:49<@DorpsGek>[OpenTTD/OpenTTD] SamuXarick commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible
14:51<@peter1138>"Fix" "Make ... possible" hmm
14:52<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible
14:52<LordAro>he speaks!
14:52<LordAro>peter1138: my bike is broken :(
14:53<@peter1138>Mine too.
14:53<LordAro>oh no
14:53<@peter1138>I broke its heart by not riding it.
14:53<LordAro>i've done less than 100 miles in the last 2 months
14:53<LordAro>very sad
14:54<@peter1138>Same. Well, zero is less than 100 ...
14:54<LordAro>anything particular stopped you, or...?
14:55<@peter1138>Weather, laziness, working from home, etc...
14:55<@peter1138>Oh and lockdown. "Stay local"
14:56<Wolf01>I've got covid instead :(
14:56<LordAro>eh, that's only ever mattered if you actually went in anywhere. less of an issue on a bike
14:56<LordAro>the weather this past month has been particularly awful though
14:58<@peter1138>Actually I think it started when I had no heating or hot water for a month in October. I didn't want to go out and get cold and wet and come back home... stay cold and wet.
14:59<LordAro>i can understand that
14:59<@peter1138>Then once you've had a month or so off and it's getting cold, just... couldn't be arsed with it.
15:01<@peter1138>Still, at least the bike hasn't been ruined by shitty winter weather. Silver linings!
15:01<LordAro>mine spent a month in the garage and the bearings haven't forgiven me
15:01<LordAro>(which were dying anyway)
15:05<@DorpsGek>[OpenTTD/OpenTTD] stormcone commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible
15:12<@DorpsGek>[OpenTTD/OpenTTD] nielsmh opened pull request #8720: Remove remaining Windows 95 support
15:13<@DorpsGek>[OpenTTD/OpenTTD] nielsmh commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects
15:14<@peter1138>Windows 95 is 25 years ago, isn't this a bit premature?
15:22<nielsm> gasp, people are calling version 1.10.3 just version 10.3 ... almost as if the 1. part barely matters
15:22<nielsm>(version 2 when?)
15:22<LordAro>the hard bit would be finding a c++17 compiler that supports win9x
15:22<TrueBrain>1st of april nielsm ? :D
15:23<nielsm>I think removing windows 95 support officially will be a good 2.0 feature
15:23<LordAro>TrueBrain: speaking of, RC1 when?
15:23<LordAro>(or beta2?)
15:23<TrueBrain>LordAro: I was hoping that we could merge OpenGL before RC
15:23<TrueBrain>but I am looking at michi_cc here if that is realistic
15:23<TrueBrain>was I think we should RC before the end of the month
15:23<TrueBrain>was? because .. lol
15:24<TrueBrain>brain faster than hands ..
15:24<LordAro>ideally, yeah
15:24<+michi_cc>TrueBrain: It's mostly a question of how fast how many people can test.
15:25<TrueBrain>we have seen that can be done pretty quickly :)
15:25<TrueBrain>and to be clear, I don't expect we get it right the first time ..
15:25<TrueBrain>the 60fps already had 2 fixes ;)
15:25<+michi_cc>I'm currently tinkering with OSX, because I want to have something new for testing, but I would expect that the final PR will not have GL as the preferred driver for OSX.
15:26<TrueBrain>would it be possible to have the PR reviewable, without OSX in that case?
15:26<TrueBrain>just so we can start testing the other OSes?
15:28-!-Tirili [] has quit [Remote host closed the connection]
15:33<supermop_Home>man what the hell was I trying to do here: "switch (FEAT_ROADVEHS, SELF, switch_pickup_box, var[0xBF,0,0xFF]) { "
15:33<supermop_Home>it looks like pick the color of a box on the truck by something, but what and why
15:37-!-Tirili [] has joined #openttd
15:37-!-Tirili is "realname" on #openttd
15:39<andythenorth>whatever var BF is :D
15:39<andythenorth>is that 80+ vars?
15:39*andythenorth can't be bothered to look it up
15:40<supermop_Home>i have no idea why i was trying to do some magic with the box in the bed of a pickup truck
15:42<@DorpsGek>[OpenTTD/OpenTTD] 2TallTyler commented on pull request #8480: Multitile depots
15:45<supermop_Home>there is no variable for vehicle_is_decelerating huh
15:45<supermop_Home>there is braking but only for trains
15:46<Eddi|zuHause>yes, BF is a 80+ var
15:46<supermop_Home>i guess that mean no fun splashes for the logs in the log flume
15:46<frosch123>supermop_Home: that's because there is no braking for road vehicles in ottd
15:46<frosch123>they stop instantly
15:48<supermop_Home>can you have a switch based on the day of the year that a RV was bult?
15:49<frosch123>there is only a build_year
15:49<frosch123>the exact date is not remembered
15:50<Eddi|zuHause>are you sure? i thought age is counted more fine grained than just year?
15:50<@DorpsGek>[OpenTTD/OpenTTD] glx22 commented on pull request #8720: Remove remaining Windows 95 support
15:51<frosch123>oh, age... funny how we store things redundantly
15:51<frosch123>there is an absolute and an relative build date :p
15:52<supermop_Home>Eddi|zuHause if that is true there is no documented way to run a switch off that afaict
15:52<+glx>haha of course it compiled, it's "dead code"
15:52<frosch123>supermop_Home: var B0 :)
15:53<frosch123>but it's clamed to 64k days
15:53<frosch123>@calc 65536/365.25
15:53<@DorpsGek>frosch123: 179.4277891854894
15:54<frosch123>so you don't know the build_date after 180 years
15:54<@DorpsGek>[OpenTTD/OpenTTD] nielsmh updated pull request #8720: Remove remaining Windows 95 support
15:54<supermop_Home>well my idea was to give the RV a special livery if you bought it in the last week of october
15:54<supermop_Home>no idea how workable that is
15:54<andythenorth>the halloween truck
15:55<frosch123>it will break after 180 years, but as long as it is only visual, it won't desync
15:55<supermop_Home>well the paint will probably rust off in 180 years anyway
15:56<frosch123>people say 180 years can pass in a few seconds...
16:00<@DorpsGek>[OpenTTD/OpenTTD] J0anJosep commented on pull request #8480: Multitile depots
16:02<@DorpsGek>[OpenTTD/OpenTTD] J0anJosep commented on pull request #8480: Multitile depots
16:05-!-Tirili [] has quit [Remote host closed the connection]
16:07<andythenorth>this is interesting
16:07<andythenorth>that's a train tick increase, isn't that completely isolated from the video loop change?
16:09<+glx>more drawing, less time to compute
16:09<TrueBrain>no, train ticks take longer glx
16:09<TrueBrain>like the time of a single tick
16:09<TrueBrain>that cannot be caused by more drawing :)
16:09<andythenorth>I am curious if we have some other performance regression recently
16:10<TrueBrain>we still have to finish that savegame archive :D
16:10<andythenorth>I have a relatively small savegame (161 trains) but stopping the trains makes a huge difference to FFWD speed
16:10<andythenorth>subjectively more than it used to
16:10<andythenorth>but that's a crap judgement because Mac FFWD used to be about 8x at best :P
16:10<andythenorth>now it's 80x
16:10<+glx>ideally he should compare with beta, not 1.10.3
16:11<TrueBrain>well, still it is a question why trains take 25% longer
16:11<TrueBrain>that feels weird :P
16:11<+glx>yeah but maybe it happens in beta too
16:11<TrueBrain>absolutely something to check out
16:11<TrueBrain>and bisect it otherwise :D
16:12<+glx>everything in game loop seems slower in the screenshot
16:12<+glx>more visible for trains because many of them
16:13<TrueBrain>good point
16:14<TrueBrain>then I am still not 100% sure what those ms mean
16:14<TrueBrain>but I assume it is the time between when the variable comes in scope and goes out of scope
16:14<TrueBrain>nielsm: am I right in that assumption? Do ticks mean how long the PFE variable was in scope?
16:15<nielsm>yes the time taken is how long the PerformanceMeasurer was in scope
16:15<TrueBrain>averaged over the amount of time it happens
16:15<TrueBrain>what is odd to me, in his earlier screenshots, that if the game runs 4 times as fast, the gameloop total time is 25% of the value
16:16<TrueBrain>that makes little sense to me .. the "ms" per tick should remain the same, not?
16:16<nielsm>yes I'm not sure what makes his game run faster there
16:16<TrueBrain>well, all his screenshots have this
16:16<nielsm>the "train ticks" is how long the code to move trains around takes to run per iteration of the game loop
16:16<TrueBrain>so there seems to be a relation between frames/s and "ms"
16:17<TrueBrain> shows this rather clearly
16:17<TrueBrain>sorry glx, I was jumping the gun there .. it indeed does not seem to mean that the train are the cause perse
16:17<nielsm>yes the simulation of trains somehow got 4x faster between those two versions
16:18<TrueBrain>I need to get a better grasp on what it all means myself :) I am assuming waaayyyyy too much :P
16:21<nielsm>"game look total" is how much time (on average, per tick) the game spends inside the game loop, "train ticks" is how much time (on average, per tick) the game spends on moving trains as part of the game loop
16:22<TrueBrain>it is weird that the "ms" correlates with the simulation rate, not?
16:22<TrueBrain>would that just be pure luck?
16:22<nielsm>no that's exactly what it does
16:23<TrueBrain>if I run the game 4x my normal speed, the time, per tick, it spends on train ticks remains the same, not?
16:23<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver
16:23<nielsm>if the game loop + graphics rendering + video output takes longer than the budget of 30 ms per frame, then you get simulation rate limited by the game loop time taken
16:23<+michi_cc>TrueBrain: Assume I have broken SDL while rebasing :D I haven't even compiled with SDL.
16:23<TrueBrain>michi_cc: well, CI will tell you soon enough :P
16:23<TrueBrain>I will test it tomorrow :)
16:24<nielsm>the indented figures under game loop (cargo, train, rv, ship, aircraft, world, link graph) are sub-components of the game loop, and their sum should roughly add up to the game loop total
16:24<+michi_cc>andythenorth: I've changed the OSX implementation for OpenGL to what felt fastest with the Apple software renderer. No idea if that is also the best for real hardware.
16:25<TrueBrain>nielsm: somewhere in my mind there still is a crash :D
16:25<TrueBrain>my mind? my head
16:25<TrueBrain>what-ever, english hard
16:26<nielsm>when you run the game on ffwd, then the game loop time should be inverse proportional to the simulation rate
16:26<TrueBrain>my simplistic logic says: if game-loop total took 80ms, and now it took 15ms, that means that the GameLoop itself got 4 times faster, not? (per tick)
16:26<nielsm>assuming the rendering/output stages don't cost too much
16:26<nielsm>yes that's exactly right
16:26<TrueBrain>so that makes me wonder ... did we change anything that makes 1.11 4 times faster?
16:26<TrueBrain>(in GameLoop)
16:27<nielsm>yeah that's the weird thing
16:27<TrueBrain>I guess it is possible
16:27<nielsm>or can there be a difference in compiler (that somehow makes things that much better)?
16:27<TrueBrain>debug vs release
16:27<TrueBrain>that would make much more sense, honestly
16:28<nielsm>1.10.3 shouldn't be a debug build tho
16:28<TrueBrain>1.10 is build old-style
16:28<TrueBrain>1.11 is build new-style (CMake etc)
16:28<TrueBrain>might also be a reason
16:28<_dp_>are you sure it calculates avg durations correctly?
16:28<TrueBrain>okay, that would add up a lot more
16:28<nielsm>should still be same compiler and same LTO
16:28<TrueBrain>no clue honestly .. we now let CMake do the right thing :)
16:29-!-JGR [~JGR@2a00:23c6:62a0:c801:ae5f:9ac4:7524:bca9] has joined #openttd
16:29-!-JGR is "realname" on #openttd
16:29<andythenorth>michi_cc does it need testing?
16:30<+michi_cc>Yes, I could have broken something for real hardware.
16:30<JGR>The 4x faster is most likely because that test is using Timberwolf's trains, and the sprite caching changes were added since then
16:30<TrueBrain>JGR: YES!
16:30<TrueBrain>tnx :D
16:30<andythenorth>michi_cc 7744 as above?
16:31<TrueBrain>JGR: that makes a lot more sense :D
16:31<TrueBrain>well, for the user that is transparent of course, knowing what causes a speed improvement is not always as clear :)
16:32<+michi_cc>andythenorth: yep
16:32<LordAro>do nightlies still have asserts enabled?
16:32<LordAro>that difference might be enough
16:32<+michi_cc>SDL is broken right now, but that doesn't affect OSX.
16:33<TrueBrain>LordAro: they should, yes
16:35<andythenorth>michi_cc fatal errors in build, you want the paste?
16:35<andythenorth>looks like GL stuff at first glance
16:35<+michi_cc>Yes, please.
16:36<nielsm>yeah drawing the trains makes a huge difference on that savegame with PKS
16:36<+michi_cc>Interesting, especially since CI actually passed for OSX.
16:36<nielsm>PKP I mean
16:36<andythenorth>$10 it's XCode nonsense?
16:36-!-WormnestAndroid [~WormnestA@] has quit [Ping timeout: 480 seconds]
16:36<TrueBrain>PKP? :D
16:37<andythenorth>PKP? :D
16:37<nielsm>polish trains newgrf
16:37<+michi_cc>And also because I didn't actually touched the headers in that file in the recent rebase.
16:37<TrueBrain>ah :D
16:37<nielsm>in 1.10.3 it just runs slowly all the time, in master the speed depends heavily on how many trains are on screen
16:37<TrueBrain>to be expected
16:37<TrueBrain>that is a nice improvement :)
16:37-!-WormnestAndroid [~WormnestA@] has joined #openttd
16:37-!-WormnestAndroid is "WormnestAndroid" on #openttd
16:37<andythenorth>michi_cc my build relies on CPLUS_INCLUDE_PATH="/Applications/"
16:37<andythenorth>dunno if that's relevant here
16:38<andythenorth>nielsm what if you stop the trains?
16:38<andythenorth>it's interesting how effective stopping trains is in my game
16:38<andythenorth>(bit limiting for fun game...but look at the ffwd speed!)
16:39<+michi_cc>andythenorth: But you did compiled successfully before? I didn't touch that file up to the point of first error, so I have no idea what is going on.
16:39<+michi_cc>Possibly do a clean / delete the build dir?
16:39<andythenorth>yeah my build does that
16:39<nielsm>2-3x speedup of ffwd by stopping the trains
16:39<andythenorth>but I'll try again
16:40<andythenorth>from configuration output
16:40<andythenorth>-- Found OpenGL: /Applications/ found components: OpenGL
16:42<+michi_cc>Same SDK path as for me, and that result in including the right header that has the types it complains about.
16:42<+michi_cc>And apparently for the CI as well.
16:43*andythenorth looks up how to get the xcode version report
16:43<andythenorth>Xcode 12.1
16:43<andythenorth>Build version 12A7403
16:45<andythenorth>google not producing much
16:50-!-frosch123 [] has quit [Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn]
16:50<andythenorth>michi_cc I can look more tomorrow night? It's usually some path issue
16:50<andythenorth>usually google turns up a clue in the end
16:51<+michi_cc>Probably. Work for me and works for the CI, so I'm afraid I can't really help.
16:52<supermop_Home>i think 1 in 160+ is an ok ratio:
16:53<_dp_>ok, unless I made a mistake somewhere here is what cargo aging does to profits:
16:54<andythenorth>_dp_ :D
16:55<andythenorth>ok, so I know play styles vary
16:55<andythenorth>but I mostly play 256x256 or 256x512
16:55-!-Samu [] has quit [Quit: Leaving]
16:55<andythenorth>so cargo aging barely moves the needle
16:55<andythenorth>charts show same
16:56<_dp_>yeah, I guess
16:56<_dp_>sh125 is too fast for 256
16:56<andythenorth>I tested a lot locally
16:56<@DorpsGek>[OpenTTD/OpenTTD] Milek7 opened pull request #8721: Fix: Allow building with Allegro and without SDL on Linux
16:56<andythenorth>75mph you can see difference on 100 tile route
16:56<supermop_Home>160 Imprezas, with 3 passengers each, will turn a slight profit eventually over longer distances..
16:57<_dp_>thouh it's diagonal so 512 on 256x256
16:57<supermop_Home>so long as there are no speedlimits
16:58<@DorpsGek>[OpenTTD/OpenTTD] nielsmh commented on pull request #8721: Fix: Allow building with Allegro and without SDL on Linux
16:58<supermop_Home>andythenorth how should i hide this Subaru so people can't find it right away?
16:59<andythenorth>do the buy menu sprite as a crate
16:59<andythenorth>and then the vehicle is a surprise (random)
16:59*andythenorth plays too many games with crates
16:59<andythenorth>they're a plague
17:00<supermop_Home>currently its a 3 in 256 chance that you get a team 555 one
17:00<supermop_Home>otherwise its a regular wrx
17:00<supermop_Home>i guess i could also take off the spoiler and make it slower
17:01<andythenorth>OpenTTD FEATURE REQUEST
17:01<supermop_Home>kei van with 1 in 100 chance of being a rally car?
17:01<andythenorth>'build surprise vehicle' button when purchase menu is filtered by cargo
17:01<supermop_Home>currently the rally car and the regular have the same speed and hp
17:02<supermop_Home>and number of seats
17:02<supermop_Home>what i really need is a vehicle that is allowed to ignore speedlimits when on DIRT
17:04<supermop_Home>ok may need to nerf it or mess with cargo decay
17:04<supermop_Home>I've now earned 2M quid from this swarm of subarus
17:07-!-Tirili [] has joined #openttd
17:07-!-Tirili is "realname" on #openttd
17:08<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver
17:13<supermop_Home>maybe 200 kmh is a little too generous
17:13<supermop_Home>random bits for an RV are the same for all switches?
17:14-!-WormnestAndroid [~WormnestA@] has quit [Ping timeout: 480 seconds]
17:14-!-WormnestAndroid [~WormnestA@] has joined #openttd
17:14-!-WormnestAndroid is "WormnestAndroid" on #openttd
17:15<Eddi|zuHause>supermop_Home: random bits are per vehicle part
17:18-!-nielsm [] has quit [Ping timeout: 480 seconds]
17:29-!-Progman [] has quit [Remote host closed the connection]
17:30-!-mirrorbird [~mirrorbir@2a00:801:446:6dfc:fadb:e310:6ed2:16d] has joined #openttd
17:30-!-mirrorbird is "mirrorbird" on #openttd
17:30-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
17:31-!-Tirili [] has quit [Remote host closed the connection]
17:34-!-Tirili [] has joined #openttd
17:34-!-Tirili is "realname" on #openttd
17:36<andythenorth>is it bedtime?
17:37-!-gelignite [] has quit [Quit: Stay safe!]
17:39-!-mirrorbird [~mirrorbir@2a00:801:446:6dfc:fadb:e310:6ed2:16d] has quit [Ping timeout: 480 seconds]
17:39-!-sla_ro|master [] has quit []
17:50-!-jottyfan [] has quit [Quit: jottyfan]
17:58-!-mirrorbird [~mirrorbir@2a00:801:446:6dfc:fadb:e310:6ed2:16d] has joined #openttd
17:58-!-mirrorbird is "mirrorbird" on #openttd
18:05<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on pull request #8720: Remove remaining Windows 95 support
18:05<@DorpsGek>[OpenTTD/OpenTTD] LordAro approved pull request #8721: Fix: Allow building with Allegro and without SDL on Linux
18:05<@DorpsGek>[OpenTTD/OpenTTD] LordAro merged pull request #8721: Fix: Allow building with Allegro and without SDL on Linux
18:08-!-andythenorth [] has quit [Quit: andythenorth]
18:10<NGC3982>any suggestion on available newgrf's containing "lots of trains"?
18:10<NGC3982>my players demands it and i shalt supply it
18:11-!-Tirili [] has quit [Remote host closed the connection]
18:30<FLHerne>NGC3982: 2cc was the traditional one, being international and huge
18:30<FLHerne>Timberwolf's has lots of UK trains
18:31<FLHerne>Iron Horse has lots compared to the default set, but is a bit more sane
18:32<FLHerne>UKRS2 and UKRS2+, or NARS, or both
18:32<FLHerne>I think Dutch Trainset is pretty big
18:33<FLHerne>(and definitely add Dutch Stations + the additions, those are great)
18:34<NGC3982>oh, cool
18:36<LordAro>pathfinder pays attention to order speed limits: yay/nay?
18:36<LordAro>(that feature of timetables that even fewer people use than timetables themselves)
18:37<FLHerne>In principle, yay
18:37<FLHerne>But tbh I've used them in about two games ever
18:38<LordAro>(see the text and/or save in #8594)
18:38<FLHerne>They're slightly useful for equalizing train speeds, if the rail speed limit doesn't do it for you
18:38<LordAro>the actual implementation is a single line addition
18:38<FLHerne>Also, I think it's "yea" /pedant
18:39<LordAro>also not sure how it will interact with path caches
18:39<LordAro>though path caches only go from one order to another, which is the only point where speed limits can be changed, so should be fine
18:41<FLHerne>How is pathfinder supposed to "fix" there being a compatible road with a higher speed limit that's Wrong?
18:41<FLHerne>There's a long explanation, but it doesn't make sense :p
18:42<LordAro> it's kinda funny - before my change in #8710, road vehicles took the shorter route, despite it being slower road. Then they took the faster expressway, now they've gone back to taking the slower road :)
18:42<LordAro>FLHerne: oh you can ignore most of the text :p
18:42<LordAro>"road classes" are not a thing anywhere
18:42<FLHerne>tbc, by "take into account" you mean "treat all speed limits as max(road limit, order limit)" ?
18:42<LordAro>pretty much, yes
18:44<FLHerne>Then yeah, if it's simple to implement and doesn't break, it seems obviously Right to me
18:44<FLHerne>Unless I missed something
18:46<LordAro>actually, i think i did it slightly wrong
18:46<LordAro>just 2 changed lines, rather than adding 1 :)
18:47<@DorpsGek>[OpenTTD/OpenTTD] michicc updated pull request #7744: Draft Feature: OpenGL video driver
18:49-!-k-man [] has quit [Quit: WeeChat 3.0]
18:51-!-k-man [] has joined #openttd
18:51-!-k-man is "Jason Lewis" on #debian-au #debian-next #debian #oftc #openttd #virt
19:02<@DorpsGek>[OpenTTD/OpenTTD] stormcone commented on pull request #8706: Feature: rail station class name filtering
19:02<@DorpsGek>[OpenTTD/OpenTTD] LordAro opened pull request #8722: Change: Make road & rail pathfinders account for maximum order speed, if set
19:06-!-glx [] has quit []
19:16<@DorpsGek>[OpenTTD/OpenTTD] TrueBrain approved pull request #8722: Change: Make road & rail pathfinders account for maximum order speed, if set
19:22<@DorpsGek>[OpenTTD/OpenTTD] LordAro commented on issue #8101: (Streetcar) vehicles do not use all open stations/gates
19:25<@DorpsGek>[OpenTTD/OpenTTD] LordAro merged pull request #8722: Change: Make road & rail pathfinders account for maximum order speed, if set
20:20-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
20:24-!-mirrorbird [~mirrorbir@2a00:801:446:6dfc:fadb:e310:6ed2:16d] has quit [Quit: Leaving]
20:29-!-JGR [~JGR@2a00:23c6:62a0:c801:ae5f:9ac4:7524:bca9] has quit [Ping timeout: 480 seconds]
20:38<@DorpsGek>[OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering
20:39<@DorpsGek>[OpenTTD/OpenTTD] perezdidac commented on pull request #8706: Feature: rail station class name filtering
20:42-!-Flygon [~Flygon@2001:44b8:411e:4e00:e997:c254:e4e7:2471] has joined #openttd
20:42-!-Flygon is "Flygon" on #openttd
20:45-!-WormnestAndroid [~WormnestA@] has quit [Remote host closed the connection]
20:46-!-WormnestAndroid [~WormnestA@] has joined #openttd
20:46-!-WormnestAndroid is "WormnestAndroid" on #openttd
20:49<@DorpsGek>[OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering
20:58<@DorpsGek>[OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering
21:07-!-k-man [] has quit [Remote host closed the connection]
21:07-!-k-man [] has joined #openttd
21:07-!-k-man is "Jason Lewis" on #debian-au #debian-next #debian #oftc #openttd #virt
21:11-!-mirrorbird [~mirrorbir@2a00:801:446:6dfc:fadb:e310:6ed2:16d] has joined #openttd
21:11-!-mirrorbird is "mirrorbird" on #openttd
21:40-!-WormnestAndroid [~WormnestA@] has quit [Remote host closed the connection]
21:40-!-JGR [~JGR@2a00:23c6:62a0:c801:ae5f:9ac4:7524:bca9] has joined #openttd
21:40-!-JGR is "realname" on #openttd
21:41-!-WormnestAndroid [~WormnestA@] has joined #openttd
21:41-!-WormnestAndroid is "WormnestAndroid" on #openttd
21:43-!-JGR [~JGR@2a00:23c6:62a0:c801:ae5f:9ac4:7524:bca9] has quit []
22:08-!-Wormnest [~Wormnest@] has quit [Quit: Leaving]
22:24-!-debdog [~debdog@2a00:79c0:62d:2b00:7a24:afff:fe8a:d04d] has joined #openttd
22:24-!-debdog is "Wowbagger" on #openttd
22:27-!-D-HUND [~debdog@2a00:79c0:654:c500:7a24:afff:fe8a:d04d] has quit [Ping timeout: 480 seconds]
22:36-!-muffindrake1 [] has joined #openttd
22:36-!-muffindrake1 is "muffindrake" on #debian-next #openttd
22:38-!-muffindrake [] has quit [Ping timeout: 480 seconds]
22:58<supermop_Home>are speed and power callback multiplied by some value?
23:50-!-mirrorbird [~mirrorbir@2a00:801:446:6dfc:fadb:e310:6ed2:16d] has quit [Quit: Leaving]
---Logclosed Mon Feb 22 00:00:49 2021