Config
Log for #openttd on 1st May 2021:
Times are UTC Toggle Colours
00:11:16  <DorpsGek> [OpenTTD/OpenTTD] Milek7 opened pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3Z33
00:25:48  <DorpsGek> [OpenTTD/OpenTTD] Milek7 updated pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3Z33
00:28:21  <DorpsGek> [OpenTTD/OpenTTD] Milek7 updated pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3Z33
00:33:14  <DorpsGek> [OpenTTD/OpenTTD] Milek7 updated pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3Z33
00:42:30  <DorpsGek> [OpenTTD/OpenTTD] MiguelHorta opened issue #9156: d4f0b6f requires cmake 3.12 https://git.io/J3Zcw
00:49:33  *** iSoSyS has joined #openttd
00:51:15  *** Progman has quit IRC
01:11:51  *** HerzogDeXtEr has quit IRC
01:26:51  <DorpsGek> [OpenTTD/OpenTTD] Milek7 updated pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3Z33
01:58:16  *** iSoSyS has quit IRC
02:25:29  *** Wormnest has quit IRC
02:50:39  *** glx has quit IRC
03:01:25  *** debdog has joined #openttd
03:04:45  *** D-HUND has quit IRC
03:39:42  *** Wuzzy has quit IRC
03:41:02  <DorpsGek> [OpenTTD/OpenTTD] odisseus commented on issue #9145: Some wagons dissappeard after few years https://git.io/J3Ge8
04:33:49  *** Flygon has joined #openttd
04:50:48  *** snail_UES_ has joined #openttd
05:04:51  *** orudge has quit IRC
05:25:16  <DorpsGek> [OpenTTD/OpenTTD] ccapitalK commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3ns5
05:38:55  *** snail_UES_ has quit IRC
05:52:30  <peter1138> forums eh?
06:03:35  *** nielsm has joined #openttd
06:12:06  <peter1138> morning
06:15:17  *** snail_UES_ has joined #openttd
06:19:50  *** snail_UES_ has quit IRC
06:32:28  <didac> morning!
06:32:57  <peter1138> It is
06:34:09  <peter1138> Alright, DSR for testing stupidly high resolutions?
06:36:14  <peter1138> Hmm, no, I get glitching with DSR enabled.
06:41:53  <peter1138> Integrating arbitrary sprite scaling is going to need a rework :/
06:49:25  <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #9043: Feature: ability to build overlapping bridges on different axes (WIP) https://git.io/J3ngn
06:50:49  *** didac has quit IRC
06:51:39  *** andythenorth has joined #openttd
06:54:50  <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #9043: Feature: ability to build overlapping bridges on different axes (WIP) https://git.io/J3ngp
06:54:51  <peter1138> Mr Andy.
06:54:55  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3ngj
06:55:18  <peter1138> Texture Atlas?
06:55:42  <andythenorth> is that a sprite sheet?
06:55:44  <peter1138> Meh, too blitter specific.
06:55:46  <peter1138> Yes it is.
06:57:02  <peter1138> Fundamentally different way to dealing with sprites.
06:59:18  <peter1138> It's strange, we still draw the screen pixel by pixel, but computers are fast enough to not really care.
07:00:39  <DorpsGek> [OpenTTD/OpenTTD] ccapitalK commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3n2Q
07:23:09  <TrueBrain> ugh, we should continue splitting things that require a lock on the game-state from things that don't ..
07:23:23  <TrueBrain> wish I had more time in a day :P
07:24:13  <TrueBrain> michi_cc: do you remember, the VideoBufferLocker a screenshot does, is that really needed for all screenshots? Or only the "current viewport" screenshot?
07:25:16  <TrueBrain> I mostly keep wondering if we shouldn't just delay the "current viewport" screenshot till the next scene has been drawn, and remove all this special extra locking :P
07:26:01  <nielsm> yeah just putting the screenshot in a queue would make more sense
07:26:12  <TrueBrain> #9155 builds the hack we already have further out .. I rather make them smaller :D
07:27:12  <nielsm> at some point maybe just make a general queue of actions that need to run next time out of the game loop
07:27:22  <nielsm> instead of a hundred flags
07:27:27  <TrueBrain> haha, yeah, we (michi and I) talked about that for a few times already :D
07:27:38  <TrueBrain> as we keep having these things that really one of the two should handle
07:27:46  <TrueBrain> but so far we also found that most disappear if you just change the logic slightly
07:27:50  <Rubidium> yeah, instead of making things harder to get right, make it harder to get them wrong :)
07:28:13  <TrueBrain> Rubidium: especially when it comes to mutexes, yes :D
07:29:31  <TrueBrain> looking at the code, I think it really is only "current viewport" screenshot that needs the lock .. but the code is hard to follow
07:30:32  <TrueBrain> it is called "MakeSmallScreenshot", but that name is misleading :D
07:30:52  <TrueBrain> it calls "CurrentScreenCallback", which is a better name
07:32:27  *** orudge has joined #openttd
07:36:03  <TrueBrain> morning orudge ; are the contracts with GOG etc signed?
07:36:16  <TrueBrain> I no longer saw email traffic of that in info@, so I am mainly just curious :)
07:37:20  *** Wolf01 has joined #openttd
07:37:42  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3nP9
07:38:01  <TrueBrain> to also put what we wrote on IRC in GitHub :)
07:39:35  <LordAro> "signalling to next tick" would also allow us to actually hide the screenshot window
07:39:53  <TrueBrain> and have the same flow no matter where the request comes from :D
07:39:56  *** Progman has joined #openttd
07:41:20  <TrueBrain> it would also mean "LockVideoBuffer" becomes an implementation detail
07:41:45  <TrueBrain> it always warms my heart when things become implementation details, instead of API details :D
07:42:52  <TrueBrain> right .. what to do today .. continuing with STUN or leveling another Path of Exile char ... hmm
07:42:54  <TrueBrain> trick question
07:44:47  <peter1138> Yes, the queue thing was the first thing to come to my mind too.
07:47:33  <TrueBrain> guess we are all in agreement; now someone to build it :P
07:48:34  *** crem3 has quit IRC
07:52:06  *** crem has joined #openttd
07:55:25  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9011: Feature: make NewGRF active list react on key presses https://git.io/J3nDk
08:03:52  *** sla_ro|master has joined #openttd
08:12:43  <Rubidium> any strong opinions about #8982 (text filter for the industry GUI)? The current incarnation of the patch is as shown in the description, however I personally like the edit box aligned to the right (example in the bottom part of the comment with image)
08:12:43  <peter1138> Hmm, we reset the font cache a lot.
08:15:08  <peter1138> The filter could fill to fit the available soace.
08:15:09  <peter1138> space.
08:15:11  <TrueBrain> Rubidium: maybe good to check how / where other windows do this, so it is at least semi-consistent? (I really do not know, I haven't been following adding these boxes everywhere at all :P )
08:16:36  <peter1138> sign list fills the widget, but has the filter... at the bottom.
08:17:07  <peter1138> Town directory... not sure, that window isn't resizable horizontally for some reason. But it fits the space it has, at least.
08:17:08  <Rubidium> ... with an additional button for matching case
08:17:16  <peter1138> Yeah, that's odd
08:17:57  *** erle- has joined #openttd
08:17:59  <peter1138> On the file save/load windows, it fits the space too.
08:18:14  <peter1138> And the multiplayer window, although the layout it slightly different there.
08:18:22  <peter1138> So I would suggest... fit the space :)
08:22:16  <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #8982: Feature: text filter for the industry directory https://git.io/J3n79
08:22:20  <peter1138> So I have ;P
08:27:45  <peter1138> Is there a cmake flag I'm missing to compile using all cores?
08:27:57  <TrueBrain> make -j9
08:28:03  <TrueBrain> CMake only generates project files
08:28:07  <peter1138> That's not a cmake flag.
08:28:12  <TrueBrain> it is up to the generated project file to do these kind of things
08:28:20  <TrueBrain> so depending if that is Makefile, Ninja, MSVC, ...
08:28:22  <peter1138> I'm building with the cmake plugin in vs code.
08:28:25  <TrueBrain> there are different options
08:28:39  <TrueBrain> so sadly, not something CMake can influence (as far as I know)
08:28:53  <peter1138> I'm fairly sure it did used to make it concurrent, because my machine used to come to a crawl :p
08:29:05  <peter1138> Now it just takes absolutely ages to compile because it's not using all 6 cores.
08:29:07  <TrueBrain> MSVC normally uses all cores, I noticed :)
08:29:23  <TrueBrain> (MSVC backend, that is)
08:29:28  <peter1138> I'm using the compiler from MSVC, which is why I'm confused.
08:33:25  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9157: Feature: make the town directory vertically resizable https://git.io/J3nFe
08:33:51  <Rubidium> I hope I did it the right (tm) way
08:35:40  <peter1138> I think it already was vertically resizable.
08:36:25  <_dp_> that's some properly cursed save there... https://www.tt-forums.net/viewtopic.php?f=31&t=88827
08:36:26  <_dp_> I wathed it for 15 minutes and still have no idea wtf is going on there xD
08:36:26  <peter1138> 33Looks right to me.
08:36:28  <peter1138> -33
08:37:05  <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #9157: Feature: make the town directory vertically resizable https://git.io/J3nFP
08:43:39  <peter1138> Got that baseset looks terrible :(
08:46:21  <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #9158: Codechange: Scale sprite font size once. https://git.io/J3nNl
08:47:06  <peter1138> Maglev is awful for highlight paths :p
08:47:25  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9154: Fix d4f0b6f4: [CMake] CMAKE_PROJECT_VERSION_XXX are not in CMake 3.9 https://git.io/J3nNg
08:47:56  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9157: Feature: make the town directory vertically resizable https://git.io/J3nFe
08:48:36  *** frosch123 has joined #openttd
08:49:20  <peter1138> _dp_, I reversed train #90 and... it glitches...
08:50:01  <_dp_> rofl
08:51:56  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9158: Codechange: Scale sprite font size once. https://git.io/J3nAm
08:52:32  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9159: Fix #9152, #9153: screenshot command showed error messages when successful https://git.io/J3nA4
08:52:32  <peter1138> _dp_, i wonder if penalties have been fiddled with
08:54:14  <_dp_> hm, what's even the easiest way to check that...
08:54:34  <nielsm> the track layout is pretty bad though, regardless
08:54:43  <frosch123> FLHerne: i remembered why original MU are refittable to everything: people like to use them for cargo transport, and if you send a train with 10 grain wagons and passenger engines to a cargo station, it will start accepting passengers, which is annoying :p
08:55:04  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9159: Fix #9152, #9153: screenshot command showed error messages when successful https://git.io/J3nA4
08:55:07  <frosch123> FLHerne: so, I guess, I'll change it to "manley-morel refittable to everything, including oil"
08:55:30  <frosch123> the "oil" exception is probably some realism bullshit of people who do not even know about tropic and water cargo
08:56:32  <frosch123> remains the ship decision: do oil tankers transport all liquid cargos like water. or are oil tankers specialised vehicles for oil and oil rigs, while the cargo ship should handle everything else
08:56:34  <nielsm> no reason you can't just stack barrels inside the car too
08:57:08  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9159: Fix #9152, #9153: screenshot command showed error messages when successful https://git.io/J3nxZ
08:57:33  <nielsm> I'd like to think of it as a "tanker ship", has liquid tanks that can hold anything that behaves like a liquid
08:57:54  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9159: Fix #9152, #9153: screenshot command showed error messages when successful https://git.io/J3nx0
08:58:25  *** gelignite has joined #openttd
08:58:52  <nielsm> realistically there would be differences in the piping and such between different liquids carried, and if you were to refit a ship to a different cargo (like crude oil to fuel oil) there would be a gigantic cleanup job as part of that, but that's not much fun
08:59:27  <nielsm> and trying to model it is a can of worms where everyone has their own opinions, easier to just make it free
08:59:29  <frosch123> nielsm: "realism" is terrible for game design. all cargo can be packaged, then you have containers everywhere, and only need a single vehicle
09:00:12  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9159: Fix #9152, #9153: screenshot command showed error messages when successful https://git.io/J3nxN
09:01:17  <andythenorth> just make tanker refittable all liquids
09:01:29  <andythenorth> it's even realism, if you have enough steam cleaning
09:02:31  <FLHerne> frosch123: Same applies to the SH 125 in that case?
09:02:56  <andythenorth> make it more free
09:03:05  <andythenorth> the realism audience can get a grf
09:05:38  <TrueBrain> Lifetime total units (?) 	425,619
09:05:41  <frosch123> FLHerne: yes
09:05:46  <TrueBrain> Daily active users 	10,673 	(average, past 7 days)
09:06:17  <_dp_> peter1138, pf penalties look default: https://pastebin.com/masATamt
09:06:27  <peter1138> Figures :)
09:06:33  <FLHerne> Next up, variable graphics on cargo refitting for base vehicles...?
09:06:36  <frosch123> TrueBrain: https://wiki.openttd.org/en/Development/NewGRF/Specification%20Status#openttd-1-12 <- despite the PR template we keep on forgetting this :p
09:06:44  <FLHerne> Just make the baseset be OpenGFX+ :p
09:06:49  <andythenorth> oof
09:06:55  <andythenorth> with trams?
09:06:56  <TrueBrain> frosch123: who touched NewGRF anything? :P
09:06:59  <FLHerne> of course
09:07:15  <TrueBrain> frosch123: how am I suppose to know that "GUI sprites" should also be on that list! :P
09:07:19  <peter1138> Reverse these trains definitely causes sprite glitches.
09:07:21  <TrueBrain> the PR template is just unclear :P :P
09:07:37  <TrueBrain> (and tnx for adding it :) )
09:08:02  <FLHerne> nielsm: UKRS2 has a mechanic where you can station-refit from "clean" to "dirty" cargos but not vice versa
09:08:02  <TrueBrain> right, Steam hardware survey of April is here .. lets see ..
09:08:05  <FLHerne> It's terrible
09:08:10  <frosch123> TrueBrain: change the in-game text "your baseset is missing X sprites" to "you added GUI sprites, please notify baseset people"? :p
09:08:21  <TrueBrain> frosch123: flashing red, ofc
09:08:33  <andythenorth> so how do I count towns on the map?
09:08:48  <TrueBrain> lol, Linux is all over the place .. from Mint to Fedora to Ubuntu to Arch
09:08:53  <TrueBrain> that is rather diverse
09:09:05  <TrueBrain> Mac .. from 10.13 up to 10.16
09:09:29  <TrueBrain> people have either 4 or 6 CPU cores (about equal in size) .. makes up for 70% of the population
09:09:38  <TrueBrain> 0.1% still has 1 CPU core, reported to Steam, that is
09:09:43  <TrueBrain> (I would guess that is just VMWare, but okay)
09:09:53  <TrueBrain> 0.01% has 32 CPU cores, lol
09:10:03  <_dp_> andythenorth, in game or in newgrf?
09:10:08  <andythenorth> newgrf
09:10:13  <DorpsGek> [OpenTTD/OpenTTD] Eric-01 commented on issue #8967: Game crash during startup https://git.io/JYAmd
09:10:14  <TrueBrain> AMD / Intel is 35 / 65
09:10:32  <_dp_> andythenorth, ¯\_(ツ)_/¯
09:10:39  <TrueBrain> NVIDIA / AMD / Intel is 76 / 16 / 8
09:10:51  <andythenorth> I want to place a specific industry into every town
09:10:56  <andythenorth> I was going to try using https://newgrf-specs.tt-wiki.net/wiki/Callbacks#Industry_availability_.2822.29
09:10:58  <TrueBrain> 1% has clockspeed of < 1.4 GHz .. lol
09:11:37  <TrueBrain> Most common motherboards are Gigabyte and MSI
09:11:59  <frosch123> TrueBrain: so 0.9% have > 1 core, but < 1.4 GHz?
09:11:59  <TrueBrain> most people (45%) have 16GB of RAM installed
09:12:04  <_dp_> andythenorth, I know gamescripts can do that relatively well
09:12:10  <frosch123> i didn't know such devices existed
09:12:15  <TrueBrain> frosch123: no clue if you can correlate like that :P
09:12:17  <_dp_> but for newgrf it's kind of an awkward task
09:12:25  <andythenorth> it's probably a trivial var
09:12:35  <andythenorth> I thought it might be in 80+ but I can't see it
09:12:38  <TrueBrain> most OSX users only have 8GB of RAM
09:12:44  <andythenorth> peasants
09:12:49  <TrueBrain> most GPUs have 8GB of RAM too
09:13:05  <TrueBrain> but <1% has 512MB :P
09:13:13  <frosch123> andythenorth: newgrf do not have that information, and they are not supposed to have it
09:13:34  <andythenorth> what if the newgrf is trying to do something known wrong?
09:13:37  <TrueBrain> almost no users have 4:3 aspect ratio anymore
09:13:39  <andythenorth> can it have the information then? :P
09:13:48  <TrueBrain> most common is 24" with 26%, and 27" with 22%
09:14:03  <TrueBrain> but we also have a single user with 7", it seems .. poor sod
09:14:21  <TrueBrain> wow: 64% play in 1080p
09:14:27  <TrueBrain> 14% in 1440p
09:14:44  <TrueBrain> still, some users have their primary display on 1024x768 (still think VMs)
09:15:02  <TrueBrain> 52% has their language set to English
09:15:03  <michi_cc> TrueBrain: As far as I can see, only SC_VIEWPORT and SC_CRASHLOG access the real video buffer.
09:15:23  <TrueBrain> Russian is next with 8%
09:15:31  <TrueBrain> so we really should fix the font stuff :P
09:15:33  <_dp_> TrueBrain, steam language or openttd one?
09:15:42  <TrueBrain> Steam language
09:15:49  <peter1138> _dp_, I increased pf.yapf.max_search_nodes to 100000 and that stops the trains looping.
09:16:07  <TrueBrain> like almost everyone running OpenTTD via Steam has SSE4.2 and older
09:16:17  <peter1138> So the layout is bad enough that it is exceeding 10000.
09:16:32  <_dp_> peter1138, I'm not that familiar with openttd pathfinder to understand what it really does
09:16:35  <frosch123> TrueBrain: openttd uses to autopick a ttf when using a non-latin language, is that broken?
09:16:52  <TrueBrain> frosch123: GOG reported it too, and on Steam discussions it is reported several time too
09:16:57  <_dp_> peter1138, doesn't look like 10000 of what I'd expect to be nodes though
09:17:11  <TrueBrain> most common GPU is GTX 1060
09:17:16  <frosch123> TrueBrain: what does your windows system do?
09:17:16  <TrueBrain> (9%!)
09:17:24  *** sla_ro|master has quit IRC
09:17:48  <andythenorth> frosch123 the use case is putting an industry into every town to tell me the contents of the town registers, for experimental reasons
09:17:50  <TrueBrain> frosch123: the fallback works for me
09:18:18  <TrueBrain> mainly the inability to select a font in-game seems to contribute to the confusion with people
09:18:42  <peter1138> _dp_, there are so many junctions and loops, it adds up.
09:18:51  <TrueBrain> 90% of the GPUs on Steam support OpenGL 4.5
09:19:18  <TrueBrain> 5%, mainly Intel, report older than 2.1 or don't report at all
09:20:54  <TrueBrain> okay, access to such survey is fun
09:21:19  <TrueBrain> michi_cc: yeah, that was my conclusion too, both calling MakeSmallScreenshot; so that means the rest can be rendered out of the video buffer lock, I guess .. already helps
09:21:55  <michi_cc> Can't really put SC_CRASHLOG into a queue, though :)
09:23:17  <TrueBrain> frosch123: also possibly the main thing that confuses people is the error about "fallback font" when selecting, say, russian
09:23:31  <TrueBrain> it is not an error they can do anything with, so they think they do something wrong
09:25:07  <_dp_> peter1138, can't be more than 1000 on a shortest path :p
09:25:14  <TrueBrain> michi_cc: true; the other thing I was thinking about is always keeping a copy of the buffer around, "in case of a screenshot", but that might be silly :P
09:25:34  <TrueBrain> on Linux crash-reports aren't really working btw .. mostly noticed when you hit CTRL+C at random times
09:25:41  <TrueBrain> 50% of the time or so it just .. hangs itself here
09:25:45  <TrueBrain> or crashes during crashing
09:25:49  <TrueBrain> guess threading issue :D
09:26:25  <andythenorth> lol attempting to circumvent GS using GRF seems to demand a GS
09:27:00  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3cJY
09:27:06  <peter1138> 	 *      - or the maximum amount of loops reached - m_max_search_nodes (default = 10000)
09:27:08  <andythenorth> placing 1 instance of a specific industry type into every town seems to be what GS is actually good at
09:27:30  <peter1138> Hm.
09:28:35  <andythenorth> I guess I could publish a GS from FIRS compile, and hope players load it alongside FIRS
09:28:36  <peter1138> So if it's the number of loops encountered, rather than the number of loops in a path, then I can see it hitting it.
09:29:06  <peter1138> It's definitely this, it all clears up after increasing it.
09:29:11  <_dp_> is that a limit on the width of the search rather than depth?
09:29:14  <peter1138> Apart from the trains that need reversing.
09:31:18  <_dp_> oh, not even width, just a total of nodes encountered, yeah, that definitely can hit 10k there
09:32:01  <peter1138> Yeah, that's why is max_search_nodes, not the max penalty or whatever.
09:32:57  <peter1138> That plus 90 degrees turns are allowed, so even more loops...
09:33:32  <nielsm> yep the track layout in that game just appears to be hell for the pathfinder
09:34:43  <_dp_> wonder how some openttdcoop games don't trigger that
09:34:56  <_dp_> may be they just increased the setting though
09:35:33  <nielsm> do those games have the same kinds of layouts that allow you to go anywhere from everywhere?
09:36:00  <nielsm> don't openttdcoop games usually use lines with well-defined directionality?
09:36:14  <peter1138> _dp_, they tend to use one-way paths.
09:36:32  <nielsm> you need to railroad the trains towards their destination
09:36:55  <_dp_> yeah, I guess, as crazy as they are, they're pretty directional...
09:37:03  <peter1138> Bah a tt-forums not understanding markdown ;(
09:38:10  <Rubidium> LordAro: any great ideas how to make NetworkError::(GetLast)AsString thread safe and return a C-string? Because as far as I can see for at least GetLastAsString the NetworkError object is out of scope after GetLastAsString returns, so it would be a dangling pointer. Unless I replace GetLastAsString with GetLast().AsString, and then dump the std::string in NetworkError. Or maybe unique_ptr<std::string>
09:38:16  <Rubidium> in NetworkError?
09:38:29  <LordAro> yeah, no real idea
09:38:37  <LordAro> i was hoping you would know :p
09:39:10  <peter1138> LordAro, "Sure" :-)
09:39:26  <peter1138> Did you ride? I didn't :/
09:39:34  <_dp_> btw, if trains are lost do they not service?
09:39:36  <peter1138> Freeeeeeezing cold (okay not quite)
09:39:45  <LordAro> peter1138: i'm going to go for Sun & Mon
09:40:01  <LordAro> legs still feeling a bit meh
09:40:05  <peter1138> _dp_, apparently not.
09:40:20  <LordAro> lost trains aren't pathfinding at all, so can't find a depot
09:40:33  <LordAro> though i would expect them to service if they magically end up in a depot
09:40:53  <LordAro> so, 1.11.2 ?
09:41:01  <peter1138> One might expect them to try to pathfind to a depot if they need a service.
09:41:09  <_dp_> well, what they apparently do I noticed, more interesting if that's what's they supposed to do xD
09:41:10  <peter1138> Maybe there's so many nodes that that isn't possible either...
09:41:42  <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #9158: Codechange: Scale sprite font size once. https://git.io/J3nNl
09:42:13  <_dp_> I've seed them ignore depots that are 2 tiles away so don't think it's pf issue
09:42:55  <_dp_> though at what point do trains even look for depot...
09:43:45  <_dp_> breakdowns too broken :p
09:44:42  <peter1138> I suspect they look for a depot after finding their path, so that they can find a depot that is en-route.
09:45:07  <peter1138> Right, sprite font text now looks better with abitrary scaling...
09:45:55  <peter1138> Still need to sort out GUI sprite context though.
09:46:51  <peter1138> https://gitlab.kitware.com/cmake/cmake/-/issues/17696 Hmm
09:46:54  <_dp_> peter1138, I know there is 20 "tile" limit for depot search so they must be looking for them somewhat continuously
09:47:17  <peter1138> Oh, random project file, never mind.
09:47:51  <peter1138> 1.11.2 eh?
09:48:03  <peter1138> Maybe this reversing sprite glitch can be fixed...
09:48:07  *** Samu has joined #openttd
09:48:08  <peter1138> Step 1) Report it.
09:49:18  <peter1138> / 42 is a very strange scaling :-)
09:49:43  <peter1138> Probably should just
09:49:45  <peter1138> ...
09:50:03  <peter1138> Probably should just change the slider code to work with variable limits.
09:51:53  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GfF
09:52:02  <nielsm> feel free to improve my slider (if you mean the volume slider thing)
09:52:33  <_dp_> yep, looks like trains look for depot OnNewDay
09:52:59  <peter1138> nielsm, yup. I fudged it for GUI scale :-)
09:53:07  <Rubidium> LordAro: I made an another attempt/proposal. It currently is a separate diff commit, but I'll combine all those thread safer commits into the actual introduction of NetworkError
09:53:28  <Rubidium> if this is a better solution than not attempting to make it thread safe
09:54:44  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #9152: Console output for `screenshot heightmap` mistakenly has the `ERROR` prefix https://git.io/J3GbD
09:54:47  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #9153: Message popup from `screenshot heightmap` is `WL_CRITICAL` and not `WL_ERROR` https://git.io/J3GNl
09:54:50  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9159: Fix #9152, #9153: screenshot command showed error messages when successful https://git.io/J3nA4
09:59:06  <LordAro> TrueBrain: #9114 you say "last 2 commits should not be backported", is this 5d614cd & 8f66e1d ?
10:06:34  <peter1138> Hmm
10:07:18  <peter1138> Seems that when a train is reversed, it does update the position and viewport hashes...
10:07:26  <peter1138> But possible only for the head of the train?
10:07:41  <peter1138> Hmm, no
10:08:53  <peter1138> Is there anything new that needs to be swapped...
10:09:09  <LordAro> Rubidium: maybe? not sure why std::unique_ptr<std::string> is necessary? just use std::string ?
10:09:27  <LordAro> peter1138: something to do with the new sprite sorting stuff?
10:09:53  <peter1138> LordAro, don't think it's sorting. If I reverse a vehicle part of it just disappears...
10:10:01  <LordAro> huh.
10:10:10  <peter1138> Quite.
10:10:31  <Timberwolf> Interesting. Vanilla, or a particular grf?
10:10:53  <peter1138> Vanilla. I noticed it with that pathfinding issue savegame.
10:11:10  <DorpsGek> [OpenTTD/OpenTTD] LordAro closed pull request #9151: Fix: Correct minimum CMake version to 3.12, as it is actually required since d4f0b6f43 https://git.io/J3Gdb
10:11:14  <DorpsGek> [OpenTTD/OpenTTD] LordAro closed issue #9156: d4f0b6f requires cmake 3.12 https://git.io/J3Zcw
10:11:17  <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #9154: Fix d4f0b6f4: [CMake] CMAKE_PROJECT_VERSION_XXX are not in CMake 3.9 https://git.io/J3ZJz
10:12:22  <peter1138> It's fine once it starts moving, but of course if it's stuck...
10:12:36  <Timberwolf> I wonder if there's something which used to happen in 1:1 step with ticks and drawing, which now doesn't.
10:12:49  <peter1138> x_extent etc?
10:13:26  <Timberwolf> Yeah - missing parts of vehicles usually happens when the game believes the dirty area for the sprite is smaller than it actually is.
10:13:49  <Timberwolf> So it draws the rectangle it has, which doesn't cover the whole vehicle.
10:14:20  <peter1138> Looks like UpdateBoundingBoxCoordinates is called. Hmm.
10:14:30  <Timberwolf> I remember some weird stuff with reversing because it happens quite late in a tick, but I was pretty sure I handled that case.
10:15:17  <peter1138> Actually.
10:15:49  <peter1138> I bet I'm just being dumb :D
10:17:19  <Timberwolf> Ooh, this is interesting - I found an unexpected way to cause the problem.
10:17:53  <peter1138> You mean I'm not being dumb?
10:18:00  <peter1138> I find that unlikely.
10:18:01  <Timberwolf> Let me upload this.
10:18:47  <Timberwolf> https://i.imgur.com/yu4v0bL.gif
10:19:20  <peter1138> Well
10:19:58  <Timberwolf> The sprite sorter doesn't seem to think the sprite is part of the dirty block, afaict.
10:20:33  <peter1138> Phew, it happens in master too.
10:20:43  <peter1138> Not good but means I wasn't wasting time :p
10:21:07  <peter1138> If the viewport hash is updating, is there something else that needs to be flagged?
10:22:42  <Timberwolf> Hmm... and now I can't reproduce it.
10:23:11  <peter1138> I can.
10:23:25  <peter1138> Well, in the same savegame.
10:24:39  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GfF
10:25:36  *** HerzogDeXtEr has joined #openttd
10:26:34  <Rubidium> LordAro: probably my mind still thinking to much in reference/pointer land. Though with just std::string it will try to resolve the name each time when the OS returns an empty string. On the other hand, there is no place that calls it twice and the OS should probably not return an empty error string anyway
10:26:55  <LordAro> it's not exactly a performance critical codepath
10:28:14  <DorpsGek> [OpenTTD/OpenTTD] LordAro opened pull request #9160: Prepare for 1.11.2 release https://git.io/J3cGn
10:30:05  <LordAro> Rubidium: looks better IMO
10:30:57  <Rubidium> then I'll squash some of the commits in that PR
10:33:20  <LordAro> dammit glx, added trailing whitespace in your 1.11 version of that cmake PR
10:34:04  <peter1138> Hmm, managed to find a train that breaks both ends.
10:34:11  <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #9160: Prepare for 1.11.2 release https://git.io/J3cGn
10:34:11  <peter1138> The middle is fine.
10:36:21  <peter1138> If I re-reverse it, it's fine again, too.
10:36:42  <peter1138> So smells like something is not updated on swap.
10:38:27  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GfF
10:44:46  <TrueBrain> LordAro: that is the "Codechange: refactor CheckGameCompatibility() from existing function" and "Change: no longer use UDP when entering the lobby of a server"
10:45:02  <LordAro> :+1:
10:45:27  <peter1138> Timberwolf, UpdateBoundingBoxCoordinates() looks sus
10:45:40  <peter1138> 		/* Extend the bounds of the existing cached bounding box so the next dirty window is correct */
10:45:50  <peter1138> It extends using the OLD this->coord.
10:45:54  <Timberwolf> Ooh... and I bet it's using... yeah, the old.
10:46:01  <peter1138> because this->coord = new_coord is update after.
10:46:08  <peter1138> I moved that to before, and the glitch has gone.
10:46:31  <peter1138> However the update_cache condition is then wrong :p
10:47:31  <Timberwolf> This sounds familiar.
10:47:55  <peter1138> I guess it needs to be after for the first condition, and before for the next condition.
10:48:07  <Timberwolf> So it was using the old coords, because that works in most cases (when the vehicle hasn't moved much between frames), and reversing breaks it.
10:48:29  <peter1138> Seems like it should always be using new coords at that point?
10:49:02  <Timberwolf> I recall going back and forth with that a few times between "coords are wrong" and "cache isn't updating at the right point"
10:49:11  <Timberwolf> But yes, that sounds about right.
10:50:14  <peter1138> Hmm, no.
10:50:29  <Rubidium> just a quick check question: might you need to dirty the old and the new location?
10:52:22  <peter1138> There is a conceptual issue here..
10:53:09  <peter1138> Because the vehicle isn't moved after because it's stuck, the viewport area isn't updated.
10:53:34  <peter1138> Therefore the coordinates will still cover the large range unnecessarily.
10:55:40  <LordAro> TrueBrain: server_lang & map_name removals are making backporting this difficult :p
10:55:55  <TrueBrain> owh, shit, yeah ..
10:55:59  <TrueBrain> completely forgot about that
10:56:02  <Timberwolf> Which is the issue with the savegame in it?
10:56:03  <LordAro> i think i got it though
10:56:09  <TrueBrain> well, they can be removed in 1.11.2 too, honestly
10:56:14  <TrueBrain> I just replaced it with empty strings
10:56:29  <TrueBrain> but sorry about that, that was unintentional more complex
10:56:32  <LordAro> plausibly
10:56:51  <TrueBrain> keeping them is also not really difficult
10:57:57  <TrueBrain> if you already did that, that is fine too :)
11:00:39  <Rubidium> I remembered something backporting related... #9137 effectively does what #8346 tries to do, so that fixes #6598. However, I'd rather not suggest backporting #9137... so what about making a minimum patch that gets shipped with 1.11.2?
11:02:56  <peter1138> Timberwolf, i'm using the savegame from https://www.tt-forums.net/viewtopic.php?f=31&t=88827&p=1244591#p1244591
11:03:15  <Timberwolf> Cool.
11:03:29  <peter1138> Assuming that's what you were asking. Not sure.
11:03:53  <Timberwolf> Yeah, I want to take a look at what's going on.
11:04:10  <peter1138> Train #90 is my first "obvious" one.
11:04:30  <peter1138> Which is left of the initial viewport.
11:06:55  <peter1138> Hmm, ^B for vehicle sprite_cache bounding boxes?
11:09:34  <LordAro> hmm, opengl is broken :(
11:09:42  <peter1138> Uh oh
11:09:44  <LordAro> because i updated my graphics driver earlier
11:09:58  <LordAro> and sdl just dies, rather than actually returning a false value
11:10:05  <LordAro> https://github.com/libsdl-org/SDL/issues/3182 oh look, it's me
11:11:03  <peter1138> Need a reboot?
11:11:10  <LordAro> yeah, that will solve it
11:11:14  <LordAro> but i wish i didn't have to
11:11:59  <peter1138> And yeah, libraries should never exit :D
11:12:46  <LordAro> arguably it's an X11 bug, because that's what _XError is calling
11:13:21  <peter1138> :/
11:13:33  <LordAro> -v sdl it is then
11:15:16  <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #9160: Prepare for 1.11.2 release https://git.io/J3cGn
11:18:48  <peter1138> [proc] Executing command: "C:\Program Files\CMake\bin\cmake.exe" --build i:/src/OpenTTD/build --config RelWithDebInfo --target openttd -j 14 --
11:18:58  <peter1138> Hmm, I guess -j 14 is the thing but...
11:19:58  <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #9157: Feature: make the town directory horizontally resizable https://git.io/J3cB0
11:21:32  <Timberwolf> Right... so something about that game causes it to repeatedly dirty large blocks of the screen, but after you reverse the train the sprites aren't being counted as part of the rectangle. (Interestingly, it draws them fine for the first frame after reversing, it's when the next frame dirties the section around the train that things go awry.
11:22:11  <Timberwolf> There's something somewhere which finds which vehicles are part of a dirty rectangle, wonder what that's using...
11:22:44  <milek7> TrueBrain: yeah, it tries to handle the crash and keeps second thread running
11:23:18  <Timberwolf> Aha. I bet it's because when the vehicle is reversed, it's not updating the viewport hash (which is what's needed for it to appear correctly)
11:23:47  <TrueBrain> LordAro: your backport PR does network-wise what I expect it to do
11:23:53  <LordAro> :)
11:24:04  <LordAro> i did a very brief test of "can i still get the list of servers"
11:24:18  <TrueBrain> I tested it with master server/client vs 1.11.2 server/client :)
11:24:37  <LordAro> little bit more than me then :p
11:25:16  <TrueBrain> also know what to look for ;)
11:26:14  <LordAro> Rubidium: do you mean #9137 ? i don't see anything in there that would affect #6598
11:27:06  <LordAro> or maybe i do..
11:27:28  <Rubidium> LordAro: well... it's way more complicated...
11:27:38  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #8346: Fix #6598: Added company id check for connect console command. https://git.io/J3c05
11:27:41  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed pull request #8346: Fix #6598: Added company id check for connect console command. https://git.io/JkpLU
11:28:28  <Rubidium> first of all #8346 is not the solution at all, and by that token #9137 does not fix #6598
11:29:53  *** iSoSyS has joined #openttd
11:30:30  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9157: Feature: make the town directory horizontally resizable https://git.io/J3nFe
11:34:41  <peter1138> Timberwolf, it is updating the viewport hash.
11:34:58  <peter1138> Timberwolf, it's not updating v->sprite_cache correctly.
11:35:23  <DorpsGek> [OpenTTD/OpenTTD] Milek7 commented on pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3cuZ
11:37:14  <peter1138> Maybe it just needs revalidate_before_draw to be set true.
11:38:09  <Timberwolf> Possibly. I'll keep looking - it looks like a viewport hash issue to me, but I haven't got near the root of it yet.
11:38:55  <Timberwolf> OK yeah, it's updating the hash in UpdateStatusAfterSwap().
11:40:20  <nielsm> this is actually also something that would make a nice unit test isn't it? check that a certain situation renders the correct pixels (load savegame paused, ask blitter to render various regions with a known graphics set, compare against known good renders)
11:40:37  <nielsm> or is that more like an integration test...
11:43:05  <LordAro> more of an integration test really
11:43:25  <LordAro> would be exceptionally difficult to feasibly unit test it, unless you really want to compare blitter contents
11:43:41  <nielsm> but it is testable at least
11:44:04  <nielsm> and can test sprite loading, scaling, pallette conversion, clipping, sorting
11:44:25  <LordAro> some sort of screenshot comparison might be more feasible
11:45:04  <_dp_> then make a screenshot competition for it xD
11:45:49  <nielsm> if the misrenderings in this savegame (I noticed them too) are caused by parts becoming invalidated and somehow not picking up that certain vehicles are supposed to be in view, that points to something about asking the renderer to draw parts but not all of a viewport having a bug
11:46:09  <nielsm> so testing taking a screenshot of a limited viewport can be useful
11:52:43  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9081: Feature: Configurable subsidy duration https://git.io/J3c22
11:58:47  <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #8390: Add: [AI/GS] Missing water related functions and objects https://git.io/J3caQ
12:00:07  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #8468: Fix #8316: Make sort industries by production and transported with a cargo filter possible https://git.io/J3cVT
12:02:29  *** iSoSyS has quit IRC
12:03:05  <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #8390: Add: [AI/GS] Missing water related functions and objects https://git.io/J3cVH
12:20:34  <DorpsGek> [OpenTTD/team] Ilistro opened issue #207: [fr_FR] Translator access request https://git.io/J3c6X
12:22:37  *** glx has joined #openttd
12:22:37  *** ChanServ sets mode: +v glx
12:23:40  <Timberwolf> OK, I think I have it. Sprite cache always uses the coordinates from two updates ago to generate the hash. In almost every situation, this is fine (and I think there was a specific problem it solves). Except in one case... the train has reversed for the second time on the spot.
12:24:43  <nielsm> it would all be solved if just trains could drive backwards, then they wouldn't need to reverse!
12:24:46  <Timberwolf> In this case, the two updates out of date hash is equal to the current hash, so it chooses not to update the viewport hash... but now the train is not where the viewport hash says it is.
12:24:55  <nielsm> reverse visually that is
12:26:10  <peter1138> nielsm, that sounds like a plan ;)
12:26:57  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor opened pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
12:27:55  <LordAro> lawks.
12:27:58  <peter1138> action 321 bridge chain eh?
12:28:18  <LordAro> "Total bridges are limited to 16711680."
12:28:39  <peter1138> That seems a strange number.
12:29:03  <peter1138> 2^24-2^16
12:29:22  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
12:29:37  <peter1138> Bridge pool. Hmm.
12:30:01  <peter1138> Action 321 bridges. Cool. Bridge-pool, not so sure :p
12:32:03  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
12:32:13  <FLHerne> Why no bridge pool?
12:32:28  <FLHerne> Also yay more bridges
12:33:49  <peter1138> It changes the scope from "add new bridge graphics" to something... rather larger.
12:34:35  <peter1138> NUM_BRIDGES
12:34:44  <peter1138> ooof, wrong window :D
12:34:44  <Rubidium> though aren't bridges limited to ~2 million already?
12:35:08  <FLHerne> Probably I don't understand
12:35:37  <FLHerne> What's the effect beyond allowing for more bridge types/non-conflicting multiple bridge grfs?
12:35:42  <Rubidium> what I understand from bridges is that they have a begin and an end tile, so they use at least 2 tiles. 2048 * 2048 / 2 = ~2 million
12:35:42  <peter1138> Only 2 million? How so?
12:35:43  <FLHerne> Or is that the 'something larger' you mean?
12:35:55  <peter1138> Maps can be more than 2048.
12:36:18  <peter1138> I don't know why 4096 was added, but it was :D
12:36:21  <Rubidium> oh... 4096... ah wel, ~8 million then
12:36:35  <FLHerne> It's a bad feature, it can be dropped in 1.12 :p
12:36:44  <FLHerne> 2048 too really
12:36:54  *** luaduck has joined #openttd
12:37:03  <Timberwolf> peter1138: https://gist.github.com/mattkimber/e2dab2f47f45d975faa2d77c61e5ea9d
12:37:36  <Timberwolf> The reason for using the "two iterations old" cache is so that when a vehicle is newly created, its "old" coords are still INVALID_COORD.
12:37:55  <Timberwolf> I suspect this can be done more cleanly, but that fixes the immediate problem with reversing trains.
12:38:26  <peter1138> Funny how you got } \n else { into our code, when } else { is our style.
12:40:04  <Timberwolf> Edited, no-one saw it, can't prove it was me, etc.
12:40:09  <LordAro> peter1138: NUM_BRIDGES appears to be flashing
12:42:28  *** Beerbelott has joined #openttd
12:42:39  <DorpsGek> [OpenTTD/OpenTTD] frosch123 updated pull request #9148: Support NewGRF cargoes with default vehicles https://git.io/J3G6D
12:42:49  <Beerbelott> TrueBrain: DIdn't forget you. I'll try to tackle this DEBUG docs for the net facility this w-e, I hope
12:43:04  <TrueBrain> no rush, when-ever you have time :)
12:43:09  <TrueBrain> would just be nice if it is solved some day :D
12:44:28  <DorpsGek> [OpenTTD/OpenTTD] nielsmh started discussion #9162: Features needed for New Bridges https://git.io/J3cM2
12:44:36  <Beerbelott> I just discovered https://github.com/OpenTTD/OpenTTD/blob/master/src/currency.cpp#L130. Setting to_euro to 1 is a special value and actually deactivates the switch to euro. Might be worth documenting?
12:45:09  <Beerbelott> CF_ISEURO = 1
12:45:15  <Beerbelott> CF_NOEURO = 0
12:46:02  <Beerbelott> Also, even if incomplete/substandard, why is the openttd.cfg page on the WIki archived?
12:46:28  <Beerbelott> Expecting people ro go read .ini files in the source code is beyond the reach of most
12:46:44  <glx> because most stuff ended archived in the switch to truewiki
12:50:22  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cDS
12:50:25  <frosch123> Beerbelott: the wiki pages were mostly one-liners, mostly incorrect
12:50:34  <frosch123> the in-game help is way better
12:50:52  <frosch123> s/incorrect/outdated/
12:52:14  <DorpsGek> [OpenTTD/OpenTTD] James103 commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cyv
12:53:42  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 opened pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3cyY
12:56:23  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cyH
13:03:22  <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #9164: Fix: Don't consider regression AIs when starting a random AI https://git.io/J3c9R
13:06:10  <DorpsGek> [OpenTTD/OpenTTD] mattkimber opened pull request #9165: Fix 3d7ab09: stopped trains not updating viewport hash when reversed for a second time https://git.io/J3c9A
13:06:30  <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9148: Support NewGRF cargoes with default vehicles https://git.io/J3cHU
13:06:58  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
13:07:34  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9164: Fix: Don't consider regression AIs when starting a random AI https://git.io/J3cHZ
13:08:18  <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9148: Support NewGRF cargoes with default vehicles https://git.io/J3cHz
13:09:56  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cH9
13:09:59  <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cHH
13:14:37  <DorpsGek> [OpenTTD/OpenTTD] nielsmh commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cQS
13:14:46  <peter1138> Crikey.
13:24:32  <LordAro> comments!
13:25:31  <glx> oups it seems #9161 is blocking all GHA
13:25:57  <glx> I fear an infinite loop somewhere
13:30:38  <LordAro> uh
13:31:12  <glx> I cancelled the 2 still in test run after almost 1h
13:32:03  <glx> but I think I'll need to cancel another one
13:32:52  <glx> so many queued GHA runs
13:33:24  <LordAro> i didn't realise there was a limit on number of concurrent jobs
13:33:48  <glx> hmm 2m30s for regression test already, I think it's hanging again
13:34:19  <LordAro> can we add our own timeouts in?
13:34:26  <glx> cancelling this one too
13:34:31  <LordAro> so that regression tests timeout faster?
13:35:11  <glx> ctest can have a timeout I think (at least it tells me that in VS)
13:35:25  <LordAro> i was thinking at the GHA level
13:35:31  <LordAro> but if that works...
13:38:46  <glx> "1: Test timeout computed to be: 10000000" <-- that's what I see in VS, and I think it's in seconds
13:38:54  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3cNj
13:38:55  <glx> that's a lot of seconds
13:41:48  <glx> let's do some testing
13:45:07  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
13:46:12  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
13:46:28  <glx> yeah more runs to cancel :)
13:47:15  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cpT
13:48:49  <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cpW
13:49:49  *** sla_ro|master has joined #openttd
13:58:13  <glx> ok timeout seems to work locally
13:58:21  <glx> let's add it to workflow
14:08:56  <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #9166: Change: [Actions] Add a 2 minutes timeout for regression test https://git.io/J3Ceh
14:13:55  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9166: Change: [Actions] Add a 2 minutes timeout for regression test https://git.io/J3Cv7
14:18:44  <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #9166: Change: [Actions] Add a 2 minutes timeout for regression test https://git.io/J3Ceh
14:19:18  <DorpsGek> [OpenTTD/OpenTTD] glx22 merged pull request #9164: Fix: Don't consider regression AIs when starting a random AI https://git.io/J3c9R
14:19:25  <peter1138> \o/
14:22:04  *** Wolf01 is now known as Guest2774
14:22:06  *** Wolf01 has joined #openttd
14:23:54  *** Wolf01 is now known as Guest2775
14:23:56  *** Wolf01 has joined #openttd
14:25:22  <peter1138> Timberwolf, hmm, odd level crossing with your roads set.
14:26:13  <peter1138> Maybe a rail type issue, not sure.
14:26:22  <Timberwolf> It has a tendency to clip a little ordinarily, but that's normally RVs hitting the gates.
14:26:36  <Timberwolf> Which track set?
14:27:43  <peter1138> Hmm, does the ground sprite come from the railtype?
14:27:47  <peter1138> I should know this :p
14:27:59  <Timberwolf> Yeah, the LC comes from the rails.
14:28:16  *** Guest2774 has quit IRC
14:29:22  <peter1138> Okay, nothing to do with your roads set then :D
14:29:35  <peter1138> Looks like rail type authors just doing it wrong.
14:30:10  *** Guest2775 has quit IRC
14:31:37  <peter1138> CZ Railset is totally bonkers
14:33:53  <peter1138> Level crossings don't work even for default roads.
14:34:53  <peter1138> Seems to be listed as CZTR Rails in bananas.
14:35:23  <Timberwolf> I'm guessing it works nicely if you have the matching CZTR roads?
14:36:39  <peter1138> No, if you load that then you don't get any roads either.
14:37:35  <peter1138> "Tried to load character sprite..." uh oh
14:42:29  <peter1138> Some kind of regression?
14:44:27  <andythenorth> won a game finally
14:50:50  <peter1138> improbable
14:52:55  <andythenorth> £200m starting loan
15:02:03  <glx> ahah it's indeed a nice infinite loop
15:04:16  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
15:04:54  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
15:05:35  <glx> ok seems he fixed the infinite loop
15:08:50  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
15:11:21  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor commented on pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3C3N
15:17:43  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on issue #9147: MakeScreenshot locking is broken when called from outside of VideoDriver::Tick https://git.io/J3GgU
15:19:51  *** snail_UES_ has joined #openttd
15:20:19  <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3CnL
15:21:06  *** andythenorth has quit IRC
15:22:35  <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #9165: Fix 3d7ab09: stopped trains not updating viewport hash when reversed for a second time https://git.io/J3CnD
15:23:08  *** andythenorth has joined #openttd
15:25:10  *** Wormnest has joined #openttd
15:27:01  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
15:31:33  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3CCN
15:38:51  <DorpsGek> [OpenTTD/OpenTTD] Milek7 commented on pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3C8I
15:42:03  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3cyY
15:43:23  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3C4g
15:44:37  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3C4F
15:52:22  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
16:01:04  *** snail_UES_ has quit IRC
16:06:37  <DorpsGek> [OpenTTD/OpenTTD] kiwitreekor updated pull request #9161: Feature: NewGRF Bridges without overriding https://git.io/J3cPO
16:19:18  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3cyY
16:19:44  <andythenorth> so how do I read the grfid and version for an industry from a GS?
16:19:51  <andythenorth> can't see it in nogo spec
16:21:14  <andythenorth> nor the industry ID also
16:22:17  <_dp_> isn't grfid one of the biggest secrets for gs? :p
16:22:44  <_dp_> you'll have to fingerprint cargo labels or do some other silly workaround I'm afraid
16:22:58  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain approved pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3Cwi
16:24:05  <peter1138> Or just write it as if your GRF is always present :D
16:28:27  <andythenorth> I do think the spec was silly, but we are where we are
16:28:43  <andythenorth> the idea that all GS must always work with all grfs seems like it was an odd design goal
16:30:12  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #6598: Possible for client to be in a nonexistent company on a server; but then the client crashes. https://git.io/fhn0d
16:30:15  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9163: Fix #6598: prevent client crashes due to failing connects https://git.io/J3cyY
16:35:05  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened issue #9167: Linkgraphs don't show direction of each link https://git.io/J3CKD
16:36:29  *** Flygon has quit IRC
16:39:53  *** felix has quit IRC
16:40:50  <andythenorth> are GS operations limited in any way I have to care about?
16:41:03  <andythenorth> e.g. I just want to force an industry into every town at game start
16:42:30  <_dp_> andythenorth, you can look at simple cb code as I'm pretty sure it does that as well
16:43:00  <nielsm> throttled the same way as AI scripts are, i.e. get paused every N operations of the squirrel VM
16:45:22  <andythenorth> so I can't deadlock map gen?
16:45:46  <nielsm> the GS gets a tick to itself after mapgen, where it has a bonus number of operations it can execute
16:46:44  <andythenorth> thx
16:46:53  * peter1138 spots a probable newgrf bug.
16:47:18  <andythenorth> oh I could use magic cargos
16:47:20  <andythenorth> to fingerprint
16:48:15  <nielsm> that's probably the simplest way yes, or maybe magic roal/rail types
16:48:23  <nielsm> road/rail types *
16:48:53  <glx> #9167 idea is nice, but don't think it's easy to do
16:49:16  <andythenorth> can I hide a cargo?
16:49:26  <nielsm> I don't think so no
16:49:26  <andythenorth> so it's produced / accepted by an industry, but doesn't appear in game?
16:49:29  <andythenorth> hmm
16:49:39  <andythenorth> we have that for railtypes
16:49:49  *** gelignite has quit IRC
16:50:08  <nielsm> even cargo types that aren't produced or accepted by anything, or even transportable by any vehicle, will appear in the various graph and list windows
16:50:18  <andythenorth> yes
16:50:20  <nielsm> as far as I remember
16:50:26  <andythenorth> they should
16:50:31  <andythenorth> maybe we need a flag on them
16:50:53  <andythenorth> then GS could read 'this cargo exists but is hidden, and the industry accepts / produces it'
16:51:16  <nielsm> that seems like a bad solution to something
16:51:27  <nielsm> that can probably be solved better with some other mechanism
16:51:39  *** felix has joined #openttd
16:51:47  <andythenorth> fingerprinting is inconvenient for testing
16:51:55  <andythenorth> the backstory is I want to make a test GS
16:52:02  <andythenorth> so I can test some economy ideas
16:52:08  <andythenorth> but industry cargos change frequently
16:52:15  <andythenorth> and I didn't find a way to reload or change the running GS
16:52:29  <nielsm> you want to test which economy FIRS is running with?
16:52:44  <andythenorth> I mean the game economy, not FIRS economy :)
16:52:47  <andythenorth> how towns grow etc
16:52:59  <andythenorth> testing will be super painful if I have to restart the entire game if the industry cargos change
16:53:09  <nielsm> if you save and reload the game, the running GS reloads from the files on disk
16:53:25  <andythenorth> presumably if the state is different, it crashes?
16:53:29  * andythenorth way out of depth
16:53:46  <andythenorth> I did make a test GS to learn
16:53:50  <andythenorth> but I crashed it quite a lot
16:53:52  <nielsm> GS doesn't save anything to the savegame except when you program it to, and it saves and loads in the format you program it to
16:54:57  <nielsm> basically, when you reload a savegame, the GS starts anew as if it hadn't run before, except that the game also calls the function that allows it to restore from savegame data
16:57:38  <andythenorth> ok
16:57:42  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened issue #9168: Linkgraphs are not colourblind-friendly https://git.io/J3C1N
16:57:57  <andythenorth> I'm only using the GS to set up a test environment for the newgrf ideas
16:58:13  <andythenorth> as some things are lacking in grf
16:58:32  <andythenorth> 'probably fine'
17:01:33  <peter1138> std::vector<std::vector<std::vector<byte>>>
17:01:36  <peter1138> So, uh...
17:02:00  <TrueBrain> a list of lists of lists with bytes?
17:02:02  <TrueBrain> sounds legit :D
17:02:16  <nielsm> and all the lists at all levels can all be different sizes
17:02:26  <nielsm> so it's certainly not a cube
17:09:42  <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #9160: Prepare for 1.11.2 release https://git.io/J3cGn
17:10:18  <peter1138> https://github.com/OpenTTD/OpenTTD/compare/master...PeterN:station-layouts
17:11:17  <peter1138> std::array for the last one maybe
17:11:18  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on issue #9117: New game fails to start after upgrading FluidSynth to version 2.2.0 https://git.io/JOxCI
17:12:17  <peter1138> Oh, there's no assign() on std::array though.
17:13:17  <DorpsGek> [OpenTTD/OpenTTD] LordAro updated pull request #9160: Prepare for 1.11.2 release https://git.io/J3cGn
17:13:24  <peter1138> There doesn't appear to be limits on length / tracks. So potentially 255 x 255 :/
17:14:41  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9165: Fix 3d7ab09: stopped trains not updating viewport hash when reversed for a second time https://git.io/J3CSl
17:15:26  <DorpsGek> [OpenTTD/OpenTTD] LordAro merged pull request #9165: Fix 3d7ab09: stopped trains not updating viewport hash when reversed for a second time https://git.io/J3c9A
17:16:58  <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #9117: New game fails to start after upgrading FluidSynth to version 2.2.0 https://git.io/JOxCI
17:21:31  <peter1138> I think you can allocate 1GB of memory if you filled every layout.
17:24:20  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3TEL
17:24:30  <frosch123> aren't the old layouts limited to 7x7 or 15x15 or something
17:24:33  *** gelignite has joined #openttd
17:24:38  <nielsm> peter1138: don't derive a class from ZeroedMemoryAllocator and then put non-POD data in it (like std::vector), I'm pretty sure that UB
17:24:41  <frosch123> those old station size buttons without drag/drop
17:24:57  <frosch123> ttdp added button 1 to 7 and then a +7 or something
17:25:25  <nielsm> the unpatched game allowed 4 tracks of length 5 for stations
17:25:27  <LordAro> frosch123: mild poke regarding #9088
17:26:00  <frosch123> yes, next thing to do :)
17:26:03  <LordAro> :)
17:26:20  <DorpsGek> [OpenTTD/OpenTTD] LordAro approved pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3C7G
17:26:21  <frosch123> or do you want to backport it straight away?
17:26:34  <frosch123> no, not important enough
17:26:51  <LordAro> it's got a backport tag :)
17:27:08  <LordAro> i put very little thought into it beyond that
17:27:09  <frosch123> yes, but i heard rumours of release today or something
17:27:11  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #9081: Feature: Configurable subsidy duration https://git.io/JOXcg
17:27:25  <peter1138> nielsm, you tell that to window_gui.h:283
17:27:46  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #9081: Feature: Configurable subsidy duration https://git.io/J3C7M
17:28:06  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #9081: Feature: Configurable subsidy duration https://git.io/J3C7Q
17:28:06  <nielsm> can we just delete that class from the code and use proper initialisation for everything
17:28:24  <peter1138> and newgrf_commons.h:171
17:28:30  <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #9167: Linkgraphs don't show direction of each link https://git.io/J3CKD
17:28:32  <peter1138> Oh wait, that's static :p
17:28:34  <LordAro> what nielsm said
17:29:02  <nielsm> and just because existing code does it doesn't mean new code can continue doing it, may as well do it properly
17:29:07  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #9081: Feature: Configurable subsidy duration https://git.io/J3C5J
17:29:20  <frosch123> with initialisation in header "int foo = 0;" it's not that bad
17:29:31  <frosch123> people tend to forget stuff in ctor lists
17:29:37  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #9081: Feature: Configurable subsidy duration https://git.io/J3C5t
17:30:57  <peter1138> GRFConfig is also ZeroedMemoryAllocator.
17:31:25  <DorpsGek> [OpenTTD/team] frosch123 commented on issue #207: [fr_FR] Translator access request https://git.io/J3c6X
17:32:09  * LordAro looks at some other things in src/core that can be blatted
17:32:11  <LordAro> ah, alloca
17:32:23  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on issue #9167: Linkgraphs don't show direction of each link https://git.io/J3CKD
17:35:53  <Rubidium> LordAro: I propose we postpone backporting #9146 to 1.11.3. Then there will be at least some others that might have tested it on "weird" environments to catch any build issues, instead of having it directly in a release
17:36:22  <LordAro> sure
17:36:26  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3OuA
17:36:29  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GfF
17:38:43  <peter1138> Hmm, how do I initialize an AnimationInfo?
17:40:03  <peter1138> grf_prop has a constructor so I guess that's okay.
17:47:40  <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #9167: Linkgraphs don't show direction of each link https://git.io/J3CKD
17:50:06  <peter1138> Okay, tweaked it, I think. Still seems to work, and compile.
17:50:13  <peter1138> ..
17:50:19  <peter1138> Other way around.
17:56:38  *** felix has quit IRC
17:57:22  <peter1138> So yeah, ZeroedMemoryAllocator deliberately mixed Calloc and new. So if it's not meant to work, why does it even have the new operator?
18:03:33  <DorpsGek> [OpenTTD/OpenTTD] michicc opened pull request #9169: Fix #9147: Asynchronously do screenshots during draw tick. https://git.io/J3Ch8
18:04:26  <peter1138> http://mikadou.github.io/ror-documentation/_zeroed_memory_allocator_8h_source.html
18:04:29  <peter1138> Hmmmmmm
18:05:41  <nielsm> "helps find problems", more like lets you ignore problems
18:06:07  <peter1138> :D
18:08:38  <michi_cc> nielsm: I don't think ZeoredMemoryAllocator is UB. A "new expression" will be executed as allocation followed by construction. ZMA overrides the allocation portion. As long as allocation and deallocation match, that should not be UB.
18:09:16  <michi_cc> It is not forbidden to construct objects into memory not allocated by new. If you want to be double sure, replace the calloc by ::new + memset.
18:09:43  <nielsm> hmm... maybe you're right...
18:10:18  <nielsm> somewhere I was imaging that the class was implemented via a default constructor that memset() itself to zeroes
18:10:23  <michi_cc> This of course assumes that nobody will cast the type away and does a free/delete on the resulting mistyped memory.
18:10:26  <nielsm> rather than operator new
18:10:40  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on issue #9167: Linkgraphs don't show direction of each link https://git.io/J3CKD
18:10:52  <michi_cc> I think we used to do that many, many moons ago. But that would indeed be totally UB.
18:11:42  <DorpsGek> [OpenTTD/OpenTTD] Milek7 closed pull request #9155: Fix: MakeScreenshot could crash when called from outside of VideoDriver::Tick, and acquire video buffer before taking game state lock to prevent erratic fast forward https://git.io/J3Z33
18:11:54  <michi_cc> TrueBrain: Maybe #9169 looks more sane to you :)
18:12:24  <TrueBrain> michi_cc: haha, why I am not surprised :P
18:12:52  <peter1138> Hmm, ({0,..}) works I guess.
18:13:55  <TrueBrain> std::bind .. wtf does that .. /me reads ..
18:14:25  <TrueBrain> ah, binding parameters
18:14:55  <peter1138> So can I put it back or should I carry on down this rabbit-hole of making sure everything is explicitly initialized...
18:15:07  <michi_cc> TrueBrain: That functions look a bit long as a lambda :)
18:15:36  <LordAro> frosch123 told me off for suggesting std::bind the other day
18:15:43  <michi_cc> Also, the string is a static constant, so no need for any value capture.
18:16:16  <michi_cc> Well, I'm also using std::function. But you can't really template something that is supposed to capture any callable.
18:16:57  <michi_cc> (Or more exactly, you'd end up with std::function :P)
18:17:09  <TrueBrain> michi_cc: crashlog is always done from main thread?
18:17:18  <frosch123> TrueBrain: std::bind is completely deprecated. since c++14 a lambda is always better
18:17:30  <LordAro> frosch123: i don't think that's correct?
18:17:44  <michi_cc> TrueBrain: Depends? However you local system executes signal handles.
18:17:53  <LordAro> https://en.cppreference.com/w/cpp/utility/functional/bind not what this suggests, anyway
18:18:09  <TrueBrain> in that case, can it still try to access OpenGL context from the wrong thread?
18:18:19  <michi_cc> Probably yes.
18:18:32  <frosch123> LordAro: well it's not "deprecated" like volatile. still it's a syntax that noone needs
18:19:14  <TrueBrain> michi_cc: well, at least it is an improvement for most cases; we can fix crashlogs another PR
18:19:30  <TrueBrain> functional-wise, I like this .. but I leave the C++ discussion for others :D
18:19:40  <TrueBrain> owh, and spam incoming .. pyup is alive
18:19:41  <DorpsGek> [OpenTTD/bananas-api] pyup-bot opened pull request #89: Scheduled monthly dependency update for May https://git.io/J3WfL
18:19:44  <frosch123> it just shows how long c++11 took... it almost deprecated things it added by adding better things :p
18:20:08  <DorpsGek> [OpenTTD/bananas-frontend-cli] pyup-bot opened pull request #25: Scheduled monthly dependency update for May https://git.io/J3Wf6
18:20:27  <andythenorth> shall I use cargo subtypes as actually intended?
18:20:41  <andythenorth> probably first person since 2013 to do it, except MB
18:21:19  * andythenorth been avoiding doing Iron Horse vehicles wagons, because vehicles can be cars / vans / trucks
18:21:24  <DorpsGek> [OpenTTD/bananas-frontend-web] pyup-bot opened pull request #56: Scheduled monthly dependency update for May https://git.io/J3WJ2
18:21:38  <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #9169: Fix #9147: Asynchronously do screenshots during draw tick. https://git.io/J3Ch8
18:21:38  <michi_cc> Okay, found the usual error of trying to make a std::string from nullptr.
18:22:01  *** felix has joined #openttd
18:22:30  <DorpsGek> [OpenTTD/bananas-server] pyup-bot opened pull request #46: Scheduled monthly dependency update for May https://git.io/J3WJ7
18:23:12  <DorpsGek> [OpenTTD/DorpsGek] pyup-bot opened pull request #48: Scheduled monthly dependency update for May https://git.io/J3WU3
18:23:41  <LordAro> oh yeah, new month
18:24:32  <frosch123> how long is the punishment for translators trying to approve themself?
18:25:05  <LordAro> probably a comment to make sure they actually know what they're doing
18:27:15  <FLHerne> frosch123: Perhaps just remove that comment from the bot reply?
18:27:25  <DorpsGek> [OpenTTD/eints] pyup-bot opened pull request #44: Scheduled monthly dependency update for May https://git.io/J3WTL
18:27:47  <FLHerne> The handful of people who actually *can* approve know how to do it, so it causes more confusion than it avoids
18:28:27  <DorpsGek> [OpenTTD/master-server] pyup-bot opened pull request #29: Scheduled monthly dependency update for May https://git.io/J3WTB
18:29:25  <DorpsGek> [OpenTTD/master-server-web] pyup-bot opened pull request #23: Scheduled monthly dependency update for May https://git.io/J3WTV
18:33:03  *** didac has joined #openttd
18:35:13  <LordAro> FLHerne: but equally, we'd like our translators to be able to actually read English
18:40:26  <didac> hii
18:40:57  <LordAro> o/
18:48:28  <TrueBrain> a good reason to deny .. if you cannot read a reply from a bot, how are you suppose to read strings to translate :P :P :P
18:49:48  <frosch123> i kind of doubt it's about reading. if they do software, they are more likely to do some QA on the bot
18:50:00  <TrueBrain> I like your thinking :D
18:50:24  <frosch123> some day little bobby tables will ask to become a translator
18:50:56  <LordAro> hence, just a comment to check :)
18:59:47  <FLHerne> LordAro: Yeah, there was that ridiculous one you /denyed
19:00:13  *** Beerbelott has quit IRC
19:25:07  <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #9043: Feature: ability to build overlapping bridges on different axes (WIP) https://git.io/JOWU8
19:25:13  <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #9043: Feature: ability to build overlapping bridges on different axes (WIP) https://git.io/J3WGs
19:40:04  <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #9081: Feature: Configurable subsidy duration https://git.io/JOXcg
20:22:54  <peter1138> Hmm, replacing MallocT with new isn't quite the same.
20:23:26  <LordAro> not quite
20:23:43  <peter1138> MallocError() 'n all that.
20:26:22  <LordAro> speaking of, i did a thing https://github.com/OpenTTD/OpenTTD/compare/master...LordAro:goodbye-alloca
20:26:55  <LordAro> win32 stuff gets real funky
20:26:58  <LordAro> and it's probably broken
20:35:12  <Rubidium> there's more funky stuff ;)
20:35:38  <Rubidium> str->assign(str->c_str()); <- that feels kinda pointless to me
20:36:25  <LordAro> lol
20:36:29  <LordAro> i meant to delete that line entirely
20:37:43  <Rubidium> two lines above that I'm wondering about too as I seem to remember seeing a std::string variant of str_validate
20:38:16  <LordAro> indeed there is
20:38:56  <LordAro> fixed :)
20:39:35  <LordAro> but the game loads and runs (on Linux), at any rate
20:43:06  <Rubidium> oh... the std::string str_validate does not change the input stream but it creates a new one. That's unexpected (for me)
20:43:22  <glx> hmm not sure you can remove alloca() from win32 area
20:43:38  <michi_cc> LordAro: For the stuff in src/network/core/tcp_http.cpp I'd personally use an ostringstream.
20:44:31  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9128: Codechange: use std::string exclusively for settings https://git.io/J3WzU
20:50:43  <frosch123> Rubidium: maybe add a https://en.cppreference.com/w/cpp/language/attributes/nodiscard to it?
20:53:46  *** reldred has quit IRC
20:53:51  <LordAro> Rubidium: ah
20:54:14  <LordAro> michi_cc: mm, likely better
20:54:54  <LordAro> ooh, regression has died horribly too
20:55:01  <LordAro> but that looks like something to do with my environment
20:55:15  *** reldred has joined #openttd
20:55:25  <LordAro> glx: i'm reasonably sure it's all valid
20:55:41  <LordAro> don't do any extra allocations inside the crashlog area
20:55:57  <LordAro> (valid conceptually, anyway, syntax might need some work)
20:56:33  <glx> yes it's valid
21:12:26  *** Wolf01 has quit IRC
21:21:18  *** Samu has quit IRC
21:22:59  *** gelignite has quit IRC
21:30:34  <andythenorth> hmm, can cargo subtypes cb return different results per cargo?
21:30:35  * andythenorth looks
21:32:07  <andythenorth> oops, forgot, subtypes don't work with autoreplace
21:35:37  <andythenorth> hmm
21:38:47  <andythenorth> can't see a var during subtypes cb for 'cargo type'
21:39:06  <andythenorth> so can't have Vehicles (cars), Vehicles (trucks), Farm Supplies (tractors)
21:46:25  <frosch123> you can make subtypes per cargotype, in fact that's the intended way
21:46:33  <frosch123> autoreplace works with subtypes just fine
21:46:49  <frosch123> as long as the upgrades provide the same subtypes
21:48:44  <glx> what doesn't work usually it's the way it's abused for liveries ;)
21:49:39  <frosch123> even that works, it's just complicated to code
21:50:36  <frosch123> you can define vehicles as transporting passengers or mail with capacity 0, and still have refitting for subtypes
21:51:12  <frosch123> (but it's complicated, as you have to set the capacity property to non-zero, and then use cb36 to set it back to zero)
21:51:46  <frosch123> 90% of why subtypes are considered bad, is andy repeating it for 10 years over and over :p
21:52:58  <peter1138> git branch -D variants
21:58:12  <peter1138> Isn't it more different cargos can return different CB results?
21:58:48  <peter1138> As there are different chains for each cargo type (and a default)
22:00:54  <peter1138> hmm, just remembered that strange NML spec cargo_profit calculation.
22:01:22  <andythenorth> wait when did autoreplace get subtype support?
22:01:25  <frosch123> there is a va2 variable for the cargotype
22:01:37  <frosch123> andythenorth: 14 years ago?
22:01:52  <andythenorth> I might be confusing it with something else
22:02:16  <andythenorth> I thought it was deliberately not implemented because there's no way to know if variant is same across vehicles
22:02:42  <frosch123> autoreplace will replicate the subtype, if the same subtype is available on the new vehicle
22:02:58  <frosch123> but it is not possible for players to select a new subtype for replacing
22:03:19  <andythenorth> is that just because we're short of UI space?
22:03:20  <frosch123> so, essentially, there is no mass-change subtypes of all consists
22:03:51  <frosch123> no, it's mostly because subtypes can only be figured out, when the vehicle is built
22:03:58  <frosch123> so you need template based replacement to make it work
22:04:11  <andythenorth> one day
22:04:43  <peter1138> That's the main issue with subtypes, there's no way to get a list of them in advance, and even if you could they might not be available.
22:05:01  <peter1138> Eh, maybe not main. It's one issue.
22:05:50  * andythenorth tries to find the var
22:07:37  <andythenorth> F2 I can find, but not the cargo type
22:07:52  <andythenorth> or do I just use 47, and it gets a magic value?
22:07:57  <DorpsGek> [OpenTTD/OpenTTD] frosch123 dismissed a review for pull request #9088: Fix: [NewGRF] industry variables 65 and 66, object variable 46 https://git.io/JODiZ
22:08:00  <DorpsGek> [OpenTTD/OpenTTD] frosch123 updated pull request #9088: Fix: [NewGRF] industry variables 65 and 66, object variable 46 https://git.io/JOD6Q
22:08:54  <frosch123> andythenorth: cargo_type_in_veh
22:09:25  <andythenorth> thanks
22:09:48  <frosch123> someone names it very different to the other variables cargo_capacity, cargo_Type and cargo_subtype :p
22:10:00  <peter1138> Who came up with this spec?
22:10:02  <andythenorth> I tend to look in nfo specs generally
22:10:09  <andythenorth> I don't really understand nml vars
22:10:32  <andythenorth> also they have a small history of not quite being reliable
22:11:29  <andythenorth> ok so that is var 47
22:14:48  <andythenorth> oof sleeping time
22:15:04  <andythenorth> tomorrow I do (cars), (trucks), (tractors) etc subtypes
22:15:08  <andythenorth> so excite :)
22:15:28  <peter1138> As if you thought that not possible...
22:15:51  <andythenorth> I bet if I look in older grfs, I've even done if before
22:15:58  <andythenorth> just being dim about the var
22:16:00  <Timberwolf> Erk.
22:16:06  <Timberwolf> More vehicle cargo sprites needed?
22:16:18  <andythenorth> I need some yes
22:16:22  <peter1138> The refit code specifically loops through all cargo types to get a list.
22:17:05  <andythenorth> if I wasn't a bad person, I'd update the wiki
22:17:24  <andythenorth> to mention that var 47 will change meaning in subtypes cb
22:18:53  <Timberwolf> Well, reading multi-object MagicaVoxel files is now working, most of the time. (Sometimes it does weird stuff if the objects were made by cloning another object from the same file)
22:19:12  <andythenorth> hurrah
22:19:16  <andythenorth> ships!
22:19:19  <Timberwolf> Unfortunately, toolchain means I also need to be able to save them before I can do anything useful.
22:19:22  <Timberwolf> But yes, ships.
22:19:52  * andythenorth very sleep
22:19:54  *** andythenorth has quit IRC
22:26:22  *** sla_ro|master has quit IRC
22:28:49  *** frosch123 has quit IRC
22:48:08  *** snail_UES_ has joined #openttd
23:06:26  *** erle- has quit IRC
23:08:49  <DorpsGek> [OpenTTD/OpenTTD] PeterN approved pull request #9088: Fix: [NewGRF] industry variables 65 and 66, object variable 46 https://git.io/J3WHh
23:12:49  <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #9169: Fix #9147: Asynchronously do screenshots during draw tick. https://git.io/J3Ch8
23:20:19  <DorpsGek> [OpenTTD/OpenTTD] Berbe opened issue #9170: DEBUG messages cleanup https://git.io/J3W5J
23:20:40  *** Beerbelott has joined #openttd
23:21:05  <Beerbelott> TrueBrain: I did a quick & dirty assessment of DEBUG use for the net facility -> https://github.com/OpenTTD/OpenTTD/issues/9170
23:21:34  <DorpsGek> [OpenTTD/OpenTTD] michicc updated pull request #9169: Fix #9147: Asynchronously do screenshots during draw tick. https://git.io/J3Ch8
23:21:45  <Beerbelott> It's clearly all over the place, and I tried to be the most concise yet understandable possible
23:24:55  <DorpsGek> [OpenTTD/OpenTTD] TrueBrain closed issue #9170: DEBUG messages cleanup https://git.io/J3W5J
23:24:58  <DorpsGek> [OpenTTD/OpenTTD] Berbe started discussion #9171: DEBUG messages cleanup https://git.io/J3W5b
23:25:12  <TrueBrain> that is more a discussion topic ;)
23:25:18  <TrueBrain> will check it out later this week, tnx
23:47:21  *** nielsm has quit IRC
23:50:42  <Beerbelott> TrueBrain: Didn't know what to create... should eventually become PR(s). I thought something even (very) quick & (very) dirty was better than nothing
23:51:08  <Beerbelott> I'm not sure I'll allocate time for that in the remaining of the week-end
23:51:53  <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #9172: Cleanup: Use std::vector is xxxSpriteGroups. https://git.io/J3WN7
23:52:29  <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #9167: Linkgraphs don't show direction of each link https://git.io/J3CKD
23:53:53  <Beerbelott> Oh OK I just saw what you did. Didn't know discussions were a thing on GitHub
23:59:51  <DorpsGek> [OpenTTD/OpenTTD] James103 opened issue #9173: Can't zoom minimap in any further when at 1x scale https://git.io/J3WAH

Powered by YARRSTE version: svn-trunk