IRC logs for #openttd on OFTC at 2021-04-30
⏴ go to previous day
00:05:29 <DorpsGek> [OpenTTD/OpenTTD] embeddedt commented on pull request #9130: Change: use TCP for everything except for master-server and initial server scan https://git.io/J3mx0
00:08:19 *** lobster has joined #openttd
02:07:11 *** tokai|noir has joined #openttd
02:07:11 *** ChanServ sets mode: +v tokai|noir
02:14:07 *** tokai has quit IRC (Ping timeout: 480 seconds)
02:54:26 *** Compu has quit IRC (Remote host closed the connection)
03:06:03 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:57:33 <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #9043: Feature: ability to build overlapping bridges on different axes https://git.io/JOWU8
03:57:58 <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #9043: Feature: ability to build overlapping bridges on different axes https://git.io/JOWU8
04:20:46 *** HerzogDeXtEr has joined #openttd
04:59:10 *** snail_UES_ has quit IRC (Quit: snail_UES_)
05:06:53 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9130: Change: use TCP for everything except for master-server and initial server scan https://git.io/J3YSj
05:16:09 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #9141: Codechange: Use C++ features for train wagon overrides. https://git.io/J3YHP
05:23:12 <DorpsGek> [OpenTTD/OpenTTD] perezdidac updated pull request #8982: Feature: text filter for the industry directory https://git.io/JOfI5
05:23:38 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #8982: Feature: text filter for the industry directory https://git.io/J3Y7X
05:37:06 *** didac has quit IRC (Remote host closed the connection)
07:08:38 *** WormnestAndroid has quit IRC (Remote host closed the connection)
07:08:51 *** WormnestAndroid has joined #openttd
07:13:34 *** sla_ro|master has joined #openttd
07:24:10 *** ChanServ sets mode: +v tokai
07:31:33 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
08:07:35 *** andythenorth has joined #openttd
08:17:45 <DorpsGek> [OpenTTD/OpenTTD] ccapitalK opened pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3OuA
08:18:15 <DorpsGek> [OpenTTD/OpenTTD] ccapitalK commented on pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3OzJ
08:22:09 <TrueBrain> LordAro: too lazy to install OpenTTD just for the screenshot? :P
08:22:34 <LordAro> also with my internet, that might have actually taken minutes
08:22:59 <TrueBrain> downloading 10MB? :P
08:23:02 <TrueBrain> either way, fixed it for you, no worries
08:23:25 <TrueBrain> in this channel we help each other!
08:23:40 <LordAro> regardless, i think at this point we're pretty confident that both types of crashes have been fixed
08:25:54 <TrueBrain> so close the tickets and lets ship 1.11.2!
08:26:43 <andythenorth> OpenTTD: 2.0.0 - "we found new ways to fuck up"
08:28:20 <DorpsGek> [OpenTTD/OpenTTD] ccapitalK updated pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3OuA
08:28:24 <Timberwolf> OpenTTD 2.0.0 should just be OpenLoco rebranded as a joke.
08:28:44 <andythenorth> how are the boats? :)
08:29:03 <Timberwolf> The usual story, requiring tooling investment :)
08:29:16 <andythenorth> I think the tooling is more interesting than the vehicles TBH
08:29:26 <andythenorth> I did once make an auto-generator for pixel trucks
08:29:30 <Timberwolf> My scale requires voxel objects >256 in length, which MagicaVoxel supports, but only but putting multiple 256xnxn objects in a scenegraph.
08:29:42 <Timberwolf> I was lazy and never wrote a reader for that part of the format.
08:29:45 <andythenorth> well hurry up and fix it :)
08:29:49 <andythenorth> I need some hull shapes :)
08:29:53 <andythenorth> 'feature requests'
08:30:33 <Timberwolf> Did a proof of concept with it yesterday evening and I can read the necessary things, it's just assembling the scenegraph and turning it into a big object.
08:31:03 <Timberwolf> Oh, and MagicaVoxel also sometimes saves bits of the scenegraph by rotating them, I need to handle that.
08:31:27 <Timberwolf> It has quite a lot of detection for "these are the same object, only transformed"
08:32:16 <Timberwolf> Also saving it, but I probably won't preserve the original scenegraph, I'll just start with an enormous object and divide it into as many cubes as necessary.
08:33:05 <TrueBrain> funny .. turns out OpenTTD does a lot of gettimeofday calls because of the performance timer :)
08:36:50 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3Ool
08:41:48 <DorpsGek> [OpenTTD/OpenTTD] ccapitalK commented on pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3OKS
08:44:53 <peter1138> There are cases where the performance timer is slowing things down...
08:47:03 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3Ois
08:57:06 <andythenorth> peter1138 something something Observer Effect
09:03:29 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3OMD
09:09:43 <TrueBrain> lol, search in Serenities codebase shows they never fire EWOULDBLOCK, which is a bit odd, as POSIX defines it should be fired for blocking operations .. they just always fire EAGAIN, but don't map those values to the same value, where most OSes just do that
09:10:08 <TrueBrain> where EGAIN is a temporary resource shortage, and EWOULDBLOCK is a "this would block" signal, according to POSIX
09:20:50 <peter1138> Was that the OS that needed SDL to be fixed?
09:22:09 <TrueBrain> funny, our RDTSC code suggests it is only used for TIC/TOC
09:22:14 <TrueBrain> but it is also used for PF performance metrics
09:22:33 <TrueBrain> (but only for debugging, ofc)
09:22:41 <peter1138> OS-specific test for EWOULDAGAIN|EAGAIN?
09:22:45 <TrueBrain> I wonder if we shouldn't remove that code from YAPF ..
09:22:51 <TrueBrain> peter1138: I think that is the best solution, yes
09:23:06 <TrueBrain> it is really rare those values are different .. and we can argue that POSIX defines we should support both
09:23:25 <TrueBrain> but .. if no mainstream OS has them as different values for decades now
09:23:28 <peter1138> If the values are the same, then compiler will(?!) optimize that out?
09:26:17 <TrueBrain> with -O1 and on, GCC does
09:27:10 <TrueBrain> but if we solve it, I think it should go in os_abstraction.h :)
09:27:14 <TrueBrain> such a niche issue :P
09:29:25 <peter1138> If the standard says it should check both values (even if they happen to be the same) then I don't see an issue doing that.
09:30:22 <TrueBrain> yeah, me neither. Just wonder what a clean solution is ..
09:30:38 <TrueBrain> as for Windows we need to map EAGAIN and EWOULDBLOCK to WSAWOULDBLOCK
09:30:43 <TrueBrain> which is also a bit weird :P
09:30:50 <TrueBrain> code becomes weird real quick this way :D
09:30:56 <TrueBrain> and easily forgotten for future-us
09:32:57 <TrueBrain> I am tempted to make an inline function in os_abstraction.h that handles this per OS for us, so we also don't accidentally mix ENNN with WASNNN
09:33:02 <TrueBrain> which can happen now really easily ..
09:33:07 <TrueBrain> (ENNN are also defined on Windows)
09:33:24 <peter1138> NetworkGetLastError is already abstracted, right?
09:33:25 <TrueBrain> but don't work the way you think :D
09:33:36 <TrueBrain> maybe just make it return our own enum values
09:34:15 <TrueBrain> on the other hand ... hmm ... no, I am really overthinking this
09:34:37 <peter1138> if (NetworkWouldBlock(err)), heh
09:34:50 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain merged pull request #9130: Change: use TCP for everything except for master-server and initial server scan https://git.io/J3Txp
09:35:32 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9140: Codechange: Acquire video buffer before taking game state lock to prevent erratic fast forward behaviour https://git.io/J3OFh
09:37:29 <peter1138> Yeah, I wondered about edge cases after :/
09:38:25 <TrueBrain> in general, moving anything out of the game-state-lock needs consideration :)
09:38:35 <TrueBrain> it might be fine .. it might blow up that one function we have :P
09:38:51 <TrueBrain> but I know screenshots take a lock on the video buffer too, I just don't know if it is a problem or not :D
09:40:41 <peter1138> Well, glad I hesitated last night.
09:41:23 <DorpsGek> [OpenTTD/OpenTTD] ccapitalK commented on pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3ON6
09:44:37 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J3OAa
09:45:28 <peter1138> That's nice and generic
09:46:23 <peter1138> A little extra code when they are not the same, but I guess that's better than not working :D
09:46:53 <TrueBrain> yeah .. I assume serenity will soon map EWOULDBLOCK to EAGAIN too, as I am pretty sure many more applications are going to fail :P
09:47:39 <peter1138> Is OpenTTD some test-case for this OS or something?
09:48:15 <TrueBrain> one person is trying to port OpenTTD to it, yes :) And he is finding lovely things :)
09:48:24 <TrueBrain> it is a nice way to make your OS compatible :D
09:49:14 <TrueBrain> quake and quake2 are also in the list now
09:49:22 <TrueBrain> quake2 landed 14 minutes ago, but okay :P
09:49:29 <peter1138> Sticking to the older games then :-)
09:49:53 <TrueBrain> I assume that is a game
09:49:58 <TrueBrain> as Nintendo would not like that
09:50:04 <peter1138> That... is odd, yeah.
09:50:06 <TrueBrain> can't find any other game in the list, which requires a patch
09:50:17 <TrueBrain> so if they tried other games, they run out-of-the-box :P
09:50:53 <TrueBrain> I am shocked that still exists .. Nintendo usually is really on top of that
09:51:57 <peter1138> Something about sprite cache
09:53:07 <peter1138> No IPv6 support. What's the point in an OS that doesn't these days...
09:53:23 <TrueBrain> it is a work-in-progress OS, from what I gather
09:53:27 <TrueBrain> you can't go from 0 to 100 in 1 day :D
09:53:36 <peter1138> Better implement IPv6 than IPv4 :p
09:53:44 <TrueBrain> IPv6 is a lot more complex,sadly
09:55:57 <peter1138> Rather annoyed that the feature I added yesterday add 1000+ LoC :(
09:56:13 <peter1138> Considering I wrote it all yesterday, that's...
09:56:27 <TrueBrain> what feature did you write?
09:56:31 <peter1138> Work related, not OpenTTD.
09:56:44 <TrueBrain> well, if you know what to write, writing is often easy :)
09:56:48 <TrueBrain> just now fixing the bugs ..
09:56:52 <TrueBrain> that is the hard part :P
09:57:23 <peter1138> #9139 was nice, +30 -117.
10:18:31 <Samu> isn't that used to count nodes
10:19:46 <nielsm> how often do you use it?
10:21:23 <Samu> last time i used was to debug ship pathfinding issues
10:22:10 <DorpsGek> [OpenTTD/OpenTTD] LordAro dismissed a review for pull request #9143: Remove: performance measurements in YAPF https://git.io/J33ks
10:22:44 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9143: Remove: performance measurements in YAPF https://git.io/J33kH
10:23:19 <nielsm> so what's the performance impact of measuring performance
10:23:47 <LordAro> "depends how expensive gettimeofday is"
10:23:48 <peter1138> I had a savegame that showed a considerable impact on the vehicle controllers.
10:24:07 <peter1138> Don't remember which.
10:25:45 <LordAro> shall i reopen it? :p
10:25:47 <peter1138> Somewhat extreme case.
10:26:06 <peter1138> Probably not. The issue is valid, the changes were... problematic.
10:26:34 <peter1138> It was slower for some systems.
10:27:18 <LordAro> perhaps we just need a lighter-weight clock
10:27:25 <LordAro> it doesn't need to be super accurate really
10:27:35 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9143: Remove: performance measurements in YAPF https://git.io/J33Lq
10:28:19 <peter1138> The issue with the tick handler is it's testing for each individual vehicle, not as a group.
10:29:30 <peter1138> Thread the tick handlers ;)
10:32:49 <nielsm> the right thing to do, I think, would be making separate vectors for storing the different vehicle types in
10:33:52 <nielsm> and if global vehicle IDs are still required (I guess they are for some things) make that a container of references to the actual storage
10:33:53 <peter1138> Yeah, splitting them fundamentally instead of just during that loop.
10:34:13 <peter1138> Hmm, of course, IDs.
10:34:53 <nielsm> there's a couple different approaches
10:35:16 <peter1138> IIRC it's possible to maintain vectors/lists for each type for just those vehicles that need a tick handler.
10:35:44 <nielsm> it might be possible to let the compiler transform virtual calls into direct calls, if the right structure is chosen
10:35:45 <peter1138> For trains you also only want head engines, anything else is dead.
10:36:02 <peter1138> And RVs too, though that's less common.
10:36:10 <peter1138> Aircraft. Okay, so everything :p
10:36:32 <nielsm> not sure about disaster vehicles
10:36:34 <peter1138> We should make a ship shadow.
10:36:44 <peter1138> Passenger/Mail ships...
10:37:34 <peter1138> Might be possible to maintain the list on running/stopped status.
10:37:43 <peter1138> My UPS just clicked... wonder if that was an auto test...
10:38:15 <peter1138> Selftest, never noticed before, heh.
10:38:34 <nielsm> even just maintaining a list of head vehicles for each type can be a big gain I think
10:38:52 <nielsm> started/stopped is probably very minor
10:39:08 <nielsm> (having a significant number of stopped vehicles is unusual isn't it)
10:40:01 <peter1138> I was think in terms of having a simple test for whether a vehicle should be in a list or not.
10:40:09 <nielsm> memory efficiency wise, having actual memory managed pools of a single type of vehicle could be a gain, but that's not relly necessary at first, I think
10:41:27 <peter1138> Hmm, what's the highest you've ever seen aircraft ticks? :D
10:41:57 <peter1138> No pathfinding at all, the only thing is the number of times their tick handler is called per tick...
10:48:57 <TrueBrain> so now the RDTSC comment is no longer a lie \o/
10:50:03 <TrueBrain> Serenity already has a PR pending to collapse EWOULDBLOCK to EAGAIN :P They move quick :)
10:59:06 <peter1138> Their PR works as is, so I'm not sure what the issue with EAGAIN under Windows is.
11:03:11 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #9141: Codechange: Use C++ features for train wagon overrides. https://git.io/J3mdD
11:15:06 <TrueBrain> peter1138: EAGAIN under Windows is not a valid socket error .. who knows what value it points to :D
11:18:41 <peter1138> Ah, so it compiles but isn't right.
11:21:00 <Rubidium> it's just checking for a return value that winsock won't return
11:21:54 <Rubidium> it's similar to EINPROGRESS
11:23:20 <TrueBrain> We fake all the other ENNN under Windows
11:23:27 <TrueBrain> Makes easier code :p
11:24:29 <Rubidium> I find some of the Serenity "fixes" for OpenTTD actually quite odd
11:32:16 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #9043: Feature: ability to build overlapping bridges on different axes https://git.io/J338Y
11:47:10 <TrueBrain> Rubidium: it is a work in progres .. so they do what they need to get it working for now, and build from there, I would guess :)
11:47:57 <DorpsGek> [OpenTTD/OpenTTD] Milek7 commented on pull request #9140: Codechange: Acquire video buffer before taking game state lock to prevent erratic fast forward behaviour https://git.io/J33RA
12:27:05 *** tokai|noir has joined #openttd
12:27:05 *** ChanServ sets mode: +v tokai|noir
12:34:02 *** tokai has quit IRC (Ping timeout: 480 seconds)
13:15:10 <DorpsGek> [OpenTTD/OpenTTD] ccapitalK commented on pull request #9142: Fix: TCP handling code is not posix compliant https://git.io/J33Qc
13:32:56 *** ChanServ sets mode: +v tokai
13:38:09 *** sla_ro|master has quit IRC ()
13:39:48 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
14:16:53 *** tokai|noir has joined #openttd
14:16:53 *** ChanServ sets mode: +v tokai|noir
14:17:44 *** Progman has joined #openttd
14:23:48 *** tokai has quit IRC (Ping timeout: 480 seconds)
15:18:13 *** Wormnest has joined #openttd
15:22:09 <peter1138> Why do I get all the 'fun' feature requests at 4pm on the Friday?
15:22:27 <peter1138> Do they think I'll be likely to just carry on working on it over the weekend...
15:30:29 <glx> oh that's a new call stack
15:30:38 <glx> but should be the same as other crash
15:36:41 <glx> and dmp is inexploitable because crash happens inside video driver
15:46:24 *** sla_ro|master has joined #openttd
15:47:59 <glx> ati driver crashing is not good
15:48:09 <peter1138> Standard practice for ATI :p
15:48:38 <peter1138> Could easily be one of the things that is fixed.
15:55:30 <glx> quick search seems to indicate this driver is very recent, and I found crash reports for after effects and minecraft
16:08:47 <glx> ok after some dll hunting I can read the dmp
16:10:47 *** andythenorth has quit IRC (Quit: andythenorth)
16:11:58 *** andythenorth has joined #openttd
16:13:06 *** andythenorth has quit IRC ()
16:14:12 *** andythenorth has joined #openttd
16:26:49 *** tokai|noir has quit IRC (Quit: c('~' )o)
16:43:31 *** y2kboy23_ has quit IRC (Remote host closed the connection)
16:47:41 <FLHerne> glx: ATI hasn't existed for a decade, so it can't be that recent :p
16:49:03 *** y2kboy23 has joined #openttd
17:09:57 *** jottyfan has joined #openttd
17:27:06 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
17:38:07 *** didac has quit IRC (Remote host closed the connection)
17:46:34 <Timberwolf> is record nonsense time.
17:46:48 <andythenorth> livestreaming is quite addictive
17:47:25 <andythenorth> did I ban-hammer FIRS without appropriate vehicle grfs yet?
17:47:33 <Timberwolf> I think I'd enjoy livestream if I had a big enough audience and didn't need to take the occasional "have the dogs undermined the foundations yet?" break.
17:52:49 <peter1138> 1) bicycle or 2) beer?
17:53:06 <peter1138> I'm... not really in the mood for 1. Why did I even mention it?
17:53:43 <Rubidium> you know you can combine them, right?
17:53:50 <FLHerne> (1), and you know it, which is why you mentioned it
17:54:04 <andythenorth> I am happy with my choices
17:54:15 <FLHerne> That said, I'm effectively at (2), but with tea
17:59:21 <peter1138> ^ those are not default vehicles, right?
17:59:40 <peter1138> Okay, the wagons are default, but the engines don't seem to be.
18:00:11 <nielsm> the Toyland to Mars set might be doing something yes...
18:01:38 <peter1138> Toyland 2 Mars doesn't exactly work. Maybe I have an ancient version of it.
18:02:36 <peter1138> "Error: You need to deactivate the default canals graphics"
18:05:26 <Rubidium> git checkout 0.1.0 ?
18:05:52 <LordAro> good luck compiling it
18:10:17 <Rubidium> I don't need luck for that, just the right tools
18:10:57 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GL5
18:14:20 <TrueBrain> GOG finished creating the OpenTTD pages, in my inbox for approval now :D (guess also in info@)
18:24:59 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GfF
18:38:46 *** gelignite has joined #openttd
18:42:11 *** luaduck has quit IRC (Ping timeout: 480 seconds)
18:42:40 <TrueBrain> funny, so basically GOG QA found two issues: they couldn't setup networking, and non-latin languages show question marks
18:42:48 <TrueBrain> their QA is pretty decent :D
18:43:15 <TrueBrain> good thing we are at least addressing the first, and we really should address the second
18:51:46 <TrueBrain> What Ubuntu version OpenTTD runs on
18:51:58 <TrueBrain> but also told more realistic is to say 18.04+ :)
18:53:59 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GCm
18:55:03 <TrueBrain> right, also looped in JGR about the network plans, to not blindside him with our changes :)
19:11:11 <andythenorth> ok let's have some bets
19:11:24 <andythenorth> can I force an industry into every town using the probability callback?
19:12:32 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
19:12:40 <andythenorth> first I need a var for number of towns on map
19:12:44 <andythenorth> that does't exist
19:17:59 <andythenorth> goes it add a var?
19:18:18 <peter1138> It wouldn't need a savegame bump at least.
19:18:37 <andythenorth> I mean...this is just for silly ideas
19:19:07 <andythenorth> if we use xml for grfs
19:19:10 <andythenorth> that will be solved
19:19:22 <peter1138> Any idea what the values mean in an svg path?
19:19:32 <peter1138> M4 66 Q5.18636 66 7.07651 66 Q8.96666 66 12
19:19:38 <andythenorth> if one of them is the colour I understand
19:19:44 <andythenorth> are these bezier curves?
19:20:32 <andythenorth> this is actually interesting
19:20:43 <andythenorth> svg is quite a nice format, it can be templated with text templaters
19:21:22 <peter1138> What I'd like is to create a file the programmer's way rather than an artists way. Putting in numbers...
19:21:34 <peter1138> Perhap more like CAD, I guess.
19:21:43 <andythenorth> Q is a quadratic bezier
19:21:58 <andythenorth> "A quadratic Bézier segment is defined by a start point, an end point, and one control point."
19:22:11 <andythenorth> Moveto is just like logo, remember logo?
19:22:23 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
19:22:24 <andythenorth> we mostly did it on screen not the actual turtle
19:22:44 <andythenorth> OT: big trak is not all that it could be
19:22:45 *** WormnestAndroid has joined #openttd
19:22:58 <andythenorth> the rotation counters in the wheels are unreliable
19:25:05 <andythenorth> hmm haven't watched Big Clive for a while
19:26:00 <Timberwolf> He was distilling whiskey the other day.
19:26:28 <Timberwolf> Assuming YT didn't just point me at a 3 year old video for reasons.
19:33:29 *** jottyfan has joined #openttd
19:33:51 * andythenorth wonders about cloning Flash in SVG
19:33:55 <andythenorth> with no programming skills
19:34:20 <andythenorth> ha ha svg Chocks Away?
19:34:26 <andythenorth> goes it Sopwith Camel?
19:40:13 *** Wormnest has joined #openttd
19:42:08 <DorpsGek> [OpenTTD/OpenTTD] Milek7 opened issue #9147: MakeScreenshot locking is broken when called from outside of VideoDriver::Tick https://git.io/J3GgU
19:55:09 *** frosch123 has joined #openttd
20:08:33 *** arikover has joined #openttd
20:12:53 *** arikover` has joined #openttd
20:18:11 *** arikover has quit IRC (Ping timeout: 480 seconds)
20:22:43 <DorpsGek> [OpenTTD/OpenTTD] frosch123 opened pull request #9148: Support NewGRF cargoes with default vehicles https://git.io/J3G6D
20:23:05 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9148: Support NewGRF cargoes with default vehicles https://git.io/J3G6H
20:23:09 <frosch123> andythenorth: your fault
20:23:43 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #9149: Codechange: Replace more FOR_ALL_XXX macros with range-based for loops https://git.io/J3G6A
20:23:56 <glx> I hate writting descriptions
20:24:43 <frosch123> yep, for 9148: 1/3 implementation, 1/3 testing, 1/3 PR description :p
20:26:14 *** jottyfan has quit IRC (Quit: jottyfan)
20:28:12 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:28:31 *** WormnestAndroid has joined #openttd
20:32:47 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
20:33:08 <DorpsGek> [OpenTTD/OpenTTD] embeddedt started discussion #9150: RFC: Have OpenTTD *not* lock the cursor position when dragging viewports by default https://git.io/J3GPg
20:46:39 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GMJ
20:49:04 <LordAro> looks a bit like opengfx is corrupted
20:49:11 <LordAro> does it happen with other basesets too?
20:49:23 <TrueBrain> how is that working as expected? :P
20:49:40 <LordAro> (i would be surprised if that commit had anything to do with it)
20:50:34 <arikover`> It happens all the time, but when launching a nightly, it works fine. I'm obviously missing something... CMake flag maybe?
20:50:53 <LordAro> debug vs release, perhaps?
20:51:13 <LordAro> cmake -DCMAKE_BUILD_TYPE=Release
20:51:19 <nielsm> the sprites missing seem to be exactly those that are "additional" over the original baseset
20:51:50 <LordAro> ah... ottd_extra.grf missing?
20:52:11 <nielsm> well yes but not, OpenGFX is supposed to contain those sprites on its own
20:54:05 <FLHerne> frosch123: Do you know when the Manley-Morel became "All but Oil" ? It must have been fairly early in OTTD, I remember exploiting that around when I first played
20:54:23 <FLHerne> I had these wood-carrying DMU trains
20:54:48 * andythenorth is NCG with Pikka and will read 9148 soon :)
20:54:56 <andythenorth> although the script just crashed, so maybe game over
20:59:08 <frosch123> LordAro: opengfx checks for ottd > 1.2
20:59:53 <frosch123> so, when _openttd_newgrf_version does not say ">= 1.2", opengfx will disable
21:01:11 <arikover`> I built with "cmake -DCMAKE_BUILD_TYPE=Release", that might be the problem...
21:05:27 *** erle- has quit IRC (Remote host closed the connection)
21:06:05 <frosch123> FLHerne: in TTD only ships and aircraft are refittable. trains do not have that button. train refitting was added before svn r1, so no one knows when exactly. but you can still find when someone messed up and added rubber during some refactoring
21:06:49 <frosch123> though TTD is already pretty arbitrary with disallowing oil, rubber and tropic food. but allowing water and arctic food :p
21:08:12 <frosch123> FLHerne: 0.3.2 (2004-05-22) lists "- Feature: Train refitting"
21:08:34 <frosch123> so between 0.3.1 (2004-04-26) and 0.3.2 (2004-05-22) :)
21:08:54 <frosch123> andythenorth: why is kaolin liquid?
21:09:04 <DorpsGek> [OpenTTD/OpenTTD] perezdidac commented on pull request #9043: Feature: ability to build overlapping bridges on different axes https://git.io/J3GSh
21:09:23 <milek7> "CMAKE_PROJECT_VERSION_MAJOR New in version 3.12."
21:09:31 <milek7> cmake_minimum_required(VERSION 3.9)
21:09:48 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
21:10:23 <nielsm> I guess kaolin is basically fine dust that behaves like a liquid?
21:10:24 <frosch123> but is it liquid, or powder?
21:11:03 <andythenorth> it can be transported as a slurry, or dry powder, or in-between
21:11:20 <andythenorth> it's a silly cargo
21:11:58 *** Gustavo6046 has joined #openttd
21:13:39 <arikover`> milek7: I've got CMake 3.10.2: It worked correctly until this commit
21:13:59 <frosch123> andythenorth: no problem, it just confused me when testing :)
21:14:06 <milek7> you need 3.12 at least
21:14:18 <andythenorth> it's a bit silly to include it in the default Basic economy
21:23:17 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
21:24:09 *** WormnestAndroid has joined #openttd
21:26:00 *** andythenorth has quit IRC (Quit: andythenorth)
21:26:07 *** Samu has quit IRC (Quit: Leaving)
21:27:50 <arikover`> Thank you all for your help milek7 LordAro nielsm
21:28:12 <arikover`> I will try and install a newer version of cmake then...
21:28:16 *** arikover` has quit IRC (Quit: ERC (IRC client for Emacs 27.1))
21:31:24 <FLHerne> frosch123: 0.3.2 is pretty early :-)
21:31:51 <FLHerne> What will happen to existing savegames where DMUs are refitted to non-passenger cargos?
21:32:06 <frosch123> see "limitations" in the PR description :)
21:33:25 <FLHerne> Is there a technical reason to restrict the existing set of cargos?
21:33:43 <FLHerne> Or did you simply decide that DMU carriages full of coal are silly?
21:34:35 <FLHerne> I assume, perhaps wrongly, that whenever it was added someone thought it was a good idea
21:34:52 <FLHerne> but since it's pre-version-control we may never know :p
21:36:42 <frosch123> i made it this way, because then the transition to using newgrf is more consistent
21:37:07 <frosch123> technically you can define dmu as: transport these default cargos, and newgrf cargos with these classes
21:39:25 <frosch123> so the options are (1) keep the weird original refittabilty, but make newgrf refitting depend on classes -> looks pretty arbitary when using newgrf (2) also make them refittable to all newgrf cargos -> but why no oil then? (3) use cargo classes for default cargos and newgrf cargos -> i like it, it's easier to explain, but it means "change" :p
21:39:46 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3Gdr
21:40:14 <frosch123> basically it comes down to: if manley-morel dmu is refittable to water, but not oil. what should it do for alcohol?
21:41:33 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9147: MakeScreenshot locking is broken when called from outside of VideoDriver::Tick https://git.io/J3GgU
21:42:00 <frosch123> same for the ships: the cargo ship transports water, but no oil. (same in ottd 0.1 and 1.11)
21:42:12 <DorpsGek> [OpenTTD/OpenTTD] Milek7 opened pull request #9151: Fix: Correct minimum CMake version to 3.12, as it is actually required since d4f0b6f43 https://git.io/J3Gdb
21:43:22 <FLHerne> frosch123: I'd think (1), people expect arbitrary stuff to be different with newgrfs anyway
21:44:06 <didac> frosch123: I made good progress on #9043 (bridges over bridges on different axes) but there are 2 rendering issues I am observing: (1) if the bottom bridge has a catenary it randomly draws that tile wrong. (2) when trains go through sometimes the bridge roof glitches too. Screenshots in the PR https://github.com/OpenTTD/OpenTTD/pull/9043. I wanted to ask you if you had a suggestion on what I can look into. Allegedly I am drawing thing
21:45:00 <FLHerne> frosch123: As it stands, your PR would 'break' quite a few of my early savegames, if I still had them :p
21:46:03 <FLHerne> Agree that it's kind of weird
21:47:13 *** gelignite has quit IRC (Quit: Stay safe!)
21:49:12 <DorpsGek> [OpenTTD/OpenTTD] frosch123 commented on pull request #9043: Feature: ability to build overlapping bridges on different axes (WIP) https://git.io/J3GF9
21:51:54 <frosch123> FLHerne: what about ships? should the cargo ship continue to transport water and rubber, while the oil tanker transport all other liquids?
21:52:23 <frosch123> also, no idea when ottd broke the aircraft from your early games
21:52:49 <FLHerne> Probably never, because aircraft are boring and I didn't use them ;-)
21:53:06 <frosch123> 0.3.6 (2005-01-24): - Feature: Aircraft refit options have been restricted to 'sane' values
21:53:54 <FLHerne> 0.3.2 -> 0.3.6 is pretty short compared to 15+ years
21:54:10 <FLHerne> So I suppose I'd say "yes" to the ship thing too
21:55:04 <FLHerne> The weirdness is a fait accompli, people who want realistic behaviour can grf it
21:55:05 <frosch123> i think ottd made bigger breaking things
21:55:50 <frosch123> like catchment area, vehicle servicing, and other things
21:56:21 <DorpsGek> [OpenTTD/OpenTTD] James103 opened issue #9152: Console output for `screenshot heightmap` mistakenly has the `ERROR` prefix https://git.io/J3GbD
21:56:45 <FLHerne> What changed with vehicle servicing?
21:57:16 <FLHerne> But you can't leave that one to grfs
21:57:55 <frosch123> vehicle servicing changes when someone uses that weird automatic servicing, where ottd decides if there is a depot nearby to visit when it wants to
21:58:06 <FLHerne> I do wonder how many other people really used the weirder cargo refits
21:58:13 <frosch123> that "nearby" probably changed several times
21:58:46 <FLHerne> Anyone without explicit 'service' orders was doomed from the start
21:59:17 <frosch123> in any case, that PR will break savegames that *do* use NewGRF, and where players happily transport alcohol with the grain hopper
21:59:26 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GNJ
22:00:29 <frosch123> so, technically, everything is possible. we can also add a hidden setting to "simulate old cargo refitting" :p
22:00:50 <frosch123> but I prefer to not pile crap on crap, when it's not worth it
22:01:00 <FLHerne> Are there industry/cargo grfs where the baseset vehicles actually carry all the cargos, if 'wrong' ones?
22:01:41 <frosch123> the baseset vehicles use cargoslots 0 to 12
22:01:44 <FLHerne> With FIRS/ECS at least that seems like a very hypothetical breakage, because no-one would play a long game without realising they needed a vehicle set
22:01:51 <DorpsGek> [OpenTTD/OpenTTD] James103 opened issue #9153: Message popup from `screenshot heightmap` is `WL_CRITICAL` and not `WL_ERROR` https://git.io/J3GNl
22:01:52 <frosch123> so they will transport the first 12 cargos of any industry set, whatever they are
22:02:07 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GN4
22:02:14 <FLHerne> Maybe TaI, I think that kept things simple
22:02:36 <FLHerne> I did think of the setting idea, but it's terrible
22:02:41 *** jottyfan has joined #openttd
22:03:07 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:03:07 <FLHerne> The only thing worse than weird behaviour is weird behaviour that's different depending on a magic setting :p
22:04:03 <frosch123> i would claim 90% of players just play like that
22:05:01 <FLHerne> frosch123: Whenever it comes up on forums, it's someone who's just started with FIRS and realized there's a problem
22:05:08 <frosch123> but okay, they would notice the "cargo is not transportable by anything" part
22:05:18 <FLHerne> I could believe that many players run into that
22:05:50 <FLHerne> I doubt many players get far into a game they'd want to keep without correcting it or abandoning FIRS or whatever
22:11:36 <Timberwolf> I put up a FIRS 4 tutorial today, it's outperformed everything I've done across all metrics (views, % viewed, time viewed)
22:12:36 <Timberwolf> I didn't realise there wasn't one out there, other than Master Hellish did a spotlight video around FIRS... 2, possibly?
22:13:13 <Timberwolf> He made the same point back then that you need to download vehicles to make it work.
22:13:56 *** sla_ro|master has quit IRC ()
22:34:14 <LordAro> wallyweb should know better
22:38:00 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on pull request #9151: Fix: Correct minimum CMake version to 3.12, as it is actually required since d4f0b6f43 https://git.io/J3Zve
22:49:33 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3GfF
22:52:34 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #9146: Codechange: encapsulate network error handling (and fix #9142) https://git.io/J3ZfD
22:57:49 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
22:59:44 <DorpsGek> [OpenTTD/OpenTTD] glx22 opened pull request #9154: Fix d4f0b6f4: [CMake] CMAKE_PROJECT_VERSION_XXX are not in CMake 3.9 https://git.io/J3ZJz
23:06:12 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
23:06:32 *** WormnestAndroid has joined #openttd
23:13:06 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:17:35 *** Wormnest has joined #openttd
23:38:02 *** Speeder_ has joined #openttd
23:42:34 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #9148: Support NewGRF cargoes with default vehicles https://git.io/J3Ztd
23:42:49 *** Speeder has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵