IRC logs for #openttd on OFTC at 2021-02-21
⏴ go to previous day
00:22:27 <DorpsGek> [OpenTTD/OpenTTD] LordAro opened pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges https://git.io/Jt9GI
00:29:29 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
00:32:04 <DorpsGek> [OpenTTD/OpenTTD] michicc approved pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges https://git.io/Jt9GP
00:42:58 <TrueBrain> There is a bug in that PR :D
00:43:08 <TrueBrain> Min speed is missing the same thing as max
00:43:29 <TrueBrain> Not logged in to GH on mobile, sadddd
00:43:30 <LordAro> it is in the rail pathfinder too
00:43:47 <LordAro> given there is nothing with a minimum speed anywhere, i didn't worry too much
00:44:31 <TrueBrain> Really weird .. why would bridge length not matter all of a sudden
00:45:02 <LordAro> you'd have to ask the madman that wrote YAPF, it appears to date back that far
00:45:48 <TrueBrain> Yeah ... let's not dwindle in the past too much :D
00:46:43 <TrueBrain> It will take 20 years for someone to notice if that is broken, so who cares :D
00:46:56 <TrueBrain> Took 10 years for someone to find this :p
00:47:58 <TrueBrain> Right, bed, good idea, night!
00:51:37 *** sla_ro|master has quit IRC ()
01:20:36 <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering https://git.io/Jt9ev
01:29:16 <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering https://git.io/Jt9ev
02:30:15 *** Progman has quit IRC (Remote host closed the connection)
02:53:11 *** jellyknight has joined #openttd
03:00:35 *** gelignite has quit IRC (Ping timeout: 480 seconds)
03:02:45 *** snail_UES_ has quit IRC (Quit: snail_UES_)
03:03:14 *** snail_UES_ has joined #openttd
03:29:10 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:51:10 *** jellyknight has quit IRC (Quit: Stay safe!)
04:02:37 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
04:07:16 *** WormnestAndroid has joined #openttd
04:28:53 *** Wuzzy2 has quit IRC (Remote host closed the connection)
06:36:43 *** snail_UES_ has quit IRC (Quit: snail_UES_)
07:02:42 *** muffindrake has joined #openttd
07:54:11 *** didac has quit IRC (Remote host closed the connection)
08:16:18 *** andythenorth has joined #openttd
08:18:32 *** jottyfan has joined #openttd
08:24:09 *** jottyfan has quit IRC (Quit: jottyfan)
09:00:16 *** jottyfan has joined #openttd
09:10:14 *** Progman has joined #openttd
09:17:57 <TrueBrain> W00p, another reply from someone who clearly did not start the game to test :)
09:18:27 <TrueBrain> It surprises me that seems to be the most difficult to people :p
09:18:45 <TrueBrain> Also shows how little people really care about that climate :D
09:19:31 *** HerzogDeXtEr has joined #openttd
09:20:32 <andythenorth> TrueBrain "I've heard you're planning to kill babies"
09:20:40 <andythenorth> "I'd just like to say that I don't agree"
09:32:08 <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" :)
09:32:50 <andythenorth> I don't like your socks
09:37:10 <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? "
09:37:16 <TrueBrain> I love clear questions
09:37:19 <TrueBrain> allow for clear answers
09:38:53 * andythenorth seriously considering Iron Horse trading cards
09:41:53 <andythenorth> custom card printing is a thing
09:44:29 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges https://git.io/Jt9wW
09:50:12 *** gelignite has joined #openttd
10:01:33 <TrueBrain> ugh, I need to be able to compile OpenTTD faster ...
10:04:02 <andythenorth> that bisecting yesterday was painful
10:04:07 <andythenorth> so useful though
10:05:29 *** Progman has quit IRC (Remote host closed the connection)
10:08:57 <andythenorth> how long do compiles take?
10:09:17 * andythenorth can't be bothered to time one :P
10:09:20 <andythenorth> seems like about 2 mins
10:09:52 <TrueBrain> LordAro: I did consider it. Then I was like, maybe I should get a job first :P
10:10:06 <TrueBrain> but mostly LTO is just annoying ..
10:15:10 <TrueBrain> okay, space in folder works fine for Linux
10:15:11 <nielsm> newgrf.cpp is gigantic and should be split up in some way
10:15:12 <TrueBrain> lets test Windows ...
10:16:56 <andythenorth> delete newgrf.cpp? :)
10:17:04 <andythenorth> simplify lives of content authors
10:17:20 <LordAro> nielsm: i've thought about putting all the newgrf* files in their own folder before
10:17:53 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #8687: CMake include error when building new project. https://git.io/JtM7E
10:18:16 <TrueBrain> adding folders in general would be lovely
10:18:26 <TrueBrain> as the root folder is just too darn long to scroll through
10:29:35 <andythenorth> so because you don't all read forums
10:29:39 <andythenorth> this is really good
10:29:51 <andythenorth> (there is a newgrf 'high speed' contest running)
10:31:50 *** sla_ro|master has joined #openttd
10:36:54 <andythenorth> outstanding use of unreleased feature at the end
10:37:09 <Wolf01> The hovercraft at the end
10:37:30 <TrueBrain> the stuttering, aarrrghhh .. we should fix that ..
10:38:17 <Wolf01> TB: I should check better, but I think I noticed some mouse pointer lag at the title screen, but not in game
10:39:04 <TrueBrain> there is no render-difference between title screen and in-game
10:39:08 <TrueBrain> so that would be a bit odd
10:39:18 <Wolf01> In game it really disappear when I move it fast
10:39:35 <TrueBrain> but make sure you test with latest master :)
10:39:57 <andythenorth> so much fun, so much better than arguing with net-negative contributors about boring crap
10:40:42 <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
10:41:24 <TrueBrain> wtf are "diagonal roads"?
10:41:51 <andythenorth> roads that go N-S or E-W
10:42:18 <andythenorth> rubidium said they're impossible as they need to span multiple tiles per 'tile'
10:42:51 <FLHerne> I was just reading forum for some reason
10:42:59 <TrueBrain> FLHerne: yeah, I have no clue what that user was smooking
10:42:59 <FLHerne> It's all andy's fault
10:43:10 <TrueBrain> the only graphics I ever did, was Lego bla
10:43:24 <TrueBrain> so no, he is heavily confusing me who someone else
10:43:34 <FLHerne> TrueBrain: Well, if you *did* have graphics and code, you'd have released them, right?
10:43:39 <FLHerne> So they're not actually wrong
10:43:48 <TrueBrain> even that is not true; depends if it added value :)
10:44:09 <TrueBrain> owh, lol, I made an image
10:44:43 <TrueBrain> sorry, context is everything
10:44:47 <TrueBrain> but he meant the image I posted in 2012
10:44:48 <Wolf01> <TrueBrain> but make sure you test with latest master :) <- Fixed in title screen now, but lagging in game, wtf?
10:45:40 <Wolf01> After alt-tabbing it gets better in game but the pointer disappear totally or partially when moved
10:47:08 <TrueBrain> FLHerne: zero memories of that event ... clearly I was just having fun with andy .. some things never change :D
10:48:05 <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.
10:48:27 <TrueBrain> Wolf01: try setting in your openttd.cfg under [gui] the refresh_rate to 30
10:48:37 <TrueBrain> but yeah, it sounds like vsync trouble
10:48:51 <TrueBrain> which is annoying, as not using WM_PAINT should kinda solve that
10:48:58 <TrueBrain> michi_cc: just hurry up with OpenGL would you :P
10:53:29 <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges https://git.io/Jt9GI
10:53:32 <DorpsGek> [OpenTTD/OpenTTD] LordAro closed issue #8594: NRT - Pathfinder doesn't consider speed limits when calculating a route https://git.io/JtqIG
10:54:04 <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
10:54:15 <TrueBrain> the "lag" you experience is 30fps :)
10:54:25 <TrueBrain> but yes, in that case you are seeing vsync issues
10:54:39 <TrueBrain> from what I understand, that has always been there on Windows
10:55:03 <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
10:55:11 <Wolf01> It seem to be more horizontal tearing than vertical tearing
10:55:22 <TrueBrain> if the issues happens on the horizontal axis
10:55:25 <TrueBrain> it is vsync issue :)
10:55:35 <TrueBrain> if it is over the vertical axis, it is our dirty-stuff acting up :)
10:55:48 <TrueBrain> (screens are drawn from top left to top right, line by line to the bottom)
10:56:18 <TrueBrain> so if you see horizontal striping etc, it is vsync most of the time :)
10:57:14 <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)
10:57:19 <Wolf01> I see half pointer, like only the left part only when moving it, or alternating the top and bottom parts
10:57:20 <TrueBrain> at the end of each line is "hsync" time
10:57:34 <TrueBrain> yeah, I guess this is what you "see" indeed
10:57:44 <TrueBrain> and only when you move it quick, I assume?
10:58:07 <Wolf01> "Quick", the usual speed :P
10:58:10 <TrueBrain> try out 1.10.3 I would say, if it happens there too
10:58:36 <TrueBrain> owh, and can you try starting the game with "-v win32:no_threads"
10:58:39 <TrueBrain> does that change anything?
10:58:55 <Wolf01> Lol, 1.10.3 crashed badly at title screen, I should not mix the configs
11:00:14 <Wolf01> It crashes while scanning
11:00:46 <LordAro> would be interested in seeing the crash.log
11:07:00 <Wolf01> The crash screenshot is interesting
11:08:28 <LordAro> now, how to read the dmp...
11:08:33 <LordAro> where's glx when you want him?
11:08:53 <LordAro> 0xC0000005 means a segfault though
11:09:20 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #8711: Microsoft store version 1.10.3 crashing at start https://git.io/Jt9Kw
11:09:42 <LordAro> TrueBrain: weren't you going to get dorpsgek to decode the dmps at one point?
11:09:45 <Wolf01> I'll try to disable the automatic UI sizing, it's the only thing I changed
11:10:56 <TrueBrain> LordAro: I was .. but everyone told me it was a waste of time .. so I didn't :)
11:11:41 <michi_cc> Hmm, min/max settings clamping is broken somehow?
11:11:45 <DorpsGek> [OpenTTD/OpenTTD] Wolfolo commented on issue #8711: Microsoft store version 1.10.3 crashing at start https://git.io/Jt9Kw
11:17:59 <TrueBrain> I like how you distracted him now :)
11:35:08 <andythenorth> features are weird
11:35:23 <andythenorth> something seems big with moving parts, then suddenly...it's done
11:35:33 * andythenorth devloloper lifestyle
11:36:26 <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)
11:37:22 <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.
11:38:14 <LordAro> something to do with the "bootstrap" settings?
11:39:56 <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.
11:41:27 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on issue #8711: Microsoft store version 1.10.3 crashing at start https://git.io/Jt9Kw
12:07:31 <FLHerne> andythenorth: I showed this video to some people and none of them comprehended it :-(
12:08:39 <andythenorth> I think it's niche
12:08:51 <DorpsGek> [OpenTTD/OpenTTD] Wolfolo commented on issue #8711: Microsoft store version 1.10.3 crashing at start https://git.io/Jt9Kw
12:09:10 <andythenorth> it works for me because my kids sing the Gas Gas Gas song to my great irritation :)
12:09:11 <FLHerne> andythenorth: How can NML not suck?
12:09:21 <FLHerne> Perhaps this question is too open-ended
12:09:31 <andythenorth> FLHerne it nearly doesn't
12:09:37 <FLHerne> The abstractions are all at the wrong level
12:10:22 <andythenorth> it's proving to be a very productive tool for those of us who can (usually python) abstract it :P
12:10:56 <andythenorth> FLHerne serious answers?
12:11:23 <FLHerne> (I was trying to make it faster, but got fed up again because nothing works)
12:11:24 <andythenorth> ok it sucks on multiple levels, long list follows :P
12:11:39 <andythenorth> 1. it's horrible to extend nml, because it's horrible to extend newgrf spec
12:12:24 <andythenorth> 2. it's horrible to extend nml because it's unpleasant to write docs for it
12:12:35 <andythenorth> 3. nml is (still) relatively slow to compile
12:13:14 <andythenorth> 4. nml is very forgiving of some kinds of authoring sloppiness, and completely hostile to others, which can be confusing
12:13:45 <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
12:14:43 <andythenorth> 6. it has no kind of templating
12:15:23 <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
12:15:44 <andythenorth> 8. it has a cache, but can't speed it up with partial compiles because it has no concept of scopes
12:15:55 <Wolf01> It seem that nml only needs to be more user-friendly
12:18:10 <andythenorth> I would make a terrible language designer, but I though it should be scoped, and use a tree
12:18:50 <andythenorth> so author declares 'train' and then all switches etc are scoped to that train, unless declared global or (global procedure)
12:19:08 <andythenorth> oh it has a few weird pseudo-helpful things as well
12:19:30 <andythenorth> like auto-managing vehicle IDs, which will instantly fail for savegames when more vehicles are added
12:20:21 <andythenorth> also it seems to miss the opportunity to automatically generate basic (sparse) reference docs as html or plain text
12:20:40 <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
12:20:43 <andythenorth> e.g. from the tree, it could output something similar to grf2html
12:20:59 <TrueBrain> Wolf01: did you try if -vwin32:nothreads changes anything about the tearing?
12:21:23 <michi_cc> Wolf01: Ah, you must have changed the "maximum zoom in level" some time in the past. Was this intentional?
12:21:59 <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.
12:22:00 <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
12:22:12 <andythenorth> and then have it read something like YAML files
12:22:45 <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
12:22:52 <andythenorth> the way Jekyll / Liquid handles templates and vars (e.g. OpenTTD website) is really neat
12:23:05 <michi_cc> Wolf01: I'm not talking about the GUI scale setting.
12:23:16 <andythenorth> declaring a train, should be more like: red_train.yaml
12:23:22 <andythenorth> and then declare which template to use
12:23:28 <andythenorth> and then declare props
12:23:42 <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.
12:24:20 <Wolf01> Oh, the viewport, no, I didn't change it from the .ini, I set it to 2x/8x
12:25:09 <Wolf01> It's set to those values for ages
12:25:29 <FLHerne> I don't really know how Horse works
12:25:46 <andythenorth> I would split properties and templating
12:25:59 <andythenorth> my approach is very 'web publishing framework'
12:26:14 <andythenorth> where typically you have a html template with slots or loops in it
12:26:18 <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.
12:26:19 <andythenorth> then you feed it content
12:26:31 <andythenorth> so a train would have a template, e.g. 'steam engine with tender' or whatever
12:26:51 <andythenorth> other approaches might be better, it's just a convention I am used to
12:27:35 <andythenorth> oh I also wondered, I suspect nml is constructing some very very elaborate advanced varact2 in places, probably over and over again
12:27:44 <andythenorth> I wondered if procedures can replace any of that
12:28:06 <andythenorth> procedures have been revolutionary for the way I'm writing grfs
12:28:15 <andythenorth> so much repetition eliminated
12:28:28 <andythenorth> so much to read and write the code
12:28:54 <andythenorth> faster compiles, smaller files
12:30:50 <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
12:31:08 <Wolf01> Now I'll try with nothreads
12:31:34 <TrueBrain> the next thing on the list: set refresh_rate to 144 or something
12:31:56 <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 https://git.io/Jt9Kw
12:32:38 <Wolf01> With nothreads it does not break, no ghosting but jumps
12:34:10 *** nielsm has quit IRC (Remote host closed the connection)
12:34:55 *** roadt__ has quit IRC (Ping timeout: 480 seconds)
12:35:05 <TrueBrain> that is a bit odd .. curious what a higher refresh-rate does for you
12:35:44 <Wolf01> With 144 behaves like nothreads, 144+nothreads it's super fast, no ghosting, I can't follow it :P
12:36:10 <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.
12:36:12 <andythenorth> somehow I persuaded openttd to load a partially written grf without crashing
12:36:23 <andythenorth> half the vehicles gone, that's usually an assert :)
12:36:37 <andythenorth> I should buy a lottery ticket today
12:36:42 <TrueBrain> Wolf01: how much Hz are your displays?
12:36:58 <TrueBrain> michi_cc: we could do the old "trick" and use what-ever CPU time is left over the draw the mouse
12:37:03 <TrueBrain> but it is hacky as fuck :P
12:37:10 <Wolf01> It seem like my hardware pointer when I set the mouse resolution up to 3000
12:37:15 <TrueBrain> I am somewhat tempted to wait and see if your OpenGL patch improves the situation
12:37:23 <Wolf01> <TrueBrain> Wolf01: how much Hz are your displays? <- 60hz
12:38:07 *** Tulitomaatti has joined #openttd
12:38:24 <TrueBrain> I would have expected the GDI to sync this correctly .. bit surprised it does not
12:38:24 <michi_cc> Okay, that work around is no work-around. It limits the whole game loop to screen refresh rate :(
12:38:30 <TrueBrain> especially as we just blit the whole screen
12:38:43 <michi_cc> But it basically confirms that it is a GDI/DWM sync issue.
12:39:28 <FLHerne> andythenorth: "I suspect nml is constructing some very very elaborate advanced varact2 in places, probably over and over again" <-- it is
12:39:40 <FLHerne> Particularly for the FIRS spriteayours
12:39:47 <TrueBrain> documentation suggests you don't have to worry about syncing
12:39:50 <TrueBrain> which is clearly a lie :D
12:40:00 <TrueBrain> I will fiddle with it a bit tomorrow, see if I can reproduce at least
12:40:23 <TrueBrain> but we can also decouple mouse handling from draw-ticks
12:40:26 <TrueBrain> so we get a mouse-tick
12:40:33 <TrueBrain> should fix it for most people
12:40:42 <andythenorth> FLHerne pretty certain that can be proceduralised, they all check the same tile stuff
12:40:53 <andythenorth> mostly they just want 0 and 1
12:41:09 <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.
12:41:54 <TrueBrain> can't it be done in the draw thread?
12:42:03 <nielsm> okay got my visual studio updated
12:42:12 <nielsm> let's see if I can build ottd
12:43:51 <nielsm> the best part about the cmake change is still that building language files no longer takes forever
12:44:21 <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?
12:44:27 <nielsm> oh right... debugging symbols... going to take a while to download
12:44:36 <TrueBrain> so if people use the GDI, everything is a lot smoother
12:44:38 *** roadt__ has joined #openttd
12:45:02 <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.
12:45:46 <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?
12:45:53 <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
12:46:13 <TrueBrain> nielsm: not as big as it used to, for sure
12:47:04 <nielsm> I just had a really stupid idea for ottd on windows
12:47:12 <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.
12:47:35 <TrueBrain> michi_cc: I am still surprised it works at all
12:47:38 <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
12:47:39 <TrueBrain> it is such a bad idea :P
12:48:04 <TrueBrain> michi_cc: I always learnt to never draw anywhere not the main thread :)
12:48:07 <nielsm> also then totally replace the main menu with a toolbar
12:48:09 <milek7_> would also fix wayland though :P
12:48:15 <TrueBrain> that is why I am a bit tempted to just remove the threading code
12:48:24 <TrueBrain> nielsm: sorry, I do not follow; make a mockup? :D
12:51:41 <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
12:52:37 <michi_cc> Yes, that is definitely the more canonical way and might even allow threading on platforms like OSX.
12:52:38 <TrueBrain> I might give that a spin tomorrow, see if that changes anything
12:52:55 <TrueBrain> especially now that code is nearly all in a single place
12:57:12 <TrueBrain> stuff to improve on :D
13:02:21 <TrueBrain> now I come to think of it, flipping it around also means it works with OpenGL
13:02:41 <TrueBrain> and if we can delay more of the drawing part, the game makes more and more use of multithreaded system
13:02:46 <TrueBrain> so hmm .. yeah, that sounds like a good idea
13:04:38 <reldred> ahahahah that's kinda goofy nielsm
13:04:45 <TrueBrain> nielsm: next, borderless windowed fullscreen? :D
13:05:27 <nielsm> I said it was a stupid idea
13:05:45 <glx> what happens if you resize to minimal width ?
13:05:57 <TrueBrain> nielsm: I am so used to playing games borderless windowed, that adding that to OpenTTD would be valuable to me :)
13:06:06 <TrueBrain> but that can be without the blue bar
13:06:18 <TrueBrain> glx: I think that is a lot easier to maintain
13:06:20 <LordAro> making the toolbar disappear until you mouse over/near it might be nice
13:06:22 <nielsm> you mean resizeable border just no title bar_
13:06:23 <TrueBrain> than the battle what we are currently battling
13:06:32 <TrueBrain> nielsm: like any modern game, yes
13:06:47 <TrueBrain> well, mostly it is used in combination with fullscreen
13:06:51 <TrueBrain> but without going to fullscreen
13:06:59 <glx> TrueBrain: yeah and it's finally quite simple
13:06:59 <TrueBrain> maximized windowed borderless
13:07:10 <nielsm> well having the system buttons and a little area to move the window around will still be nice imo
13:07:32 <glx> I just need to do the same for release workflow
13:07:52 <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
13:08:21 <TrueBrain> had to look up how the rest of the world calls it: Borderless Windowed
13:08:28 <TrueBrain> I always forget the weird combination of words
13:08:31 <TrueBrain> and that is "fullscreen"
13:08:44 <TrueBrain> what is cool about it, it allows your mouse to freely move in and out of that screen
13:08:52 <TrueBrain> open any modern game and you will see it has this mode btw :)
13:08:58 <TrueBrain> Dyson Sphere Program was an exception :P
13:09:03 <glx> there are 2 fullscreen modes in today's world
13:09:18 <reldred> some don't implement it well and still capture the cursor
13:09:48 <glx> usually borderless has better support to alt-tab
13:10:30 <glx> but the other one may have direct access to GPU
13:11:14 <glx> and different resolution than desktop of course
13:12:19 <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)
13:12:30 <nielsm> i.e. whole divisors of the actual desktop resolution
13:12:36 <TrueBrain> most games don't bother with that
13:12:45 <TrueBrain> borderless windowed is just what-ever-your-native-resolution-is
13:13:08 <glx> yup borderless is a normal window, so it can only use desktop
13:13:10 <nielsm> I've seen several that allow you to render the game in lower resolution which is then upscaled
13:13:29 <nielsm> like rendering at 1080p then upscaling to 2160p
13:13:46 <Xaroth> That only works with DLSS
13:13:52 <Xaroth> and really isn't relevant for openttd.
13:16:39 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened issue #8713: Win32 OTTD2FS/FS2OTTD used from multiple threads but use a static buffer https://git.io/Jt9XE
13:21:48 <nielsm> btw can we make win32 assume wchar_t everywhere instead of trying to pretend we still compile for windows 95?
13:24:38 <Xaroth> I hear we have a volunteer
13:30:03 <TrueBrain> nielsm: sounds like the proper fix for that issue, but that is a lot more work :P
13:32:23 <milek7_> I think real 'fullscreen' modes are going away
13:32:38 <nielsm> 1.8 was the last successful win9x build right?
13:32:53 <milek7_> windows even tries to do it even when application requests direct fullscreen
13:35:18 <andythenorth> adjusting vehicle cost balance is frigging painful
13:35:30 <andythenorth> when the profit numbers don't update
13:37:50 <LordAro> the solution is relatively easy
13:42:23 <nielsm> hmm, this comment... "XXX: Hurray for MS only having an ANSI GetProcAddress function"
13:42:34 <nielsm> well yes, linker symbol names are not unicode
13:44:08 <TrueBrain> you will find in comments that in many cases the author had no idea how stuff really worked :D :D :)
13:50:14 <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)
13:50:54 <nielsm> okay WChar is a type of our own definition apparently
13:51:06 <supermop_Home> ugg dropped and chipped coffee mug
13:51:15 <supermop_Home> not quite awake
13:51:18 <milek7_> couldn't we get rid of these silly windows widechar functions?
13:51:24 <supermop_Home> despit it being alost 9
13:51:26 <milek7_> and use utf8 everywhere?
13:52:39 <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."
13:52:51 <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)
13:52:55 <LordAro> milek7_: windows will always use utf16 internally, so no, not entirely
13:53:11 <LordAro> and modifying the codepage has ...other weird results
13:53:13 <glx> milek7_: we still support windows before 10 1804
13:54:19 <glx> and yes I enabled utf8 on my windows, but it has some nasty effects with some CLI tools
13:55:32 <milek7_> setlocale sets it per-application
13:55:52 <milek7_> but yes, older windows is a problem
14:05:21 <michi_cc> Also, many of the OS functions we call are not part of the C runtime anyway.
14:07:52 <LordAro> TrueBrain: https://pasteboard.co/JPocE8u.png 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 :)
14:08:09 <TrueBrain> AND HE IS RIGHT IN DOING SO :D
14:09:55 <andythenorth> LordAro that's an awesome side effect
14:10:02 <andythenorth> pls try to retain it :)
14:10:09 <glx> if veh max speed is lower than bridge max speed anyway
14:10:44 <TrueBrain> working as intended
14:10:48 <TrueBrain> but awesome that is finally works :)
14:11:06 <LordAro> glx: yes, but it is faster than the bridge speed (32 vs 80), just not enough slower
14:11:34 * LordAro goes back to trying to work out why the vehicle list window is never invalidated
14:11:37 *** frosch123 has joined #openttd
14:11:49 *** jellyknight has joined #openttd
14:12:20 <glx> ok implemented my changes in release workflow, let's trigger a fake release
14:12:53 <andythenorth> LordAro well we know which commit introduced it :)
14:13:02 <glx> hmm but I'll wait for CI run (in case it can reuse cache)
14:13:05 <TrueBrain> awesome work there glx :D Should be a lot less buggy and "magic" :D
14:13:20 <LordAro> andythenorth: the issue is that there's nothing in there that should change anything about that
14:13:33 <supermop_Home> love to see that huge mining truck on a wood bridge
14:13:52 <glx> I kept the GNU tar workaround in release (even if it doesn't use VS2017) so it may reuse cache from CI
14:14:08 <glx> (not sure it will, but...)
14:14:14 <LordAro> TrueBrain: that was basically the rest of Zorg's comment on the original issue
14:14:35 <TrueBrain> it was? Haha, I was being sarcastic :D
14:14:46 <LordAro> i didn't read it all that closely
14:15:19 <glx> yeah it was about vehicle using roads they "should not"
14:15:39 <glx> but we don't have these limitations implemented
14:18:15 *** gelignite has quit IRC (Ping timeout: 480 seconds)
14:20:15 *** jellyknight has quit IRC (Ping timeout: 480 seconds)
14:21:39 <glx> ok it can reuse CI cache, keeping the same cache config was a good idea
14:22:35 <glx> hmm was too fast, not reusing cache
14:23:27 <LordAro> you know, i'm not sure i'm a fan of the new vehicle location button
14:24:49 <TrueBrain> if things are too small, it is time you change your GUI zoom factor :)
14:25:08 <LordAro> it's a fairly standard screen
14:25:17 <LordAro> no highdpi weirdnesses going on
14:25:48 <TrueBrain> so you need glasses :P
14:26:20 <LordAro> yes, but not for close-stuff :p
14:26:44 <frosch123> well, that "rocket gronk" video is clearly the end-scene for the next stream :)
14:26:55 *** jottyfan has quit IRC (Quit: jottyfan)
14:30:00 <glx> Warning: /Users/runner/work/OpenTTD/OpenTTD/src/video/cocoa/cocoa_v.mm:95:15: warning: unused function 'GetTick' [-Wunused-function] <-- need to check recent master, my branch is not fully up to date
14:30:54 <TrueBrain> and even then unused really
14:31:00 <TrueBrain> I thought I removed most of it ..
14:31:42 <LordAro> mm, _tEvent is set, but never read
14:32:07 *** peter1138 has joined #openttd
14:32:07 *** ChanServ sets mode: +o peter1138
14:32:10 <TrueBrain> recent change by me
14:32:18 <TrueBrain> there was a lot of debugging timing stuff in the OSX driver
14:32:41 <glx> there was a lot of weird thing in OSX driver ;)
14:34:16 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain opened pull request #8714: Codechange: [OSX] remove final bits of old debugging code https://git.io/Jt9Dy
14:34:24 <TrueBrain> did not compile it myself, so lets see if the CI agrees with my change :)
14:36:38 <glx> building OSX release is slow (of course it's building 2 arch)
14:41:45 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8714: Codechange: [OSX] remove final bits of old debugging code https://git.io/Jt9yU
14:42:19 <glx> TrueBrain: should I also use "cmake --build ." for all ?
14:42:32 <TrueBrain> but that is my opinion :D
14:43:44 <TrueBrain> could always influence it by setting MAKEFLAGS ofc
14:44:18 <TrueBrain> no, it runs -j1 it seems from a local test :)
14:44:30 <TrueBrain> cmake --build accepts -j
14:46:21 <glx> yes --parallel [<jobs>], -j [<jobs>]
14:58:29 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #8714: Codechange: [OSX] remove final bits of old debugging code https://git.io/Jt9Dy
15:12:46 <DorpsGek> [OpenTTD/OpenTTD] stormcone commented on pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges https://git.io/Jt9Sm
15:13:32 <TrueBrain> haha, someone is asking for the magic 4 :D
15:13:59 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8710: Fix road pathfinder behaviour with speed limits on roadtypes/bridges https://git.io/Jt9Sc
15:14:03 <TrueBrain> I was surprised there was no comment at the rail PF about it
15:16:18 <LordAro> i think the tiles_skipped accounts for the bridgeheads, so it's not that
15:16:25 <LordAro> maybe just arbitrarily increasing the cost?
15:16:31 <TrueBrain> at least 1 of them is from the tile itself
15:16:40 <TrueBrain> the other 3 ... shrug
15:16:46 <TrueBrain> sounds like the cost is overestimating this way
15:16:53 <TrueBrain> but I am sure it is not the only weird thing in the PF :)
15:21:52 <nielsm> progress: it compiles and doesn't crash violently
15:22:01 <nielsm> but doesn't find any language files either
15:23:49 <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
15:28:17 <glx> because language files not found is typical to "Visual Studio" cmake generators IIRC
15:30:14 <nielsm> the same build worked before I started editing all the file handling code
15:30:57 <glx> then I guess you are using Ninja (default in "open folder" mode)
15:31:30 <glx> so yeah, your changes broke something :)
15:36:48 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
15:38:29 <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
15:38:49 <nielsm> but if I store the return from FS2OTTD or OTTD2FS into a local variable then it works
15:39:24 <nielsm> shouldn't the returned temporary be scoped to the scope it's returned inside?
15:39:35 <nielsm> or is that me misunderstanding something?
15:39:39 <glx> ah yes I noticed things like that before
15:39:57 <LordAro> shouldn't have an issue returning a function-local std::string
15:42:04 *** jottyfan has joined #openttd
15:42:24 <DorpsGek> [OpenTTD/OpenTTD] LordAro opened pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed https://git.io/Jt99a
15:43:12 <LordAro> glx: i think there are issues with calling c_str on a temporary
15:43:20 <LordAro> as the object is immediately destructed
15:43:33 <LordAro> and/or goes out of scope
15:44:11 <glx> maybe it's the same for return if it's not stored anywhere
15:44:23 <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
15:44:40 <LordAro> c_str isn't a copy - if you haven't made your own copy, it'll disappear
15:47:52 <nielsm> I guess it's only scoped to the statement then, the string object?
15:50:43 <nielsm> unix.cpp also has some unsafe iconv code using a global
15:51:38 <glx> oups ubuntu 18.04 cmake is too old to support -j
15:54:28 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on issue #8713: Win32 OTTD2FS/FS2OTTD used from multiple threads but use a static buffer https://git.io/Jt9XE
15:58:58 <michi_cc> .c_str() is basically just the internal pointer. For it to remain valid, the object must stay around, too.
15:59:20 <nielsm> yes the question was about the lifetime of the object
16:05:30 <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 https://en.cppreference.com/w/cpp/language/eval_order would read to me that the temporary does not survive into the function body.
16:06:49 <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.
16:09:10 <DorpsGek> [OpenTTD/OpenTTD] nielsmh opened pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9Ha
16:11:46 <LordAro> ideally those changes would be separate commits
16:12:02 <nielsm> yeah I know, that's why I made it a draft so far
16:18:54 <DorpsGek> [OpenTTD/OpenTTD] nielsmh updated pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9Ha
16:30:07 <andythenorth> the mac performance improvements also yield when openttd is paused and in the background btw michi_cc
16:30:09 <glx> ahah looking at the diff I new some platform won't build, and it seems only macos is using iconv
16:30:30 <andythenorth> openttd is sitting at 1.3% of one thread unit right now, it used to sit at 5-10% paused
16:30:40 <andythenorth> was a constant tiny battery lag
16:30:40 <TrueBrain> far less drawing :)
16:30:49 <TrueBrain> where is my love for that?! :P
16:31:18 <andythenorth> I disabled the emoji bar on this mac so I can play openttd
16:31:40 <TrueBrain> now that is better!
16:31:48 <andythenorth> emojibar support anyone? :P
16:31:54 <andythenorth> emojibar, such a turkey
16:32:20 <michi_cc> Is that a codeword for touch bar, or it there some other bar?
16:32:21 <glx> so using cmake, ctest and cpack everywhere mostly work, except for ubuntu 18.04
16:33:33 <andythenorth> for adding emojis
16:33:46 <andythenorth> and silently turning off your screen, or sound, or accidentally locking the mac
16:34:13 <andythenorth> a totally flat surface, right next to the number keys, with no haptic or audio feedback
16:34:14 <DorpsGek> [OpenTTD/OpenTTD] nielsmh updated pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9Ha
16:37:08 <LordAro> we can probably cope with a slightly slower compilation for 18.04 for now
16:37:25 <LordAro> alternatively, MAKEFLAGS is universal
16:38:06 <glx> I can probably go with MAKEFLAGS to work around yes
16:44:32 <glx> oh I can also try adding -- so -j is not handled by cmake
16:44:55 <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed https://git.io/Jt99a
16:47:24 <DorpsGek> [OpenTTD/OpenTTD] LordAro opened pull request #8717: Fix #8349: Close depot vehicle list windows when closing the depot window https://git.io/Jt97e
16:54:39 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible https://git.io/Jt970
16:55:29 <LordAro> we can probably close #8300 now, right?
16:57:44 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on issue #8292: Game cutting of savefile name after charecters with diacritics. https://git.io/JJMxx
16:57:47 <DorpsGek> [OpenTTD/OpenTTD] LordAro closed issue #8292: Game cutting of savefile name after charecters with diacritics. https://git.io/JJMxx
16:59:11 <frosch123> nielsm: the static code checker on gh found some valid issues in 8716
17:01:44 <andythenorth> close that *******
17:14:42 <DorpsGek> [OpenTTD/OpenTTD] nielsmh updated pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9Ha
17:18:48 *** magla has quit IRC (Remote host closed the connection)
17:20:40 <andythenorth> right what am I doing?
17:21:13 <Eddi|zuHause> if you don't know...
17:24:17 *** snail_UES_ has joined #openttd
17:24:52 <andythenorth> finishing Restaurant Cars apparently
17:30:12 <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 https://git.io/Jt959
17:31:25 <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
17:32:58 <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
17:34:32 <DorpsGek> [OpenTTD/OpenTTD] LordAro opened pull request #8719: Fix #8276: Crash when a NewGRF object's size was not set https://git.io/Jt95b
17:35:42 <DorpsGek> [OpenTTD/OpenTTD] btzy commented on pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed https://git.io/Jt95p
17:38:27 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9dt
17:39:03 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed https://git.io/Jt9dq
17:41:45 <DorpsGek> [OpenTTD/OpenTTD] btzy commented on pull request #8715: Fix: Vehicle list windows did not update when this year's profit changed https://git.io/Jt9dG
17:49:47 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8706: Feature: rail station class name filtering https://git.io/Jt9dz
17:50:16 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9dV
17:51:54 *** jottyfan has joined #openttd
17:55:45 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #8717: Fix #8349: Close depot vehicle list windows when closing the depot window https://git.io/Jt9dh
17:55:59 <DorpsGek> [OpenTTD/OpenTTD] stormcone commented on pull request #8706: Feature: rail station class name filtering https://git.io/Jt9dj
17:57:19 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9FT
17:58:23 <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #8717: Fix #8349: Close depot vehicle list windows when closing the depot window https://git.io/Jt97e
17:58:48 <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
17:59:18 <Eddi|zuHause> did you reach 1000 rating?
17:59:26 <Eddi|zuHause> or 100% coverage?
18:00:12 <Wolf01> I did not bankrupt until 2050, that's all, and I played with some different NRT roads too
18:01:03 <Wolf01> Just a wood chain to try the performance :P
18:04:31 *** jottyfan has quit IRC (Quit: jottyfan)
18:09:40 <frosch123> ahahahaha, timberwolf submitted a titlegame entry showing the new terrain generator
18:10:09 <Wolf01> New terrain generator?
18:10:29 <frosch123> desert at tile height > 4
18:10:36 <frosch123> i think that is new, isn't it?
18:10:55 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #8719: Fix #8276: Crash when a NewGRF object's size was not set https://git.io/Jt9FF
18:11:15 <frosch123> hmm, otoh, i think that map was made with scenario eidtor
18:11:33 <frosch123> desert is not close to the ocean otherwise
18:14:02 *** Wormnest has joined #openttd
18:15:01 <DorpsGek> [OpenTTD/OpenTTD] frosch123 approved pull request #8719: Fix #8276: Crash when a NewGRF object's size was not set https://git.io/Jt9bO
18:16:12 <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #8719: Fix #8276: Crash when a NewGRF object's size was not set https://git.io/Jt95b
18:17:58 *** Progman has joined #openttd
18:24:49 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9bd
18:33:53 <DorpsGek> [OpenTTD/OpenTTD] nielsmh updated pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9Ha
18:34:29 <TrueBrain> I so hope the correct answer is: nevah!
18:39:31 <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #8706: Feature: rail station class name filtering https://git.io/Jt9ev
18:43:32 *** qwebirc21041 has joined #openttd
18:45:40 <nielsm> hmm okay I think there's 3 separate changes in that PR, I need to separate out
18:46:23 <nielsm> there's some stuff in crashlog_win32.cpp changing how allocations are done, that's mostly stand-alone (removes dependency on OTTD2FS)
18:46:39 <nielsm> then there's simplifying win32 by always assuming UNICODE
18:46:55 <nielsm> and then the actual changing OTTD2FS and FS2OTTD
18:57:49 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8706: Feature: rail station class name filtering https://git.io/Jt9AJ
18:57:55 *** qwebirc21041 has quit IRC (Remote host closed the connection)
19:00:27 <DorpsGek> - Update: Translations from eints (by translators)
19:01:16 *** jottyfan has joined #openttd
19:35:50 *** gelignite has joined #openttd
19:45:39 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick updated pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible https://git.io/JLHah
19:49:04 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible https://git.io/Jt9ps
19:49:18 <DorpsGek> [OpenTTD/OpenTTD] SamuXarick commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible https://git.io/Jt9pG
19:51:47 <peter1138> "Fix" "Make ... possible" hmm
19:52:21 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible https://git.io/Jt9pl
19:52:46 <LordAro> peter1138: my bike is broken :(
19:53:19 <peter1138> I broke its heart by not riding it.
19:53:48 <LordAro> i've done less than 100 miles in the last 2 months
19:54:17 <peter1138> Same. Well, zero is less than 100 ...
19:54:55 <LordAro> anything particular stopped you, or...?
19:55:07 <peter1138> Weather, laziness, working from home, etc...
19:55:21 <peter1138> Oh and lockdown. "Stay local"
19:56:16 <Wolf01> I've got covid instead :(
19:56:27 <LordAro> eh, that's only ever mattered if you actually went in anywhere. less of an issue on a bike
19:56:40 <LordAro> the weather this past month has been particularly awful though
19:58:39 <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.
19:59:16 <LordAro> i can understand that
19:59:19 <peter1138> Then once you've had a month or so off and it's getting cold, just... couldn't be arsed with it.
20:01:06 <peter1138> Still, at least the bike hasn't been ruined by shitty winter weather. Silver linings!
20:01:36 <LordAro> mine spent a month in the garage and the bearings haven't forgiven me
20:01:55 <LordAro> (which were dying anyway)
20:05:23 <DorpsGek> [OpenTTD/OpenTTD] stormcone commented on pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible https://git.io/Jt9pH
20:13:32 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #8716: Fix #8713: Change OTTD2FS and FS2OTTD to return string objects https://git.io/Jt9hs
20:14:47 <peter1138> Windows 95 is 25 years ago, isn't this a bit premature?
20:22:40 <LordAro> the hard bit would be finding a c++17 compiler that supports win9x
20:22:44 <TrueBrain> 1st of april nielsm ? :D
20:23:09 <LordAro> TrueBrain: speaking of, RC1 when?
20:23:10 <nielsm> I think removing windows 95 support officially will be a good 2.0 feature
20:23:25 <TrueBrain> LordAro: I was hoping that we could merge OpenGL before RC
20:23:30 <TrueBrain> but I am looking at michi_cc here if that is realistic
20:23:36 <TrueBrain> was I think we should RC before the end of the month
20:23:58 <TrueBrain> was? because .. lol
20:24:03 <TrueBrain> brain faster than hands ..
20:24:39 <michi_cc> TrueBrain: It's mostly a question of how fast how many people can test.
20:25:01 <TrueBrain> we have seen that can be done pretty quickly :)
20:25:07 <TrueBrain> and to be clear, I don't expect we get it right the first time ..
20:25:13 <TrueBrain> the 60fps already had 2 fixes ;)
20:25:41 <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.
20:26:14 <TrueBrain> would it be possible to have the PR reviewable, without OSX in that case?
20:26:19 <TrueBrain> just so we can start testing the other OSes?
20:28:49 *** Tirili has quit IRC (Remote host closed the connection)
20:33:00 <supermop_Home> man what the hell was I trying to do here: "switch (FEAT_ROADVEHS, SELF, switch_pickup_box, var[0xBF,0,0xFF]) { "
20:33:31 <supermop_Home> it looks like pick the color of a box on the truck by something, but what and why
20:39:27 <andythenorth> whatever var BF is :D
20:39:37 <andythenorth> is that 80+ vars?
20:39:41 * andythenorth can't be bothered to look it up
20:40:32 <supermop_Home> i have no idea why i was trying to do some magic with the box in the bed of a pickup truck
20:45:32 <supermop_Home> there is no variable for vehicle_is_decelerating huh
20:45:50 <supermop_Home> there is braking but only for trains
20:46:00 <Eddi|zuHause> yes, BF is a 80+ var
20:46:27 <supermop_Home> i guess that mean no fun splashes for the logs in the log flume
20:46:47 <frosch123> supermop_Home: that's because there is no braking for road vehicles in ottd
20:46:50 <frosch123> they stop instantly
20:48:46 <supermop_Home> can you have a switch based on the day of the year that a RV was bult?
20:49:39 <frosch123> there is only a build_year
20:49:46 <frosch123> the exact date is not remembered
20:50:46 <Eddi|zuHause> are you sure? i thought age is counted more fine grained than just year?
20:51:38 <frosch123> oh, age... funny how we store things redundantly
20:51:52 <frosch123> there is an absolute and an relative build date :p
20:52:11 <supermop_Home> Eddi|zuHause if that is true there is no documented way to run a switch off that afaict
20:52:22 <glx> haha of course it compiled, it's "dead code"
20:52:56 <frosch123> supermop_Home: var B0 :)
20:53:45 <frosch123> but it's clamed to 64k days
20:53:56 <DorpsGek> frosch123: 179.4277891854894
20:54:21 <frosch123> so you don't know the build_date after 180 years
20:54:34 <supermop_Home> well my idea was to give the RV a special livery if you bought it in the last week of october
20:54:45 <supermop_Home> no idea how workable that is
20:54:55 <andythenorth> the halloween truck
20:55:22 <frosch123> it will break after 180 years, but as long as it is only visual, it won't desync
20:55:53 <supermop_Home> well the paint will probably rust off in 180 years anyway
20:56:16 <frosch123> people say 180 years can pass in a few seconds...
21:05:52 *** Tirili has quit IRC (Remote host closed the connection)
21:07:54 <andythenorth> that's a train tick increase, isn't that completely isolated from the video loop change?
21:09:01 <glx> more drawing, less time to compute
21:09:20 <TrueBrain> no, train ticks take longer glx
21:09:25 <TrueBrain> like the time of a single tick
21:09:30 <TrueBrain> that cannot be caused by more drawing :)
21:09:53 <andythenorth> I am curious if we have some other performance regression recently
21:10:13 <TrueBrain> we still have to finish that savegame archive :D
21:10:24 <andythenorth> I have a relatively small savegame (161 trains) but stopping the trains makes a huge difference to FFWD speed
21:10:32 <andythenorth> subjectively more than it used to
21:10:43 <andythenorth> but that's a crap judgement because Mac FFWD used to be about 8x at best :P
21:10:48 <glx> ideally he should compare with beta, not 1.10.3
21:11:01 <TrueBrain> well, still it is a question why trains take 25% longer
21:11:05 <TrueBrain> that feels weird :P
21:11:16 <glx> yeah but maybe it happens in beta too
21:11:52 <TrueBrain> absolutely something to check out
21:11:54 <TrueBrain> and bisect it otherwise :D
21:12:13 <glx> everything in game loop seems slower in the screenshot
21:12:42 <glx> more visible for trains because many of them
21:14:01 <TrueBrain> then I am still not 100% sure what those ms mean
21:14:10 <TrueBrain> but I assume it is the time between when the variable comes in scope and goes out of scope
21:14:30 <TrueBrain> nielsm: am I right in that assumption? Do ticks mean how long the PFE variable was in scope?
21:15:23 <nielsm> yes the time taken is how long the PerformanceMeasurer was in scope
21:15:33 <TrueBrain> averaged over the amount of time it happens
21:15:58 <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
21:16:09 <TrueBrain> that makes little sense to me .. the "ms" per tick should remain the same, not?
21:16:27 <nielsm> yes I'm not sure what makes his game run faster there
21:16:42 <TrueBrain> well, all his screenshots have this
21:16:54 <nielsm> the "train ticks" is how long the code to move trains around takes to run per iteration of the game loop
21:16:55 <TrueBrain> so there seems to be a relation between frames/s and "ms"
21:17:38 <TrueBrain> sorry glx, I was jumping the gun there .. it indeed does not seem to mean that the train are the cause perse
21:17:40 <nielsm> yes the simulation of trains somehow got 4x faster between those two versions
21:18:44 <TrueBrain> I need to get a better grasp on what it all means myself :) I am assuming waaayyyyy too much :P
21:21:58 <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
21:22:25 <TrueBrain> it is weird that the "ms" correlates with the simulation rate, not?
21:22:28 <TrueBrain> would that just be pure luck?
21:22:39 <nielsm> no that's exactly what it does
21:23:06 <TrueBrain> if I run the game 4x my normal speed, the time, per tick, it spends on train ticks remains the same, not?
21:23:22 <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
21:23:32 <michi_cc> TrueBrain: Assume I have broken SDL while rebasing :D I haven't even compiled with SDL.
21:23:49 <TrueBrain> michi_cc: well, CI will tell you soon enough :P
21:23:52 <TrueBrain> I will test it tomorrow :)
21:24:35 <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
21:24:42 <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.
21:25:41 <TrueBrain> nielsm: somewhere in my mind there still is a crash :D
21:25:46 <TrueBrain> what-ever, english hard
21:26:08 <nielsm> when you run the game on ffwd, then the game loop time should be inverse proportional to the simulation rate
21:26:15 <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)
21:26:30 <nielsm> assuming the rendering/output stages don't cost too much
21:26:40 <nielsm> yes that's exactly right
21:26:54 <TrueBrain> so that makes me wonder ... did we change anything that makes 1.11 4 times faster?
21:27:05 <nielsm> yeah that's the weird thing
21:27:05 <TrueBrain> I guess it is possible
21:27:33 <nielsm> or can there be a difference in compiler (that somehow makes things that much better)?
21:27:55 <TrueBrain> that would make much more sense, honestly
21:28:00 <nielsm> 1.10.3 shouldn't be a debug build tho
21:28:07 <TrueBrain> 1.10 is build old-style
21:28:12 <TrueBrain> 1.11 is build new-style (CMake etc)
21:28:14 <TrueBrain> might also be a reason
21:28:26 <_dp_> are you sure it calculates avg durations correctly?
21:28:28 <TrueBrain> okay, that would add up a lot more
21:28:33 <nielsm> should still be same compiler and same LTO
21:28:44 <TrueBrain> no clue honestly .. we now let CMake do the right thing :)
21:29:51 <andythenorth> michi_cc does it need testing?
21:30:12 <michi_cc> Yes, I could have broken something for real hardware.
21:30:15 <JGR> The 4x faster is most likely because that test is using Timberwolf's trains, and the sprite caching changes were added since then
21:30:54 <andythenorth> michi_cc 7744 as above?
21:31:42 <TrueBrain> JGR: that makes a lot more sense :D
21:31:59 <TrueBrain> well, for the user that is transparent of course, knowing what causes a speed improvement is not always as clear :)
21:32:30 <LordAro> do nightlies still have asserts enabled?
21:32:37 <LordAro> that difference might be enough
21:32:44 <michi_cc> SDL is broken right now, but that doesn't affect OSX.
21:33:08 <TrueBrain> LordAro: they should, yes
21:35:16 <andythenorth> michi_cc fatal errors in build, you want the paste?
21:35:24 <andythenorth> looks like GL stuff at first glance
21:36:14 <nielsm> yeah drawing the trains makes a huge difference on that savegame with PKS
21:36:32 <michi_cc> Interesting, especially since CI actually passed for OSX.
21:36:46 <andythenorth> $10 it's XCode nonsense?
21:36:52 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
21:37:05 <michi_cc> And also because I didn't actually touched the headers in that file in the recent rebase.
21:37:13 <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
21:37:25 <TrueBrain> that is a nice improvement :)
21:37:32 *** WormnestAndroid has joined #openttd
21:37:36 <andythenorth> michi_cc my build relies on CPLUS_INCLUDE_PATH="/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include"
21:37:49 <andythenorth> dunno if that's relevant here
21:38:08 <andythenorth> nielsm what if you stop the trains?
21:38:21 <andythenorth> it's interesting how effective stopping trains is in my game
21:38:58 <andythenorth> (bit limiting for fun game...but look at the ffwd speed!)
21:39:08 <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.
21:39:19 <michi_cc> Possibly do a clean / delete the build dir?
21:39:27 <andythenorth> yeah my build does that
21:39:29 <nielsm> 2-3x speedup of ffwd by stopping the trains
21:39:30 <andythenorth> but I'll try again
21:40:23 <andythenorth> from configuration output
21:40:25 <andythenorth> -- Found OpenGL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/OpenGL.framework found components: OpenGL
21:42:26 <michi_cc> Same SDK path as for me, and that result in including the right header that has the types it complains about.
21:42:33 <michi_cc> And apparently for the CI as well.
21:43:27 * andythenorth looks up how to get the xcode version report
21:43:54 <andythenorth> Build version 12A7403
21:45:26 <andythenorth> google not producing much
21:50:37 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
21:50:38 <andythenorth> michi_cc I can look more tomorrow night? It's usually some path issue
21:50:55 <andythenorth> usually google turns up a clue in the end
21:51:09 <michi_cc> Probably. Work for me and works for the CI, so I'm afraid I can't really help.
21:55:19 <andythenorth> ok, so I know play styles vary
21:55:28 <andythenorth> but I mostly play 256x256 or 256x512
21:55:35 *** Samu has quit IRC (Quit: Leaving)
21:55:37 <andythenorth> so cargo aging barely moves the needle
21:55:54 <andythenorth> charts show same
21:56:21 <_dp_> sh125 is too fast for 256
21:56:47 <andythenorth> I tested a lot locally
21:56:54 <DorpsGek> [OpenTTD/OpenTTD] Milek7 opened pull request #8721: Fix: Allow building with Allegro and without SDL on Linux https://git.io/JtHfy
21:56:56 <andythenorth> 75mph you can see difference on 100 tile route
21:56:56 <supermop_Home> 160 Imprezas, with 3 passengers each, will turn a slight profit eventually over longer distances..
21:57:05 <_dp_> thouh it's diagonal so 512 on 256x256
21:57:07 <supermop_Home> so long as there are no speedlimits
21:58:07 <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #8721: Fix: Allow building with Allegro and without SDL on Linux https://git.io/JtHf7
21:58:43 <supermop_Home> andythenorth how should i hide this Subaru so people can't find it right away?
21:59:30 <andythenorth> do the buy menu sprite as a crate
21:59:41 <andythenorth> and then the vehicle is a surprise (random)
21:59:54 * andythenorth plays too many games with crates
21:59:58 <andythenorth> they're a plague
22:00:20 <supermop_Home> currently its a 3 in 256 chance that you get a team 555 one
22:00:29 <supermop_Home> otherwise its a regular wrx
22:00:45 <supermop_Home> i guess i could also take off the spoiler and make it slower
22:01:07 <andythenorth> OpenTTD FEATURE REQUEST
22:01:17 <supermop_Home> kei van with 1 in 100 chance of being a rally car?
22:01:29 <andythenorth> 'build surprise vehicle' button when purchase menu is filtered by cargo
22:01:43 <supermop_Home> currently the rally car and the regular have the same speed and hp
22:02:06 <supermop_Home> and number of seats
22:02:42 <supermop_Home> what i really need is a vehicle that is allowed to ignore speedlimits when on DIRT
22:04:13 <supermop_Home> ok may need to nerf it or mess with cargo decay
22:04:37 <supermop_Home> I've now earned 2M quid from this swarm of subarus
22:13:15 <supermop_Home> maybe 200 kmh is a little too generous
22:13:48 <supermop_Home> random bits for an RV are the same for all switches?
22:14:09 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:14:45 *** WormnestAndroid has joined #openttd
22:15:47 <Eddi|zuHause> supermop_Home: random bits are per vehicle part
22:18:12 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:29:03 *** Progman has quit IRC (Remote host closed the connection)
22:30:32 *** mirrorbird has joined #openttd
22:30:45 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:31:19 *** Tirili has quit IRC (Remote host closed the connection)
22:37:52 *** gelignite has quit IRC (Quit: Stay safe!)
22:39:05 *** mirrorbird has quit IRC (Ping timeout: 480 seconds)
22:39:18 *** sla_ro|master has quit IRC ()
22:50:27 *** jottyfan has quit IRC (Quit: jottyfan)
22:58:23 *** mirrorbird has joined #openttd
23:05:46 <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8721: Fix: Allow building with Allegro and without SDL on Linux https://git.io/JtHIv
23:05:53 <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #8721: Fix: Allow building with Allegro and without SDL on Linux https://git.io/JtHfy
23:08:53 *** andythenorth has quit IRC (Quit: andythenorth)
23:10:15 <NGC3982> any suggestion on available newgrf's containing "lots of trains"?
23:10:25 <NGC3982> my players demands it and i shalt supply it
23:11:35 *** Tirili has quit IRC (Remote host closed the connection)
23:30:30 <FLHerne> NGC3982: 2cc was the traditional one, being international and huge
23:30:53 <FLHerne> Timberwolf's has lots of UK trains
23:31:24 <FLHerne> Iron Horse has lots compared to the default set, but is a bit more sane
23:32:02 <FLHerne> UKRS2 and UKRS2+, or NARS, or both
23:32:56 <FLHerne> I think Dutch Trainset is pretty big
23:33:11 <FLHerne> (and definitely add Dutch Stations + the additions, those are great)
23:36:37 <LordAro> pathfinder pays attention to order speed limits: yay/nay?
23:36:59 <LordAro> (that feature of timetables that even fewer people use than timetables themselves)
23:37:32 <FLHerne> But tbh I've used them in about two games ever
23:38:12 <LordAro> (see the text and/or save in #8594)
23:38:17 <FLHerne> They're slightly useful for equalizing train speeds, if the rail speed limit doesn't do it for you
23:38:40 <LordAro> the actual implementation is a single line addition
23:38:57 <FLHerne> Also, I think it's "yea" /pedant
23:39:02 <LordAro> also not sure how it will interact with path caches
23:39:41 <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
23:41:15 <FLHerne> How is pathfinder supposed to "fix" there being a compatible road with a higher speed limit that's Wrong?
23:41:24 <FLHerne> There's a long explanation, but it doesn't make sense :p
23:42:07 <LordAro> https://pasteboard.co/JPrXzha.png 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 :)
23:42:20 <LordAro> FLHerne: oh you can ignore most of the text :p
23:42:36 <LordAro> "road classes" are not a thing anywhere
23:42:40 <FLHerne> tbc, by "take into account" you mean "treat all speed limits as max(road limit, order limit)" ?
23:44:16 <FLHerne> Then yeah, if it's simple to implement and doesn't break, it seems obviously Right to me
23:44:24 <FLHerne> Unless I missed something
23:46:23 <LordAro> actually, i think i did it slightly wrong
23:46:30 <LordAro> just 2 changed lines, rather than adding 1 :)
23:49:15 *** k-man has quit IRC (Quit: WeeChat 3.0)
continue to next day ⏵
