IRC logs for #openttd on OFTC at 2023-04-09
⏴ go to previous day
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: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: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: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
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> It's "say text_goes_here"
07:40:16 <pickpacket> Azusa: in the terminal..?
07:40:25 *** andythenorth has joined #openttd
07:59:04 *** sla_ro|master has joined #openttd
08:43:10 <LordAro> wild Alberth PR appears
08:46:20 <andythenorth> Alberth might have played the game a bit
08:46:27 <andythenorth> had some DM chat
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:39 <andythenorth> _someone_ has to play vanilla 😛
09:03:55 <EmperorJake> Directional buoys don't need JGR
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:20:28 <TrueBrain> Writing a gist, as I need this written down 😄
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: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> 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` 😄
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: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> 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: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: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: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: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> 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: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: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: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: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:49:32 <dP> may still be possible btw, same way as a crash into water in #6503 comments
11:49:43 <EmperorJake> glx[d]: Ayy I got it to work, thanks so much 🙂
11:53:08 *** gelignite has joined #openttd
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 https://github.com/OpenTTD/OpenTTD/pull/10570 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:58:04 <dP> and for trains that took some playing with vehicle direction offsetting position
12:00:20 <JGR> TrueBrain: The documentation on cppreference.com 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-> 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: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:28 <TrueBrain> or, ofc, boost::thread_pool
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:52 <ag> Is that a different language altogether?
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: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: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: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:51:45 <glx[d]> We really should release 13.1
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: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: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: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: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: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: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: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: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: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: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: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:16:00 <dP> if clear cost is the same undo->build new, if not clear->build
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: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: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: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:34:37 *** Smedles has joined #openttd
16:41:02 *** sla_ro|master has quit IRC ()
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: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:33 <dP> does master without pr load it?
17:00:34 <petern> Hmm, missing origengs.grf
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: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:28 <LordAro> i'm wondering if max_size is garbage
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: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:22:16 <TrueBrain> 3 minutes between bug report and fix .. I am afraid this sets expectations 😛
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:24:59 *** ChanServ sets mode: +v tokai
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 ticks.zip in the main body
17:33:55 <JGR> I thought it seemed familiar...
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:54 <JGR> LordAro: The issue is that it can make some penalties negative, and cause signed integer overflow issues
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: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: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: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: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: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:07:38 <LordAro> one might expect that turning the pathfinder settings into compiletime constants may improve pathfinder performance as well
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: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: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:39:30 <TrueBrain> made some terrible mistakes in coding style, but who is still using tabs in this day and age 😛
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
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: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-> virtual ~RegisteredEventHandler() = 0;
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:37 <jfs-> ~IntervalTimer() override
19:09:39 <jfs-> TimerManager<TTimerType>::UnregisterTimer(*this);
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:25:07 <JGR> OpenTTD isn't anywhere near that level, thankfully
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: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:39 <TrueBrain> in fact, the CI refuses PRs with any warnings on any of the platforms 🙂
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> 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: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:12 <TrueBrain> works on my machine!
20:25:20 <LordAro> (we genuinely do that at work)
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: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:35:06 <TrueBrain> I was writing a reply 😦
20:35:14 <TrueBrain> you are much more rude 😛
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:53 <LordAro> "my bad", i'm assuming
20:38:59 <TrueBrain> ah, that makes more sense 🙂
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: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:49:07 <TrueBrain> that is fucking hilarious 😄
20:49:19 <TrueBrain> but LordAro made someone ragequit GitHub
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:09 <TrueBrain> on the other hand: at least test your work? 😛
20:50:32 <TallTyler> Truly the least you can do
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: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: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: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: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: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:33:12 <TrueBrain> if we want to go that way; people always have a love-hate relation with those
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: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:32:20 *** gelignite has quit IRC (Quit: Stay safe!)
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: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...
continue to next day ⏵
