IRC logs for #openttd on OFTC at 2025-06-21
โด go to previous day
00:39:50 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:39:53 *** WormnestAndroid has joined #openttd
01:11:38 *** gelignite is now known as Guest18490
01:11:43 *** gelignite has joined #openttd
01:16:32 *** WormnestAndroid has quit IRC (Remote host closed the connection)
01:17:57 *** WormnestAndroid has joined #openttd
01:19:00 *** Guest18490 has quit IRC (Ping timeout: 480 seconds)
01:22:21 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzโฆ)
01:59:23 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:59:27 *** WormnestAndroid has joined #openttd
01:59:28 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:59:29 *** WormnestAndroid has joined #openttd
01:59:32 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:59:54 *** WormnestAndroid has joined #openttd
02:27:31 *** gnu_jj_ has joined #openttd
02:30:51 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:38:02 *** Wormnest has quit IRC (Quit: Leaving)
07:57:07 *** gelignite has joined #openttd
07:59:12 <truebrain> `FileNotFoundError: [Errno 2] No such file or directory: 'OpenGFX2/graphics/fonts/1/graphics/fonts/1/mapgen_8bpp.png'`
07:59:20 <truebrain> something is missing ๐
07:59:26 <mnhebi> andythenorth: I mean back in the day they said calculators made people dumber.
08:01:26 <truebrain> _zephyris: any idea why that file is missing? I can't even find a reference to that file anywhere ๐
08:02:08 <truebrain> I do have `./graphics/fonts/1/mapgen_32bpp.png`
08:02:14 <truebrain> but .. yeah, that is not the same ๐
08:03:28 <truebrain> owh, the folder goes wrong
08:04:03 <mnhebi> what makes people dumber is these constant education reforms that are aimed at making perfect drones for the workplace, not people..
08:08:34 <truebrain> _zephyris: what Python version are you using locally?
08:10:29 <truebrain> `glob.glob` normally returns the full path to the match, and you prefix that with a basepath again, creating the double-double path ๐ I honestly can't see why that would work for you ๐ But, it is also an easy fix ๐
08:11:37 <truebrain> `ValueError: setting an array element with a sequence. The requested array has an inhomogeneous shape after 1 dimensions. The detected shape was (3,) + inhomogeneous part.`
08:11:50 <truebrain> on `newspaper_32bpp.png`
08:12:03 <truebrain> I am getting seriously confused how this works for you; it feels like I am doing something wrong/different ๐
08:18:01 <truebrain> `ValueError: operands could not be broadcast together with shapes (3,3) (2,3) `
08:18:01 <truebrain> As if we are using totally different versions of `numpy` ๐ What might also help, next to the Python version, is the result of `pip freeze`. Possibly best to post that in the PR you have in draft. `pip freeze` shows the exact version you are using.
08:21:17 <andythenorth> mnhebi: I could subscribe to your newsletter about that happily. But having used a lot of GPT I think it does change mental processes
08:21:58 <mnhebi> andythenorth: If used too young, yes. Just like tablets and phones.
08:22:26 <mnhebi> Right tools at the right age.
08:22:38 <andythenorth> Brain stays plastic into middle age
08:23:12 <andythenorth> Clay is a plastic ๐
08:23:15 <truebrain> Hmm, numpy isn't wrong. The objects actually are of different dimensions.
08:23:32 <truebrain> I wish I understood graphics in general enough to understand this code; I don't ๐
08:23:42 <truebrain> `out32bitvalue = (numpy.max(src32bit, axis=0) - numpy.max(src8bit, axis=0) + 128).astype(numpy.uint8)`
08:23:50 <merni> andythenorth: Is clay *a* plastic?
08:23:59 <andythenorth> Clay has plasticity
08:24:09 <truebrain> Please find your way to Discord channel #off-topic-1 guys ๐
08:24:10 <andythenorth> I should ask GPT
08:24:32 <mnhebi> nothing serious ever survives in off-topic-1 or 2
08:24:43 <merni> which is the one full of dutch people
08:25:45 <mnhebi> it depends on the day lol xD
08:25:56 <mnhebi> one day its off-topic-1, one day its off-topic-2, some days its both
08:25:58 <truebrain> I was asking; but it wasn't a question
08:36:56 *** foodliker has joined #openttd
08:36:56 <foodliker> merni: usually both
08:37:24 <foodliker> it's a very small and flat country so they don't have much else to do but post on discord
08:41:56 <truebrain> I don't think there is a way to test #13945 without just .. merging it. YOLO? ๐
09:13:08 *** _zephyris has joined #openttd
09:13:08 <_zephyris> truebrain: Sorry, out with the kids! 3.12 on desktop, 3.13 on laptop IIRC
09:13:17 <truebrain> Never be sorry for having a personal life ๐
09:16:04 <_zephyris> truebrain: Defo odd, I'll do post this later
09:16:24 *** dihedral has quit IRC (Remote host closed the connection)
09:16:37 <_zephyris> truebrain: Hehe. Is it "personal life" or is it "family life"?
09:16:47 <truebrain> a non-opensource-life? ๐
09:18:50 *** dihedral has joined #openttd
09:19:46 <truebrain> lol, okay, this is rather odd: with Python 3.13 it does work
09:19:57 <truebrain> it is not common for Python to be this breaking between 3.8, 3.11 and 3.13 ๐
09:34:43 <truebrain> `If GitHub Actions downloads a 500 MB file that is tracked with LFS, it will use 500 MB of the repository owner's allotted bandwidth.`. Oof, dat would make testing OpenGFX2 rather expensive really quick.
09:46:18 <truebrain> and wow, you said it was slow, but .. yeah, this takes a while ๐
09:47:10 <_zephyris> Need to cython the 8bpp->32bpp conversion, that's where it chugs
09:48:22 <_zephyris> truebrain: Fine if there's a persistent environment, incremental pulls will almost always be slow
09:48:41 <truebrain> Yeah, but that is very difficult for many reasons ๐
09:48:53 <truebrain> for example, you use modified date to check if a file has changed, from what I can tell
09:49:02 <truebrain> but if you do a fresh git clone, the modified date is always that of today
09:49:09 <truebrain> so it would rebuild everything anyway ๐
09:49:27 <truebrain> (you can fix that by resetting the date to the date in the git, but it becomes increasingly tricky to maintain such setup)
09:57:27 <_zephyris> I could try to make things more make
09:59:38 <truebrain> Wouldn't solve the issue; `make` does the same ๐
09:59:44 <truebrain> ` nmlc ERROR: "ogfx2e_extra_8.nml", line 7295: OVERLAY_ROCKS is not a valid sprite replacement type`
10:00:00 <truebrain> And with that error I really need help, as I have no clue what it means ๐
10:00:09 <truebrain> ```$ nmlc --version
10:00:15 *** zyliety has joined #openttd
10:00:15 <zyliety> Hey guys Is it possible to download the my japan buildings object latest version? I donโt know why this problem happened. It seems that it works well with my machine.
10:05:04 <truebrain> zyliety: I can download v2.2 just fine. And although the user has v2.2 downloaded, it is not the version that is active (v2 is active). No clue why that is, maybe others do.
10:05:22 <truebrain> I never know how upgrading GRFs work in running savegames ๐
10:05:34 <truebrain> (or more exact: I can never remember ๐ )
10:06:23 <truebrain> _zephyris: `user 65m41.178s` to get to the NML issue. I just looked it up, GitHub allows running jobs for 6 hours, before they are killed. so this might just work. Just a release will be a very slow process ๐ Which isn't a bad thing, I guess ๐
10:08:31 <truebrain> Okay, `nml` just needs a new release
10:08:37 <truebrain> current release doesn't work with OpenGFX2 ๐
10:08:44 <truebrain> so that needs fixing before we can run this on the CI ๐
10:08:57 <_zephyris> Ah, yes, I should have mentioned that!
10:09:14 <truebrain> `17M Jun 21 12:07 OpenGFX2_Classic-0.7.tar`
10:09:32 <zyliety> truebrain: Thanks, I seldom use that upgrade button in my games too๐
10:23:34 *** reldred has joined #openttd
10:23:34 <reldred> truebrain: Yeah I can't see it in bananas at all, I've got the old v2 version downloaded from nanas but the new one doesn't show in JGRPP at least.
10:23:36 <reldred> Min version shenanigans?
10:24:50 <truebrain> the upload has no conditions defined; so it is not a BaNaNaS thing in that sense
10:25:52 <reldred> Huh, couldn't see it an hour or two ago
10:26:09 <truebrain> did you refresh the page? ๐
10:27:16 <reldred> ah you did the old sneaky edit didya didya didya now
10:27:29 <truebrain> as that is all published information, I can even proof it ๐
10:27:35 <reldred> that sounds like something you'd say
10:28:02 <truebrain> but no, without joking, I just opened OpenTTD and checked out the download
10:28:26 <truebrain> So I wouldn't know why it didn't work for you 2 hours ago
10:29:23 <reldred> Huh, could just chalk it up to me being incredibly stupid
10:30:38 <truebrain> I doubt that; but I also don't know what happened
10:45:50 <truebrain> in theory that should work. But first, we need a new nml ๐
11:36:09 *** SpComb^ has joined #openttd
11:44:40 <andythenorth> orders are no longer backed up when selling a train in depot? ๐
11:58:07 <_glx_> truebrain: Means I have to do changelog and things...
11:59:17 <truebrain> There are others that can do that too I am sure ๐ But yeah, I guess someone has to ๐
12:06:02 <_glx_> well based on recent history ๐
12:21:45 <_zephyris> andythenorth: I think I saw a bug report for that, linked with shared orders?
12:26:00 <andythenorth> I looked in issues and recent commits, but might need more coffee
12:53:35 *** gelignite has joined #openttd
14:17:55 *** Wormnest has joined #openttd
15:10:21 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
15:13:53 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:14:09 *** WormnestAndroid has joined #openttd
15:22:36 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:22:38 *** WormnestAndroid has joined #openttd
15:26:49 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:26:53 *** WormnestAndroid has joined #openttd
15:38:59 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
15:42:10 *** WormnestAndroid has joined #openttd
15:53:55 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:55:29 *** WormnestAndroid has joined #openttd
16:03:42 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
16:08:14 <andythenorth> 15.0 by April then? ๐
16:10:08 <Rubidium> obviously the one 15.0 will be released in :D
16:12:18 *** WormnestAndroid has joined #openttd
16:17:44 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
16:20:20 *** WormnestAndroid has joined #openttd
16:54:41 *** digitalfox has joined #openttd
16:54:41 <digitalfox> glx22viaGitHub: Would be nice to add to 0.8
16:54:41 <digitalfox> Add: Support for NewGRF badges. #359
17:25:55 *** wensimehrp has joined #openttd
17:25:55 <wensimehrp> zyliety: Sounds like you didn't update the version number
17:26:21 <wensimehrp> The in-game integer only one
17:30:29 <peter1138[d]> LordAro: Sorry was cycling and then being plied with beers.
17:30:49 <peter1138[d]> Pretty sure I wiped out the benefits.
17:38:06 <_zephyris> If the benefit was being happy, sounds like you nailed it!
17:38:21 <_zephyris> Anything useful I can do for nml badge testing?
17:41:00 <andythenorth> it needed a reviewer I believe
17:41:37 <andythenorth> oh frosch reviewed it
17:41:44 <peter1138[d]> Probably needs a rebase to get rid of the fix comments.
17:54:21 <peter1138[d]> Or commits, even.
18:02:23 <michi_cc> Hmm, I was updating the NewGRF PR tracker earlier, and got reminded of #12183. What's up with that?
18:39:43 <truebrain> Fun fact: OpenTTD is growing on Steam year-over-year. Where 3 years ago we had a peak of 700 players, we currently have 1000.
18:39:43 <truebrain> Also, we are 467th on the "top rated" game list of steamdb.
18:46:52 *** squirejames has joined #openttd
18:46:52 <squirejames> You have to announce that with a big white board full of bar charts, and a very nasally voice with huuuuuge adenoids
18:57:43 *** Tirili has quit IRC (Remote host closed the connection)
19:00:43 <truebrain> _zephyris: I am still baffled that I had issues with one Python version and not with the other. I am guessing numpy dropped support for 3.8 etc
19:01:10 <truebrain> but the weirdest issue is that your usage of `glob` shouldn't work, and didn't with 3.8, but does with 3.13. That is so odd. But what-ever ๐
19:01:21 <truebrain> ah, yes, numpy is 3.11+
19:12:48 <_zephyris> The `glob` one is bizarre!
19:14:10 <truebrain> "This code shouldn't work" ๐
19:15:15 <_zephyris> _zephyris: ^^^ Well I did warn you!
19:15:22 <_glx_> always the fun part when it works but I don't know why
19:15:29 <truebrain> No, this is not on you. Python should be stable, in these regards ๐
19:17:04 <truebrain> ha, funny; `base_path` is now an absolute path, where it isn't on earlier versions
19:18:13 <truebrain> that explains the difference
19:19:05 <truebrain> clearly a good move, as it makes things easier to work ๐
19:22:48 <truebrain> a simple workflow, to at least enable manual running workflows in branches ๐
19:23:12 <LordAro> python type linting would (probably) have caught it :)
19:30:08 <LordAro> param didn't change its name, carry on
19:31:07 <_glx_> (yeah I checked the config)
19:32:15 <truebrain> awh, I still can't trigger a build? Sad face
19:32:21 <_glx_> and nml release is done
19:32:53 <truebrain> I know another trick .. but that is becoming weird ๐
19:33:42 <truebrain> _zephyris: for a short moment, I am going to change the default branch of OpenGFX2. This is so we don't merge the PR before we know it actually works. But GitHub is GitHub.
19:34:42 <truebrain> owh, I know of at least one issue .. I provisioned this repository as "OpenGFX2", but we are building "OpenGFX2_Classic" ๐
19:34:49 <_glx_> manual trigger via `workflow_dispatch` ?
19:35:08 <truebrain> you can only do that if the workflow exists in the default branch
19:35:48 <_glx_> yeah, and it can be limited to use default branch workflow only too
19:36:28 <_glx_> (it's the case for openttd, but forks can use workflows from other branches
19:37:17 <truebrain> it is just this weird: once you have it, you can run it on branches; but before that: screw you ๐
19:38:14 <_glx_> there's always the option to commit a do nothing workflow first
19:39:08 <truebrain> what is also silly, is that it complaints it can't see secrets that are there ... ugh, what was that about
19:40:09 <truebrain> owh, I know a way around that too ๐
19:42:11 <truebrain> This will fail in uploading, but till then, let's see what it does ๐
19:44:02 <_glx_> very useful fail log ๐
19:44:44 <truebrain> `opengfx2c` or `opengfx2_classic` ? ๐
19:44:50 <truebrain> (mostly, me being lazy of typing)
19:53:07 <truebrain> right, fixed that issue. It is now doing its first "git lfs" clone ๐
19:54:04 <truebrain> we will see how long this is going to take ๐
19:55:16 <truebrain> `Converting title_letters_32bpp.png`
19:55:21 <truebrain> it is doing something at least ๐
19:58:45 <truebrain> I configured it makes a nightly every week btw; not really a nightly, but you get the point ๐
19:59:49 <_zephyris> What's the build VM specs? There's a couple of points which are slow and not well parallelised
20:00:08 <_zephyris> (the extra zoom high score/endgame screens)
20:00:27 <truebrain> Linux, 4 vCPU, 16GB
20:01:22 <_zephyris> Probably won't make much difference in the scheme of things, butworth thinking about
20:01:23 <_glx_> might be better to do it on macos runner
20:04:00 <truebrain> This all reminds me we should kinda also setup that all our binaries are uploaded to GitHub releases too. We know how. But I keep forgetting ๐
20:04:31 <truebrain> okay, adjusted the infra so it accepts `opengfx2_classic` .. that should also propegate eventually to the website etc
20:04:40 <_jgr_> It seems that compile time reflection and various associated features have been adopted into C++26. Looks pretty interesting at first glance.
20:05:23 <truebrain> now that looks funky ๐
20:06:34 <truebrain> I am not sure that syntax will make code more readable, but okay ๐
20:14:34 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
20:15:06 <truebrain> `highscore` took 8 minutes ๐ So if that is the slowest, we will be fiiinnnneeeee
20:35:02 *** WormnestAndroid has joined #openttd
20:45:23 <truebrain> Okay, one thing that might be worth trying: GitHub does have a cache, which is per repository. It is 10GB, and it auto-evicts anything older than 7 days.
20:45:23 <truebrain> Two ways I can see this working:
20:45:23 <truebrain> 1) do a cache restore before git clone, to save on LFS bandwidth. Just might be a bit tricky, as normally you do a clone first before anything else.
20:45:23 <truebrain> 2) store the resulting 8bpp in this cache. The trick here will be to know when to rebuild. As using the modified time won't cut it
20:46:06 <truebrain> One could think about switching to a checksum based system, where you run a checksum over the 32bpp file, and if that matches the value in some cache file, it doesn't reproduce the output
20:46:14 <truebrain> so there are a few things we could do here to speed thing sup
20:46:37 <truebrain> That said: GitHub Caches are a bit weird, and sometimes hard to deal with. For example: a PR can access the cache made by the default branch, but not the other way around
20:46:41 <truebrain> which makes sense, but .. also .. tricky ๐
20:48:42 <peter1138[d]> Drop 8bpp support, just make classic 1x zoom ๐
20:49:02 <peter1138[d]> Ah but it's needed for recoloured stuff.
20:53:09 <truebrain> okay, it is done generating the GRF. Took less than an hour
20:53:20 <truebrain> It will now take ~5 minutes or so to crease a source tarball ๐
20:53:35 <truebrain> and .... I made a mistake somewhere ๐
20:54:54 <_glx_> I still think it might make sense to try it on macos runner
20:55:26 <truebrain> Feel free to try it out ๐ But I don't really see how that matters in the current stage of this all
20:56:13 <_glx_> I know it's mostly affected by I/O but image processing may be faster on ARM
20:56:51 <truebrain> For some reason, the repository got into a "modified" state .. and I don't see why
20:57:26 <_glx_> incomplete .gitignore ?
20:57:51 <truebrain> owh, wait, it executed `make` twice
20:57:55 <truebrain> so `findversion` is executed twice
21:01:07 <truebrain> well, no, that only kinda explains why the source was in `m` state .. not why all was in that same state ....
21:06:21 <truebrain> `"NAMING_VERSION=20250621-release-workflows-tb-g0e902d5e98"`
21:06:21 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
21:06:28 <truebrain> when I dump the name, it at least is correct ...
21:06:49 <truebrain> `"NAMING_VERSION=20250621-release-workflows-tb-m0e902d5e98"` is directly after that
21:07:29 <truebrain> ``` deleted: graphics/terrain/64/universal_rivertiles_bt32bpp.png
21:07:29 <truebrain> deleted: graphics/terrain/64/universal_watertiles_bt32bpp.png```
21:07:36 <truebrain> _zephyris: why does a "make clean" remove those files?
21:07:57 <truebrain> (or maybe more to the point: why are they committed?)
21:08:01 *** WormnestAndroid has joined #openttd
21:10:00 <truebrain> take as many as you like ๐
21:10:55 <_zephyris> The `_bt32bpp.png` are blue to transparent versions, for the 32bpp variants, which shouldn't be committed
21:11:05 <truebrain> okay, so I can safely remove them. Perfect!
21:11:45 <_zephyris> Best guess is that I assumed they'd always be in `pygen`, python generated, directories.
21:12:55 <truebrain> Or you just accidentially "git add"'d them
21:12:57 <truebrain> happens to me all the time ๐
21:13:33 <truebrain> yeah, now the working folder is clean \o/
21:14:08 <truebrain> will take another hour, but by the looks, this should work. If something fails, it is most likely because I forgot something in the infra
21:16:47 <_zephyris> I'll double check that case tomorrow - water tiles are one place where I've done odd manual wrangling.
21:17:09 <truebrain> If the now-running-build fails, we know it wasn't okay to remove them ๐ ๐
21:17:25 <truebrain> Trial by fire, or something ๐
21:19:05 <_zephyris> Thanks for all of your work on this
21:19:37 <truebrain> No worries ๐ Would be nice if we automated this. Care-free new releases are nice ๐
21:21:22 <truebrain> And I think my idea of caching might just work .. would require changing `check_update_needed`, but you already centralized that nicely. It would add an extra file for each generated output, but that hardly sounds like an issue. Well, worth trying after this PR is done ๐
21:21:43 <truebrain> "First get it to work, then make it pretty" ๐
21:32:06 <truebrain> cool, I wrote scripts to keep our CDN nice and tidy
21:32:10 <truebrain> I did not execute them in a long time ๐
21:34:46 <peter1138[d]> Teach, normally.
21:35:22 <truebrain> PR could use an approve if anyone minds ๐
21:38:21 <truebrain> okay, cleaning up the CDN is something to look into tomorrow ๐ But there is a lot of diskspace being used for no good reason ๐
21:38:33 <peter1138[d]> Well. It's still too hot ๐ฎ
21:39:03 <_glx_> phone says 26ยฐC outside
21:39:17 <truebrain> I just don't go outside. Solves that problem for me ๐ (I have airco in my house, so .. yeah ๐ )
21:40:23 <_glx_> being under the roof really doesn't help
21:44:00 <truebrain> okay, that should be the last piece
21:44:36 <truebrain> I am like 70% sure the OpenTTD nightly will fail, either on CDN generation or website generation. I already announced OpenGFX2-classic release folder, and it is currently empty. I can't imagine something is going to have a hard time with that ๐ But we will see that when it happens ๐
21:46:52 *** ChanServ sets mode: +v tokai
21:50:37 <truebrain> we have 120GB of Symbol files ๐
21:50:45 <truebrain> pretty sure a few of those can be removed by now .. like most nightlies etc ๐
21:52:49 <_glx_> old nightlies definitely
21:53:55 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
21:58:45 <truebrain> I do have scripting for the CDN itself, but not for the Symbol server. lol.
21:59:39 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:02:58 *** WormnestAndroid has joined #openttd
22:07:51 <truebrain> Okay, it did not need those two files to generate GRFs. So there is that ๐ Now it is generating the source-tarball again ... so slooowwww. (it is also 700 MiB)
22:08:43 <truebrain> well, creating the tarball is quick. The compression (to save a wopping 100 MiB!) takes forever ๐
22:12:56 <peter1138[d]> If only we used a standard image format ๐
22:13:16 <truebrain> Okay, files are being uploaded to CDN now
22:14:46 <truebrain> `<head><title>413 Request Entity Too Large</title></head>`
22:15:43 <truebrain> yeah, because we upload via a Worker, we are limited to 100MB
22:15:50 <truebrain> I was already doubting if uploading the source was actually a good idea
22:15:55 <truebrain> and I guess this settles that debate ๐
22:16:09 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:16:23 <truebrain> unless someone strongly objects to us storing the result, but not the source? ๐
22:16:38 <_glx_> well source is in the repo
22:16:41 <truebrain> (we used to do it so you can always recreate the output again, even if everything else burns down)
22:16:57 <truebrain> but yeah, given how much git clones there are around these days
22:17:02 <truebrain> I doubt losing the source is actually an option ๐
22:17:33 <truebrain> okay, so tomorrow I will make uploading source optional in the workflow.
22:17:54 <truebrain> But at least the rest is working ๐
22:18:24 <_glx_> at least worker failed with a non cryptic message
22:18:39 <_glx_> unlike the many nightly failures
22:23:22 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
22:36:31 *** WormnestAndroid has joined #openttd
22:37:32 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:43:06 <peter1138[d]> Your entity is too large.
22:54:58 *** Wormnest has joined #openttd
23:26:26 *** Flygon has quit IRC (Read error: Connection reset by peer)
continue to next day โต