IRC logs for #openttd on OFTC at 2024-11-10
⏴ go to previous day
02:01:08 *** nielsm has quit IRC (Ping timeout: 480 seconds)
03:27:28 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:35:53 *** D-HUND is now known as debdog
04:45:28 <DorpsGek> - Update: Translations from eints (by translators)
05:13:09 *** Smedles has joined #openttd
05:15:42 <pickpacket> Lots of people worried that OpenTTD will be affected by atari buting TT
05:17:02 <pickpacket> Would it be worth writing a blog post about it?
07:36:53 <andythenorth> categorically not IMHO 🙂
07:48:00 <kuhnovic> We don't know what their plans are, we don't know if they'll be making threats to OpenTTD. So not sure what we should write about at this point. There's a "don't poke the bear" element to it too.
07:51:06 <andythenorth> also, reddit being in a flap....is what reddit does
07:51:34 <reldred> Doesn't sound like there's anything to write about
07:51:45 <reldred> Probably best to say nothing.
08:06:26 <peter1138> This morning I have mostly been drinking tea and cleaning up dog sick.
08:08:50 <andythenorth> I re-watched all of the Fast Show recently, it's aged quite well
08:12:47 <peter1138> 53 files changed, 1808 insertions(+), 71 deletions(-)
09:28:59 *** Flygon has quit IRC (Read error: Connection reset by peer)
09:59:46 *** keikoz has quit IRC (Ping timeout: 480 seconds)
11:02:08 *** XYZ has quit IRC (Read error: Connection reset by peer)
11:14:48 <xarick> nice, looks simpler. I always wondered why we had to put a begin and end on std::find
11:21:48 *** XYZ_ has quit IRC (Quit: AndroidIrc Disconnecting)
11:33:56 <peter1138> std::find requires begin and end.
11:34:50 <peter1138> Anyway, non-Linux is unhappy. Oh well.
11:35:24 <dwfreed> who needs non-linux anyway
11:36:18 <_jgr_> The player platform distribution doesn't quite match the developer platform distribution 😛
11:36:59 <_jgr_> Ranges will be nice when it finally gets here
11:40:24 <_glx_> peter1138: Looks like non Linux didn't like search and replace 😉
11:42:43 <dwfreed> the failure seems to be that you're asking it to find a ulong in a vector of DLSWave's
11:43:05 <xarick> I wish the TicToc would auto adapt itself
11:45:31 <peter1138> Ah there's an operator==
11:56:00 <dwfreed> peter1138: macOS succeeded, so looks like that fixed it
12:00:35 *** XYZ has quit IRC (Read error: Connection reset by peer)
12:01:56 <xarick> CheckIfFarEnoughFromConflictingIndustry is the slow one
12:02:15 <_jgr_> Oh nice, I thought that'd be more of a problem
12:04:54 *** XYZ_ has quit IRC (Read error: Connection reset by peer)
12:10:44 <xarick> kdtree for CheckIfFarEnoughFromConflictingIndustry ?
12:15:50 <peter1138> Now, does it break anything...
12:16:15 <peter1138> There is one struct that has an operator== and an operator!= that do different things.
12:18:54 <peter1138> No, I was right. CargoSummaryItem.
12:26:05 <xarick> compiling industry_cmd.cpp takes 21 seconds
12:30:44 <xarick> let's force the "slow" method
12:33:56 <truebrain> right, time for some light maintenance on openttd.org .. let's see if that can be done with as little downtime as possible 🙂
13:27:51 *** DorpsGek has joined #openttd
13:27:51 *** ChanServ sets mode: +o DorpsGek
13:28:00 <truebrain> and DorpsGek is back too \o/
13:28:26 <truebrain> nasty bug in my scripting is causing the wrong version to deployed on first attempt; I should fix that 😛
13:28:50 <truebrain> IRC <-> Discord bridge needs a restart too 🙂
13:28:58 <xarick> peter teached me `if (std::ranges::any_of(indspec->conflicting, [i, indspec](auto conflicting) { return i->type == conflicting; })) {`
13:29:16 *** DorpsGek_vi has quit IRC (Remote host closed the connection)
13:29:16 *** xarick has quit IRC (Remote host closed the connection)
13:29:16 *** truebrain has quit IRC (Remote host closed the connection)
13:29:18 *** DorpsGek_vi has joined #openttd
13:31:16 <xarick> I don't need the indspec
13:34:50 *** peter1138 has joined #openttd
13:34:50 <peter1138> You don't need the lambda either.
13:35:35 <peter1138> (You need a projection)
13:36:40 *** truebrain has joined #openttd
13:36:40 <truebrain> right, all production parts are redeployed. Now for the preview parts .. but those are less important 🙂
13:38:02 <xarick> I wanna try the kdtree approach, but i'm not sure where to begin
13:41:49 <stenyg> xarick: kd-tree is a nnda right?
13:41:53 <stenyg> nearest neighbour data approach
13:42:54 <truebrain> In other goods news, the new game-coordinator protocol is robust enough for most (all?) servers to rejoin minutes after the GC was back online 🙂
13:44:15 <truebrain> everything should be back online; let me know if there are any after-effects 🙂
13:46:48 <xarick> I have no idea what kdtree is, but it's probably that
13:47:07 <xarick> nearest neighbour fast searching
13:56:50 <truebrain> right, time to repeat this exercise on OCI I guess ... which most likely will see the same faith. But it just hosts BaNaNaS, so it is less of an issue in that sense 🙂
14:17:46 <truebrain> at least I am not the only one that had this issue with upgrading Nomad
14:17:50 <truebrain> makes me a tiny bit less sad
14:20:55 <truebrain> either way, at least we can safely say OpenTTD has their disaster recovery plans well in order 😛 Not many companies can say that, let alone Open Source projects 😛 😄
15:26:27 <truebrain> Okay, BaNaNaS is rolling from one issue into the next. Lol. It is online and working, but it doesn't show any content 🙂
15:26:35 <truebrain> server says it loaded content just fine
15:28:14 *** SigHunter has joined #openttd
15:33:16 <mnhebi> server is playing hide and seek with you
15:33:29 <truebrain> IPv6 traffic is not flowing correctly
15:33:35 <truebrain> "it used to work" 😛
15:37:37 <xarick> how do I iterate over the tiles of an industry which are really theirs
15:37:51 <xarick> somehow I ended up on a clear tile type
15:38:58 <truebrain> grrrr, firewalls .. grrrrr
15:40:46 <truebrain> for some reason the IPv6 firewall was configured differently. So it was blocking all internal traffic that needed to go through the FORWARD rule. Oops 🙂
15:40:48 <truebrain> owh well, all fixed now
15:43:27 *** andythenorth has joined #openttd
15:43:27 <andythenorth> so `const` in nml eh
15:43:29 <andythenorth> is really useful
15:46:59 <andythenorth> is there anything existing thing like macro expansion? There's lots of magic in nml
15:47:40 <andythenorth> I'd like to set refittable and non-refittable classes off a single declaration of something
15:49:26 <peter1138> There's PR (draft?) for includes.
15:53:33 <peter1138> Maybe it was just a branch.
15:57:31 <andythenorth> so I could do e.g. `VEHICLE_FLATBED_REFITTABLE_CLASSES = bitmask(CC_FOO, CC_BAR);` and `VEHICLE_FLATBED_NON_REFITTABLE_CLASSES = bitmask(CC_HAM, CC_EGGS);`
15:58:40 *** Wormnest has joined #openttd
15:58:43 <andythenorth> and provide a set of these in a file for includes
16:00:14 <truebrain> The shit that eats your time away. Stupid Docker ... "yeah, I will manage your firewall .. owh, did you mean I also had to forward traffic? NAH BRO! I am just being a pain in your ass"
17:16:41 *** XYZ has quit IRC (Quit: AndroidIrc Disconnecting)
17:38:48 <_glx_> peter1138: just a branch for now
17:39:45 <_glx_> it works but it doesn't prevent infinite include recursion
17:40:12 <xarick> I'm attempting a rudimentary implementation of kdtree for industries
17:40:25 <xarick> already shoved 20 seconds
17:40:50 <_glx_> what do you want to do with that ?
17:41:13 <xarick> conflicting industries
17:42:53 <andythenorth> pff, are there any nml props that can take a list of lists? 😛
17:43:27 <andythenorth> my_fancy_prop: [bitmask(CC_FOO, CC_BAR), bitmask(CC_HAM)];
17:43:33 <_glx_> station use arrays of arrays 🙂
17:44:21 <andythenorth> for vehicle authors, it would be so much more convenient to just have pre-defined refittable and non-refittable classes for common vehicle types
17:44:30 <andythenorth> higher chance of predictable behaviour
17:44:56 <_glx_> you can do `bitmask(...) | bitmask(...)
17:45:08 <andythenorth> won't that OR them? 🙂
17:45:38 <andythenorth> yeah, this would be something expanded to (train) prop 0x28 and prop 0x29
17:45:58 <andythenorth> but declared as a single property, so I can use `const` 😛
17:47:05 <_glx_> you can use `const`, `const my_vehicle_type = bitmask(...)` then you use it in the property
17:47:17 <andythenorth> yes, I have that 🙂
17:47:23 <andythenorth> just there are 2 props to set
17:55:17 *** Borg has quit IRC (Quit: leaving)
18:06:27 <xarick> projected what is this?
18:06:41 <xarick> predicator and projected
18:16:03 <xarick> 1.1. CheckIfFarEnoughFromConflictingIndustry] 337022 us [avg: 0.0 us] wow
18:16:09 <xarick> that was totally worth it
18:17:59 <xarick> im so suspicious i broke something
18:19:37 <xarick> that's too fast for my liking
18:21:23 <xarick> what used to take 42 seconds, now takes 0.3 seconds
18:32:00 *** kuhnovic has joined #openttd
18:32:00 <kuhnovic> Just to be sure: you are comparing in release right?
18:40:46 <kuhnovic> Ok good. Then from 42 to 0.3 sounds kinda crazy indeed.
18:42:16 <xarick> I'm only concerned about DistanceMax
18:42:31 <xarick> not sure what kind of distance Kdtree internals use
18:50:38 <xarick> any nasty NewGRF industries I could test?
18:50:58 <xarick> looking for conflicting industries
18:52:00 <andythenorth> ECS has quite significant location checks if I remember correctly
18:52:32 <_glx_> but won't be affected by CheckIfFarEnoughFromConflictingIndustry I think
18:53:14 <andythenorth> generally grfs provide their own conflict checks afaik
18:53:22 <andythenorth> the built in property is very limited
18:55:58 <xarick> what's the name of the grf, I get a tons of ECS
18:56:57 <peter1138> I thought the purpose of ECS it to play a game of "figure out which combination and order is permitted".
18:57:05 <_glx_> I think it uses var64 for distance check
18:58:04 <xarick> I don't know which one to download
18:58:42 <xarick> NewGRF's has always this problem... too many of the same
18:59:29 <_glx_> you need to read the doc to know what to get
19:00:48 <_glx_> but ECS probably uses var64 so GetClosestIndustry()
19:01:51 <xarick> I'll look at that one if it can use kdtree
19:19:05 <peter1138> Looping industries to find the nearest.
19:19:56 <peter1138> The fact GetClosestIndustry is a function in newgrf_industries.cpp suggests that isn't otherwise much call for knowing industry distances.
19:46:08 <xarick> be a good enough cpu for me to buy
19:46:14 <xarick> an entire new platform
19:46:36 <xarick> building openttd is starting to become slow
19:47:58 <xarick> i wanna build master, then i wanna build my current branch, pff
19:48:07 <peter1138> We keep using more and more STL instead of rolling our own old C stuff.
19:48:16 <xarick> and then i forgot what i was doing in the meantime
19:48:24 <peter1138> That's easy, have two separate checkouts.
19:48:36 <andythenorth> get an M-series and build on that 😛
19:49:05 <peter1138> The problem with that is you're then on a Mac, and nobody wants that.
19:49:27 <peter1138> Do they have more than one mouse button these days?
19:49:37 <andythenorth> I don't have any mouse buttons
19:50:25 <andythenorth> is Asahi Linux ready yet?
19:50:48 <_jgr_> Some of that STL stuff probably doesn't needing to be included in every C++ file. Likewise for the fmt implementation stuff.
19:51:09 <_jgr_> Probably won't make a big difference though
19:51:33 <peter1138> Only if you like the risk of Apple accidentally bricking it at any moment.
19:52:22 <andythenorth> I blame Tim Apple
19:52:49 *** gelignite has joined #openttd
19:55:56 <peter1138> Hmm, maybe I should simplify this config stuff a bit.
20:11:53 *** johnfranklin has joined #openttd
20:11:53 <johnfranklin> Oof, consumed 2 pints milk in one day.
20:15:07 <johnfranklin> 1/10 of which was used to cook pasta, so I drank 1L
20:23:53 <xarick> dear experts, is it possible for TicToc to return the number of times it was called for a code block, because windows terminal printing slows down the whole thing if I ask it to print every 1 time.
20:24:15 <xarick> I am interested in that total
20:24:20 <xarick> but only print it at the end
20:27:03 <_jgr_> How does TicToc know that you've finished, and you want to print something?
20:27:32 <_jgr_> In general, perhaps it may be useful to consider trying a profiling tool
20:44:32 <peter1138> You could make the destructor of TicToc::State output something.
20:44:42 <peter1138> Probably not wise though.
20:45:04 <xarick> IndustriesResolverObject ugh... magic black box
20:45:32 <peter1138> ResolverObjects just contain state that is used during variable resolving.
20:46:12 <xarick> CBID_INDUSTRY_LOCATION
20:49:00 <_glx_> that's just a value for a newgrf variable (var0C)
20:53:57 <xarick> that's expensive, I'm testing a smaller map and the total is 11 seconds
20:54:42 <xarick> with a bunch of ECS'ss
20:56:10 <xarick> i have no idea what to do here
20:59:01 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:59:51 <_jgr_> At some point you'll need to look at what the particular GRF is doing to see why it is/isn't performant
21:00:47 <_jgr_> You can't get fine-grained information just by using stuff like TicToc
21:01:02 *** tokai|noir has joined #openttd
21:01:02 *** ChanServ sets mode: +v tokai|noir
21:07:43 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:16:45 <xarick> GetClosestIndustry has that annoying condition that the industry must be of a certain type
21:28:47 <andythenorth> 'annoying' / 'useful' /s
21:32:23 <xarick> IndustryKdtree industries = _industry_kdtree; I hope this creates a temporary copy
21:32:40 <xarick> i don't want to mess up the base one
21:43:03 <xarick> well... it's slow at removing
21:45:08 <_glx_> maybe it would be faster to create a copy filtered by type
21:45:18 <peter1138> Hmm, dropdown submenus?
21:48:42 <peter1138> Do we have a general purpose edit or config button? Hmm.
21:49:21 <xarick> how many industry types can be in the game?
21:49:31 <xarick> do you fancy that number of kdtrees?
21:51:19 <peter1138> Not sure what the memory and cpu cost is of maintaining a kd-tree.
21:51:48 <xarick> a vector containing 240 kdtrees per industry type + another containing all
21:52:21 <peter1138> Why 240 per industry type?
21:52:36 <peter1138> Surely just one per industry type.
21:53:12 <peter1138> 57600 vs 240 is a big difference.
21:53:57 <peter1138> Each IndustrySpec is already 992 bytes
21:54:41 <peter1138> Oh, less than that, I added 24 bytes already since master 😄
22:35:04 *** gelignite has quit IRC (Quit: Stay safe!)
22:43:44 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:51:49 <xarick> ```std::array<IndustryKdtree, INVALID_INDUSTRYTYPE> _industry_kdtree;
22:51:49 <xarick> //IndustryKdtree _industry_kdtree(&Kdtree_IndustryXYFunc);```
22:52:29 <xarick> i want an array of IndustryKdtree but each tree requires this (&Kdtree_IndustryXYFunc) thing
22:53:35 <xarick> ```typedef Kdtree<IndustryID, decltype(&Kdtree_IndustryXYFunc), uint16_t, int> IndustryKdtree;
22:53:35 <xarick> extern IndustryKdtree _industry_kdtree;```
22:54:47 <peter1138> We can improve that, I think.
22:55:20 <xarick> requires skills, which I don't have
22:56:33 <xarick> ```inline uint16_t Kdtree_IndustryXYFunc(IndustryID iid, int dim) {
22:56:33 <xarick> return (dim == 0) ? TileX(Industry::Get(iid)->location.tile) : TileY(Industry::Get(iid)->location.tile);
23:08:45 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:28:08 *** ellwill has joined #openttd
23:28:08 <ellwill> Have any UK sets ever considered adding the Class 424?
23:33:02 <peter1138> (Incorrect terminology there)
23:42:45 <peter1138> xarick: 13074 should help there.
continue to next day ⏵
