IRC logs for #openttd on OFTC at 2023-04-09
00:00:53 <DorpsGek> [OpenTTD/OpenTTD] glx22 commented on issue #10615: [Bug]: Flatpak OpenTTD hangs and never starts
00:00:56 <DorpsGek> [OpenTTD/OpenTTD] glx22 reopened issue #10615: [Bug]: Flatpak OpenTTD hangs and never starts
00:04:49 *** Orang has quit IRC (Quit: User went offline on Discord a while ago)
00:25:32 *** sla_ro|master has quit IRC ()
00:39:14 *** Flygon has quit IRC (Remote host closed the connection)
01:15:24 <DorpsGek> [OpenTTD/OpenTTD] KenSharp commented on issue #10615: [Bug]: Flatpak OpenTTD hangs and never starts
01:51:59 *** geli has joined #openttd
01:59:22 *** gelignite has quit IRC (Ping timeout: 480 seconds)
02:09:48 *** geli has quit IRC (Quit: Stay safe!)
02:23:46 *** Wormnest has quit IRC (Quit: Leaving)
02:35:16 *** bryjen has quit IRC (Quit: Leaving)
02:53:22 *** D-HUND has joined #openttd
02:56:50 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:02:01 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:02:04 *** WormnestAndroid has joined #openttd
03:03:51 *** D-HUND is now known as debdog
03:03:52 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:04:29 *** WormnestAndroid has joined #openttd
03:42:47 *** keikoz has joined #openttd
03:45:04 *** TallTyler has quit IRC (Remote host closed the connection)
03:45:04 *** petern has quit IRC (Remote host closed the connection)
03:45:04 *** TrueBrain has quit IRC (Remote host closed the connection)
03:45:04 *** EmperorJake has quit IRC (Remote host closed the connection)
03:45:04 *** wyndbain has quit IRC (Remote host closed the connection)
03:45:04 *** MnHebi has quit IRC (Remote host closed the connection)
03:45:04 *** DorpsGek_v has quit IRC (Remote host closed the connection)
03:45:04 *** discord_user_f4a0790 has quit IRC (Remote host closed the connection)
03:45:04 *** michi_cc[d] has quit IRC (Remote host closed the connection)
03:45:04 *** Brickblock1 has quit IRC (Remote host closed the connection)
03:45:04 *** dP has quit IRC (Remote host closed the connection)
03:45:04 *** Kuhnovic has quit IRC (Remote host closed the connection)
03:45:04 *** andythenorth has quit IRC (Remote host closed the connection)
03:45:04 *** AJ[d] has quit IRC (Remote host closed the connection)
03:45:04 *** audigexJon has quit IRC (Remote host closed the connection)
03:45:04 *** JohnFranklin has quit IRC (Remote host closed the connection)
03:45:04 *** glx[d] has quit IRC (Remote host closed the connection)
03:45:04 *** JGR has quit IRC (Remote host closed the connection)
03:45:04 *** jfs- has quit IRC (Remote host closed the connection)
03:45:04 *** Paltala has quit IRC (Remote host closed the connection)
03:45:30 *** DorpsGek_v has joined #openttd
06:15:56 *** nielsm has joined #openttd
07:03:26 *** Merni has joined #openttd
07:03:26 <Merni> I have a question- why are the 4 big climate selection buttons still there on the main menu, when they only take effect in the new world generation?
07:06:48 <nielsm> that's a really good question
07:07:03 <nielsm> "because they're iconic for the main menu layout", probably
07:08:40 <nielsm> in Transport Tycoon Deluxe, as far as I remember, when you clicked the New Game button you were shown a list of scenarios and "random world" to start from, and the climate selection buttons determined which set of scenarios would be shown
07:18:44 <pickpacket> Is there a way to send messages in the chat from a dedicated server?
07:18:58 <pickpacket> iiuc the server itself is a player
07:35:10 *** Azusa has joined #openttd
07:35:10 <Azusa> It's "say text_goes_here"
07:40:16 <pickpacket> Azusa: in the terminal..?
07:40:25 *** andythenorth has joined #openttd
07:40:25 <andythenorth> moin
07:59:04 *** sla_ro|master has joined #openttd
08:10:57 <Azusa> Yes
08:11:18 *** Wolf01 has joined #openttd
08:37:57 <DorpsGek> [OpenTTD/OpenTTD] Alberth289346 opened pull request #10616: Fix: Update top toolbar tooltips for added features.
08:43:10 <LordAro> wild Alberth PR appears
08:46:03 <andythenorth> woo
08:46:20 <andythenorth> Alberth might have played the game a bit
08:46:27 <andythenorth> had some DM chat
08:46:37 <andythenorth>
08:46:37 <andythenorth> meanwhile ships ๐Ÿ˜›
08:46:45 <andythenorth> are like ants marching a line
08:47:25 <andythenorth> can we say the word 'stochastic' here?
08:49:19 *** gelignite has joined #openttd
08:51:02 *** lobstarooo_ has joined #openttd
08:54:58 *** EmperorJake has joined #openttd
08:54:58 <EmperorJake> It looks better if you use directional buoys
08:55:27 <EmperorJake> And JGR ships avoid collision
08:58:33 <andythenorth> well
08:58:39 <andythenorth> _someone_ has to play vanilla ๐Ÿ˜›
08:58:46 <andythenorth> it's usually me
09:03:55 <EmperorJake> Directional buoys don't need JGR
09:13:14 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on issue #10615: [Bug]: Flatpak OpenTTD hangs and never starts
09:13:56 *** TrueBrain has joined #openttd
09:13:56 <TrueBrain> "why doesn't it work?!" .. well .. offscreen is offscreen? ๐Ÿ˜„
09:17:35 <TrueBrain> okay, I was looking through our code how many different timers we have and want to have .. I am up to 6 .. we might want a bit of better infrastructure for this ๐Ÿ˜„
09:19:56 <andythenorth> I heard you like timers?
09:19:59 <LordAro> what are they?
09:20:28 <TrueBrain> Writing a gist, as I need this written down ๐Ÿ˜„
09:48:28 <TrueBrain> still working on it, but just trying to give an overview of all the different places we have date/time concept ๐Ÿ™‚
09:48:43 <TrueBrain> and how I think we have to address it ๐Ÿ™‚
09:49:59 <TrueBrain> I still ike OnHundredthTick .. it is just: poke me once in a while so I can refresh my list
09:50:05 <TrueBrain> but the name suggests something much more specific ๐Ÿ˜›
09:50:14 <DorpsGek> [OpenTTD/OpenTTD] michicc approved pull request #10616: Fix: Update top toolbar tooltips for added features.
09:52:29 <TrueBrain> some Window code is just a bit odd ... we check every 30ms if the fast-forward and pause button are in the correct state ๐Ÿ™‚
09:56:04 <TrueBrain> but in general it seems we have reimplemented date/time concepts over and over in different places, by different developers ๐Ÿ™‚ Similar, but different.
09:58:26 <TrueBrain> ha, `HandleBankruptcyTakeover` is ofc also game-time based .. explains ofc why in FFWD that goes by rapidly ๐Ÿ˜„
09:58:39 <TrueBrain> I get it, but it is also annoying ๐Ÿ˜›
10:04:09 *** gelignite has quit IRC (Quit: Stay safe!)
10:06:55 <TrueBrain> that gist also shows why fast-forward for multiplayer would be terrible .. people would lag out left and right ๐Ÿ˜›
10:21:07 *** dP has joined #openttd
10:21:07 <dP> it can be fine if used resonably
10:21:14 <dP> 2x ff on the start of the game won't lag out anyone
10:46:54 <nielsm> TrueBrain: if a network server is paused, wouldn't a client that's falling behind actually be able to catch up? the server pause should happen on a specific game tick afaik, and if the client is behind then it'll keep running the simulation until it reaches that tick where the server paused. I think.
10:49:50 <TrueBrain> nielsm: Yup, it will catch up. You just have to pause before it lags out
10:50:13 <TrueBrain> Not sure why you ask?
10:50:35 <nielsm> because your gist is written as if that's an unintended and undesired effect
10:53:14 <TrueBrain> There are two things to that remark. Mostly, my gist is pointing out how silly it is to use game-ticks to detect things like "time a client has to join a game"
10:53:42 <TrueBrain> But also, even if we take your suggestion: pausing would mean the client catches up. But as soon as you unpause, it will start to lag behind again
10:53:52 <TrueBrain> so you get a jojo effect there ๐Ÿ™‚
10:55:20 <TrueBrain> it is just such weird code .. it always has been .. but back then we didn't have `std::chrono` ๐Ÿ˜„
10:58:51 *** Flygon has joined #openttd
11:06:14 <dP> network lag uses frame counter, not tick counter so it's not affected by pause
11:07:12 *** lobstarooo_ has quit IRC (Remote host closed the connection)
11:10:31 *** sla_ro|master has quit IRC ()
11:16:12 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on pull request #10614: WIP: scale out TileLoop, to speed up bigger maps
11:16:30 <dP> it's actually not a bad side-effect that if server starts lagging it extends timeouts
11:17:40 <TrueBrain> JGR: those are the only two you found? ๐Ÿ˜„ But yeah .. many places currently break .. there are more side-effects in the TileLoop than I was hoping for ๐Ÿ™‚
11:18:50 *** JGR has joined #openttd
11:18:50 <JGR> I was going to do some tests on the worker thread pool and noticed that issue
11:19:39 <TrueBrain> the thing I am currently a bit afraid of: making TileLoop thread-safe might in fact result in a slower experience overall
11:19:47 <TrueBrain> because of the amount of locking / queuing needed
11:19:57 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on pull request #10614: WIP: scale out TileLoop, to speed up bigger maps
11:20:02 <TrueBrain> or that it is faster with 8 cores, but not with 2
11:20:03 <TrueBrain> something like that
11:21:24 <TrueBrain> and, I guess, the amount of "I can't join this server on my shitty computer" will get worse ๐Ÿ˜›
11:21:34 <TrueBrain> now everyone is on the same level .. as everyone has at least one core!
11:22:14 <DorpsGek> [OpenTTD/nml] EmperorJake commented on issue #79: No support for NRT tunnels
11:22:46 <EmperorJake> I'm trying to make a nice road set and keep running into roadblocks (heh)
11:23:05 <EmperorJake> so I will keep pestering until maybe somethig gets done
11:23:27 <JGR> Many of the tile loop handlers themselves can be further optimised, which affects the calculations for how much parallelisation is useful
11:23:54 <JGR> On large maps, it's not so much a CPU issue, as a memory access one
11:24:20 <dP> actually, yeah, tileloop generally doesn't take that much time
11:24:27 <dP> especially if you optimize flooding
11:24:31 <TrueBrain> JGR: which can be seen by the fact a 4kx4k map is 3 times faster with my PR, but consumes 5 times more CPU ๐Ÿ˜„
11:25:06 <JGR> The tile loop is effectively random access meaning cache misses, and many tile loop handlers (unnecessarily) access their neighbours, meaning more cache misses
11:25:09 <TrueBrain> it really doesn't help we walk semi-random through the tiles ๐Ÿ˜›
11:25:41 <TrueBrain> so I am not sure if my PR is actually a good path to walk .. but it is a nice experiment ๐Ÿ™‚
11:25:42 <dP> reorder map array randomly? ๐Ÿคฃ
11:26:26 <JGR> I've tried to reduce unnecessary neighbour checks for things like water flooding and snow line movement
11:26:36 <FLHerne> remove map array in favour of mechanic-specific data structures :p
11:26:46 <TrueBrain> JGR: did that help any?
11:26:46 <dP> snow line uses neighbour checks? why?
11:26:50 <FLHerne> or a lot of it
11:26:57 *** glx has joined #openttd
11:26:58 <glx> EmperorJake: `tunnels` callback doesn't work ?
11:27:31 *** glx is now known as Guest10432
11:27:31 <EmperorJake> Not part of the NRT spec because someone decided it's not necessary and that's that
11:27:32 *** Guest10432 is now known as glx[d]
11:28:09 <JGR> dP: Because GetTileZ checks three neighbouring tiles
11:28:10 <EmperorJake> the comments in the github issue tell the story
11:28:17 <dP> splitting map array into chunks may also be an interesting solution...
11:28:34 <dP> spread performance between random checks and neighbor checks
11:28:39 <JGR> But in most cases you only need the height of the current tile's corner to make a decision
11:29:20 <dP> oh, silly height xD
11:29:42 <JGR> TrueBrain: It does help on large maps
11:29:58 <TrueBrain> good; as that is the one thing that annoys me a lot .. that I can't really play a 4kx4k map
11:30:14 <glx[d]> EmperorJake: It's just missing documentation, but it's implemented
11:30:45 <TrueBrain> either way, the idea of scaling out I still like, as that enables more people to enjoy bigger maps .. but meh @ thread safety ..
11:30:53 <EmperorJake>
11:30:53 <EmperorJake> is my NML outdated?
11:31:17 <EmperorJake> Let me check a newer version
11:31:31 <JGR> Avoiding multiplayer desyncs are also likely to be interesting
11:31:46 <dP> it would be more beneficial to parallelize vehicles
11:32:07 <dP> something like calculate path in parallel, approve in order
11:32:08 <TrueBrain> JGR: hihi, very true ๐Ÿ™‚ That is why TileLoops need to have no side-effects! ๐Ÿ™‚
11:32:18 <TrueBrain> but it is much more subtle how it is not ๐Ÿ™‚
11:32:32 <glx[d]> Not in release yet EmperorJake
11:32:33 <dP> tileloop can't have no side-effects
11:32:44 <dP> whole game is very much a cellular automata
11:32:58 <nielsm> dP: that's the concept I was trying to implement in the branch I started last year or whenever it was
11:33:15 <nielsm> untangling the vehicle tick code is horrible
11:33:38 <TrueBrain> I have some more ideas to try out for TileLoop .. but first I am going to help out 2TallTyler with this date/time mess we have in OpenTTD ๐Ÿ˜„
11:34:01 <nielsm> I wonder if it'd be less work to just rewrite the entire vehicle movement code from scratch than try to convert it
11:34:19 <JGR> For game state stuff, I've generally gone for trying to streamline single-thread performance as much as possible
11:34:28 <TrueBrain> nielsm: you won't be the first to try it; but it has a lot of nuances and other weirdness ๐Ÿ˜› But worth another try honestly ๐Ÿ™‚
11:34:38 <JGR> Trying to untangle it for parallelisation is a bit daunting
11:34:47 <dP> nielsm: yeah, that may very well be the best approach
11:34:56 <dP> not only for parallel stuff but also movement logic
11:35:03 <dP> and maybe split infra from map array
11:35:20 <nielsm> the vehicles definitely need to be split into separate arrays
11:35:26 <nielsm> by type
11:35:38 <nielsm> or maybe just bookkeep arrays of the head vehicles
11:35:38 <TrueBrain> JGR: totally understandable ๐Ÿ™‚ But we get more and more CPUs with a lower clockspeed, but with more L2-cache and more cores .. bit afraid over time OpenTTD becomes less and less performant in that sense ๐Ÿ™‚
11:36:08 <JGR> nielsm: That's one thing I've got in my branch
11:36:14 <dP> idk about type, there was some unfixed bug that could benefit from it but other than that may not matter
11:36:23 <dP> openttd has very weird "vehicles" though
11:36:28 <dP> like graphic effects xD
11:39:18 <nielsm> I also wonder, if doing parallelisation of vehicle ticks, how much is it acceptable to alter behaviour slightly
11:39:43 <dP> depends on your definition of slightly xDDD
11:39:53 <TrueBrain> nielsm: at least one person would complain; I can promise you that ๐Ÿ˜„
11:40:02 <TrueBrain> but that shouldn't hold you back in doing so, honestly
11:40:27 <dP> if in general vehicles would still the same time to get from A to B it's probably ok
11:40:33 <nielsm> like taking one more or one less ticks to start moving or loading when departing or arriving at a station
11:40:53 <TrueBrain> even if you take 5 more ticks
11:41:10 <dP> take 10 less plz xD
11:41:20 <dP> of whatever that pbs backoff whaever is ;)
11:41:26 <TrueBrain> it really isn't all that relevant. Yes, the game will change. But that isn't an actual problem. We shouldn't aim to be bug-compatible either, for example ๐Ÿ™‚
11:41:57 <dP> haha, tell that to sprite sorter :p
11:42:08 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:42:39 *** WormnestAndroid has joined #openttd
11:44:08 <TrueBrain> nielsm: honestly, rewriting the vehicle code might just be a good exercise to see if it can be done in a multi-threaded way at all
11:45:19 <TrueBrain> (and if it actually helps :D)
11:46:09 <nielsm> maybe make it understandable
11:46:33 <dP> nielsm: actually, speaking of arriving at station, there is a whole bugged sub-tile, not just some ticks xD (#6503)
11:46:53 *** NGC3982 has quit IRC (Ping timeout: 480 seconds)
11:47:15 <nielsm> well that's the thing that has allowed you to crash competitor vehicles since the original Transport Tycoon, right?
11:47:28 <dP> something like that, yes
11:47:47 <dP> vehicle movement in ttd/openttd is graphical, not logical
11:47:50 <TrueBrain> nielsm: make sure we keep that; without that, the game feels broken ๐Ÿ˜›
11:47:53 <dP> causing numerous issues
11:49:32 <dP> may still be possible btw, same way as a crash into water in #6503 comments
11:49:43 <EmperorJake>
11:49:43 <EmperorJake> glx[d]: Ayy I got it to work, thanks so much ๐Ÿ™‚
11:52:07 <DorpsGek> [OpenTTD/OpenTTD] michicc merged pull request #10616: Fix: Update top toolbar tooltips for added features.
11:53:08 *** gelignite has joined #openttd
11:53:56 <Rubidium_> I think the whole problem with crashing beyond the tile is primarily due to a slew of off-by-ones, because the bound checks should practically be [x, y) in a particular direction (better explanation at
11:54:13 <JGR> TrueBrain: I had a look at the worker thread pool and came up with: <> instead
11:55:58 <dP> Rubidium_: because of movement being graphical it's kind of hard to tell where the vehicle actually is in the subtile and so how these off-by-ones should even work
11:56:04 <Rubidium_> the first thing to do is, I guess, write down exactly how it should work. And maybe even attempt to write some unit-ish tests for the different orientations; in I added something similar to ensure the (new) slopes are consistent
11:56:18 <JGR> Likely the difference with unconditionally notifying is small, but it depends on the platform
11:56:45 <TrueBrain> JGR: yeah, the unconditionally notifying is bad if you send a lot of tasks to the queue .. ๐Ÿ˜„
11:57:03 <TrueBrain> JGR: why btw not send the notification before the unlock? (in other words: why the `notify` boolean?)
11:57:21 <TrueBrain> as you still have the lock, a worker can't wake up anyway, right?
11:57:39 <dP> for road vehicles for example I couldn't even find an interpretation that makes movement continuous
11:57:55 *** petern has joined #openttd
11:57:55 <petern> Beep
11:58:04 <dP> and for trains that took some playing with vehicle direction offsetting position
12:00:20 <JGR> TrueBrain: The documentation on suggests that it's better to notify after releasing the lock
12:00:40 <TrueBrain> surprises me, but guess they have their reason ๐Ÿ˜„
12:00:41 <JGR> I haven't checked if there's any measurable difference
12:01:20 <TrueBrain> okay, yesterday I didn't realise yet why I trigger this issue .. but it was simply because I added items to the queue faster than the first thread woke up to pick up the work
12:01:33 *** jfs- has joined #openttd
12:01:33 <jfs-> I also wrote a worker thread implementation for my attempt at multithreading, I used promises/futures for it and that worked nicely
12:02:07 <jfs-> they handle all the synchronisation stuff internally including if the task finishes before the first check for being done
12:02:08 <TrueBrain> jfs-: I actually needed a promise-variant of JGR's work for my PR, but I was too lazy for it ๐Ÿ˜„
12:02:32 <TrueBrain> (so I wrote an ugly function that waits till the queue is empty ... HACK! :D)
12:03:29 <TrueBrain> bit surprised you didn't need something like that btw JGR
12:04:10 <TrueBrain> I would expect you want to sync up with the viewport drawing too, to ensure everyone is done?
12:04:21 <JGR> The viewport stuff has two levels of jobs, the first level jobs can enqueue second level jobs, so I needed something a bit more than just whether the queue is empty
12:04:53 <jfs->
12:05:02 <jfs-> there's my threadpool code
12:05:09 <TrueBrain> owh, you wrote it on top of the pool, haha, that works too JGR
12:05:11 <jfs-> buried in the wrong file
12:07:00 <JGR> TrueBrain: Looking at it, it's because there's the third part of the drawing to do in the main thread, so the waiting it tied in with that
12:09:07 <TrueBrain> but honestly, instead of writing our own, we might be better off using an existing library that is rather popular, like
12:09:28 <TrueBrain> or, ofc, boost::thread_pool
12:09:30 * TrueBrain runs
12:13:46 <jfs->
12:13:46 <jfs->
12:13:46 <jfs-> spot the differences
12:14:31 <TrueBrain> Is it highlighted in yellow?
12:15:03 <TrueBrain> this must have been the easiest "spot the difference" in existence ๐Ÿ˜„ Hihi, sorry ๐Ÿ™‚
12:15:25 <jfs-> "Install type" and "Install Type" have different capitalisation for some reason
12:19:38 *** TallTyler has joined #openttd
12:19:38 <TallTyler> But not Game Directory. And I would have expected American to overcapitlize everything
12:21:36 *** ag has joined #openttd
12:21:36 <ag> "American"
12:21:52 <ag> Is that a different language altogether?
12:21:57 <ag> I dunno
12:24:01 <TrueBrain> ugh, I need to learn OpenTTD's coding style again .. this will be "fun" ๐Ÿ˜›
12:25:09 <dP> is there a good way in git to find at what commit line was removed?
12:25:15 <dP> preferably on github
12:27:00 <nielsm> hmm I don't know if there is anything like "reverse git blame"
12:28:19 <dP> `git log -S <string> path/to/file` apparently works fine
12:30:24 <dP> chatgpt suggests `git blame -L <line number>,<line number> <file name>`
12:30:38 <dP> google wins :p
12:34:55 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #10584: Port dirty rect handling from JGRPP
12:35:26 <DorpsGek> [OpenTTD/OpenTTD] ldpl commented on pull request #10584: Port dirty rect handling from JGRPP
12:36:34 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #10584: Port dirty rect handling from JGRPP
12:37:47 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:37:59 *** WormnestAndroid has joined #openttd
12:42:56 <TrueBrain> bah, it is scary how quickly you unlearn C++ templates ๐Ÿ˜›
12:43:59 <JGR> Templates are one of those things which are best used in moderation
12:45:08 <TrueBrain> I succeeded in that part ๐Ÿ˜›
12:45:10 <TrueBrain> as I forgot ๐Ÿ˜ฆ
12:47:55 *** NGC3982 has joined #openttd
13:10:57 *** sla_ro|master has joined #openttd
13:26:13 <petern> Does `std::vector<int *> list(100)` init each pointer (to nullptr)?
13:29:15 <Rubidium_> potentially if that's the default for pointers. However, why not `std::vector<int *> list(100, nullptr)`? That would make it explicit
13:34:09 <jfs-> std::vector always contains initialized elements
13:34:33 <jfs-> and for pointers the default initialization is nullptr
13:39:44 <dP> "always" is a bit of an overstatement in c++ ๐Ÿ˜†
13:42:12 <jfs-> I'm pretty sure you can't make a vector of objects that can't be default initialized? or at least can't construct it with a size or use resize() if the object doesn't have a default constructor
13:44:03 <dP> not normal way, but corrupting memory is easy af in c++
13:44:05 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #10584: Port dirty rect handling from JGRPP
13:48:37 <DorpsGek> [OpenTTD/OpenTTD] PeterN commented on pull request #10602: Change #10028: Improved Overtaking Routines
13:49:38 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10602: Change #10028: Improved Overtaking Routines
13:50:23 <DorpsGek> [OpenTTD/OpenTTD] Caber-nl opened issue #10617: [Crash]:
13:51:45 <glx[d]> We really should release 13.1
13:51:52 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on issue #10617: [Crash]: When clicking on local authority button
13:52:10 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on issue #10617: [Crash]: When clicking on local authority button
13:53:49 <LordAro> yes
14:00:56 <TrueBrain> TallTyler: I am thinking along those lines for all the timer bla; would make solving the autosave / ai-start-date a lot easier ๐Ÿ™‚
14:01:15 <TrueBrain> I have some compilable code already that seems to work fine; just need to think if I actually like this ๐Ÿ˜›
14:01:32 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10602: Change #10028: Improved Overtaking Routines
14:02:53 <DorpsGek> [OpenTTD/OpenTTD] Caber-nl commented on issue #10617: [Crash]: When clicking on local authority button
14:03:17 <jfs-> TrueBrain: do consider that those will basically be subscriptions to an event, and you need a way to unsubscribe those events too, e.g. in case of an event owned by a GUI window
14:03:58 <TrueBrain> yeah; basically I just wanted to use RAII for that ๐Ÿ™‚
14:04:39 <TrueBrain> so `CreateIntervalTimer` will be more like `auto timer = IntervalTimer(..)` ๐Ÿ™‚
14:04:50 <TallTyler> Fancy, looks like it could streamline things a lot
14:05:09 <TrueBrain> mostly I am now puzzling with an easy way to change TimerGameEconomy with another implementation, runtime
14:05:25 <TrueBrain> so you can switch between calendar-based and realtime-based, without much actual change
14:05:43 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on issue #10617: [Crash]: When clicking on local authority button
14:05:57 <TrueBrain> but yeah, C++ singletons ftw ๐Ÿ˜›
14:06:32 <TrueBrain> still not sure I actually like it ... `TimerManager<TimerGameCalendar>` is the singleton atm .. which is a bit odd
14:06:41 <TrueBrain> rest of OpenTTD makes `_timer_game_calendar` the singleton
14:06:59 <TrueBrain> but that means you need a lookup table from "type" to one of those ..
14:07:02 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on issue #10617: [Crash]: When clicking on local authority button
14:07:05 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler closed issue #10617: [Crash]: When clicking on local authority button
14:07:05 <TrueBrain> doing it by type is far easier ๐Ÿ˜„
14:07:23 <TrueBrain> (basically, abusing the compiler to create the lookup table
14:07:39 <TrueBrain> meh, let's first play a game, to see later today if I still like it or not ๐Ÿ™‚
14:09:55 <dP> game timers don't really need to resubscribe so that interface is a bit pointless
14:10:15 <dP> in fact they can't resubscribe as that would require storing them in the save
14:10:24 <dP> so it's actually misleading
14:18:10 <dP> hm, it's similar to how citymania stuff works though...
14:20:29 <dP> <> ๐Ÿ˜…
14:22:13 <nielsm> at least it's beneficial for understanding to have time and date related code subscribed and placed near the thing it concerns, and avoid "magical" overridden methods that get called as event handlers from a superclass
14:22:36 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler approved pull request #10104: Update: [Dev] Improve .editorconfig with C++ formatting rules based on OpenTTD code style
14:22:55 <nielsm> the NUI events etc are always really confusing for me, I need to dig through multiple header files and sometimes implementations too to find the appropriate method to override to do something
14:23:24 <dP> what's nui?
14:23:46 <dP> you mean gui?
14:23:54 <nielsm> at least I think that's what it's called, "new UI" the widgets and windows framework
14:24:21 <dP> ah, yeah, NewEverything xD
14:24:23 <petern> I've never seen that before ๐Ÿ™‚
14:24:30 <dP> I just thought you meant some external library first xD
14:26:06 <dP> though I don't see how events are much different, it's still an indirect call which is much harder to follow
14:26:19 <dP> especially order of execution for different handlers
14:26:39 <dP> in citymania I have slots to somewhat order handlers
14:27:30 <nielsm> well, Visual Studio (as far as I know) doesn't have any tools to help me find methods I can override, but it does have toosl to help me find methods I can call (to set an event handler)
14:28:46 <JGR> They're all part of struct Window, surely?
14:30:17 <dP> and marked as `virtual` ;)
14:30:29 <dP> but, yeah, events are a bit more explicit in that
14:30:34 <dP> but less explicit in runtime
14:30:52 <dP> as you never know who subscribed to what until prying it open with debugger
14:31:51 <JGR> They're are easy enough to grep for, same as anything else
14:32:17 <dP> you can grep for subscription call but how do you know whether it was executed?
14:32:56 <JGR> By looking at the function which calls the event handlers
14:34:49 <dP> and what does it tell you? <>
14:35:16 <dP> if overall stucture is flat and, say, all events are registered at initialization, and there are no conditional subscriptions, yes, you can kinda tell what's going to be executed
14:35:17 <JGR> That you should grep for "emit" instead ๐Ÿ˜›
14:35:49 <dP> emit tells you when it's called, not what it's calling
14:43:01 <dP> I switched from virtual fuctions to events in citymania because there was just too much variability
14:44:15 <dP> for example CB controller can define ClaimedTownPopulationChanged event, throw it whenever, then declare a goal type that listens to that event and updates the goal value
14:44:36 <dP> and suddenly there is a population goal that other controllers have no clue about
14:45:33 <dP> vanilla doesn't really have that
14:45:43 <dP> only in gamescripts but that's a whole different story
14:55:13 <dP> oh, there is also an important part that citymania doesn't change game state in any event handlers after initialisation
14:55:32 <dP> though I relaxed that condition a bit lately
14:57:23 *** michi_cc[d] has joined #openttd
14:57:23 <michi_cc[d]> glx[d]: Give me some PR's to approve, I like pressing buttons ๐Ÿ™‚
14:57:44 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler opened pull request #10618: Fix eabb9db: Allow overbuilding station and waypoint tiles
14:58:22 <TallTyler> andythenorth: Care to chime in on ? We discussed it last week sometime and it was annoying me today, so I want to fix it. ๐Ÿ™‚
14:59:35 <JGR> I'm not Andy, but I'd argue that the whole premise of 9852 is incorrect, because there is no reason why overbuilding should be free
15:00:05 <JGR> From that it follows that there's no reason for the already built error behaviour either
15:00:49 <TallTyler> Discussion of the premise is in #9810 for anyone following along:
15:01:29 <TallTyler> I could have sworn there was more discussion about not punishing eyecandy builders ๐Ÿค”
15:01:30 <dP> I can argue that overbuilding is part of construction, not modification so shouldn't be taxed
15:01:44 <dP> it's very easy to click wrong direction in openttd horrendous ui
15:02:27 <dP> and, yeah, eyecandy stuff
15:03:46 <michi_cc[d]> TrueBrain: `BS::thread_pool` looks nice. And it being a single header, it'd be easy to integrate without worrying about external availabilty.
15:03:47 <dP> also generally better gameplay, doesn't punish for build mistakes when already out of money
15:04:49 <JGR> Measure twice, cut once? ๐Ÿ˜›
15:05:17 <dP> use cmclient, wrong direction is non-issue with preview and autorotation :p
15:06:07 <JGR> That said I can see that trying to replace a stop or station tile with an identical one could be free, but making replacing a station tile with a completely different one, even if in the same direction, free, seems weird to me
15:06:49 <TrueBrain> Realism vs fun gameplay, I guess?
15:07:08 <TallTyler> In any case, I don't feel like reverting 9852 is really the right move here
15:07:37 <TrueBrain> Well, fun .. not the right word .. realism vs stylism
15:07:45 <TrueBrain> More what I meant ๐Ÿ˜„
15:07:57 <TallTyler> OpenTTD is supposed to be work, not fun ๐Ÿ˜›
15:08:27 <TallTyler> Realism isn't fun, and OpenTTD should be a simulation of that, not a "game" ๐Ÿ˜›
15:09:15 <TrueBrain> No, I mean more that the discussion seems to be about playstyles .. which are really hard to resolve ๐Ÿ˜„
15:09:51 <TallTyler> Yes, I saw your point, was just being difficult ๐Ÿ™‚
15:09:57 <TallTyler> "Fun" is subjective
15:10:07 <TrueBrain> Weird, discord doesn't notify me whe people reply to a message of mine .. annoying ๐Ÿ˜„
15:10:12 <dP> ultra-realism mode, you can only use money in the game after you donate it to openttd :P
15:10:30 <JGR> Also, NewGRF roadstops have build and clear cost multiplier properties
15:11:16 <JGR> So you could evade those costs with this, not that this has any gameplay benefit at all
15:11:27 <michi_cc[d]> TrueBrain: Does it notify now? ๐Ÿ™‚ (There's a ping toggle).
15:11:46 <TrueBrain> Ah, yes, lol
15:12:05 <TrueBrain> Never noticed that toggle, funny
15:12:47 <petern> Great, this map in TNT is bugged and cannot be finished.
15:13:28 <dP> JGR: well, in theory overbuild can work as undo build, build new
15:14:10 <dP> though I guess that would be avoiding clear costs xD
15:14:35 <dP> silly newgrf things :p
15:16:00 <dP> if clear cost is the same undo->build new, if not clear->build
15:16:43 <dP> Players. Must. Suffer.
15:17:07 <JGR> dP: Some people are into such things
15:18:43 <LordAro> was about to start trying to benchmark the dirty rect stuff
15:18:56 <LordAro> immediate segfault on loading the ottdc progame i had lying around
15:19:03 <LordAro> that's with master, to be clear
15:19:22 <JGR> But for me at least there's a bit of an element of suspending disbelief. the game is trying to model the idea of constructing real things in a real world
15:19:35 <JGR> Even if the physics and such are a bit wibbly wobbly
15:19:53 <dP> JGR: bdsmpp when? :p
15:21:01 <dP> LordAro: you mean my pr? works fine for me, haven't tried on master though
15:21:08 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:21:20 <dP> also, I updated it recently
15:21:37 *** WormnestAndroid has joined #openttd
15:25:38 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:25:42 *** WormnestAndroid has joined #openttd
15:29:43 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:30:02 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 updated pull request #10570: Fix: inconsistent partial Z calculations for different slopes
15:32:13 *** WormnestAndroid has joined #openttd
15:42:16 <Rubidium_> michi_cc[d]: ^ you can press some buttons on that PR ;)
15:45:43 <TrueBrain> Does that contribute to 13.1? :p
15:53:40 <DorpsGek> [OpenTTD/OpenTTD] michicc commented on pull request #10570: Fix: inconsistent partial Z calculations for different slopes
15:54:12 <michi_cc[d]> Sorry, wrote comments instead ๐Ÿ™‚
16:00:12 <TallTyler> I think it's pretty crucial to fix the station overbuilding issue before 13.1, so either #10618 or reverting the original PR
16:03:22 <TallTyler> Also I've got buttons to press on #10519, which has been done for about a month ๐Ÿ˜›
16:07:00 *** Wormnest has joined #openttd
16:15:07 <andythenorth> Station overbuilding thing is lol ๐Ÿ™‚
16:15:44 <andythenorth> Stuff like that will just cause flail and erode cover / motivation to break more useful things ๐Ÿ™‚
16:18:25 <TallTyler> Like what?
16:21:36 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 commented on pull request #10570: Fix: inconsistent partial Z calculations for different slopes
16:34:29 *** Smedles has quit IRC (Quit: - Chat comfortably. Anywhere.)
16:34:37 *** Smedles has joined #openttd
16:41:02 *** sla_ro|master has quit IRC ()
16:41:13 <DorpsGek> [OpenTTD/OpenTTD] michicc approved pull request #10570: Fix: inconsistent partial Z calculations for different slopes
16:57:11 <LordAro> dP: ProZoneGame_2013 crashes in the loading of linkgraphs on master
16:57:25 <dP> can you post a save somewhere?
16:58:00 <petern> Does it load in 13.0?
16:58:17 <LordAro>
16:58:29 <petern> An openttdcoop link that works? ๐Ÿ˜ฎ
16:58:36 <LordAro> i was just as surprised as you
17:00:27 <dP> hm, interesting, it loads on cmclient but crashes in pr
17:00:32 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10570: Fix: inconsistent partial Z calculations for different slopes
17:00:33 <dP> does master without pr load it?
17:00:34 <petern> Hmm, missing origengs.grf
17:00:35 <Rubidium_> thanks michi_cc
17:00:36 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #10514: [Bug]: Inconsistent (partial) Z
17:01:57 <dP> yeah, it crashes master too so not my fault :p
17:02:08 <LordAro> yeah, didn't mean to accuse you :p
17:02:21 <LordAro> just typical of me...
17:03:01 <dP> some change between 13.0 and master by the looks of it
17:03:04 <petern> Hmm, dinner time perhaps.
17:04:34 <petern> LordAro, "problem" with riding the recumbent is Strava thinks there's hardly any effort... heart rate is lower, speed is lower, but leg still get a workout...
17:04:56 <LordAro> dP: probably #10314
17:04:59 <LordAro> cc michi_cc[d] :p
17:05:10 <dP> ๐Ÿคทโ€โ™‚๏ธ
17:05:25 <LordAro> petern: oh no
17:05:37 <DorpsGek> [OpenTTD/OpenTTD] FLHerne commented on pull request #10618: Fix eabb9db: Allow overbuilding station and waypoint tiles
17:07:02 <dP> LordAro, also, I mainly merged those rect changes to reduce visual glitches not even performance
17:07:26 <dP> it's not as noticeable in vanilla but it still is, for example in transport mode of minimap
17:08:45 <dP> and while rect handling doesn't really fix them it is a nice workaround as it just avoids redrawing minimap in small regions for every changed tile underneath
17:08:52 <JGR> When I was making those changes, performance was my primary motivation
17:10:02 <petern> _linkgraph->nodes[...].edges is empty for each one, but we try to load 0 to max_size. Hmm.
17:10:10 <LordAro> indeed
17:10:28 <LordAro> i'm wondering if max_size is garbage
17:10:29 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10596: Change: Increase max cargo age and let min cargo payment approach zero.
17:11:06 <LordAro> (so am running it through valgrind to find out. it is slow)
17:11:54 <LordAro> it is not garbage memory
17:12:08 <petern> max_size is _linkgraph->nodes.size()
17:13:09 <petern> I think it's meant to load it into edges, not nodes[].edges.
17:13:24 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #10596: Change: Increase max cargo age and let min cargo payment approach zero.
17:14:17 <petern> Not sure though. A little further down edges[to] is pushed onto the real edges.
17:15:37 <petern> It doesn't crash after making that change. I don't know if it's correct though ๐Ÿ™‚
17:16:18 <petern> 60ms train ticks, I need a faster PC.
17:16:30 <petern> i7-8700k is old hat now...
17:17:43 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler approved pull request #10596: Change: Increase max cargo age and let min cargo payment approach zero.
17:18:28 <DorpsGek> [OpenTTD/OpenTTD] LordAro opened issue #10619: [Crash]: In LinkGraph edges saveload when loading savegame
17:21:19 <DorpsGek> [OpenTTD/OpenTTD] PeterN opened pull request #10620: Fix #10619: Crash loading linkgraph for older savegames.
17:21:22 <DorpsGek> [OpenTTD/OpenTTD] TrevorShelton updated pull request #10602: Change #10028: Improved Overtaking Routines
17:22:16 <TrueBrain> 3 minutes between bug report and fix .. I am afraid this sets expectations ๐Ÿ˜›
17:22:24 <LordAro> :D
17:22:49 <TallTyler> dP: If you change #9637 to follow FLHerneโ€™s suggestion (you mention adding a setting to cmclient), Iโ€™ll approve that one too. Your poll was inconclusive but this isnโ€™t a democracy. ๐Ÿ˜„
17:23:35 <dP> hm, let me see ๐Ÿ˜†
17:24:59 *** tokai has joined #openttd
17:24:59 *** ChanServ sets mode: +v tokai
17:26:23 <DorpsGek> [OpenTTD/OpenTTD] TrevorShelton commented on pull request #10602: Change #10028: Improved Overtaking Routines
17:27:22 <LordAro> ooh, another crash
17:27:38 <TrueBrain> STOP IT
17:27:56 <LordAro> this one's in YAPF
17:27:58 <petern> Can we do this? <>
17:28:01 <LordAro> which is interesting.
17:29:23 <JGR> You can crash YAPF by changing the penalty settings to stupid values, for a while some players cargo-culted doing this
17:30:06 <LordAro> openttd: /home/lordaro/dev/OTTD/openttd/src/pathfinder/yapf/yapf_destrail.hpp:213: bool CYapfDestinationTileOrStationRailT<Types>::PfCalcEstimate(Node&) [with Types = CYapfRail_TypesT<CYapfRail1, CFollowTrackT<TRANSPORT_BEGIN, Train, true>, CNodeList_HashTableT<CYapfRailNodeT<CYapfNodeKeyTrackDir>, 8, 10>, CYapfDestinationTileOrStationRailT, CYapfFollowRailT>; Node =
17:30:11 <LordAro> CYapfRailNodeT<CYapfNodeKeyTrackDir>]: Assertion `n.m_estimate >= n.m_parent->m_estimate' failed.
17:30:29 <LordAro> i'm not entirely sure where i got this save, it's named "bug7670.sav"
17:30:37 <LordAro> which would suggest something to do with #7670
17:32:03 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
17:33:16 <LordAro> looks like it's the one from road vehicle in the main body
17:33:35 <JGR> <>
17:33:55 <JGR> I thought it seemed familiar...
17:34:10 <LordAro> ha
17:34:15 <dP> TallTyler: can we at least agree to keep the network command parameter so I can do ctrl-thing in cmclient without much hassle?
17:34:16 <LordAro> still, feels like it shouldn't crash...
17:34:20 <dP> can also help mitigate the damage
17:34:28 *** BobisNew has joined #openttd
17:34:29 <TrueBrain> LordAro: easy: remove PF settings!
17:34:43 <LordAro> ha
17:34:54 <JGR> LordAro: The issue is that it can make some penalties negative, and cause signed integer overflow issues
17:35:01 <LordAro> ah
17:35:24 <petern> Removing PF settings is not a bad idea. Just ignore what the savegame has.
17:35:58 <petern> There are some that are probably useful in some cases though./
17:37:40 <TrueBrain> we have talked about this so many times, yet we never actually do it ๐Ÿ˜„
17:38:22 <LordAro> i think i can remove all the YAPF/NPF specific settings without issue
17:38:49 <JGR> rail_look_ahead_signal_p0 to rail_look_ahead_signal_p2 are the most problematic ones
17:39:20 <JGR> These describe a quadratic curve which no user is ever going to set correctly
17:39:21 <petern> Could reduce the max bounds to something sensibler?
17:39:51 <petern> def = 500
17:39:51 <petern> min = -1000000
17:39:51 <petern> max = 1000000
17:39:54 <petern> ๐Ÿ˜ฎ
17:40:07 <JGR> If the curve goes below 0, you have a problem, which is fixable by clamping, but better off just to not have it as a setting
17:42:35 <JGR> <>
17:42:45 <petern> there's that twoway_eol setting that people swear by...
17:43:01 <dP> yeah, some settings are occasionally useful
17:43:02 <LordAro> that's not specific to a particular pathfinder though
17:43:02 <petern> But I guess they're also "path signals are bad" people
17:43:12 <dP> twoway eol, backoff interval, max nodes...
17:43:13 <petern> It's listed under yapf.
17:43:25 <LordAro> oh, was it?
17:43:33 <dP> Imo better to just limit the range to values that don't crash
17:44:06 <LordAro> oh, i was looking at pf.wait_twoway_signal
17:44:09 <LordAro> which, yeah, something else
17:45:38 <TallTyler> dP: Iโ€™m not opposed to a setting in OpenTTD to enable Ctrl-drag for area fill, maybe only available in console/config like 2way_eol
17:45:46 <dP> a bit of an old scan but shows that ppl still use pf settings occasionally for whatever reason <>
17:46:07 <TrueBrain> TallTyler: please consider our technical depth ๐Ÿ™‚
17:47:03 <TallTyler> I wonder if thereโ€™s a way to gauge how much pushback weโ€™d get from removing it entirely besides listening to the squeakiest wheels
17:47:23 <TrueBrain> add telemetry you say? ๐Ÿ˜„
17:47:39 <TrueBrain> maybe send out a poll on Discord?
17:47:53 <glx[d]> 2way_eol is some kind of hack because there's no other option to achieve the effect
17:48:27 <glx[d]> a specific signal type could be better
17:48:44 <JGR> 2way_eol is not really a problem because it's well defined what it does and easy to test
17:48:58 <TrueBrain> glx[d]: instead of a modifier, a toggle in the GUI people can hit? ๐Ÿ™‚
17:49:12 <JGR> Many of the other settings are totally arcane and non-default values never get any testing
17:49:30 <dP> psst, twoway_eol is already on and noone noticed ๐Ÿ˜‰
17:50:59 <petern> So just remove the setting.
17:51:49 <glx[d]> anyway twoway_eol use case is for very specific way of signaling
17:52:29 <glx[d]> if using pbs only it doesn't matter
17:53:19 <TrueBrain> wasn't that one of the settings that got left in to make sure older savegames still function correctly?
17:53:36 <TrueBrain> I know we have a few of those settings .. hidden far far far FAR away ๐Ÿ˜›
17:54:25 <glx[d]> they are hidden in the console
17:56:37 <glx[d]> originally pf penalties settings were just for debug/dev, because it's easier to test different values without requiring to rebuild
17:56:51 <petern> To make sure older savegames still break correctly, you mean? ๐Ÿ˜„
17:57:21 <glx[d]> but some people found them and started to abuse
17:58:30 <TrueBrain> petern: yes!
17:59:12 <dP> some settings are kind of useful for certain playstyles
17:59:26 <dP> 10k node train track may be a bit unconventional but why not xDD
18:00:15 *** BobisNew has quit IRC (Quit: Page closed)
18:00:53 <dP> also depot search distance, some people like to build off-line depots with long entries for long trains to slow down
18:01:39 <dP> signal lookahead of 10 is also kind of small when spamming signals every 2 tiles
18:03:26 <JGR> The signal lookahead distance is also the uncached distance
18:04:32 <JGR> Increasing it reduces pathfinder performance, for diminishing returns
18:05:19 <JGR> Signals also still work when at a more sensible distance apart ๐Ÿ˜›
18:05:42 <dP> but train density :P
18:07:38 <LordAro> one might expect that turning the pathfinder settings into compiletime constants may improve pathfinder performance as well
18:07:42 <LordAro> slightly.
18:07:59 <TrueBrain> let that be the excuse to remove them all! ๐Ÿ˜›
18:08:16 <TrueBrain> "but we wanted your 4000 train savegame to run just ever so slightly faster!!!"
18:15:23 <dP> TallTyler: so should I add the setting or not? I'm fine with having it in cmclient but can do for vanilla
18:16:54 <dP> btw, had an idea recently to remove even drag, just have it click to fill xD
18:16:58 <dP> only problem is direction
18:17:16 <dP> but may be fine with building preview in cmclient, need to try
18:19:37 <dP> or have one-way track like one-way road...
18:22:17 <DorpsGek> [OpenTTD/OpenTTD] michicc approved pull request #10620: Fix #10619: Crash loading linkgraph for older savegames.
18:29:00 <DorpsGek> [OpenTTD/OpenTTD] PeterN merged pull request #10620: Fix #10619: Crash loading linkgraph for older savegames.
18:29:03 <DorpsGek> [OpenTTD/OpenTTD] PeterN closed issue #10619: [Crash]: In LinkGraph edges saveload when loading savegame
18:29:27 <TallTyler> dP: That should be left to someone above my pay grade ๐Ÿ™‚
18:29:47 <TallTyler> The imposter syndrome is strong this weekend ๐Ÿซ 
18:30:59 <dP> oh, I also missed #10538 comments
18:31:14 <dP> any other opinions on auto vs explicit type?
18:38:53 <TrueBrain> TallTyler: still not completely sure, but this would be the boilerplate to work from. It is functional .. I could replace the OnNewDay function with a timer instead.
18:39:30 <TrueBrain> made some terrible mistakes in coding style, but who is still using tabs in this day and age ๐Ÿ˜›
18:39:37 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master
18:39:38 <DorpsGek> - Update: Translations from eints (by translators)
18:39:42 <TrueBrain> michi_cc[d]: if you are a bit bored, could use an opinion on the timer approach in the above URL ๐Ÿ™‚
18:40:11 <TrueBrain> especially on the singleton usage ๐Ÿ˜›
18:48:05 <michi_cc[d]> Eh, you'll find people that will say singletons are BAD, but at the same time advocate for using DI and IoC containers, which are all just globals as well. There are a lot of globals in OTTD anyway, so it fits right in.
18:50:39 <nielsm> singletons are a different syntax for global variables
18:51:50 <nielsm> a slight difference is that if you access them via a function call rather than direct you can do delayed construction of the object
18:54:25 <TrueBrain> well, okay, I guess I was more curious what we think about this autoregister stuff to make RAII work ๐Ÿ˜›
18:57:25 <nielsm> it looks like your editor is set up to indent with 4 spaces rather than tabs
18:57:33 <TrueBrain> my editor is setup sane, yes
18:57:34 <TrueBrain> ๐Ÿ˜›
19:00:47 *** Speedy` has quit IRC (Ping timeout: 480 seconds)
19:03:17 *** WormnestAndroid has quit IRC (Remote host closed the connection)
19:03:17 *** WormnestAndroid has joined #openttd
19:07:23 *** Kuhnovic has joined #openttd
19:07:23 <Kuhnovic> One of the main drawbacks of a singleton is that it's very difficult to replace the real singleton by a mock if you want to do testing. But you only face that issue if you're actually writing tests ๐Ÿ˜›
19:07:52 <DorpsGek> [OpenTTD/OpenTTD] PotatoMasherGUI commented on issue #5283: Scripts and pause mode
19:09:32 <jfs-> for bikeshedding, I think I'd prefer abstracting the "registered event handler that needs to be unregistered" away a bit from the timer types, something like
19:09:32 <jfs-> ```C++
19:09:32 <jfs-> struct EventHandler {
19:09:32 <jfs-> virtual ~RegisteredEventHandler() = 0;
19:09:32 <jfs-> }
19:09:33 <jfs-> using RegisteredEventHandler = std::unique_ptr<EventHandler>;
19:09:33 <jfs-> template <typename TTimerType>
19:09:35 <jfs-> class IntervalTimer : public EventHandler {
19:09:35 <jfs-> // ...
19:09:37 <jfs-> public:
19:09:37 <jfs-> ~IntervalTimer() override
19:09:39 <jfs-> {
19:09:39 <jfs-> TimerManager<TTimerType>::UnregisterTimer(*this);
19:09:41 <jfs-> }
19:09:41 <jfs-> // ...
19:09:43 <jfs-> }
19:12:11 <TrueBrain> isn't that only useful if it is used more than once?
19:12:25 <Kuhnovic> Why not just unregister the timer in the baseclass? Then you can't forget it
19:13:59 <nielsm> also, TimerManager::RegisterTimer should probably be marked with the [[nodiscard]] attribute or whatever it's called, to make the compiler yell at you if you forget to store the registration
19:14:44 <nielsm> uh... something different but to that effect, is what I meant
19:22:11 <TrueBrain> nielsm: smart!
19:23:37 <dP> reminds me of stuff like <> ๐Ÿ˜œ
19:25:07 <JGR> OpenTTD isn't anywhere near that level, thankfully
19:26:22 <dP> it's getting there ๐Ÿ˜†
19:26:26 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:32:03 *** sla_ro|master has joined #openttd
20:09:51 <TrueBrain> `warning: ignoring return value of โ€˜IntervalTimer<TTimerType>...`
20:14:33 <LordAro> sounds like you're having fun
20:15:29 <TrueBrain> the only way to survive the day, not?
20:18:30 <LordAro> something like that
20:19:58 <Kuhnovic> Now enable warnings-as-errors and you're all set! You might first have to fix a couple (hundred) other warnings though ๐Ÿ˜›
20:20:26 <TrueBrain> how to tell you never compiled OpenTTD without telling you haven't compiled it ๐Ÿ˜„
20:21:11 <LordAro> last time i checked we don't have any warnings in any of the tested compilers...
20:21:19 <TrueBrain> like I said ... ๐Ÿ˜‰
20:21:39 <TrueBrain> in fact, the CI refuses PRs with any warnings on any of the platforms ๐Ÿ™‚
20:22:03 <LordAro> does it?
20:22:12 <LordAro> i thought we never got around to doing that
20:22:14 <TrueBrain> any form of annotation is refused ๐Ÿ˜›
20:22:43 <Kuhnovic>
20:22:43 <Kuhnovic> Ah! It's intellisense that's coughing up these warning
20:23:23 <Kuhnovic> Indeed there are no compiler-generated warnings. I take back what I said ๐Ÿ˜‰
20:23:39 <Kuhnovic> Just don't occuse me of never compiling ๐Ÿ˜‰
20:23:49 <TrueBrain> MWHAHAHAHA
20:23:53 <TrueBrain> can't promise that ๐Ÿ˜›
20:23:54 <LordAro> might be worth fixing some of those :p
20:24:04 <TrueBrain> some of those are horrible ... CodeQL even mentions a few ..
20:24:12 <TrueBrain> we have 10KiB+ objects on our stack
20:24:59 <LordAro> -Wl,--stack,0x100000000
20:25:00 <LordAro> fixed.
20:25:09 <TrueBrain> "fixed"
20:25:12 <TrueBrain> works on my machine!
20:25:20 <LordAro> (we genuinely do that at work)
20:25:23 <LordAro> (i don't like it)
20:25:27 <TrueBrain> I ... wow
20:25:39 <LordAro> tbf, Ada makes it difficult to use strings not on the stack
20:26:00 <Kuhnovic> TrueBrain: Yeah the YAPF instances are created on the stack, and they are quite big...
20:26:53 <TrueBrain> right, now to find all the places we can use timers over what-ever-custom-code-was-in-there
20:26:54 <TrueBrain> fun
20:31:30 <DorpsGek> [OpenTTD/OpenTTD] PotatoMasherGUI opened pull request #10621: Update .editorconfig
20:31:59 <TrueBrain> that is a really weird PR
20:32:22 <TrueBrain> we don't have a `source` folder, nor do we indent with spaces ..
20:33:09 <LordAro> that feels very ChatGPT
20:33:31 <LordAro> as does their comment on #5283
20:34:58 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10621: Update .editorconfig
20:35:01 <DorpsGek> [OpenTTD/OpenTTD] LordAro closed pull request #10621: Update .editorconfig
20:35:06 <TrueBrain> I was writing a reply ๐Ÿ˜ฆ
20:35:11 <LordAro> too slow
20:35:13 <LordAro> <3
20:35:14 <TrueBrain> you are much more rude ๐Ÿ˜›
20:35:53 <LordAro> better than their other PR
20:36:12 <DorpsGek> [OpenTTD/OpenTTD] TrueBrain commented on pull request #10621: Update .editorconfig
20:36:14 <TrueBrain> there, I sitll post my nice reply
20:37:26 <LordAro> other than their reply in the above, everything written looks very ChatGPT
20:37:55 <TrueBrain> not everyone knows English that well
20:37:57 <TrueBrain> so I give them that
20:38:02 <TrueBrain> but not testing your PR .. that is just weird
20:38:22 <LordAro> they know it well enough to use slang like "MB" in their response
20:38:31 <TrueBrain> manabreak?
20:38:53 <LordAro> "my bad", i'm assuming
20:38:59 <TrueBrain> ah, that makes more sense ๐Ÿ™‚
20:39:46 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #10104: Update: [Dev] Improve .editorconfig with C++ formatting rules based on OpenTTD code style
20:42:12 <TrueBrain> Rubidium is like: QUICK, GET THE OTHER ONE IN
20:42:13 <Kuhnovic> Is anyone aware of a NewGRF that contains super fast ships? I'm torture-testing my ship pathfinder, the faster the ships go the harder it's going to be on the pathfinder
20:42:13 <TrueBrain> I understand ๐Ÿ™‚
20:46:07 <TallTyler> SHARK has some hydrofoils and hovercraft that go 100 mph
20:47:48 <TallTyler> LordAro: You shut down the chatbot so hard that it deleted its account, that's funny ๐Ÿ˜†
20:48:40 <TrueBrain> wait, what? LOL
20:49:07 <TrueBrain> that is fucking hilarious ๐Ÿ˜„
20:49:14 <TrueBrain> or not .. depends
20:49:19 <TrueBrain> but LordAro made someone ragequit GitHub
20:49:32 <LordAro> oh nice
20:49:54 <TrueBrain> someone was like: today is going to be the day that I am going to help Open Source
20:50:00 <TrueBrain> and here we are ..... destroying those dreams
20:50:04 <LordAro> oh no
20:50:09 <TrueBrain> on the other hand: at least test your work? ๐Ÿ˜›
20:50:28 <petern> Weird.
20:50:32 <TallTyler> Truly the least you can do
20:51:48 <LordAro> seriously though, is super ChatGPT
20:52:05 <TrueBrain> it really is ๐Ÿ™‚
20:52:18 <TrueBrain> didn't even see that comment
20:52:47 <TallTyler> The first solution is such a terrible programming idea
20:52:55 <TrueBrain> in fact, so much so, I just pressed `Hide`
20:53:00 <TallTyler> "Duplicate your code, ChatGPT says it's a good idea"
20:53:28 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
20:53:33 <LordAro> hehe
20:53:35 <TrueBrain> the PR itself is also very ChatGPT-like .. so maybe someone was creating a bot to fix all Open Source issues ๐Ÿ™‚
20:54:32 <TrueBrain> hmm, darn it, my timer-idea has one minor issue .. there have to be two "real-time" timers
20:54:36 <TrueBrain> one for windows, one for the game
20:54:36 <LordAro> i played around with bing bot the other day, it was able to recreate a couple of scripts i'd written a couple of weeks ago with relative ease
20:54:39 <TrueBrain> as they run in different threads
20:54:54 <TallTyler> If the AI of the future is good at fixing bugs, I doubt you would hear much complaining ๐Ÿ™‚
20:56:54 <TrueBrain> hmm, naming these timers is the biggest trick ๐Ÿ˜„
20:57:31 <LordAro> realtime_timer1, realtime_timer2
20:57:46 <TrueBrain> exactly
20:58:37 <Rubidium_> what AI of the future? Or do you mean the thing you ask "X" but you actually mean "write me something that sounds like an answer for X"
20:59:46 <LordAro> i would estimate ChatGPT to be able to replace ~10% of my colleagues
21:00:01 <LordAro> with a similar accuracy rate
21:00:19 <TrueBrain> even holds true for OpenTTD PRs ๐Ÿ˜›
21:00:27 <LordAro> :D
21:01:14 <TallTyler> I could be replaced. Main reason I've decided against going for junior developer jobs. The chatbots will probably get better at approximately my learning speed ๐Ÿ™ƒ
21:01:42 <TrueBrain> given by the speed you have been picking up work in OpenTTD, I think you underestimate yourself ๐Ÿ˜›
21:01:50 <LordAro> ^
21:04:53 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
21:05:23 *** WormnestAndroid has joined #openttd
21:05:45 <TrueBrain> when will C++ get decorators?
21:05:47 <TrueBrain> I need them ๐Ÿ˜›
21:06:58 <Rubidium_> aren't type traits just C++'s way of decorating?
21:07:38 <Rubidium_> or at least the way they're implemented
21:08:47 <TrueBrain> I learn fun things ... "white border" on windows is only active for 90ms ๐Ÿ™‚
21:09:38 <TrueBrain> every 30ms this is checked for all windows; also funny ๐Ÿ˜›
21:12:57 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:21:34 <TrueBrain> Rubidium_: not sure if you and I mean the same with type traits or decorators, but I wouldn't know how those are similar?
21:22:51 <TrueBrain> I just want to do: `@call_on_interval(30ms)` on a function .. would be so much easier ...
21:24:19 <andythenorth> ehmm
21:30:06 <TrueBrain> yeah, I would prefer decorators ๐Ÿ˜›
21:32:54 <LordAro> might help a little?
21:33:12 <TrueBrain> if we want to go that way; people always have a love-hate relation with those
21:33:27 <LordAro> true
21:33:54 <TrueBrain> but okay, this is basically a function with a decorator around it .. it just is a bit more annoying to read ๐Ÿ™‚
21:34:27 <TrueBrain> at least they can now go locally, like for example NetworkChatMessageLoop can move close to the actual NetworkChatMessageLoop function
21:34:34 <TrueBrain> instead of in some random other place it is now ๐Ÿ˜› (read: window.cpp)
21:35:23 <TrueBrain> I guess the main question is, before I change everything: is this the direction we want to go to. Guess I should make a small enough PR so it already helps a bit, but not go all-out of fixing a ton of these weird statements we have ๐Ÿ™‚
21:36:11 <TrueBrain> LordAro: btw, those magic numbers should be enums, I guess ๐Ÿ™‚ Would also help ๐Ÿ™‚
22:01:39 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler updated pull request #10618: Fix eabb9db: Allow overbuilding station and waypoint tiles
22:04:10 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10618: Change: Allow overbuilding station and waypoint tiles
22:04:25 <DorpsGek> [OpenTTD/OpenTTD] LC-Zorg commented on pull request #10596: Change: Increase max cargo age and let min cargo payment approach zero.
22:05:28 <JGR> Brevity is an under-appreciated skill
22:06:17 <LordAro> those test saves look useful
22:06:58 <LordAro> i do like the pathological nature of save 2
22:09:31 <petern> 1st, 2nd, 3rd... the zip file contains 3 files, none of which indicate which is 1st, 2nd or 3rd.
22:10:48 <petern> (Also 2 of them have non-bananas NewGRFs)
22:15:38 <LordAro> i somehow doubt LC will mind if asked to provide more information :p
22:23:12 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10613: Codechange: Refactor timetable GUI
22:26:24 <DorpsGek> [OpenTTD/OpenTTD] LordAro commented on pull request #10613: Codechange: Refactor timetable GUI
22:27:15 <DorpsGek> [OpenTTD/OpenTTD] 2TallTyler commented on pull request #10613: Codechange: Refactor timetable GUI
22:32:20 *** gelignite has quit IRC (Quit: Stay safe!)
22:49:06 <DorpsGek> [OpenTTD/OpenTTD] ldpl updated pull request #10538: Show the number of hidden vehicles on the button
22:51:59 <DorpsGek> [OpenTTD/OpenTTD] LC-Zorg commented on pull request #10605: Feature: Change speed of calendar progress (with optional real-time display)
22:55:40 <dP> 2025 lc save crashes master :/
22:55:58 <dP> oh, that's just newgrf thing...
22:57:42 <dP> I always forget it's "normal" for missing newgrfs to crash the game
23:05:22 <DorpsGek> [OpenTTD/OpenTTD] LC-Zorg commented on pull request #10596: Change: Increase max cargo age and let min cargo payment approach zero.
23:08:54 <petern> Because without the NewGRF the information for the engines is not available.
23:09:27 <petern> There is a big red warning though, which would have read.
23:12:02 *** sla_ro|master has quit IRC ()
23:28:56 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:36:15 <petern> Hmm, addon wads downloaded with the rerelease versions of Doom are a bit weird...