IRC logs for #openttd on OFTC at 2023-11-03
⏴ go to previous day
00:08:23 *** Farrokh[m] has joined #openttd
00:20:46 *** patrick[m]12 has joined #openttd
00:22:37 *** FrenDianiel has joined #openttd
00:27:43 *** michi_cc[d] has joined #openttd
00:27:43 <michi_cc[d]> Win32 and OSX were easy and only took like 15 minutes. ICU on the other hand...
00:32:53 *** Elysianthekitsunesheher[m] has joined #openttd
00:47:00 *** FrenDianiel has quit IRC (Ping timeout: 480 seconds)
01:04:30 *** Eddi|zuHause has quit IRC ()
01:09:46 *** shedidthedog[m] has joined #openttd
01:45:51 *** Wormnest has quit IRC (Quit: Leaving)
01:48:44 *** menelaos[m] has joined #openttd
01:48:47 *** Eddi|zuHause has joined #openttd
01:58:20 *** igor[m] has joined #openttd
02:19:55 <Flygon> You make it sound like ICU took you to the ICU :P
03:17:50 *** pikaHeiki has joined #openttd
03:43:09 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:14:58 *** vista_narvas[m] has joined #openttd
04:32:00 *** hamstonkid[m] has joined #openttd
04:35:02 *** JamesRoss[m] has joined #openttd
04:51:28 *** patricia[m]1 has joined #openttd
05:26:56 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
05:35:17 *** zzy2357[m] has joined #openttd
05:44:12 <goddess_ishtar> this article is a trip
05:44:42 <goddess_ishtar> last updated 12 years ago, how times have changeed
05:54:38 *** Gadg8eer[m] has joined #openttd
06:09:04 *** emperorjake has joined #openttd
06:09:04 <emperorjake> That's for TTDPatch which is very different from OpenTTD internally
06:10:18 <emperorjake> OpenTTD's had things like larger maps and more airports since very early on
06:11:11 <emperorjake> I didn't even know that the joined stations thing was a limitation in TTDPatch
07:15:09 *** xyii[m] has joined #openttd
07:18:57 *** soylent_cow[m] has joined #openttd
07:28:50 *** freu[m] has joined #openttd
07:34:28 *** joey[m]1 has joined #openttd
08:08:19 *** amal[m] has joined #openttd
08:32:45 <peter1138> It's likely from before that date too.
08:33:27 <LordAro> TTDP has been dead for about 12 years, so likely
08:34:17 <peter1138> I miss those catching-up days.
08:36:09 <peter1138> CRT monitors, 32-bit CPUs and RAM was still measured in MB.
08:37:49 <LordAro> "Larger airports (more runways). It's possible, but would involve recoding the whole aircraft movement scheme of an airport, which not much is known about. This may be possible, but requires more time and effort than any patch developer is willing to spend at the moment."
08:37:55 <LordAro> well that's still true
08:38:57 <peter1138> We know how movement code works.
08:39:17 <peter1138> It's just not very flexible.
08:40:47 <peter1138> The structure is not very helpful, and the fact it is built into a different layout before it's actuallye used...
08:53:27 <peter1138> There are currently 155 WindowDescs defined. That means each time I add a unit test we get +155 results :p
08:54:08 <peter1138> The funny thing I was thinking about doing this, and wondering the best way to make register WindowDescs. And then it turned out they already are.
08:56:07 *** YungJudas[m] has joined #openttd
08:56:35 *** thelounge34 has joined #openttd
08:58:01 <LordAro> is there a way to get github to display unit tests "nicely", in some sort of table?
09:00:51 <peter1138> That would be useful.
09:01:53 <truebrain> You can do that as a comment (which only kinda works on failure, otherwise it is rather annoying) or in the CI results
09:01:53 <peter1138> --output-junit <file> = Output test results to JUnit XML file.
09:23:57 <peter1138> Yeah, that is not a comment :)
09:24:52 <peter1138> I assume some kind of matrix of test by platform is needed.
09:29:37 *** temeo[m] has joined #openttd
09:42:15 <Eddi|zuHause> one would assume in most cases if a unittest fails, it would fail on all platforms
09:44:52 <peter1138> That is definitely not the case for the regression tests.
09:47:12 <Eddi|zuHause> maybe i'm too naive :p
09:47:39 *** ahyangyi has joined #openttd
09:47:39 <ahyangyi> depending on what you are testing
09:48:18 <ahyangyi> for example, if you try to read "A.GRF" but the file is named "a.grf", you won't fail in Windows 😛
09:56:58 <peter1138> Mainly due to accidental undefined behaviour, so what happens depends on the compiler used.
09:57:32 <peter1138> (As opposed to deliberate undefined behaviour, where you get sent away and banned from ever contributing again)
09:58:07 <LordAro> *peter1138 = "i have a patch for that";
10:00:20 <ahyangyi> Well, it's undefined behavior, so the compiler might decide to ban the contributor regardless 😛
10:05:01 <peter1138> Hmm, seems it's not possible to scope using namespace :(
10:05:56 <peter1138> (`{ }` blocks are not allowed at file-level)
11:12:25 *** thelounge34 has quit IRC (Ping timeout: 480 seconds)
11:18:35 *** Bilb[m] has joined #openttd
11:27:01 *** thelounge34 has joined #openttd
11:38:43 *** rudolfs[m] has joined #openttd
11:39:47 *** georgevb has joined #openttd
11:39:47 <georgevb> variant_group Vehicle ID or alternatively the vehicle numeric ID (0 ... 65535)
11:39:47 <georgevb> Is there any value that can be used as "no group"? Like CB_FAIL?
11:48:43 <peter1138> The default value is INVALID_ENGINE which is 65535 / 0xFFFF. So you could set that, but there shouldn't be a need to that.
11:54:49 <georgevb> Thank you, I would prefer to use INVALID_ENGINE, because it clearly indicates the purpose, not just missing by accident.
11:55:23 <peter1138> Making your NewGRFs bigger, gotcha :)
11:55:43 <peter1138> `nmlc -O3` isn't a thing :D
11:59:38 <peter1138> Exactly, it is not a thing.
12:16:14 <peter1138> Although actually there's not much point in using a class for it..
12:23:42 <merni> Rubidium: Rubidium: Well, COMPILING.md states ICU is required to compile on Linux. Not even "encouraged" like liblzma :)
12:24:55 *** wormnest[m] has joined #openttd
12:30:12 *** jeremy[m]1 has joined #openttd
12:45:52 *** giords[m] has joined #openttd
12:46:52 *** virtualrandomnumber has joined #openttd
12:47:58 <peter1138> But it's okay, it gives me an excuse to update it.
12:55:26 *** CornsMcGowan[m] has joined #openttd
12:57:50 *** virtualrandomnumber has quit IRC (Quit: virtualrandomnumber)
13:17:15 *** magdalena[m] has joined #openttd
13:20:26 *** fiddeldibu[m] has joined #openttd
13:28:43 <peter1138> The Matrix slowly returns.
13:29:38 *** andythenorth[m] has joined #openttd
13:29:49 *** leward[m] has joined #openttd
13:44:51 <peter1138> andythenorth[m] *poke*
13:53:49 *** blikjeham[m] has joined #openttd
14:46:49 *** Wormnest has joined #openttd
14:51:22 *** Heiki[m] has joined #openttd
15:13:07 <peter1138> cargopacket.h:315 vs cargopack.cpp:228
15:13:13 <peter1138> Parameters are swapped.
15:20:20 *** karoline[m] has joined #openttd
15:25:59 <truebrain> are they actually swapped? Or just poorly named? 😄
15:27:06 <peter1138> truebrain, well, the names are inverted :)
15:27:15 <truebrain> yeah, but that is just that: names 🙂
15:27:27 <truebrain> it is only a problem if the users of that function have a different opinion on what merges in to what 😛
15:27:49 <peter1138> Sure but the function itself has a different opinion on that.
15:28:45 <truebrain> well, that is my question .. see, `cp` vs `icp` .. if you just "fix" it in the header-file, nothing actually changed 😛
15:29:32 <truebrain> all callers use icp / cp, so yeah, nothing broken; just headers being headers 😛
15:29:41 <truebrain> only for 24 hours 😛
15:32:25 <truebrain> their "main" DC had a power failure
15:32:35 <truebrain> and as it turns out ...... they are not as decentralized as they suggest they are 😛
15:32:42 <truebrain> their "brain" is all located in that one DC
15:33:22 <truebrain> And seems failover was never properly tested on this scale 😛
15:37:01 *** talltyler has joined #openttd
15:37:01 <talltyler> (just a rebase to re-run checks)
15:38:20 <LordAro> "Email Noticatifications: Emails updates from Cloudflare are being delayed or not sent"
15:38:45 <LordAro> some prime panicked update writing there :)
15:40:13 <truebrain> yeah ... I can imagine them being a bit ... stressed 😛
15:40:46 *** SergioMassa[m] has joined #openttd
15:41:20 *** FelixActually[m] has joined #openttd
15:45:42 <truebrain> hmm .... downloading stuff with 900 Mbps from Steam
15:45:48 <truebrain> something I cannot stop not enjoying
15:46:04 <truebrain> still, downloading games takes ... 5 minutes
15:46:31 <merni> If only all games were openttd :p
15:46:53 <merni> truebrain: If I had 900 mbps speeds I would not stop enjoying a lot of other things :P
15:47:15 <merni> Firstly being able to stream videos in 1080p without lag
15:48:05 <truebrain> I wonder if I should try to get OpenTTD on the GeForce NOW
15:48:09 <truebrain> just because it sounds funny 😛
16:00:10 *** thomas[m]1234567 has joined #openttd
16:21:35 *** citronbleuv[m] has joined #openttd
16:56:51 *** _zephyris has joined #openttd
16:56:51 <_zephyris> 100%, got to get OpenTTD running on those sweet, sweet cutting edge GPUs
16:57:45 <_zephyris> ... not that I need it [gpuflex.png]
16:59:51 *** alfagamma7 has joined #openttd
17:00:20 <alfagamma7> It's a pain to make it work in Linux
17:02:08 <_zephyris> Yeah... It's supposed to be in a linux server right now, but stupid opaque driver/cuda/pytorch version incompatibilities
17:19:06 *** elliot[m] has joined #openttd
17:22:18 *** HerzogDeXtEr has joined #openttd
17:38:26 *** jact[m] has joined #openttd
17:46:27 *** philip[m]123 has joined #openttd
17:47:37 *** kstar892[m] has joined #openttd
18:01:35 <peter1138> Is it? I didn't get that memo...
18:05:23 <peter1138> Hmm, is everything in tests/ included in a normal build too?
18:07:40 <peter1138> Ah no, add_test_files is not add_files :-)
18:12:01 *** gelignite has joined #openttd
18:32:01 *** einar[m] has joined #openttd
18:38:58 <DorpsGek> - Update: Translations from eints (by translators)
18:45:39 *** gretel[m] has joined #openttd
18:46:48 <talltyler> Hmm, GitHub is somewhat down form e
18:47:07 <talltyler> Right when I want to open an exciting new PR too 😛
18:47:24 *** emilyd[m] has joined #openttd
18:48:01 <peter1138> Is it on Cloudflare too?
18:49:32 <talltyler> I was just getting GitHub's 404 page
18:51:11 <peter1138> Phew, I've managed to mock the spritecache without dumping lots of extra into the main source.
18:54:32 <peter1138> Run it on someone elses computer, they said...
18:54:39 <talltyler> It's finally time for NotDaylength ... as soon as I can open a PR for it 😄
18:55:00 <talltyler> It's built atop two big PRs, but is actually only one commit itself
18:55:19 <peter1138> Thwarted by Github.
18:58:01 <talltyler> Time for a snack while I wait
19:06:22 <truebrain> so you raged and deleted the whole repo? Makes sense 😛
19:08:16 <truebrain> according to their status page, they fixed Slack, so now everything else is broken 😛
19:11:47 <talltyler> If I had permissions to delete the OpenTTD repo, that's your fault 😛
19:12:21 <peter1138> andythenorth would've done it long ago :-)
19:16:19 <talltyler> Ugh, I should add a compatibility layer for scripts...that sounds annoying :/
19:22:03 <peter1138> Hmm, is it possible to have a game with no cargo types...
19:27:25 <talltyler> Peter: If you disable all cargo types you get a CTD, reported as #9545
19:27:43 <talltyler> (not because I think it should be possible, but because it should give an error instead of crashing)
19:47:17 <peter1138> Ooh there's a GRF I can test with :-)
19:47:38 <peter1138> My next WindowDesc unit-test fails because there's no cargos defined...
19:48:54 <peter1138> It's simple enough to fix but adding a check just becuase of unit-tests seems a bit weird.
19:49:44 <talltyler> Ha, now there's a ticket you can close!
20:01:40 <jfs> I still think a setting in % is the wrong way to set speed of calendar progress. It flips the scale on its head and makes the generally most useful side limited in precision, while making the less useful side too high precision on a scale it can't actually fulfill.
20:01:40 <jfs> Expressing the calendar progression speed in time units per day, or maybe per year, makes the scaling of the sensible option values linear and gives precision where needed. The only thing then is expressing the setting value of "frozen calendar", which could still use the zero value as a sentinel, but is probably better managed by a separate checkbox in the UI and a separate setting value, so the
20:01:40 <jfs> player could also "pause/unpause" calendar progression.
20:03:53 *** nolep[m] has joined #openttd
20:04:50 <talltyler> It's just a question of what to replace it with, which is hard to wrap my brain around sometimes
20:07:10 <talltyler> Real minutes per year? That would be a default of 12, and would allow the player to put in whatever they want. I think most people can easily do a conversion of minutes to hours if they want to greatly slow it down
20:08:27 <goddess_ishtar> decoupling game time from everything sounds great
20:08:49 <goddess_ishtar> seems like it would make timetabling much easier ;p
20:09:31 <talltyler> Timetabling moves to real seconds in #11341
20:11:15 <goddess_ishtar> speaking of, did they remove minutes and hours for timetables? when I tried it the game had it in days
20:11:32 * Rubidium wonders about the implications of real minutes per year. Would be weird when calendar time progresses equally fast for say Wentbourne when it's a relase build without assertions vs a debug build without optimisations :D
20:14:52 <talltyler> goddess_ishtar: JGRPP does its own thing with timetabling, making up its own game minutes and hours which are connected to neither game days nor real-world time. It's sort of a mess, which is why my approach is totally different 🙂
20:15:36 <talltyler> Rubidium: It's not actually real minutes per year, it's "real minutes per year if the computer runs OpenTTD at full speed". Wentbourne would just slow down as usual.
20:16:37 <talltyler> There's a caveat about this in the Real-Time Mode helptext 😉
20:18:00 <_glx_> talltyler: I think we are not that many to have access to the red buttons
20:18:38 <talltyler> WTF is wrong with CI, it's now failing on `error: no member named '_settings_game' in the global namespace` on #11428
20:19:04 <talltyler> But it works fine on #11341, with the exact same code
20:19:56 <talltyler> #11341 works fine, #11428 is based on it and doesn't touch the file that fails
20:20:23 <_glx_> can be indirect stuff too
20:21:09 <goddess_ishtar> what's the conversion factor between the "km/h" the game claims and the actual "tiles/day"?
20:21:48 <talltyler> Oh, I see how they're connected but not why it fails
20:21:50 *** gelignite has quit IRC (Quit: Stay safe!)
20:22:39 <talltyler> Possible circular dependency or something
20:23:52 <talltyler> Absolutely not a case of PEBKAC
20:24:02 <_glx_> at least all compiler agree on this one
20:24:27 <talltyler> It would be an indirect circular dependency, but still...
20:26:31 <talltyler> No, timer_game_calendar.h needed access to DAY_TICKS in timer_game_ticks.h, and that's the file where the error was occurring
20:26:40 <peter1138> goddess_ishtar, "yes"
20:27:24 <talltyler> Heh, on #11429 Peter apparently isn't building on OSX and cppcheck doesn't know to look there 🙂
20:27:29 <_glx_> ah yes, probably a header requiring another header to be included before it
20:27:39 <goddess_ishtar> if you take the numbers at face value, cities must be huge if driving down the block at 50km/h takes 10 days
20:28:04 <talltyler> Oh, that's an interesting and incredibly stupid failure mode
20:28:06 <_glx_> we have some hell with headers
20:28:09 <goddess_ishtar> it's pretty silly, even though I know it's a game abstraction
20:28:44 <peter1138> Hmm, did I do one too many? I thought I did a search on everything...
20:29:33 <peter1138> Ah maybe I did that one by reference, and even VS Code doesn't show that.
20:29:45 <peter1138> "wtf is a .mm file" ;)
20:30:26 <goddess_ishtar> so correct me if I'm wrong, but the purpose of the branch is to completely decouple the economy from the calendar?
20:30:29 <_glx_> improvements on #11428 but still fails
20:30:40 <talltyler> Yes, now that's a missing header 😉
20:30:58 <goddess_ishtar> Production, cargo payment, and everything else would have to be changed to have their own separate units then wouldn't they?
20:31:24 <talltyler> Interesting that it builds fine locally on Windows, there must be some OS-specific weirdness happening
20:31:34 <peter1138> Trunk-based development would be... well, that was committed, now we have to revert... and it's recorded forever.
20:32:24 <goddess_ishtar> What would the units for economy time be called?
20:33:08 <talltyler> Economy days, months, and years. Outside Real-Time Mode they mirror calendar days/months/years perfectly, so they need to act the same way
20:33:47 <Rubidium> peter1138: those .mm files are Objective-C++
20:34:11 <peter1138> Rubidium, I was paraphrasing cppcheck and my VS Code :)
20:34:14 <_glx_> weird syntax but can call C++ stuff 🙂
20:34:25 <goddess_ishtar> Wouldn't that lead to a lack of sync between the economy and calendar dates?
20:34:59 <talltyler> In Real-Time Mode, yes, they are decoupled entirely
20:35:18 <peter1138> Yes, the kinda the point.
20:35:52 <_glx_> yeah the split is the most clean implementation
20:36:19 <talltyler> Economy time always ticks along at the usual rate, controlling finances, vehicle breakdowns/maintenance, etc. Calendar time is only for technology (new vehicles, building appearance) and variable snowline, and can be sped up or slowed down, or even frozen entirely
20:36:26 <_glx_> else you have to take care of a lot of thing when changing day length
20:38:30 <goddess_ishtar> yeah, but it might be confusing to have two different dates in the same units
20:38:54 <talltyler> The player never sees economy units
20:39:19 <talltyler> Because the second trick is that the user interface shows real time units, so seconds and minutes
20:39:49 <talltyler> One economy day is two seconds so an economy month (always with 30 days in Real-Time Mode) is one minute
20:40:51 <goddess_ishtar> And the economy calendar is always proceeding at the fixed 2 seconds per day?
20:45:50 <talltyler> _glx_: #11428 is still failing on Emscription and MacOS but builds locally and on Windows CI... any ideas?
20:50:32 <_glx_> hmm it fails at link time, so maybe something is wrong in the way `CalendarTime` stuff is declared/defined
20:51:51 <goddess_ishtar> talltyler: if I have it right, then that's 12 real-time minutes per economy period, right?
20:51:58 <goddess_ishtar> or "economy year"
20:52:35 <goddess_ishtar> oh yeah it says further down in the PR
20:57:03 <goddess_ishtar> and the start date for timetables, instead of being synced to calendar dates ("start at 1/5/1960") are synced to real time intervals ("start in 90 seconds from now")?
20:58:54 <goddess_ishtar> which still lets you do autospacing and complex synchronization of several vehicles' timetables (say, for a bus that holds for a connection from a train)
20:59:40 <goddess_ishtar> That's actually pretty clever
21:00:01 <goddess_ishtar> because we naturally think of timetables as intervals anyway
21:00:36 <goddess_ishtar> it does prevent you from doing clock face scheduling the same way as irl, but I'm not sure if that actually matters much
21:01:32 <talltyler> Yeah, I use timetables in both vanilla and JGRPP and seconds make it easier to do almost clockface scheduling. Just have a vehicle with your maximum interval (say 60 seconds) ping-ponging between two stations somewhere, and use it as your reference point
21:02:03 <goddess_ishtar> you'd have to sync the periods of all your vehicles I think
21:02:46 <goddess_ishtar> but then I think you have to do that already, just in days
21:03:47 <talltyler> It's currently not really feasible because months have different lengths
21:04:02 <talltyler> So you'd have to do lots of calculating, or start everything at the same time
21:05:49 <talltyler> _glx_: Yes, the problem seems to exist only in settings_table.cpp, and I'm not sure why... or maybe it just gets processed and fails first
21:10:21 <goddess_ishtar> How does the current JGRPP daylength patch work then? My understanding is that it slows down the economy relative to the calendar, not the other way around
21:15:48 <goddess_ishtar> right so that's what I'm thinking of
21:15:48 <goddess_ishtar> in JGR production is synced to calendar time instead of real time, so the economy is proportionally slowed down compared to vehicles
21:16:39 <goddess_ishtar> which isn't the case in NotDayLength, since everything bar tech progression, seasons, and inflation is synced to economy time (and therefore real time)
21:18:55 <talltyler> Daylength in JGRPP doesn’t split time into calendar and economy clocks, it slows everything down and then compensates by boosting other things back up, like house and industry production. Vehicle movement is not based on calendar time so they aren’t affected, of course
21:19:33 <goddess_ishtar> that sounds like a mess
21:21:52 <goddess_ishtar> all this to say: will there be an option to slow down different timers relying on the economy clock relative to each other?
21:22:24 <talltyler> Not sure what you mean here
21:24:18 <goddess_ishtar> I know some people like playing JGRPP daylength because it slows down industry production and town growth relative to vehicle speed and running costs and I was wondering if this can be replicated in NotDayLength or if it's beyond the scope of the project
21:25:38 <talltyler> Because as you say, that is the other half of why people play with DayLength in JGRPP
21:26:52 <talltyler> talltyler: I guess it doesn't really matter for now, since I'll be redoing the units anyway and perhaps the bug will go away in the course of the redesign. A problem for tomorrow, though!
21:33:11 <goddess_ishtar> talltyler: This slows down production relative to real time (i.e. less production per economy day) and keeps the 2s/economy day conversion constant, right?
21:37:36 <goddess_ishtar> goddess_ishtar: yes it does
22:01:46 *** tokai|noir has joined #openttd
22:01:46 *** ChanServ sets mode: +v tokai|noir
22:08:48 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:20:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
23:13:38 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
