IRC logs for #openttd on OFTC at 2024-01-15
โด go to previous day
00:03:39 <xarick> `GetCrossRegionAqueductTileCoordinate` Very description, informative needed
00:05:48 <truebrain> right .. compiling a libc 2.28 variant, based on AlmaLinux 8
00:05:55 <truebrain> seems to have a lot newer software for .. everything ๐
00:09:14 <truebrain> `The error was: wayland not available`
00:09:21 <truebrain> okay ... so there is an issue somewhere else here ๐
00:13:50 <truebrain> very odd, that you have an SDL that says: I support Wayland, but when you run it, it says: nah
00:15:46 <peter1138[d]> Possibly "I support Wayland, but only with some specific set of options and I won't tell you what they are"
00:16:27 <truebrain> I suspect that the vcpkg version of sdl just isn't right
00:17:35 <truebrain> okay, at least progress on #11353 .. one problem gone, next shows up ๐
00:26:09 <truebrain> okay, I see that the SDL library compiles the wayland files
00:29:55 <truebrain> but when I check with `strings` in the final library, there are no references to wayland there
00:30:03 <truebrain> something isn't doing what it is suppose to do .. and I just blame vcpkg ๐
00:35:18 <truebrain> rebuild everything, NOW I see references to wayland
00:35:27 <truebrain> seems if you rebuild a vcpkg package, it isn't actually rebuilding everything, or something
00:35:36 <truebrain> right, lets build OpenTTD now
00:38:15 <truebrain> and I get the same error as the others ๐
00:38:38 <truebrain> the X11 support also seems a lot better
00:38:49 <truebrain> so yeah ... I think a 2018 Linux variant is well worth it ๐
00:47:47 <truebrain> haha, I don't have a decorator library compiled, so now I don't have anything to use ๐
00:47:58 <truebrain> can't find a decorator library in this distro ....
00:49:07 <truebrain> Wayland is just buggy .. where the window opens changes every time .. while we calculate the center and use that ๐
01:52:17 *** clandry94 has joined #openttd
02:09:27 <FLHerne> orudge set up the list, so he might know
02:10:22 <FLHerne> I don't remember it being used much, everything was on the development forum or IRC
02:12:33 <FLHerne> looking at your linked history, I think that probably /is/ a complete set of the messages; it never really caught on
02:37:28 <_glx_> oh I still have messages from 2006-2007 in thunderbird
03:46:20 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:57:21 *** Wormnest has quit IRC (Quit: Leaving)
04:21:55 *** limyx826 has quit IRC (Quit: User went offline on Discord a while ago)
05:56:54 *** Flygon has quit IRC (Remote host closed the connection)
06:22:55 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:31:53 *** ChanServ sets mode: +v tokai
07:38:50 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
07:51:26 <reldred> You are personally responsible
07:51:34 <reldred> You will be held accountable
08:05:27 <truebrain> pfff ... E_TOO_MANY_SDL_ISSUES ๐
08:05:37 <truebrain> but I think I now have them all in their own little ticket ๐
08:15:33 <Eddi|zuHause> i still feel the priority level of that "bug" to be somewhere near "there should be earrings on both ears"
08:22:11 <wensimehrp> I'd say it's a very minor bug and fixing it or not fixing it doesn't really affects player's gaming experiences.
08:30:46 <locosage> Pretty sure I've built rails on shore before
08:31:07 <locosage> There was even a bug of them crashing into water sometimes
08:31:41 <wensimehrp> locosage: I remember somewhere in the forums or tt-ms there is a description about building railways on shores
08:33:13 <reldred> parallel to the shoreline is fine but I don't understand what they'd even want with perpendicular to the shoreline
08:34:24 <LordAro> reldred: we've never stopped users doing pointless things before
08:34:44 <locosage> with flooding though
08:35:09 <emperorjake> I swear I remember being able to do that but I fired up 0.4.0 and it wasn't allowed even back then
08:35:27 <emperorjake> maybe it was a bug that got introduced and fixed at some point
08:36:13 <locosage> btw, running one-way road into water works quite well as a griefing
08:45:36 <Eddi|zuHause> you can build rails to the shore if you bulldoze it and quickly build before it re-floods
08:51:11 <peter1138[d]> Yeah, so much work for something we thought nobody used ๐
08:51:30 <truebrain> I hope you are not talking about Linux ๐
08:53:05 <LordAro> Eddi|zuHause: as per the gif in the repo
08:53:16 <LordAro> which is mostly why i say it's actually a bug that needs fixing
08:53:32 <LordAro> there's no reason why there should be any difference between the two
08:54:01 <Eddi|zuHause> well, that's the same behaviour with flat ocean tiles
08:54:48 <Eddi|zuHause> and surely you don't want to allow building rails there
08:55:05 <truebrain> somewhat funny, it does help you cannot build rails like that for new people; as they most likely don't want to pay the bill to demolish the shoreline to find out the rail is not put on foundation
08:55:25 <truebrain> but what I hear LordAro say, we should fix you cannot build road like that ๐
08:56:24 <truebrain> or demolish the tile!
08:56:52 <LordAro> if people want to try to run their trains into the ocean, we should let them, imo
08:57:01 <truebrain> but they don't actually run in the ocean
08:57:10 <truebrain> for that we first need a patch that makes trains derail when they hit the end of the line
08:57:12 <LordAro> i know, but they should be allowed to find that out for themselves
08:57:13 <peter1138[d]> There's a bug, they can do ๐
08:57:52 <truebrain> so I first expect a PR to makes it possible to launch trains in the air and that there is no emergency stop at the end of the line
08:57:58 <truebrain> then we can make this change ๐
08:58:14 <peter1138[d]> RollerCoasterOpenTTD?
08:58:17 <truebrain> it is monday monday monday ooowwwwhhh
09:02:56 <peter1138[d]> Oh dear. Time to sign in again.
09:04:36 <truebrain> yeah .. I know the pain ๐ฆ
09:05:16 <peter1138[d]> And I had to put the heating back on, -2ยฐC :/
09:05:26 <truebrain> there is snow here!
09:05:57 <wensimehrp> Snow with rain this Wednesday. I hate that kind of weather
09:06:13 <wensimehrp> Dry snow much better
09:09:13 <peter1138[d]> Maybe I need to get one of these Zwift things.
09:15:01 <andythenorth> don't remove building on cleared coasts pls
09:15:07 <andythenorth> if that was the suggestion
09:17:08 <truebrain> wtf are those pipes .. lol
09:17:20 <truebrain> and they should be underwater
09:18:09 <peter1138[d]> Transport companies that branch out to oil pipeline construction...
09:18:49 <peter1138[d]> They probably 'own' the oil rig too, purely because they started trans...piping.
09:47:07 <peter1138[d]> 9:45 and already hunting for food...
10:48:05 <andythenorth> pipes are valid tansport ๐
10:49:02 <andythenorth> it was salmon on a slice
10:49:08 <andythenorth> and it might be More Coffee
10:49:38 <peter1138[d]> Coffee sounds reasonable.
10:53:37 <peter1138[d]> @openttd@fosstodon.org now has a whole 140 followers, despite not posting anything much.
10:58:34 <andythenorth> found a Dairy Milk with Daim bar in it
10:58:40 <andythenorth> it's not great TBH
11:00:31 <peter1138[d]> Followed by Simutrans, heh
12:05:40 <LordAro> computer crashed, i think that makes it lunchtime
12:36:21 *** jeanyves_32366 has joined #openttd
12:36:21 <jeanyves_32366> peter1138[d]: I am following and I am not a bot ๐
12:37:40 <peter1138[d]> That's what the bots always say!
12:49:08 *** D-HUND is now known as debdog
13:35:48 *** Smedles_ has joined #openttd
13:38:57 *** Smedles has quit IRC (Ping timeout: 480 seconds)
13:40:14 *** Smedles has joined #openttd
13:47:40 *** Smedles_ has quit IRC (Ping timeout: 480 seconds)
14:08:26 <FLHerne> Road vehicle movement code is one of the remaining areas of weird C code that no-one's touched for 15 years :-(
14:08:55 <FLHerne> manual bitwise hashing and all that
14:23:58 <peter1138> Are you toching it then?
14:42:35 <FLHerne> I'm trying to in a minor way, but there's a bit of a learning cliff
14:43:18 <FLHerne> (trying again to make road vehicles not lemming-queue onto partially blocked crossings)
14:46:08 <FLHerne> what exactly are the 'x' and 'y' coordinates used for location within a tile? pixels?
14:54:21 <xarick> that's when I touched, 2 years ago
14:54:59 <xarick> there was a PR for it, somewhere
14:55:06 <peter1138> It's the 16ths that limit 2x/4x zoom-in movement to discrete steps.
14:56:33 <peter1138[d]> Not to be confused with a Motorola 6809.
14:56:41 <peter1138[d]> Oh hey, I'm here again.
14:57:18 <LordAro> you've been here the whole time
15:37:29 <xarick> I'm wondering if I should store depot information
15:37:43 <xarick> in the water region descriptor
15:38:23 <xarick> only for performance reasons, but that might bite me in the back
15:51:34 <LordAro> xarick: i think you're losing the forest for the trees again
15:53:50 <xarick> I already made it store aqueduct bits
15:55:04 <xarick> it reuses traversability_bits
15:55:14 <xarick> expanded to 32 bits instead of 16
15:55:47 <xarick> there can be only one aqueduct crossing the edge
15:56:27 <xarick> resuses the same logic that's already in
15:59:52 <peter1138[d]> Oops, my cup of tea is cold ๐ฆ
16:13:56 *** alfagamma7 has quit IRC (Quit: User went offline on Discord a while ago)
16:15:00 <xarick> I noticed the original water region code doesn't give aqueducts the unique_label treatment
16:16:15 <xarick> unique label is for the same neighbour region
16:16:41 <xarick> but there can be multiple aqueducts going to different regions, and each would need its own unique_label treatment
16:22:35 <xarick> the way it is now, it's going to feed the pathfinder multiple times the same water region patch with the same label
16:23:28 <xarick> more nodes for no reason
17:08:05 <peter1138[d]> I broke it a bit.
17:09:50 <xarick> is it neighbor or neighbour?
17:24:58 <xarick> std::map std::pair or std::vector for what I wanna do
17:27:45 *** Wormnest has joined #openttd
17:35:45 <peter1138[d]> Ah I should've seen that too ๐ฎ
17:37:32 <peter1138[d]> xarick: It was never std::map, the comment doesn't say that it was.
17:37:48 <peter1138[d]> But also, the comment says why it is a vector.
17:38:20 <xarick> just wondering if he had dealt with aqueducts before
17:46:05 *** HerzogDeXtEr has joined #openttd
17:46:08 <xarick> what type of container do I need for
17:46:38 <xarick> hmm... I need something above std::vector
17:48:14 <xarick> I need a container containing unique neighbouring regions and each neighbouring region containing unique patch labels
17:49:43 <xarick> every neighbouring region that is added contains at least 1 patch label
17:50:36 <xarick> if I want to add the label, I have to add the region
17:50:45 <xarick> if it doesn't exist in the container
17:55:22 <peter1138[d]> Hmm... why are my zoomed out sprites corrupted... wonder if it's the encoder of the scaler.
17:59:01 <peter1138[d]> Hmm, floor vs ceil.
18:12:46 <peter1138[d]> I have TTD savegames here that load fine... o_O
18:15:47 <peter1138[d]> Don't think that would affect orders.
18:16:54 <_glx_> yeah didn't check the report ๐
18:17:35 <peter1138[d]> Hmm, current_order.type is 10, which is out of range.
18:22:49 <peter1138[d]> Oh, unless it's 'a'
18:24:07 <peter1138[d]> Hmm, front->tile == 0
18:25:31 <peter1138[d]> Think that's probably in the air, not actually loading.
18:27:33 <peter1138[d]> Says VEH_AIRCRAFT
18:39:28 <DorpsGek> - Update: Translations from eints (by translators)
18:43:12 <peter1138[d]> Looks like an out-of-order afterloadgame.
18:43:28 <peter1138[d]> Rework of orders happens in SLV 93
18:43:57 <peter1138[d]> Adding vehicles to st->loading_vehicles happens earlier SLV_57
18:44:26 <peter1138[d]> So aircraft is adding to the airport loading list in the section from 1598 to 1610
18:44:45 <peter1138[d]> Then the orders are fixed up from 1728 to 1758
18:45:27 <peter1138[d]> This seems to be not a new bug at all.
18:46:04 <peter1138[d]> Hmm, and changing it doesn't fix it, so maybe it's something else.
18:48:04 <_jgr_> There seems to be another issue that road type of road vehicle's tile checks in AfterLoadVehicles happen before road tiles are updated in the map array
18:48:37 <truebrain> right, done with one job, a day of coding. Now up to the next one ... debugging more SDL shit .. ๐
18:48:51 <_jgr_> Various stuff in AfterLoadVehicles look like they might do the wrong thing with the map not in a sensible state
18:49:20 <peter1138[d]> Hm, even after the order conversion the vehicle is set to OT_LOADING
18:49:23 <peter1138[d]> But it's in the air...
18:49:33 <truebrain> up in the air? ๐
18:51:27 <peter1138[d]> After finishing loading the z_pos switches from 9 to 118.
18:51:34 <peter1138[d]> And the order changes from OT_LOADING to OT_DUMMY
18:51:57 <truebrain> can't believe someone actually tries to load such old games ๐
18:52:27 <peter1138[d]> I wonder if it loads in TTD ๐
18:53:42 <peter1138[d]> Although it's TRP... is that a TTDPatch save?
18:54:14 <truebrain> never saw TRP before in the context of OpenTTD
18:54:22 *** gelignite has joined #openttd
18:57:01 <truebrain> I like step 1, like: I tested all TTD savegames in existance ๐
18:58:16 <truebrain> `-- SDL_X11_XRANDR (Wanted: ON): ON`
19:01:59 <peter1138[d]> The TTO one is an obvious bug now I see it though ๐
19:02:47 <truebrain> failing on map-size is a bit odd ๐
19:03:17 <peter1138[d]> I don't know why it worked.
19:03:29 <peter1138[d]> We try to allocate a map of 65536x65536 instead of 256x256
19:03:41 <truebrain> when did that break? ๐
19:04:50 <Rubidium> the TTO one is obvious, but there's another bug causing it to not open (yet)
19:05:23 <Rubidium> as in... working on it as I type
19:06:10 <truebrain> was I the one who broke it? ๐
19:07:18 <truebrain> now I feel less alone ๐
19:07:23 <truebrain> it feels like a bug I would introduce ๐
19:13:00 <truebrain> owh, lol, that "shares" fix
19:14:15 <truebrain> I should add fix numbers in those PR titles .. I always forget ๐
19:17:36 <truebrain> now for Wayland ... am I going to custom build wayland, and keep the old glibc, or am I going to go through the trouble of adding another linux-generic, with all the issues that come from that .. hmm
19:27:10 <truebrain> `openttd-linux-2020` and `openttd-linux-2014` good names? (instead of the current `openttd-linux-generic`)
19:27:30 <talltyler> Huh thatโs not a PR comment
19:27:35 <truebrain> so happy we have a hook on that crap ๐
19:28:09 <truebrain> I think you have to make a PR now to fix that talltyler ๐
19:30:55 <Eddi|zuHause> truebrain: linux-current and linux-legacy?
19:31:13 <truebrain> not against naming like that, honestly
19:31:34 <truebrain> makes it easier for people to understand what to download, I guess
19:31:52 <truebrain> just `legacy` might suggest to them that it is OpenTTD, and not Linux, it is referring to
19:32:21 <peter1138[d]> How does a user know what to download?
19:32:26 <LordAro> doesn't really matter as long as the description is suitable
19:32:47 <truebrain> peter1138[d]: that is not a simple question to answer, sadly
19:32:51 <truebrain> if `current` works, use that ๐
19:32:59 <truebrain> we can list some bigger distros
19:33:14 <truebrain> like: Ubuntu 22.04+ is `current`, and Ubuntu 20.04 is `legacy`
19:34:33 <Eddi|zuHause> alternatively just "linux" and "linux-legacy"
19:34:35 <LordAro> stable & oldstable :p
19:34:43 <truebrain> owh, but if you updated Ubuntu 20.04, it is fine again
19:35:30 <truebrain> Eddi|zuHause: the `legacy` is what I was having issues with; so that doesn't solve anything ๐
19:35:50 <Eddi|zuHause> "linux" "oldlinux" :p
19:36:13 <Eddi|zuHause> that sounds silly
19:36:20 <truebrain> ah, okay, the documentation of this manylinux container seems a bit off .. 18.04 doesn't work, but 20.04 works fine
19:36:31 <truebrain> anyway, I would have to check with the major names, see what version is for which
19:37:42 <Eddi|zuHause> tell them what actually makes the distinction?
19:38:03 <peter1138[d]> That actually sounds sensible :p
19:38:10 <truebrain> I wanna bet most users do not know what libc is; so that might be even more confusing
19:38:35 <LordAro> maybe that - use the same manylinux nomenclature and then expand the description as much as possible
19:38:55 <peter1138[d]> I think I need a separate sprite cache :/
19:39:30 <truebrain> alternatively, we could just drop this 2014
19:39:35 <truebrain> looking at the distros, they are all EOL
19:39:51 <LordAro> i would say too soon to drop it entirely
19:40:03 <truebrain> Ubuntu 18.04, Debian 9, FC34
19:40:36 <truebrain> LordAro: yes, but you literally always say that, like, no matter what ๐ Yet I and glx are the ones maintaining them ๐
19:41:01 <truebrain> but glibc 2.28 has been mainstream for a lot longer than I expected
19:41:16 <LordAro> didn't you say that 2.28 would exclude Ubuntu 20.04?
19:41:27 <truebrain> did you read anything I wrote in the last 10 minutes? ๐
19:41:44 <truebrain> to quote 5 minutes ago: `ah, okay, the documentation of this manylinux container seems a bit off .. 18.04 doesn't work, but 20.04 works fine`
19:42:25 <LordAro> because that's super clear what you're talking about :p
19:43:03 <truebrain> so, for the LordAro's among us: this new libc would be supported by Ubuntu 20.04+, Debian10+, Fedora 34+
19:43:06 <truebrain> does that help? ๐
19:43:57 <LordAro> ok, that's probably fine then
19:44:14 <truebrain> any arch installation of younger than 4 years
19:44:44 <truebrain> LordAro: ๐ฎ well, if even you agree ๐ Hihihihi, sorry, pulling your leg ๐
19:46:09 <truebrain> hmm .. bunch more libs would be included with this new version .. just not sure if they all should ...
19:46:13 <talltyler> truebrain: Making a PR is less work than making an issue, so I guess so ๐
19:48:04 <truebrain> ah, libgthread has more dependencies; fine, doesn't actually hurt
19:48:38 <peter1138[d]> Hmm, sprite cache pointer per zoom level...
19:48:57 <peter1138[d]> Although if I do that is there much point in a sprite cache...
19:49:27 <peter1138[d]> Aim: Support non-integer zoom levels.
19:49:49 <peter1138[d]> (In a less hacky way than I tried before :))
19:50:55 <talltyler> Now just one commit, for you Peter ๐
19:51:15 *** mryakov has joined #openttd
19:51:15 <mryakov> Hello, can somebody help with compilation, i successfully compile game itself, even with my changes. However, when i try to include tile_map.h, IDE says "cannot open source file "table/strings.h" (dependency of "tile_map.h")C/C++(1696)" and compilation failed with thousands of errors.
19:53:06 <truebrain> mryakov: bit confusing information; without your patch, the game builds fine, you say?
19:53:17 <truebrain> but when you modify it, you get that error? Where are you including `tile_map.h`?
19:53:44 <truebrain> anyway, `table/strings.h` is a generated file; so it is not in a common folder, but CMake takes care of that.
19:55:25 <talltyler> Speed demon over here!
19:55:35 <truebrain> not rocket science ๐
19:55:57 <LordAro> now do a full rebuild and test of everything
19:56:09 <mryakov> truebrain: I have custom_logic.h and custom_logic.cpp. And i can compile game with this files, and all work fine, even my own logic(at current stage it just print to console that all working)
19:56:09 <mryakov> However, if i include tile_map.h, no matter in cpp or h file, compilation break
19:56:58 <truebrain> did you follow how other files do it? Did you add it to CMakeLists.txt? Very hard to say without seeing code. Push your work to GitHub and we might be able to help more
19:57:04 <truebrain> but now it is just throwing dart in the dark ๐
19:57:28 <truebrain> it works in all the files in the current repository, so I would say: copy an existing file, and empty it
19:58:51 <xarick> question about parethesis
19:59:02 <xarick> return this->traversability_bits[side] & (1 << WATER_REGION_EDGE_LENGTH) - 1;
19:59:02 <xarick> return this->traversability_bits[side] & ((1 << WATER_REGION_EDGE_LENGTH) - 1);
19:59:34 <xarick> which one is better codestyle?
19:59:37 <LordAro> if you need to ask, you need them anyway
20:00:33 <andythenorth> I always over-use parentheses
20:01:08 <andythenorth> I had not one but several teachers who were firmly against bodmas etc
20:01:35 <andythenorth> and insisted that omitting parentheses caused errors in practical engineering useage
20:02:04 <Eddi|zuHause> there is probably a middle ground somewhere
20:02:07 <andythenorth> whereas some people prefer to optimise them away, probably to improve performance or something
20:02:31 <andythenorth> I imagine in a modern CPU and compiler that parentheses are a major source of slow
20:03:12 <_jgr_> For the really obvious cases it's generally fine to omit them
20:03:38 <andythenorth> I wouldn't be able to parse Xarick's first example reliably
20:04:03 <_jgr_> But in general no-one correctly remembers them whole operator precedence table for whatever language they're using at that moment
20:04:33 <locosage> c++ has some ridiculous operator precedence
20:04:51 <locosage> so I always put them with >> & | and such
20:05:23 <andythenorth> I thought all computers just implemented BODMAS?
20:05:44 <Eddi|zuHause> there's no & or << in bodmas
20:05:46 <andythenorth> doesn't it also cover logical operators?
20:06:21 <locosage> for / * + - sure, precedence is fine
20:06:40 <Eddi|zuHause> there's also no == in bodmas
20:06:52 <andythenorth> I never learnt it for some reason
20:07:02 <andythenorth> not sure why it was missed out in my school system
20:07:15 <Eddi|zuHause> nor are there any of the more crazy operators like ++,
20:08:13 <locosage> and that was before some madlad decided it's a good idea to use >> and << for i/o
20:09:13 <_jgr_> iostreams is not that widely used (fortunately)
20:09:23 <Eddi|zuHause> someone once told me what bodmas stands for, but nothing like that was ever taught in my language
20:09:34 <Rubidium> still, the computer doesn't need bodmas. It's so stupid it cannot handle more than one operator ;D
20:09:49 <truebrain> _zephyris: the `A` renders a bit weird with the font, they are almost eating the latter that follows ๐
20:10:15 <truebrain> even better example ๐
20:10:21 <Eddi|zuHause> we should all switch to reverse polish notation :)
20:10:26 <truebrain> seems the only letter that does so
20:10:28 <Rubidium> bisecting is soo much fun, when you need to patch out two other bugs each of the steps..
20:12:42 <locosage> omg c++ has cmp operator <=>
20:17:01 <Eddi|zuHause> locosage: so implementing a<=>b as b-a is valid?
20:18:10 <locosage> it almost feels like they wanted it just for operator overload, it's kinda hard to use <=> in actual expressions
20:20:53 <locosage> you can kinda do condition like `(a <=> b) * (c <=> d) > 0` but who's gonna understand that
20:21:07 <locosage> `(a > b) == (c > d) ` is far more readable
20:22:54 <Rubidium> isn't <=> purely so you only have to implement one comparator, and then the compiler can generate the 6 default ones from there?
20:23:58 <locosage> yeah, looks like that
20:26:18 <mryakov> truebrain: After some experiments I found, that if i include stdafx.h before tile_map.h, it would compile. So problem solved.
20:26:38 <truebrain> good to hear! And remember: always look at examples, they really help ๐
20:26:50 <truebrain> you will see all include-blocks start with `stdafx.h` and end with `safeguard.h`
20:27:16 <mryakov> Yea, my bad, initially i looked in h file, not cpp
20:27:29 <truebrain> no worries; ask anything else you run into ๐
20:32:15 <truebrain> feature or change .. hmm
20:32:35 <truebrain> /me forgot to assign meaning to dice-roll
20:32:44 <truebrain> euh, 1 = feature, 2 = change
20:33:16 <truebrain> LordAro: went with `linux-legacy` after all .. but `linux-generic` vs `linux-legacy` ๐
20:34:50 <truebrain> okay .. that should solve all open SDL / Linux issues ... pffffffff
20:43:14 <truebrain> As for the Social Integration .. some of you gave reviews, but do we all agree this is the way forward? I kinda miss not being able to poll devs .. does silence mean: sure? ๐
20:46:52 <truebrain> pitchfork PR approved!
20:47:03 <truebrain> let the plague commence !
20:48:17 <talltyler> truebrain: I am in favor of your approach. I havenโt spoken up because the code is above my head but it seems future-proof as far as Iโm concerned.
20:53:32 <_glx_> assumed the new file was a copy of the old one
20:53:44 <truebrain> I double triple checked; there are some minor changes
20:53:52 <truebrain> I now remember why I wanted to do 2 commits ...
20:53:58 <truebrain> but I changed the title, and there is a `sed` in there now
20:54:08 *** gelignite has quit IRC (Quit: Stay safe!)
21:00:09 <truebrain> sorry, had to rebase to remove that single commit
21:01:17 <truebrain> funny, the new linux container is a lot quicker ๐
21:01:23 <truebrain> owh, would it support node20?
21:01:52 <_glx_> just 4 chars to remove ๐
21:01:58 <truebrain> "easy", but yeah, let's test ๐
21:04:05 <truebrain> talltyler: what was the opinion of the players yesterday? Did they like the frozen calendar? ๐
21:04:47 <_glx_> ah yeah it also need a manual release run from the fork because it's the only way to actually test the new workflow
21:04:55 <DorpsGek> - Add: summary for week 02 of 2024 (by OpenTTD Survey)
21:05:26 <truebrain> I guess we keep legacy for the 14.X series, and drop it for 15 ๐
21:05:53 <_glx_> can we report libc version in survey ?
21:06:04 <truebrain> hmm .. good question
21:06:11 <truebrain> it isn't in there now, as it is not a direct dependency
21:06:33 <_zephyris> truebrain: Oof, that's not pretty. But I can't replicate it! Is that under Linux? Latest nightly?
21:07:03 <truebrain> Linux (well, WSL, but yes), and latest master
21:08:12 <truebrain> just odd it only does it with `A` ๐
21:09:48 <_zephyris> I bet that's it. The character width is 794 units instead of 800 (100 units = 1px).
21:10:18 <_zephyris> I guess that could lead to some weird (read: bad) hinting...
21:11:01 <truebrain> _zephyris: so something you could in theory fix? I am your guinea pig!
21:11:29 <_zephyris> Just checking for any other non multiples of 100 widths
21:11:38 <truebrain> okay, survey actually helped; over 50% of JGRPP players have the train stop in "middle". That is a large number of players ๐
21:11:56 <peter1138[d]> Might just be the default in JGRPP ๐
21:18:26 <talltyler> truebrain: Yes, people were generally in favor
21:19:04 <_glx_> I didn't pay attention to the calendar
21:19:19 <_glx_> except it wasn't moving ๐
21:19:24 <truebrain> if you didn't and you notice no issues, that is promising ๐
21:19:55 <_zephyris> truebrain: Have a TTF!
21:20:33 <talltyler> Besides the vehicle aging issue, of course ๐
21:20:35 <_zephyris> A few other characters were also off by up to 4 units: `'` `\` `โ` `โ` `,`. I guess similar loss of whitespace between characters might happen with those too, but'd be much less obvious. Comma `,` might be the best trial.
21:21:13 <truebrain> _zephyris: 100% better ๐
21:21:50 <truebrain> picture to proof it
21:22:12 <truebrain> the new `W` design will need getting used to
21:22:30 <truebrain> it is not bad; just different ๐
21:22:39 <peter1138[d]> It's actually pretty similar to the original W
21:23:16 <peter1138[d]> No, but OpenGFX's font is wrong ๐
21:23:19 <truebrain> _zephyris: it looks really good now ๐
21:23:36 <truebrain> peter1138[d]: I wasn't in the right or wrong business; just different. OCD ... takes time .. to get .. used to ๐
21:23:47 <truebrain> OCD? Just call it autism ๐
21:23:57 <truebrain> (not really, but you know)
21:24:04 *** nielsm has quit IRC (Remote host closed the connection)
21:25:26 <andythenorth> talltyler: there might be some issue with wallclock and GS dates, but I haven't had brain space to investigate, so this is a bit of a crap report sorry ๐
21:26:11 <FLHerne> re. the "middle" thing
21:26:34 <FLHerne> can we have a "middle at through platforms, far end in bays" option?
21:26:42 <FLHerne> it would look even nicer :D
21:26:49 <truebrain> if you would program it, I am sure we could!
21:27:57 <_jgr_> The near/middle/end setting is just the default, players can use whichever one works best for particular stations if they want
21:29:02 <Rubidium> FLHerne: that sounds like a really bad design choice. It should really look at where the actual station building and over/underpasses are and do it automatically and correctly ;)
21:29:24 <FLHerne> hm, it might be easier than what I'm trying to do now
21:29:35 <FLHerne> _jgr_: yeah, but I get tired of setting it :p
21:32:13 <xarick> I need to define an invalid WaterRegionPatchDesc for pathfinder reasons
21:33:22 <xarick> need to store in the path node the current and parent
21:34:10 <xarick> but the starting node has no parent, so I need a defined invalid WaterRegionPatchDesc
21:37:19 <_glx_> arrg, so much flood in my notifications (from the moved to discussion)
21:37:48 <truebrain> yeah ... still bullshit how GitHub handles that
21:38:37 <_glx_> oh it only shows the closed issue, but there are many of them
21:40:52 <truebrain> I also still can't believe that because someone random, not even a dev, made a project and dragged our tickets in there, every ticket mentions it
21:40:54 <peter1138[d]> Well `[]() { ... } ()` is a funny construct.
21:41:39 <_zephyris> truebrain: Ace. I'll do checks on the other fonts for similar potential issues.
21:43:24 <truebrain> so AlmaLinux, which now makes our linux-generic, doesn't seem to have a decor library for Wayland
21:43:31 <truebrain> curious how long it will take before we get bug reports about that ๐
21:43:56 <peter1138[d]> Aren't they provided by the system it's running on?
21:43:59 <_glx_> did it work with previous linux-generic ?
21:44:12 <truebrain> peter1138[d]: on all but gnome, internet says
21:44:20 <truebrain> _glx_: previous linux-generic had no Wayland support
21:45:02 <truebrain> it is such a stupid design choice to not have a fallback decor in Wayland itself
21:45:07 <truebrain> it is like .. wth are you thinking
21:45:07 <_glx_> so we fix one thing just to make our "customers" unhappy ๐
21:45:22 <truebrain> most distros will fix it
21:45:41 <_glx_> not the first weird decision I think
21:46:07 <truebrain> owh, it is in AlmaLinux 9, just not in AlmaLinux 8
21:46:13 <truebrain> but that gives options
21:46:23 <truebrain> vcpkg doesn't even have it! ๐
21:47:13 <Rubidium> I think #11786 is ready for review... for whoever dares to take a peek at it
21:48:04 <truebrain> some of those Codechanges are scary ๐
21:49:47 <truebrain> does this buy me a review token for the social integration PR? ๐
21:52:59 <truebrain> someone is more awake than I am!
21:55:02 <xarick> constexpr WaterRegionPatchDesc INVALID_WATER_REGION_PATCH = WaterRegionPatchDesc{ 255, 255, 255 };
21:55:52 <_glx_> wow TTDp hacks are scary
21:56:03 <peter1138[d]> Hmm, is programmatically creating a window instead of using an NWidgetPart array okay?
21:56:13 <truebrain> I went by the rule: if they load now, it is an improvement, so I am sure the code is okay. As I got nightmares ๐
21:56:30 <truebrain> peter1138[d]: aren't both programmatically? ๐
21:57:29 <truebrain> okay, manually installing libdecor is relatively straightforward; let's see if SDL picks it up
21:57:55 <peter1138[d]> I just can't see an obvious way to, e.g. "set all widgets to COLOUR_RED"
21:58:06 <peter1138[d]> As you have to understand the nested tree.
21:58:34 <truebrain> hmm, yeah, if you want to do it like that, that can be tricky ๐
21:58:44 <truebrain> guess templating it would be hard too
21:59:08 <xarick> region 255 255 exists in a 4096x4096 map, and although label 255 is theoretically possible, but not in reality
21:59:15 <peter1138[d]> Not sure I can template an array. Maybe I can.
21:59:40 <peter1138[d]> Oh, that reminds me ๐
21:59:46 <truebrain> `CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.`
22:02:28 <truebrain> peter1138[d]: glad it reminded you
22:03:19 <truebrain> `-- Package 'libdecor-0', required by 'virtual:world', not found`
22:04:02 <truebrain> hmm .. it also compile-time links against libwayland-client
22:04:38 <_glx_> missing sprites everywhere
22:05:30 <locosage> that's just some wrong offset on depot sprites
22:05:46 <locosage> that somehow corrupts them all even though there isn't a single depot on the map
22:06:27 <_jgr_> Corrupts the GRF file, or the memory state when the file is loaded?
22:06:56 <locosage> idk what it corrupts but if I remove depot sprites everything is fine
22:13:12 <locosage> oh, it wasn't even building what I thought it is so I've no idea what I even did there...
22:18:10 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:20:49 <truebrain> Fingerprinting .. Next stop, DRM! ๐
22:22:26 <locosage> it is quite a big problem though
22:22:50 <truebrain> I really hope 14.0 moves more BaNaNaS downloads over http so we are left with more funds to do cool stuff ๐
22:39:57 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:40:20 <locosage> talltyler: with logic :P
22:40:26 <locosage> don't let bomb houses in cb etc
22:41:35 <talltyler> Ah, so differentiating what's being bombed, not who's doing it
22:43:11 <peter1138[d]> Game scripts would need a redesign for that.
22:44:39 <peter1138[d]> TrueBrain probably has a patch for that.
22:44:41 <truebrain> It has nothing to do with GameScript. That is hammer->nail talking ๐
22:45:13 <truebrain> peter1138[d]: I do! ๐
23:25:25 <truebrain> pffff; just trying to align everything between different widgets is a pain in my ass
23:30:59 <truebrain> talltyler: I will make it so Steam is shipped with Steam, and Discord can be done via a DLC or something; need to figure out how that works, but that will be fine ๐
23:38:21 <reldred> Content downloader ๐
23:43:09 <truebrain> not sure what to think of it myself ๐
23:51:02 <truebrain> haha, funny, `-O1` does what I would hope it does, and unrolls the for-loop
23:51:50 <truebrain> euh, `-O3`, nasty typo
23:55:30 <truebrain> meh; I tried postponing it for as long as I could, but I guess we really do need to add some form of encryption to OpenTTD now .. as it is kinda a good idea to validate if the plugins are actually authored by us, just to avoid any weird abuse.
23:55:36 <truebrain> I was hoping this PR would be simple ... owh well ๐
23:55:51 <truebrain> no need to rush this, so it is fine ๐
23:56:13 <truebrain> and JGRPP already has some code for it, so maybe I can just use that ๐
continue to next day โต