IRC logs for #openttd on OFTC at 2025-01-25
⏴ go to previous day
01:32:26 *** liquidsnake0123 has quit IRC (Quit: User went offline on Discord a while ago)
03:15:39 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:25:16 *** Wormnest has quit IRC (Quit: Leaving)
03:49:26 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:42:53 <DorpsGek> - Update: Translations from eints (by translators)
08:23:01 *** akimoto has joined #openttd
09:01:26 *** akimoto has quit IRC (Remote host closed the connection)
09:36:48 <truebrain> That took way longer than I would like to admit to figure out. Ugh.
09:38:23 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
09:38:25 <truebrain> I could have done this correct the first time
09:38:28 <truebrain> but pushing 3 times is much more fun
09:41:04 <truebrain> owh, that didn't work .. wth .. lol
09:41:50 <andythenorth> have you had coffee yet? 🙂
09:42:10 <truebrain> it worked during testing ...
09:42:14 <truebrain> well, isn't this annoying
09:45:11 <truebrain> owh, GitHub has a slightly older version of the CLI
09:45:21 <truebrain> and I guess it was buggy enough, that those commands don't actually work
09:45:31 <truebrain> why has this become such a mess 😦
09:48:26 <truebrain> now Cloudflare says: downgrade your AWS CLI. The issue is: AWS only distributes the latest version as binary. Can't find anywhere where I can download an older version. lol
09:49:58 <truebrain> lol, but I could guess the URL. So there is that.
09:56:45 <truebrain> this time, it actually works 😛
10:24:03 *** HerzogDeXtEr has joined #openttd
10:31:22 *** kuka_lie has joined #openttd
11:47:00 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
12:25:21 <Rubidium> industry colour remap?
12:32:42 <pickpacket> Rubidium: I guess, but I don't understand it. I don't know how the night theme works. Weird that farms with other colour combinations aren't affected
12:33:12 <pickpacket> Would be cool to make the Tea Tea Deluxe NewGRF work with the night theme
12:34:34 <Rubidium> don't know the night theme, so I've got no clue about that
12:51:54 <andythenorth> `-0` valid concept or not?
12:53:29 <Rubidium> andythenorth: in IEEE754 it is ;)
12:53:43 <andythenorth> I think it's valid
13:13:09 <pickpacket> Why would it be valid? Double counting a zero in a signed int?
13:44:28 *** kuka_lie has quit IRC (Quit: Lost terminal)
13:50:08 <truebrain> close it once, close it twice! 🙂
13:54:12 <peter1138> That's happened a couple of times recently.
13:55:15 <peter1138> Does that enum thing mean we shouldn't be using them for 'weak' types?
13:55:42 <peter1138> Or is it ok because we disable it.
13:59:22 <truebrain> Just a weird GitHub buck where both the commit and ticket close a ticket. No clue why it acts like that .. you would think they would have fixed that by now 😛
14:00:36 <truebrain> buck? bug! Lol .. weird typo 😛
14:07:43 <Rubidium> peter1138: the undefined behaviour could be a reason not to use them, but... also any of the enums with flags are undefined behaviour. Take EngineDisplayFlags where the compile might replace the (x & y) == y with just x == y as it knows all the values of the enumeration
14:09:31 <peter1138> So we'd need to replace a lotbof enums.
14:10:30 <Rubidium> what GCC 4.5 did was make `for (SignalVariant var = SIG_ELECTRIC; var <= SIG_SEMAPHORE; var = (SignalVariant)(var + 1))` an infinite loop, as all variants of the SignalVariant are less than or equal to SIG_SEMAPHORE
14:14:23 <peter1138> There is a type safe way thst can work, but it'll be a somewhat large change.
14:14:24 <Rubidium> technically we'd need to replace them yes, though practically none of the current compilers are over optimising this and they will likely not do so as that will create thousands of vulnerabilities
14:15:29 <peter1138> (For the bitmasks, not for the biunds checks.)
14:16:47 <_jgr_> The enum bitmasks seem like something that could be checked for in src/tests
14:18:23 <_jgr_> It is a bit disappointing that C++ makes "doing the right thing" so awkward/unergonomic at times
14:27:45 <truebrain> Porting OpenTTD to Zig when?
14:29:32 <truebrain> How lovely, on my Win11 machine I cannot open Display Settings nor Windows Updates anymore
14:29:37 <truebrain> very useful addition, or something
14:33:50 <peter1138> Ah, it's turned into Gnome - removing options that people use.
14:36:08 <truebrain> I don't think they are suppose to be gone
14:58:42 <truebrain> `The Windows Update diagnostic failed to run`
15:01:48 <Rubidium> _jgr_: you meant something like #13380, right?
15:54:18 *** gelignite has joined #openttd
16:29:12 *** kuka_lie has joined #openttd
17:12:45 <xarick> can someone look into check online content being sluggish on windows?
17:13:16 <xarick> I remember testing it on linux with no slowdowns at all, very responsive
17:13:55 <xarick> i even thought it was normal, until I checked openttd on linux
17:25:22 <_zephyris> Opens and lists all content in under a second on my generic laptop
17:27:13 <peter1138> Let's see if that builds...
17:29:17 <ahyangyi> peter1138: I think Gnome typically only hides the options people use, not remove them?
17:30:18 <ahyangyi> But on the other hand there aren't many options to start with...
18:05:51 <xarick> maybe I should make a video
18:06:44 <xarick> funny, now it's not being that sluggish
18:15:01 *** chilla55 has joined #openttd
18:21:05 <peter1138> ahyangyi, yeah... there used to be.
18:22:46 *** gelignite has quit IRC (Ping timeout: 480 seconds)
18:25:24 *** gelignite has joined #openttd
18:26:34 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
18:39:06 <xarick> DepotCommand and DepotCommands
18:44:04 <peter1138> Could be DepotCommandFlag/Flags.
18:45:10 <xarick> it's only different by a character
18:45:44 <truebrain> I need a translator 😦
18:45:48 <peter1138> Yeah, none of that makes sense.
18:46:10 <LordAro> it's at best irrelevant
18:47:16 <xarick> DepotCommand / Mask, BitSet, something more descriptive I guess
18:48:02 *** tokai|noir has joined #openttd
18:48:02 *** ChanServ sets mode: +v tokai|noir
18:51:44 <Rubidium> well... removing -flto will probably save a bit of memory in the linker, -Os might as well ;)
18:52:05 <LordAro> i was gonna say, release build will be using lto
18:54:17 <Rubidium> xarick: be happy there isn't an Aircraft :D
18:54:21 <peter1138> Okay, done for DepotCommand the same that I did for Borders.
18:55:03 *** tokai has quit IRC (Ping timeout: 480 seconds)
18:55:45 <peter1138> Having `DepotCommandFlag` and `DepotCommandFlags` is clearer than just `DepotCommand` being a bitmask.
18:59:38 <xarick> wait, unbunch order flags not touched
19:01:35 <peter1138> Absolutely loads are untouched.
19:01:51 <peter1138> As the PR says, I only touched some of the `enum class` enums.
19:02:08 <peter1138> TBH, it's kind of a proof-of-concept.
19:02:26 <peter1138> It might be a bad idea.
19:08:57 <Rubidium> though... you got a serious case of side-quest again, right? ;)
19:09:41 <truebrain> isn't his life one big side-quest? 😄
19:22:12 <peter1138> Some of this was bugging me already, to be honest.
19:24:39 <peter1138> Especially in places where it's ambiguous if an enum is bit numbers (a.k.a. just a regular enum) or a bitmask.
19:44:50 <xarick> I have a multithreading question
19:45:58 <xarick> there is the Map array, and lets say one thread wants to set the desert zone of the same tile as the other
19:46:21 <xarick> so 2 threads try to write at the same location, what happens?
19:47:06 <michi_cc> Random things happen and stuff will break six months later when nobody remembers anymore.
19:48:57 <xarick> hmm I was imagining RemoveDesertAroundRiver multithreaded
19:49:38 <_jgr_> xarick: Your trial and error approach is not suitable for thread-related work
19:51:34 <xarick> I am so tempted to test
19:52:15 <xarick> but I'm not sure about atomic operations
19:52:15 <truebrain> _jgr_: Remember that this is write-only channel for him 🙂
19:52:40 <andythenorth> Are we still learning multithreading together? 🤣
19:53:01 <truebrain> didn't we fix that page last time?
19:54:07 <truebrain> `Command Injection - Common Attack Commands`
20:12:16 <peter1138> Things like `TRACK_BIT_3WAY_NW = TRACK_BIT_Y | TRACK_BIT_UPPER | TRACK_BIT_LEFT` get a bit awkward to define with this :(
20:17:15 <Rubidium> by the way, can't you make the EnumBitSet constructor take 1 or more Enum values, so it'd become constexpr TrackDirs TrackBit3WayNW = TrackDirs(BitY, BitUpper, BitLeft)
20:19:32 <xarick> [RemoveRiverArtifacts st] 36183 us
20:19:32 <xarick> [RemoveRiverArtifacts mt] 4674 us
20:20:58 <_glx_> there's one simple rule for threading, reading can be parallel, writing nees exclusive access
20:21:49 <_glx_> so no thread should be able to read/write when another one is writing
20:24:32 <andythenorth> peter1138[d]: think badges is done? 😛
20:25:10 <xarick> DoClearSquare is I assume, safe, but ModifyDesertZoneAroundRiver(tile)... meh, it runs circular tile search which may overlap on a tile of another thread
20:25:47 <peter1138> It's safe if you don't have any threads.
20:26:59 <_glx_> if you don't do any terraforming it could be possible the split the map in blocks for different threads
20:27:41 <_glx_> but they might need to access tiles of other blocks on borders
20:28:38 <_glx_> anyway multithreading requires a lot of thinking before even starting implementation
20:28:41 <andythenorth> peter1138: what if I have 1 threads? 👀
20:30:15 <xarick> ow,... !IsWaterTile(other_tile) might be a problem too
20:31:15 <xarick> DoClearSquare(tile) might just happen to remove water on the "other_tile"
20:31:20 <andythenorth> if we merge it....then JGRPP can merge it
20:31:25 <andythenorth> then the grf authors will use it
20:32:14 <peter1138> IRC has much better ignore features than discord.
20:32:33 <andythenorth> Truebrain used to confuse /ignore with /kick quite a lot
20:32:50 <andythenorth> personal experience
20:44:17 <xarick> > [RemoveRiverArtifacts st] 33639 us [avg: 33639.0 us]
20:44:17 <xarick> > desert: 4094903; normal: 3618425; rainforest: 9063888; river: 178944
20:44:17 <xarick> > [RemoveRiverArtifacts mt] 4895 us [avg: 4895.0 us]
20:44:17 <xarick> > desert: 4094903; normal: 3618425; rainforest: 9063888; river: 178944
20:44:45 <xarick> expected something different honestly
20:46:09 <xarick> there's tile overlapping
20:46:55 <xarick> between desert and normal
20:48:02 <Rubidium> that something doesn't happen, doesn't mean it can't happen. You might've been lucky
20:51:15 <xarick> converting desert to normal in a radius of 5
20:51:42 <xarick> i wanted to trigger a case of "writing to the same location"
20:53:38 <xarick> when a conversion occurs it's always from desert to normal anyway, but... I dunno, is it normal nothing strange happens? not even a crash or lockup?
21:06:16 <_glx_> no real reason for crash in those map accesses
21:06:41 <_glx_> at worse unexpected results
21:11:40 <_glx_> "unsafe" when threading is often not about crashes, but mostly about data integrity
21:12:12 <_glx_> (which can lead to crashes for some data)
21:28:12 <peter1138> Bums, our list filtering code only supports one function. Hm.
21:28:55 <peter1138> I suppose logically the one function can do anything.
21:28:55 <_glx_> you want chained filters ?
21:30:18 <peter1138> Oh, the BuildVehicle stuff is a bit messy, it has the cargo filter function, but also filters by name separately.
21:30:25 <peter1138> (And already filters by badge names there.)
21:34:14 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:46:54 <peter1138> Well, badge-filter by drop down list.
21:46:59 <peter1138> Just need more configuration.
21:49:02 <andythenorth> want a Horse grf?
21:57:53 <peter1138> The template args makes things like BORDERFLAGS_ALL a lot nice to set up.
21:58:00 <xarick> CoPilot is giving me ideas
21:58:54 <Rubidium> peter1138: yes, it does... though not BorderFlags::All ;(
21:59:06 <peter1138> Yeah, I don't think that's possible.
21:59:17 * andythenorth too tired to refactor Horse name text stack
22:04:15 <peter1138> Seems to break other bits though :(
22:06:54 <andythenorth> no power suffixes eh (left side)
22:06:59 <andythenorth> but less traditional
22:07:11 <andythenorth> easier to read 😛
22:07:33 <belajalilija> Power suffixes are bad yes
22:07:44 <peter1138> It would be clearer if you had the icons as well.
22:09:25 <belajalilija> You will need sprites for voltage type though
22:09:39 <belajalilija> I’ve made some but they’re not intuitive
22:10:01 <peter1138> `e->display_flags | EngineDisplayFlag::Shaded` no longer works :(
22:10:10 <andythenorth> it's quite possible that AC vs DC is stupid 🙂
22:10:16 <andythenorth> haven't tried it really
22:10:16 <peter1138> Voltage type is definitely a bad feature.
22:10:33 <belajalilija> It’s not one i like personally
22:10:37 <belajalilija> But it is in my set
22:11:13 <belajalilija> My design for voltage relies on people running my set with SETS
22:11:30 <andythenorth> ok so engines aren't pluralised on top level name
22:11:51 <belajalilija> As the colours next to the voltage sparks in my set correspond to the colours of the OHLE poles
22:12:03 <andythenorth> pluralising is more name string handling 😛
22:12:53 <peter1138> I bet different sets use different colours though.
22:13:13 <belajalilija> peter1138: No idea, we used the xUSSR standard
22:13:34 <andythenorth> my planned European set is Alpine 😛
22:13:46 <andythenorth> so I AC vs DC is already the redux version 😛
22:14:11 <andythenorth> I didn't do 3 phase or weird French 3rd rail
22:14:47 <belajalilija> andythenorth: I’m glad that I’m not the only person to talk about plans but take ages to act on them :kek:
22:16:07 <peter1138> belajalilija, doesn't xUSSR have about 5 million different colours for ac vs dc, voltages, frequencies and phases?
22:17:36 <andythenorth> belajalilija: there's always more Horse to do
22:18:20 <andythenorth> wonder how much compile time I could save
22:18:33 <andythenorth> they're all fancy advanced varact2s writing to the text stack also
22:18:40 <peter1138> Okay, so red spark is DC.
22:18:53 <peter1138> Brown spark is... also DC, but 1500V.
22:19:15 <peter1138> Double red and brown spark is DC 3kV and DC 1500V
22:19:24 <belajalilija> peter1138: We’re using 4
22:20:25 <peter1138> Oh, your icons are of course completely different :)
22:21:26 <peter1138> Dark blue is AC 25kV
22:21:31 <peter1138> Well, xUSSR is a bit mad.
22:21:52 <belajalilija> peter1138: Mine work better for multi voltage
22:21:56 <peter1138> Dark blue an red, AC 25kV / DC 3kV
22:22:14 <andythenorth> hmm can I make 'name' empty and just use a badge 😛
22:22:32 *** kuka_lie has quit IRC (Remote host closed the connection)
22:22:42 <belajalilija> belajalilija: The coloured bar is 12 pixles and we have 4 voltages
22:22:55 <belajalilija> So any combo can be represented
22:23:13 <peter1138> Right but it isn't really clear.
22:23:27 <belajalilija> Nah that’s what i said
22:23:34 <belajalilija> Voltage is optional though
22:23:40 <belajalilija> I won’t personally play with it
22:24:27 <belajalilija> It is a feature brickblock wanted and it didn’t hinder my vision for the set so i ran with it
22:24:51 <belajalilija> belajalilija: Ideally the poles would have more colour
22:25:15 <belajalilija> My colours are slightly different to improve contrast
22:25:36 <peter1138> Ideally we would have some default badges for this so that users are not left guessing, but the combinations are a bit mad.
22:26:08 <peter1138> And the colours xUSSR uses kinda conflict with the existing "standard" light blue for "electric"
22:26:27 <belajalilija> I don’t think there’s a reasonable way to get all that info into 12x16 or whatever
22:27:00 <belajalilija> I’ll gladly go along with whatever badges you come up for it though
22:28:15 <peter1138> Hmm, can I enable a variadic template but ensure only one type is present...
22:28:19 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:32:43 <peter1138> `constexpr EnumBitSet(std::initializer_list<const Tenum> values)`
22:41:55 <peter1138> `constexpr EnumBitSet(Tstorage data) : data(data) {}` probably ought to be explicit.
22:42:37 <xarick> Trying dumb stuff... static std::unique_ptr<std::shared_mutex[]> tile_mutexes;
22:49:08 <xarick> std::unique_lock write_lock(Tile(tile).mutex());
22:59:57 <xarick> I'm getting unresolved external link
23:11:07 <xarick> nope, i can't do it...
23:11:16 <xarick> unresolved external symbol
23:17:17 <xarick> I have in Map::Allocate
23:17:17 <xarick> `Tile::tile_mutexes = std::make_unique<std::shared_mutex[]>(Map::size);`
23:18:11 <xarick> `static std::unique_ptr<std::shared_mutex[]> tile_mutexes;`
23:19:28 <xarick> ``` debug_inline std::shared_mutex &mutex()
23:19:28 <xarick> return tile_mutexes[this->tile.base()];
23:20:23 <xarick> ```debug_inline std::shared_mutex &TileMutex(TileIndex tile)
23:20:23 <xarick> return Tile(tile).mutex();
23:21:06 *** keikoz has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
