IRC logs for #openttd on OFTC at 2024-07-15
β΄ go to previous day
02:03:24 *** Wormnest has quit IRC (Quit: Leaving)
03:05:44 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:55:53 *** Flygon has quit IRC (Read error: Connection reset by peer)
04:43:43 <DorpsGek> - Update: Translations from eints (by translators)
05:46:44 <gubipe> im having issues. It says build failed. And then when I debug, it says Target missing executable. openttd.exe does not have an executable configured.
06:02:44 <gubipe> for more context, I have been trying to add new options to the local authority. I suspect I have some kind of issue with the code itself I implemented. However, I have now encountered a new issue. WHen I try to run the base game with no modifications through visual studios 2022, the game runs and asks to download missing content. While downloading, the game freezes and crashes
07:13:32 <DorpsGek> - Add: summary for week 28 of 2024 (by OpenTTD Survey)
07:32:10 *** Leopold_ has quit IRC (Ping timeout: 480 seconds)
09:42:51 *** SigHunter has joined #openttd
09:51:01 <truebrain> I FINALLY DID IT! IPv6 Prefix Delegation up and running on Oracle Cloud π Now to update the whole cluster, so I can actually migrate the first service π
09:51:09 <truebrain> stupid OCI, thinking it can put restrictions on me
10:30:14 <LordAro> sounds like something you should write up somewhere
10:32:14 <truebrain> none of this is manual work
10:32:21 <truebrain> as if it would, it would have worked 4 days ago π
10:32:25 <truebrain> it is fully scripted and repeatable
10:50:25 <merni> truebrain: The link to Pulumi is broken :)
11:43:00 <pickpacket> LordAro, _glx_: ty :)
11:52:39 <truebrain> hmmm .. I can connect to a BaNaNaS server running on Oracle Cloud; HTTP works, listing works, but in-game the list remains empty. Hmmmmmmmm
11:53:58 <truebrain> it does connect correctly .. so there is a TCP connection .. what did I do wrong? π
12:37:46 <pickpacket> best version control system I've ever worked with
12:47:22 <truebrain> yippie, bananas-preview now runs on OCI. And everything works. Listing, downloading, uploading, web, TCP, everything π
12:47:33 <truebrain> okay .. now to let this just sit and run for a few days, making sure it is actually stable
12:47:41 <truebrain> then we can migrate over the actual BaNaNaS, and see how that behaves
12:48:30 <truebrain> and no, you don't see a difference. That is the point π
12:48:59 <truebrain> (https still goes via Cloudflare, so there is zero difference. The only actual difference is TCP, which will connect to OCI, instead of AWS. There might be latency differences etc)
12:50:42 <truebrain> And if you want to help test in-game BaNaNaS, start OpenTTD with `OTTD_CONTENT_MIRROR_URI="https://binaries-preview.openttd.org/bananas" OTTD_CONTENT_SERVER_CS="content-preview.openttd.org:4978"`. This will connect to the OCI infra, and not to the AWS infra. Everything should work etc. Just a MUCH smaller list of BaNaNaS content π
13:02:18 <andythenorth> Is OCI cheaper than AWS? Or we just ran out of free credits?
13:10:51 <andythenorth> I have alternative news about weather, as I am not on Mud Island
13:11:22 <LordAro> it has finally stopped raining here
13:11:28 <LordAro> just in time for the end of the weekend
13:12:08 *** garlic_bread42 has joined #openttd
13:12:08 <garlic_bread42> Speaking of Bananas... the last Iteration of GETS Hits at roughly 320 MB of size. I'd really NOT want to cause any trouble, so I'd like to ask on how to behave:
13:12:08 <garlic_bread42> Is filesize an issue?
13:12:08 <garlic_bread42> Is there something like a maximum file size? If so, would you mind telling me?
13:12:08 <garlic_bread42> Concerning updates, afaik bananas keeps the old versions up an running - would it be better to have less but bigger updates?
13:12:18 <andythenorth> Itβs 32 degrees here, with slight breeze (10 mph)
13:13:33 <LordAro> andythenorth: i am suspicious of your current location
13:14:10 <LordAro> oh wait, i have just understood "not on Mud Island"
13:20:30 <pickpacket> truebrain: are we moving to OCI? π€
13:21:02 <pickpacket> I trust Oracle about as far as I can toss a grown blue whale
13:24:39 <andythenorth> Can you name any cloud IaaS where someone doesnβt turn up and say that? π
13:30:41 <pickpacket> Can't say it matters to me which one we're on tbh π if we're moving I'm curious about the reason
13:55:32 <truebrain> andythenorth: OCI is significant cheaper than AWS, and we hadn't had free credits in years
13:56:07 <truebrain> garlic_bread42: No, no, yes, don't care
13:57:17 <truebrain> Filesize isn't any issue, and the max filesize .. I think 2GB or so. As than users will complaint that it doesn't fit on their FAT32. And how many updates you throw, that is up to you. Just .. don't abuse the system. The infrastructure is run by donations, so use common sense to what is sane and what is not. Also remember that every update, users have to download it. So there too .. use some
13:57:17 <truebrain> common sense, and you will be fine
13:58:22 <truebrain> pickpacket: We are not moving perse; but we are offloading the TCP BaNaNaS connections to OCI, and as a result, the whole BaNaNaS deployment will be on OCI. Cloudflare will still do the HTTPS, which is 88% of the traffic. But for some reason, ~12% of the traffic is still TCP, and it is incredibly expensive on AWS
13:58:53 <garlic_bread42> truebrain: Thanks for that detailed explanation :)
13:59:43 <truebrain> garlic_bread42: No worries. And always remember that at a certain point it might be better to have more than one NewGRF, instead of one biggy. Not from an infrastructure point of view, but from a user point of view
14:00:04 <pickpacket> truebrain: that makes perfect sense. Great job of you to shop around and find better offers!
14:00:54 <pickpacket> People are wary of using more than one industry NewGRF at a time though. From that perspective it makes sense to have one big one
14:01:35 <truebrain> pickpacket: In context, about 40% of our monthly bill is just TCP BaNaNaS traffic. Which is insane, as it is < 12% of our users, on a small part of our online offering. So yeah. Also, I still have no clue why so many downloads happen via TCP, instead of HTTPS.
14:01:41 <pickpacket> I don't know if I can run Tea Tea Deluxe with any other industry set, tbh.
14:02:07 <pickpacket> Which version did we start using https in?
14:02:28 <truebrain> 14.0. And since .. 7.0 it was via HTTP. Same deal. The TCP was always between 10% and 20%.
14:02:38 <truebrain> I hoped https would move that number to something lower. It did not.
14:03:26 <garlic_bread42> truebrain: That's exactly what we're discussing internally at the moment.
14:04:14 <pickpacket> It must be some extremely old servers running out there
14:04:32 <truebrain> pickpacket: Nope. These are 14.0 clients using TCP to download content.
14:04:47 <truebrain> Initially I wanted to do brown-outs, and wait for people to report that they can't download from BaNaNaS
14:04:53 <truebrain> so we can understand why they can't use HTTP
14:05:10 <pickpacket> Huh? I didn't know the 14.0 version could do tcp
14:05:10 <truebrain> but I didn't have time for that lately. Migrating it to OCI is easier
14:05:31 <truebrain> before 0.7 there was no BaNaNaS
14:05:35 <pickpacket> Is there a setting for it?
14:05:44 <truebrain> it will always try HTTPS first
14:06:29 <pickpacket> Will it try http after https?
14:06:45 <truebrain> no. pre-14 will always use HTTP, 14+ always HTTPS
14:07:52 <pickpacket> Hmm. I was gonna say it's possible that some older systems can't do https because of outdated truststore. But if they couldn't do http before either
14:08:19 <truebrain> Without a brownout, I doubt I will ever figure out what is actually happening
14:08:47 <pickpacket> I can't see any other way either
14:09:21 <pickpacket> Is this only for downloading bananas content or the server coordinator too?
14:09:28 <LordAro> no discernable pattern from access logs?
14:10:19 <truebrain> pickpacket: those are totally different beast. This is about BaNaNaS content. It is the only service that has both HTTP(S) and TCP
14:10:34 <truebrain> LordAro: none I could deduce
14:11:23 <truebrain> and it could be Linux distros that disable HTTP, or patchpacks that compile releases poorly, or block the port, or or or .. but I never found any reason I could point at
14:11:29 <truebrain> has been going on for years btw
14:12:39 <pickpacket> Maybe add a popup in the next version that says "Download had to fall back to legacy connection type. Please contact Our Lord And Saviour TrueBrain before he decides to run you over with a Kirby steam engine."
14:12:45 <truebrain> And you would think, as the years go on, people will care less about a game like OpenTTD, and BaNaNaS downloads go down .. but it is pretty much the other way around π
14:12:57 <truebrain> pickpacket: haha π
14:13:22 <truebrain> One day, when I have some more time on my hands, I might just disable TCP for a day or so, and just wait for the first reports
14:13:37 <pickpacket> That's probably a good idea
14:13:38 <truebrain> but who knows, people might see a stalled download, retry, and it works
14:13:46 <truebrain> and that the HTTP(S) issue are all just temporary
14:13:55 <truebrain> or maybe there is a bug in our code, that once in a while it just doesn't try HTTP(S)
14:14:05 <truebrain> so many options ! π¦
14:14:24 <truebrain> but this week, I will just migrate the whole thing to OCI, and #care π
14:14:30 <pickpacket> Remove the fallback to tcp and we'll find out quickly
14:14:49 <truebrain> yeah, but given it is 12% of the downloads .... that seems a bit rough
14:15:33 <pickpacket> [insert Elmo with flames in background here]
14:15:49 <truebrain> I now remember I still have to double-double check if it is not our "savegame-only" downloads
14:15:55 <truebrain> that used to be available only over TCP
14:15:59 <truebrain> but these days I also serve that over HTTP
14:20:08 <truebrain> nope, it really serves them all via CDN
14:25:00 *** gelignite has joined #openttd
15:56:53 *** Wormnest has joined #openttd
16:03:08 *** HerzogDeXtEr has joined #openttd
16:13:36 <audigex> It's possible to get the Sprite ID of a specific position in the consist using something like the following
16:13:36 <audigex> `[STORE_TEMP(num_vehs_in_consist - 1, 0x10F), var[0x61, 0, 0x0000FFFF, 0xC6]]`
16:13:36 <audigex> Is it possible to get the length of the target vehicle too? If not, how hard would that be to add on a scale of easy to impossible?
16:16:58 *** brickblock19280 has joined #openttd
16:16:58 <brickblock19280> you could create a procedure which is a lookuptable given an id which you can get with C6
16:40:33 *** greeter has quit IRC (Remote host closed the connection)
16:41:22 *** ufo-piloot has quit IRC (Quit: you click on fancy icons. i execute code !)
16:42:38 *** ufo-piloot has joined #openttd
16:51:01 *** greeter has joined #openttd
17:08:07 *** ufo-piloot_ has joined #openttd
17:14:24 *** ufo-piloot has quit IRC (Ping timeout: 480 seconds)
17:23:59 *** gelignite has quit IRC (Quit: Stay safe!)
18:22:10 *** gelignite has joined #openttd
19:46:34 *** gelignite has quit IRC (Quit: Stay safe!)
19:59:19 *** ufo-piloot_ is now known as ufo-piloot
20:50:46 *** nielsm has quit IRC (Remote host closed the connection)
21:01:00 *** Tirili has quit IRC (Quit: Leaving)
21:25:59 *** f_ has quit IRC (Ping timeout: 480 seconds)
21:41:03 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:44:07 *** ChanServ sets mode: +v tokai
21:44:43 <silent_tempest> ```In static member function βstatic void Pool<Titem, Tindex, Tgrowth_step, Tmax_size, Tpool_type, Tcache, Tzero>::PoolItem<Tpool>::operator delete(void*) [with Pool<Titem, Tindex, Tgrowth_step, Tmax_size, Tpool_type, Tcache, Tzero>* Tpool = (& _vehicle_pool); Titem = Vehicle; Tindex = unsigned int; long unsigned int Tgrowth_step = 512; long unsigned int Tmax_size = 1044480; PoolType Tpool_type =
21:44:43 <silent_tempest> PT_NORMAL; bool Tcache = false; bool Tzero = true]β,
21:44:43 <silent_tempest> inlined from βvirtual RoadVehicle::~RoadVehicle()β at /home/tempest/oss/OpenTTD/src/saveload/../roadveh.h:123:50:
21:44:43 <silent_tempest> /home/tempest/oss/OpenTTD/src/saveload/../core/pool_type.hpp:263:53: warning: β*(Vehicle*)this.Vehicle::Pool<Vehicle, unsigned int, 512, 1044480>::PoolItem<(& _vehicle_pool)>.Pool<Vehicle, unsigned int, 512, 1044480>::PoolItem<(& _vehicle_pool)>::indexβ is used uninitialized [-Wuninitialized]
21:44:43 <silent_tempest> 263 | assert(pn == Tpool->Get(pn->index));
21:44:52 <silent_tempest> This compiler warning is driving me nuts
21:44:58 <silent_tempest> I can't seem to fix it.
21:45:45 <silent_tempest> With color highlighting
21:47:32 <silent_tempest> I think it is complaining about this index variable defined on pool_type.hpp:238
21:47:50 <silent_tempest> But even after amending the code to initialize it the warning remains
21:50:48 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:07:44 <_jgr_> It's because it is technically UB, this is one of the reasons why `-flifetime-dse=1` is in the compile flags
22:08:58 <_jgr_> Initialising it will not make the warning go away because this code is called after the destructor has executed
22:20:45 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:21:39 <_glx_> default init solved the warnings for CI release builds
continue to next day β΅