IRC logs for #openttd on OFTC at 2023-08-09
⏴ go to previous day
00:00:31 <leothejewishturtle> thank you, i shall scower the forums until i have another question lol
00:05:52 *** Kitrana1 has joined #openttd
00:07:04 <leothejewishturtle> where would the code be for the windows? would you recomend looking on my local files or on github?
00:08:33 <leothejewishturtle> am i at the right location? lol
00:09:50 <peter1138> You'd need to download the source, via git. or you could view directly on github.
00:10:30 <leothejewishturtle> what is the differnce between the souce and what i have now? should i uninstall from steam and reinstall from git?
00:12:45 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
00:22:03 <FLHerne> leothejewishturtle: source code is lots of text, mostly in the C++ programming language
00:23:02 <peter1138> Don't uninstall from Steam. That's the game that you play. The source is the code behind the that is compiled to the game.
00:23:33 <FLHerne> although as peter1138 says, downloading via git will make life easier if you start making changes
00:24:24 <FLHerne> the source code is 'compiled' into an executable program that can actually be run
00:25:40 <peter1138> For now it's probably easiest to view via github. You can download but to build you need to set up a fairly complicated environment to do that.
00:28:43 <leothejewishturtle> Ok it's kind of starting to make sense. So the compiled files are what's on my local files. If I wanted to edit the current financial window i would have to un-compile the right files and rewrite the code in like an IDE and then recompile and put them back in the right directory?
00:28:59 <leothejewishturtle> and thank you tyler, I am going to check that out
00:29:25 <peter1138> Well, you don't un-compile, you just get the source which hasn't been compiled yet 🙂
00:29:31 <peter1138> But otherwise, yes.
00:30:36 <leothejewishturtle> ok awesome, that makes sense. Should've learned C++ instead of python lol
00:34:03 <debdog> well, the real challenge is being able to read, understand and modify the compiled binary
00:39:52 <leothejewishturtle> i think the bottom of the computational stack is the most interesting anyway, its just all the fun stuff is at the top. Playing through Turing Complete blew my mind when I got to code in binary on a computer you built from logic gates and it actually made sense
00:41:11 <leothejewishturtle> not only could you code in binary, but you could change the hardware to alter what order of bits called for what operation. If you haven't played it I would highly recomend
00:42:31 <leothejewishturtle> Where i get lost is with all the BIOS and OS stuff. When its a basic ALU it makes sense but I dont understand all the layers up to a running game on an OS like OpenTDD
00:45:38 <debdog> leothejewishturtle probably is an electronics technician or such
00:57:01 <leothejewishturtle> I'm honestly honored you think that lol, I'm going to school for business (energy/finance, that's why I love OpenTDD and want to make the economy system more in depth) but I swear in another life I was a Computer Science major
01:05:50 <leothejewishturtle> It's been a long term goal of mine to understand the full computational stack. OpenTDD seem like a great place to start learning code, files, networks/servers, OS, etc. Everyone here has been super helpful and knowledgeable so I might actually follow through with learning and implementing this. I have like a million ideas for how the economy could be added to/improved
01:09:52 <debdog> good thing we've open source kernels and operating systems. this way folks like you are able to have a look behind the curtains
01:22:52 *** Kitrana has joined #openttd
01:28:26 *** Kitrana1 has quit IRC (Ping timeout: 480 seconds)
01:29:20 *** Kitrana1 has joined #openttd
01:33:04 <leothejewishturtle> Exactly. I probably wouldn't fuss with any other structure of game even if I could. I understand the accessibility and ease of AAA games, consoles, Apple products, etc. but they disconnect users from the real beauty of their product imo. I guess that's sometimes the goal of these larger organizations, as if allowing consumers to think will scare off profits
01:34:38 <leothejewishturtle> That might be overly political but idk, dev teams and games like this are cool as fuck in comparison lol
01:35:23 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
01:35:32 <debdog> s/sometimes/probably always/
01:45:22 *** Kitrana has joined #openttd
01:52:20 *** Kitrana1 has quit IRC (Ping timeout: 480 seconds)
01:56:23 *** Kitrana1 has joined #openttd
01:57:58 *** Wormnest has quit IRC (Quit: Leaving)
02:02:53 *** Kitrana has quit IRC (Ping timeout: 480 seconds)
02:03:31 *** herms has quit IRC (Quit: bye)
03:01:35 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:06:58 *** D-HUND is now known as debdog
07:58:27 <LordAro> locosage: yeah, "you guys"
08:56:02 <jorropo> FLHerne: I'm trying multiagent pathfinding, right now I'm using YAPF in flat junction network and the entry and exit of my stations is constantly getting it wrong, one train will be greedy and do a big sweeping arc around a train that is leaving.
08:56:02 <jorropo> While if it just waited a tiny bit 4 trains could go at once.
08:56:55 <jorropo> I'm realising this is harder than I expected since the current API isn't setup for it, I need to maintain global state in the game and modify routes as conflicts are detected.
08:58:41 <FLHerne> That sounds interesting, but I can see it being tricky
08:59:37 <jorropo> You can't do good multiagent path finding at large scale since it's equal to solving the tsp or backpack problem.
08:59:37 <jorropo> So the goal is to have a ~5 reservation "future buffer" and to use NPF or YAPF for the rest.
09:03:59 <FLHerne> Rail tiles have quite a few bits to spare, I wonder if tracking how frequently they're contended and altering the PF cost accordingly would work
09:04:48 <FLHerne> it would be a lot simpler than real multi-agent PF I think
09:28:13 *** milek7_ has quit IRC (Remote host closed the connection)
09:54:41 <jorropo> basically I uesd to have a situation like this the train on the top right want to go down right, and the train in the station second platform starting from the left wants to go down right too
09:55:50 <jorropo> instead of having the train from the right use the inner two track and the train on the left use the outer one
09:56:54 <jorropo> I get it's quite hard but this solves many other situations like merging two lines into one, a faster train behind a slow one.
09:56:54 <jorropo> Basically it would understand that speed is valuable and would slow down trains so that they reach signals when they turn green with speed
10:23:09 <FLHerne> I'd like this but it sounds difficult to achieve
10:26:00 <FLHerne> it adds a bit more lookahead to train path reservations which might be somewhat relevant
10:35:53 <jorropo> I have seen it, I've tried it and I found it made the game much harder which is cool but not really what I'm after.
10:35:53 <jorropo> Trains do reserve ahead but I havn't found them to unreserve or change their decision based on other trains.
10:35:53 <jorropo> The theory is that the train in the station would reserve the shorter path but remember the very sligthly longer path that takes the outside track, then when then when the presimulation realise the other train would like to go it's able to move the first train from the inner track to the outer track.
10:37:17 <jorropo> Maybe I'm wrong and this patch is smarter, overall it made the game harder than I wanted and turned off quite quickly.
10:38:24 <Eddi|zuHause> my immediate thought is that this will be impossible(tm) because you'll constantly fight against overcorrecting...
10:39:11 <Eddi|zuHause> "if i tweak it so situation X gets better, situation Y gets worse"
11:12:00 <truebrain> I made some changes to how wiki.openttd.org is served; there is a lot more caching going on now, which should improve how the site looks&feels. But as with any caching .. I might have made mistakes 😄 So let me know if you see something weird that wasn't there before 🙂
11:14:35 <truebrain> as an extra bonus, changing images should now be visible a lot quicker 😄 Only one person ever reported having an issue with the old system, but still 😛
11:22:20 <jorropo> You are right this is a pain point, I already wrote code for doing something similar in a totaly unrelated environment.
11:22:20 <jorropo> You "just" end up with `O(2**N)` code.
11:22:20 <jorropo> To make it realisticall there are tricks where you can isolate different contention points and limit the search. I'm not after a mathematically optimal solution, something limited that can solve trivial things would be good.
11:40:24 *** VincentKadar[m]1234 has quit IRC (Quit: Client limit exceeded: 20000)
12:02:47 *** peter1139 has quit IRC (Ping timeout: 480 seconds)
13:24:47 *** eirc has quit IRC (Ping timeout: 480 seconds)
13:30:11 <_glx_> first test being to disable the workaround for 17.6.5 (it still is broken)
13:35:06 <talltyler> Issue tracker tidied 👍
13:36:41 * pickpacket read that as ”issue tracker died 👍”
13:37:46 <talltyler> Goodbye hard-to-fix bugs and feature requests in the wrong place 😛
14:01:06 *** peter1139 has joined #openttd
14:20:49 <truebrain> meh; caching is not populating at a rate I would like ... I hate cold caches .. it takes to darn long ...
14:21:27 <truebrain> about 50% of the traffic is now cached .. and that after 3 hours ... GO FASTER
14:21:42 <alfagamma_0007> update needed?
14:22:13 <truebrain> (mainly as that 50% of the requests is only 20% of the bandwidth)
14:22:32 <alfagamma_0007> What's the remaining 80
14:22:58 <alfagamma_0007> Lot of work to do huh
14:23:05 <truebrain> no; caching happens
14:23:50 <truebrain> some images on our wiki are also really big 😛
14:25:43 <andythenorth> Run a crawler over it :p
14:25:50 <alfagamma_0007> That's pretty mid for an image but ok
14:32:27 *** esselfe has quit IRC (Remote host closed the connection)
14:35:50 *** esselfe has joined #openttd
14:36:11 *** peter1139 has quit IRC (Ping timeout: 480 seconds)
14:39:30 *** peter1139 has joined #openttd
14:50:16 <_glx_> and I can confirm the compiler bug is fixed (finally)
15:11:05 <_glx_> almost 1 year for a fix, at least they provided a workaround 🙂
15:11:36 *** Wormnest has joined #openttd
15:49:43 <leothejewishturtle> I've found some locations for the company Financials window source code and I'm ready to start tinkering around with it, but a couple questions have come up:
15:49:43 <leothejewishturtle> 1) How do I know which files get compiled where (I think I'll be working primarily in src)? Is it all compiled to the openttd Application .exe file?
15:49:43 <leothejewishturtle> 2) Do I need to delete this file every time I make an edit and recompile from the edited source code?
15:49:45 <leothejewishturtle> 3) How do I recompile from the edited source code?
17:01:23 *** peter1139 has quit IRC (Ping timeout: 480 seconds)
17:11:52 *** gelignite has joined #openttd
17:35:38 *** argoneus has joined #openttd
17:41:05 <FLHerne> leothejewishturtle: (1) yes (2) CMake will overwrite it in the build directory (3) see _glx_'s link
17:44:39 *** peter1139 has joined #openttd
18:03:24 *** peter1139 has quit IRC (Remote host closed the connection)
18:04:41 *** peter1139 has joined #openttd
18:40:31 <DorpsGek> - Update: Translations from eints (by translators)
19:16:59 <talltyler> michi_cc[d]: In my ongoing work to add calendar time scaling (NotDayLength), TrueBrain requested that I resolve some tech debt before continuing, including switching linkgraph updates to proper timers. I've been trying to wrap my head around how this works and how to do it with timers, and...failing. Do you have any interest in helping out by tackling this? I am hoping to get everything done by
19:16:59 <talltyler> Christmas for a 14.0 release, if being able to play with the feature is any incentive. 🙂
19:22:32 <michi_cc[d]> I'm not sure the assumption that I understand this stuff is valid though. 😆
19:22:58 <talltyler> Didn't you write linkgraph, or am I mistaken there?
19:23:11 <michi_cc[d]> No, that was fonsinchen
19:23:47 <michi_cc[d]> I wrote the never-finished alternative 😛
19:23:52 <talltyler> Is there anyone still active who understands it?
19:24:50 <michi_cc[d]> I'd actually guess that JGR understand the most by now, just by having made changes to it.
19:26:20 <talltyler> Heh, it's a pity that my new feature will be a huge PITA to integrate or work around with JGRPP, so there might be a dis-incentive to help 😛
19:27:01 <Eddi|zuHause> when we said "we can release as often and whenever we like", how did that end up as "we just move april 1st release to christmas release"?
19:27:35 <talltyler> If I can get it done sooner I'll write a changelog sooner, but it seems like a good timeline for the amount of work remaining 🙂
19:27:50 <_glx_> because someone still needs to do the administrative stuff and push a button
19:28:22 <_jgr_> talltyler: I doubt that it will be such a huge issue
19:29:16 <_jgr_> You don't need to understand the vast majority of the link graph code just to tweak the scheduling
19:30:08 <Eddi|zuHause> _glx_: well, i guess that's how this world works, people make extensive claims on how radically different things will be now. and in the end it's just a miniscule superficial change :p
19:31:29 <_glx_> oh pushing the button is the easier part
19:35:18 <talltyler> _jgr_: I suppose, although I suspect it's more of a rewrite than a tweak
19:35:31 <talltyler> I'm not sure how to do it with timers
19:36:02 <talltyler> There would be potentially thousands of links, right? Too many to each get their own timer?
19:36:55 <_jgr_> If timers are not the right abstraction, you don't have to use them
19:37:38 <_jgr_> Presumably though, the only thing that you need to worry about are when to merge jobs, and the units for things like the compression date
19:38:45 <michi_cc[d]> A timer per link doesn't sound very useful. Besides the merging, the other things stale link timeouts and a simple timestamp (like it is now) seems to fit much better.
19:41:05 <talltyler> Maybe truebrain can elaborate on his request for a timer? 🙂
19:41:42 <truebrain> did I request a timer? I think I only mentioned it needs looking into 😄 Having it on the calendar tick, as it is now, will be silly after your change 😛
19:41:50 <michi_cc[d]> Well, one timer is useful, after all the updates are peridoically triggered.
19:42:03 <truebrain> from what I always understood, we just want to update links "once in a while", so it should be real-time something? 😄
19:42:53 <michi_cc[d]> Link update interval is (or should be) related to vehicle movement speed and cargo generation interval.
19:44:10 <michi_cc[d]> Well, cargo flow update actually. The link graph itself is "static" if orders/vehicles don't change.
19:44:52 <talltyler> The relationship is so it follows fast-forward?
19:45:20 <_jgr_> Whether the game is fast-forwarded or not should have no effect on the game simulation
19:45:42 <_glx_> aren't links synchronized too ?
19:46:03 <michi_cc[d]> Whole link graph/cargo flow is part of the lock-step simulation, yes.
19:46:08 <truebrain> what would be nice in the linkgraph code, if we can do away with the module stuff etc .. it is just a bit quirky to understand what it actually does, and if we make timers strong typed, that will require weird casts. But that is a nice-to-have, nothing else 🙂
19:47:12 <talltyler> Are you talking about strong typed timers, or dates?
19:47:16 *** nielsm has quit IRC (Ping timeout: 480 seconds)
19:47:35 <truebrain> `TimerGameEconomy::date % (_settings_game.linkgraph.recalc_interval / SECONDS_PER_DAY) == (_settings_game.linkgraph.recalc_interval / SECONDS_PER_DAY) / 2`
19:47:42 <truebrain> these kind of statements are ... difficult to process
19:48:09 <truebrain> but again, just a nice-to-have 🙂
19:48:10 <talltyler> In my view, having investigated all the things you asked me to investigate in #10700, strong typed dates are the only thing standing in the way of #10700 🙂
19:48:27 <truebrain> strong typed dates will proof you didn't forget anything 😄
19:48:37 <talltyler> Yes, that's why it's neccesary 😄
19:48:53 <talltyler> Because there's no way I didn't miss something somewhere
19:48:53 <truebrain> it is to prevent mixing the different timers; possibly there are other ways to avoid that problem btw 🙂
19:49:03 <truebrain> but has little to do with the linkgraph, I guess
19:50:00 <talltyler> I am still counting on you to figure out how to keep me from mixing timers 🙂
19:50:19 <talltyler> If I can make that easier by getting rid of modulos or simplifying other code, let me know 🙂
19:50:36 <truebrain> (get the irony? 😄 )
19:50:42 <truebrain> there are some other places we do funky shit with timers
19:50:49 <truebrain> I reworked a few, as mostly it is just a timer in a timer
19:50:53 <truebrain> which is a lot easier to read
19:51:23 <truebrain> but the main issue I have with my current PR, is that it adds casts in tons of places
19:51:27 <truebrain> that doesn't sit right with me 😛
19:51:41 <truebrain> anyway, you were talking about linkgraph 🙂
19:52:59 <talltyler> Well, linkgraph may be a non-issue if it should continue to use economy dates
19:54:07 <talltyler> Maybe I can help reduce casts?
19:54:10 <truebrain> well, we do have this discussion about linkgraph once in a while; so maybe some code cleanup to make it more clear what our intentions are would be good
19:54:46 <truebrain> make it less .... intertwined 😛
19:58:40 <talltyler> Wow, that's a lot of casting, and it does seem hard to reduce
19:58:52 <talltyler> Are there other ways to prevent mixing timers?
20:00:28 <truebrain> my PR needs splitting up; there are parts with the TileIndex that we currently just do a bit nasty, and should be addressed either way 🙂
20:00:54 <truebrain> and what I was working on, is making more of the functions like SetDParam accept strong-typed entries
20:00:59 <truebrain> that really reduces most of it
20:01:08 <truebrain> the main issue left if I remember correctly are the GUI parts
20:01:15 <truebrain> there we just randomly do shit with dates like there is no tomorrow 😄
20:04:33 <talltyler> I don't see that many GUI changes in your current PR, or do you mean you haven't even gotten to casting those yet?
20:04:45 <truebrain> no, they are all in there
20:04:59 <truebrain> most were SetDParam, I fixed that, but a few are left
20:10:29 <talltyler> Anything I can do to help? Unfortunately the entire project is sort of stuck behind this task
20:11:01 <truebrain> other than finishing the PR, not really honestly. It is just biting in there, and getting it done ..
20:11:28 <talltyler> There's still a lot of casts when using SetDParam(), I guess those changes haven't been pushed yet?
20:11:31 <truebrain> in the GUI, it misuses `selected` a lot to store "anything" .. just a shared variable between all GUIs 😛
20:11:51 <truebrain> no, the casts that are there are needed, and often unrelated to SetDParam
20:12:13 <truebrain> `SetDParam(1, e->GetLifeLengthInDays() / DAYS_IN_LEAP_YEAR);`
20:12:22 <talltyler> Oh I see, that's the one I'm looking at 🙂
20:12:23 <truebrain> like .. we as humans understand this means: make the date into a year
20:12:35 <truebrain> but from a typed point-of-view, what does it mean?
20:12:42 <truebrain> what is a "date divided by a number"
20:12:49 <truebrain> it has no actual unit like that 😛
20:13:01 <truebrain> so I was thinking of making something nice that converts a Date to a Year-since-0
20:13:11 <truebrain> instead of all the "divide by DAYS_IN_LEAP_YEAR" code
20:13:41 <truebrain> I think it would be easier to understand than the current approach
20:13:50 <truebrain> similar we have Year to Date, which is a multiplication with DAYS_IN_YEAR
20:13:57 <truebrain> for some reason we stopped carying about LEAP there
20:14:40 <truebrain> `SetDParam(1, TimerGameCalendar::date + (arr_dep[i / 2].arrival + this_offset) / DAY_TICKS);` is also a true gem 😄
20:15:02 <truebrain> but okay, I added a cast there; that is no longer actually needed
20:15:13 <talltyler> Timetable GUI is a scary place 🙂
20:15:26 <truebrain> so yeah, all SetDParam changes are only needed for the Date -> Year conversion
20:15:39 <truebrain> I am not sure how fancy we want to solve it ..
20:15:58 <truebrain> one could argue a `TimerGameCalendar::date.toYear()` is consistent with other STL-related functions
20:16:08 <truebrain> but a `DateToYear(TimerGameCalendar::Date)` might just be easier for most of us
20:16:32 <talltyler> I was going to do the latter in date_type.h, where it would have lots of friends already
20:17:14 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
20:31:24 <talltyler> Hmm, vehicle age shouldn't be date...right? It's a number of days, not a date...
20:31:34 <truebrain> that is kinda the same 🙂
20:31:50 <truebrain> Date is just "amount of days", but mostly based from 1 of januari year 0
20:32:07 <talltyler> I guess for vehicles, year 0 is when they were purchased
20:32:22 <truebrain> always the case with "days since"
20:32:33 <truebrain> we call it "date", but it just adds a reference point to the story
20:32:41 <truebrain> I had a similar debate with myself, what does "date - date" mean?
20:32:47 <truebrain> as it doesn't output a date
20:32:55 <truebrain> but something VERY similar to it .. namely the days since the first date
20:33:08 <truebrain> so I guess a more correct name for the type is "DaysSince" 🙂
20:33:33 <truebrain> but for now, that seems like overcomplicating the story 😄
20:47:26 <truebrain> also YearToDate, or other PR?
20:50:20 <talltyler> Unless you want it in the same?
20:50:30 <truebrain> I was just asking 🙂
20:51:58 <talltyler> We already have DateAtStartOfYear, it just isn't used many places 🙂
20:55:16 <talltyler> if (age == DAYS_IN_LEAP_YEAR * 0 || age == DAYS_IN_LEAP_YEAR * 1 ||
20:55:16 <talltyler> age == DAYS_IN_LEAP_YEAR * 2 || age == DAYS_IN_LEAP_YEAR * 3 || age == DAYS_IN_LEAP_YEAR * 4) {
20:55:16 <talltyler> v->reliability_spd_dec <<= 1;
20:55:40 <talltyler> That's some quality code right there, especially the first calculation 😛
21:04:06 <_glx_> talltyler: and it was worse before introduction of {COLOUR} with manual string placement
21:06:02 <_glx_> oh the nice bool math magic
21:08:55 <truebrain> does in either PR mean we can remove the macro too?
21:09:11 <truebrain> (it isn't really a macro, I know)
21:09:30 <truebrain> just to avoid people using it later on
21:10:52 <talltyler> Not really, both DAYS_IN_YEAR and DAYS_IN_LEAP_YEAR still get used a few places
21:20:58 *** gelignite has quit IRC (Quit: Stay safe!)
22:22:31 <talltyler> Aw, regression tests failed 😦
22:31:06 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:39:08 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:39:32 <talltyler> I always forget where the output gets saved
22:40:11 <talltyler> Running tests is not verbose, and when I run the executable directly nothing has changed
22:40:45 <talltyler> When I run regression targets in MSVS, it doesn't output anything and says the subcommand failed
22:41:27 <_glx_> the regression output is in build dir
22:41:47 <_glx_> you can compare it to expected output
22:42:15 <talltyler> Where in the build dir?
22:43:21 <_glx_> regression_regression_output.txt
22:47:18 <talltyler> I have a result.txt in `OpenTTD\out\build\x64-Debug (default)\ai\regression` but it is not updated with the new output
22:47:18 <_glx_> would mean it didn't even ran the script
22:47:32 <talltyler> `Errors while running CTest
22:47:32 <talltyler> Output from these tests are in: C:/Users/tyler/Documents/GitHub/OpenTTD/out/build/x64-Debug (default)/Testing/Temporary/LastTest.log
22:47:32 <talltyler> Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.`
22:47:37 <_glx_> yeah that's the expected output
22:48:00 <talltyler> ^ that file contains details of the tile slope testing, but not regression details
22:48:02 <_glx_> oh you can check the log for a start
22:48:54 <talltyler> CMake Error at C:/Users/tyler/Documents/GitHub/OpenTTD/cmake/scripts/Regression.cmake:49 (message):
22:48:54 <talltyler> Regression did not output anything; did the compilation fail?
22:49:05 <talltyler> I don't know what to do with that
22:51:55 <_glx_> at least action output shows some difference in ages
22:52:16 <_glx_> building the PR locally
22:55:44 <talltyler> Oh, and #11173 failed for 2 annotations, but I can't find them... separate issue 🙂
22:56:18 <talltyler> Don't they normally show up in the files tab?
22:56:34 <_glx_> weird it failed to find a graphic set when I ran ctest
22:58:33 <_glx_> (was something in my documents)
22:59:50 <talltyler> OpenTTD itself does not crash, I ran it on fast-forward and vehicles age properly
23:00:49 <peter1138> Oh TImberwolf dropped a video 😄
23:03:28 <talltyler> I miss Timberwolf hanging around here
23:04:59 <_glx_> LastTest.log shows all the outputs for me
23:07:42 <talltyler> I’ll just copy that then 🙂
23:09:31 <_glx_> you can replace result.txt with it
23:11:28 <_glx_> differences in GetMaxAge outputs seems consistent
23:12:48 <_glx_> some are 11 days less, some 22 days less
23:16:52 <_glx_> most likely the changes in engine.cpp
23:17:15 <_glx_> as it looks like only engine info are wrong
23:17:41 <_glx_> (well and vehicles too, but they get that data from engine)
23:25:50 <talltyler> Yes, I expected those differences since we actually account for leap years instead of assuming all years are leap years
23:32:17 <talltyler> Where do I see the annotations for #11173? The checker failed saying there are two, but they don't show up in the files tab.
23:32:53 <talltyler> Thanks for your help with the regression, I appreciate it 🙏
23:37:03 <_glx_> annotations are in summary
23:37:28 <_glx_> mingw issue, I rerun the check
23:38:55 <_glx_> well not directly mingw, the action failed to get the problem matcher and had to retry the step, giving some annotations
23:39:25 <_glx_> not related to your changes
23:47:51 <twb> How do I tell openttd to download DLC via an HTTP proxy? I can't see it in the GUI options or in ~/.config/openttd, and just doing "http_proxy=http://10.0.2.2:3142/ openttd" didn't seem to work
23:53:22 <twb> Hrm, maybe last time I did this (pre-fetching some DLCs for prison inmates who don't have direct internet access), I just did tcpdump and grabbed the URLs from there. That seems to work, at least
23:54:37 <twb> Aha yep found it in my bash history: 2022-02-14 19:55:07 tshark -r openttd-downloads.pcap -T pdml | grep -Eo 'http://[^"]+' >openttd-downloads.urls
continue to next day ⏵
