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