IRC logs for #openttd on OFTC at 2025-06-18
⏴ go to previous day
00:13:16 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
00:21:38 *** WormnestAndroid has joined #openttd
01:02:35 *** bigyihsuan has joined #openttd
01:02:35 <bigyihsuan> off jgrpp because i don't care to debug this all that much
01:02:35 <bigyihsuan> think this looks good?
01:03:50 <bigyihsuan> thin spots really don't work that well
01:05:03 <bigyihsuan> but when you're not looking at it that closely it sure does look pretty good
01:05:19 <bigyihsuan> other than the rivers going up the slope, obviously
01:18:08 *** reldred has joined #openttd
01:21:44 <bigyihsuan> ye it's neat, it's something i want so that i don't have to manually fill river valleys in the scenario editor
01:21:53 <bigyihsuan> it needs more work though, as you can see
01:22:28 <reldred> Wait so what’s the method here?
01:23:03 <reldred> I see some weird river tile placement
01:26:21 <bigyihsuan> reldred: take river map (black = no river, white = river)
01:26:21 <bigyihsuan> set tile type to river
01:26:21 <bigyihsuan> that's pretty much it. it needs more tuning, probably some landscape modification as well
01:28:37 <reldred> Ah nice, so an alternate heightmap
01:29:22 <reldred> Could start getting some really accurate recreations off real world locales now with the town import facility too
01:37:48 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:37:50 *** WormnestAndroid has joined #openttd
01:38:21 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:38:21 *** WormnestAndroid has joined #openttd
01:38:25 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:38:36 *** WormnestAndroid has joined #openttd
01:47:21 *** talltyler has joined #openttd
01:47:21 <talltyler> Yeah, I’d love to see people build on what I started with the town data importer
01:48:02 <talltyler> By the time it finally got merged I sort of lost interest in using it for scenario creation 😅
02:30:56 *** Wormnest has quit IRC (Quit: Leaving)
02:34:06 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:14:14 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:15:50 *** WormnestAndroid has joined #openttd
04:43:29 <DorpsGek> - Update: Translations from eints (by translators)
05:05:05 *** dh1_ has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
05:41:11 <truebrain> Second day the nightly didn't break. Doesn't mean my change fixed it. Just that it worked. Lol.
06:17:32 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
06:58:01 <LordAro> truebrain: what was your change?
06:58:38 <peter1138[d]> That was weird, missing symbols for a `static const` defined in a class in a header, alongside other `static const` that had no problem.
06:58:49 <peter1138[d]> Changed them to `static constexpr` and it seems to be fine now.
06:59:16 <truebrain> LordAro: It blindly retries uploading on failure. The issue is, if only a single byte of the response body is read, it will fail. And I don't know if these 500 errors happen before or after a byte is read.
06:59:39 <truebrain> (Inside the worker doing to upload)
07:58:13 <truebrain> LordAro: Much more a "let's try this before it becomes complicated", as the actual solution would be rather annoying.
07:59:03 *** kojonek2 has joined #openttd
07:59:03 <kojonek2> Just a stupid question. If my PR was approved then someone from the contributors will merge it or it is something that I should do? I see that most closed PR are merged by the author of the PR. I'm not used to github as I use gitlab at work and there only someone with write access can merge PR
08:02:49 <LordAro> kojonek2: no, just waiting for someone else to look at it
08:03:02 <pickpacket> kojonek2: only the maintainers of the repo can merge. The reason that most PRs are merged by their authors is because most are made by the maintainers :)
08:04:36 <truebrain> Space heater issues incoming. Now I can't remove arbitrary files on my disk from within OpenTTD anymore 😦
08:06:47 <truebrain> kojonek2: The basic idea behind this is that 2 devs look at a PR. One approves, the other merges.
08:22:43 <pickpacket> truebrain: space heater?
08:57:38 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
09:07:03 <peter1138[d]> Just to make sure the cargo_type really is 0xFF?
09:07:58 *** andythenorth has joined #openttd
09:07:58 <andythenorth> is that Iron Horse?
09:08:03 <peter1138[d]> OpenGFX+ Trains.
09:08:20 <peter1138[d]> It's broken by the default cargo type for MUs being Goods instead of Passengers.
09:08:32 <andythenorth> "that's gone well"
09:09:27 <peter1138[d]> The NML is templated and macro-full, but has `default_cargo_type: _MU_DEFAULT_CARGO([PASS]);`
09:09:37 <peter1138[d]> But clearly whatever that is, doesn't end up in the NewGRF that way.
09:09:51 <peter1138[d]> Or: the source code is for something else and my NewGRF doesn't match it 🙂
09:12:14 <peter1138[d]> Okay, it is that. The last release 0.3.0 isn't the latest version of the code.
09:12:30 <reldred> A lot of the old OpenGFX+ stuff is... interesting.
09:16:15 <peter1138[d]> Cargo table lists GOOD before PASS, so I guess that makes GOOD a better default than PASS?
09:16:32 <peter1138[d]> > Use first refittable cargo from cargo translation table
09:17:59 <peter1138[d]> Where do you set the GRF version with NML?
09:31:46 <andythenorth> believe nmlc sets it, but I didn't check
09:36:02 <peter1138[d]> So what I think happened is that OpenGFX+ Trains was designed for GRFv7, then got updated and built with GRFv8, without noticing that there are subtle behaviour differences between v7 and v8. And NML just uses the latest version.
09:41:31 <peter1138[d]> > Note that the default cargo cannot be selected explicitly. Instead it is automatically set to use the first refittable cargo, whenever one of the refitting properties is set.
09:42:20 <peter1138[d]> So "first refittable cargo" was always the case but grfv7 vs grfv8 changes what "first refittable cargo" means.
09:54:11 <peter1138[d]> File under "players don't report bugs because they don't know that it is a bug"
09:59:46 <peter1138[d]> This is, IMHO, a design flaw in the tooling.
10:00:20 <peter1138[d]> Bit too late to change that now, I guess.
10:26:23 *** cmcaine has joined #openttd
10:26:23 <cmcaine> What's the idiomatic way to return a tuple in the OpenTTD codebase?
10:27:27 <LordAro> std::tuple, probably :D
10:41:12 <peter1138[d]> std::pair if it's just two things.
10:42:46 <peter1138[d]> Hmm, though we do use std::tuple for two in some cases.
10:51:52 <talltyler> Huh? I need to be more awake before I read the PR carefully but I’m fairly sure that is wrong 🙂
10:52:11 <LordAro> i wouldn't put any effort in while it's in that state
10:52:53 <talltyler> Code looks copied from calendar time, there’s a reason they’re different 😛
10:53:05 <talltyler> I only spent 13 months making them different 😛
10:59:06 <_glx_> Yeah economy time never stops for a good reason
11:24:33 <pickpacket> is there a way to view the contents of a git repo at a specific commit without checking it out?
11:26:07 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:26:17 *** WormnestAndroid has joined #openttd
11:31:16 <peter1138[d]> pickpacket, in github at least, go the commit, then click on "Browse files" on the top right.
11:34:00 <pickpacket> peter1138[d]: I meant in CLI
11:36:29 <peter1138[d]> No, that's what checkout is for.
11:37:54 <pickpacket> peter1138[d]: yeah, I thought so
11:38:08 <LordAro> aaand we're done here
11:38:45 <LordAro> talltyler: i'll leave you to work out if there's actually any bug there, i can't quite tell what the picture is supposed to be showing
11:39:14 <peter1138[d]> It's not a bug report, so there's no bug.
11:39:47 <LordAro> not everything needs a bug report to be bug :p
11:39:57 <LordAro> what are you, our QA department?
11:40:07 * LordAro grumbles in #work processes
11:41:12 <pickpacket> "disable the possibility for increase play time and possibility to increase one year time in game?" -- that wasn't there to begin with... How was it then disabled? Or am I missing something here?
11:41:15 <peter1138[d]> From their snippet of config, they want `minutes_per_calendary_year` to be applied even without using wallclock mode.
11:41:24 <talltyler> The only oddity in their screenshot is that they started in period 1950 and not period 1. I think Scenario Editor can give that result though.
11:41:38 <talltyler> I haven't looked at this stuff in a while. 🙂
11:41:48 <peter1138[d]> This is deliberately not implemented.
11:41:56 <pickpacket> peter1138[d]: yeah, that's how I understood it too.
11:42:28 <pickpacket> It looks to me like they're asking for a "slow forward" as opposed to the "fast forward"
11:44:09 <pickpacket> can the fast forward be set to values lower than 1?
11:44:14 <reldred> "out of scope, use jgrpp for the desired functionality, cope and seethe"
11:46:53 <peter1138[d]> Not really anything to do with ticks per second, pickpacket.
11:48:19 <peter1138[d]> Bah, I should document my ideas for better movement code and hope that someone more intelligent than me can actually design it...
11:49:02 <reldred> I'd be curious to see what you're thinking
11:49:15 <talltyler> Hmm, how do you get economy time to start matching the calendar year? New games and Scenario Editor both start in calendar period 1...
11:49:37 <pickpacket> peter1138[d]: that's a matter of interpretation :D They complain that time runs too fast.
11:49:38 <talltyler> Maybe a savegame with its mode changed via Scenario Editor using a file extension change?
11:50:10 <reldred> I mean, back when TTD originally came out we generally spent a lot less time on them.
11:50:16 <talltyler> I remembered struggling with this for a while before I gave up and said "wallclock mode only for new games, no saveload required"
11:50:27 <talltyler> (when developing the feature, I mean)
11:50:31 *** locosage has joined #openttd
11:50:31 <locosage> idk what their code is doing but from the pr description I just fell like they want minutes per year to work in calendar mode
11:50:46 <locosage> as it does look a bit odd that it forces wallclock
11:50:51 <pickpacket> talltyler: keep it as is
11:51:04 <locosage> also, not sure what happens when config is edited manually like they did
11:52:57 <talltyler> Oh, interesting, that should not be possible 😅
11:54:01 <peter1138[d]> For me, those buttons are active, but the value doesn't change.
11:54:07 <talltyler> Yeah, that seems to be what happened. Changing mode of a savegame via Scenario Editor resets economy year to 1. Seems I thought of that workaround. 🙂
11:54:12 <peter1138[d]> (They probably should be inactive, but...)
11:54:34 <talltyler> I couldn't figure out how to make the setting inactive based on the timekeeping mode 🙂
11:54:42 <talltyler> (buttons inactive, rather)
11:55:17 <talltyler> Okay, so the bug is that a manual config can set minutes per year while timekeeping mode is Calendar 🙂
11:55:17 <peter1138[d]> Probably needs yet another callback function to be added. So yeah, TMWFTLB 😉
11:56:26 <peter1138[d]> Hmm, so it's validated when changing it, and not validated on load?
11:57:16 <talltyler> Yeah, rookie mistake
11:57:29 <peter1138[d]> Good job we haven't released 15.0 yet then 😉
11:57:58 <locosage> there will always be bugs 😜
11:58:06 <talltyler> That's a 14.0 bug 😉
11:58:18 <peter1138[d]> Reminds me of another settings bug where settings were moved from one place to another, and the old settings were loaded, and then trashed by the loading the new settings which defaulted things...
11:58:18 <talltyler> But yeah, opening an issue now that I can self-assign for later
12:07:11 <pickpacket> btw, I saw someone joke about creating a 32x32 map. It got me thinking; would it be hard to implement custom map sizes?
12:07:47 <peter1138[d]> You already can, but it must be a power-of-2.
12:08:17 <LordAro> fairly limited view of 'custom' :p
12:09:20 <peter1138[d]> Maps are 256x256 and you will like that.
12:09:25 <kojonek2> in code I saw there is log of side of map used so probably it will be more expensive in terms of computation if it were not power of 2
12:09:35 <LordAro> any size as long as it's black
12:09:49 <peter1138[d]> That's what she said.
12:12:47 <pickpacket> 32x32 is a power of 2, so I guess that should be okay :D
12:13:02 <pickpacket> also 1x1, 2x2, 4x4, 8x8, and so on
12:14:05 <LordAro> i think you might have trouble with a 1xanything map
12:14:27 <pickpacket> LordAro: playing on, yes. But generating?
12:18:57 <peter1138[d]> When you get to really small sizes, the void tiles start eating into it a bit.
12:19:35 <peter1138[d]> For a 16x16 map only 14x14 is actually usable.
12:20:25 <peter1138[d]> We never bothered excluding the void tiles from the map size display 🙂
12:20:59 <pickpacket> what's a void tile?
12:21:41 <locosage> kojonek2: likely not, it may even be faster
12:22:12 <peter1138[d]> Tiles at the edge of the map that are used to shape the terrain and prevent vehicles traversing over the edge.
12:22:16 <locosage> supporting non-power of 2 probably just needs some careful range checking here and there
12:22:49 <locosage> but also no real reason to support it imo
12:22:52 <peter1138[d]> Multiples of 16 are required for the water region system.
12:26:35 <kojonek2> locosage: isn't bit shifting faster than multiplication?
12:29:20 <locosage> in like last 30 years probably not
12:30:02 <locosage> but I recall non-power of 2 arrays being faster to access
12:30:02 <LordAro> depends on the multiplication
12:30:15 <locosage> may not be relevant for last 20 years as well though xD
12:32:02 <cmcaine> And division is much slower than bitshifts or multiplication, which is a common reason why people use power-of-2-sized data structures.
12:32:54 <locosage> on modern processors vectorisation and branching predictability is way more important for performance than what the actual operations are
12:35:08 <peter1138[d]> Yeah, the question should've been about division, not multiplication.
12:35:27 <peter1138[d]> Shifting is faster, whether it matters is a different question.
12:41:27 <cmcaine> DIV is 10 cycles per operation, in throughput conditions where you're just doing loads of divisions in a row with no other operations.
12:41:27 <cmcaine> MUL is 1 cycle per operation (throughput conditions)
12:41:27 <cmcaine> SHL (Shift left) is 0.5 cycles per operation.
12:41:27 <cmcaine> You have to have pretty wide vector ops before a DIV by a bad number doesn't matter.
12:41:55 <cmcaine> *matter for high performance code.
12:44:02 <cmcaine> Well, "matter" isn't the right word, and microbenchmarks are generally silly.
12:44:02 <cmcaine> But if you do ever end up with some code that is problematically slow, it is occasionally worth recalling that DIVs are a lot slower than other arithmetic operations.
12:44:23 <LordAro> compilers generally do everything they can to avoid actual DIV operations though
12:44:33 <cmcaine> andythenorth: I made and ate hummus, it was lovely, thanks 🙂
12:44:40 <LordAro> andythenorth: i had soup
12:44:46 <LordAro> running a bit low on food
12:45:05 <peter1138[d]> LordAro: Yeah. That's easy when it's a constant, less so when it's a variable with unknown range.
12:47:13 <cmcaine> What Peter said. There are runtime libraries for doing the same kind of tricks that compilers do for constants so that a repeated division by a (runtime) known value can be accelerated, but an ahead-of-time compiler won't do it for you automatically
12:48:14 <peter1138[d]> By "matter", in mean in the context of the game. Is the difference noticeable in most common circumstances, and if it is, does it actually cause problems.
12:50:44 <LordAro> "But if you do ever end up with some code that is problematically slow..." it's cute that you think my code is slow because of arithmetic
12:54:00 <locosage> I do occasionally end up with a code that's slow because of arithmetic...
12:54:10 <locosage> may have something to do with python 🤣
13:17:29 <cmcaine> How do I get DrawString to change colour part way through?
13:18:08 <peter1138[d]> Put a colour code into the string you're drawing.
13:19:18 <peter1138[d]> And by that I also mean use the StringID system, not just raw strings.
13:20:31 <peter1138[d]> `GetString(STR_HOTKEY_SHIFT, "F10")`
13:20:50 <peter1138[d]> I made up a StringID there.
13:50:04 <cmcaine> Do you mean `GetStringWithArgs`, peter1138[d] ?
13:58:49 *** keikoz has quit IRC (Ping timeout: 480 seconds)
14:20:07 <peter1138[d]> Yeah, I still don't get docker/docker-compose.
14:20:19 <peter1138[d]> docker-compose shows it using variables from .env.
14:20:27 <peter1138[d]> docker-compose up suggests that... no, it's not using them at all.
14:21:01 <peter1138[d]> I copied the configuration to another directory, did `docker-compose up` there and... yup, it worked.
14:35:57 *** akimoto has joined #openttd
15:14:20 *** Wormnest has joined #openttd
15:53:22 <peter1138[d]> Oof, this branch is old enough to not use stdint types 😦
16:32:43 *** gelignite has joined #openttd
16:40:38 <truebrain> Time to see if I can manage to upgrade 2 clusters ... will be interesting, haven't done it in a while 😄
16:54:34 <truebrain> 336s to boot up a machine .. I think I/O is a bit lacking 😄
16:55:16 <truebrain> owh, no, it is the CPU that is lacking. "only" 2GHz
16:57:38 <truebrain> `Template failed: (dynamic): execute: template: :12:39: executing "" at <.Tags>: wrong type for value; expected string; got dependency.ServiceTags`
16:58:49 <truebrain> I hate it when applications tell me to go to a line where the problem absolutely isn't
17:02:12 <truebrain> no mention in the changelogs something changed in this area .. grrr
17:12:23 <andythenorth> hmm grfs....could we think of nice way to hide a vehicle model immediately that the replacment is available?
17:21:18 <truebrain> going to try something; BaNaNaS might become unavailable for a bit
17:23:24 <truebrain> still seems to work
17:27:38 *** _zephyris has joined #openttd
17:27:38 <_zephyris> First time I've seen w00p as a question!
17:28:23 <_zephyris> While a github workflow guru is around, any pointers for trying to set up ogfx2 builds/cdn upload?
17:29:32 <_zephyris> I can find and copy ogfx1 yamls... But not much more than that!
17:29:55 <truebrain> I can give it a look tomorrow or so. Can't remember what was needed 🙂
17:30:01 <truebrain> most likely some keys that need provisioning
17:31:20 <truebrain> another attempt on not murdering BaNaNaS .......
17:32:10 <truebrain> Okay, now I did murder it ....
17:33:09 <truebrain> oops, mixing private ports with public ports
17:33:12 <truebrain> that tend not to work 😛
17:44:06 *** WormnestAndroid has quit IRC (Remote host closed the connection)
17:44:09 *** WormnestAndroid has joined #openttd
17:47:04 <truebrain> And another short interruption on BaNaNaS while I roll over the old servers .. should be good as new now 😄
17:48:39 <truebrain> now to scale back, and hope it shuts down the old machines, not the new 😛 It should, but .... 😄
17:51:24 <truebrain> IPv4 and IPv6 still work. I am always amazed when things still work months later 🙂
17:52:14 <truebrain> (Provisioning IPv6 on OCI is .... weird. But it works, so *shrug*)
18:02:45 <truebrain> lol, I saw disconnects on the new cluster. Like, wtf?
18:02:45 <truebrain> `[ 4295.548486] eth0: renamed from vethf38c3c7`
18:02:45 <truebrain> For some reason, 4000s after boot, something is like: let's rename the primary NIC name!
18:02:50 <truebrain> as why the fuck wouldn't you do that ...
18:03:35 <truebrain> 4000s? No, it is much less. What-ever .. "a long time after boot"
18:05:59 <truebrain> _zephyris: So what is needed that I tell our infrastructure automation to provision a new "CDN Upload key", which will be set in the GitHub repository. With that key, the GitHub Actions workflows we have can upload files to our CDN.
18:05:59 <truebrain> There are "nightlies" and "releases". The first will create a new version every "night" (only if there is a change), and the "releases" on tag. Much like OpenTTD (well, exactly like OpenTTD).
18:06:04 <truebrain> so I will take care of those keys tomorrow
18:06:09 <truebrain> after that, it should be just a copy/paste
18:08:18 <truebrain> so I am not sure that matches with OpenGFX2
18:08:30 <truebrain> but plenty of people here that can help out with that part too; although I will give it a looksy tomorrow
18:08:42 <truebrain> ``` make maintainer-clean
18:08:42 <truebrain> make bundle_zip bundle_xsrc```
18:08:47 <truebrain> those 2 statements are the important parts
18:08:50 <_zephyris> Yeah, I think I need to change/add some make targets
18:09:04 <truebrain> and the filenames need to be very exact
18:09:17 <truebrain> so we might just want to clone this, and modify it to our needs
18:09:29 <truebrain> the `-source.tar.xz` might be a bit excessive large
18:10:07 <truebrain> and there is the GitLFS to figure out
18:10:26 <_zephyris> Devil always in the detail
18:10:41 <truebrain> Yeah, but the more I look at it, the more I don't think this can follow the same workflow as the other basesets
18:10:54 <truebrain> we will find a way 😄
18:11:03 <truebrain> are all the files needed part of the repo?
18:11:36 <truebrain> and how long does it take, give or take, to build a bundle?
18:14:11 <_zephyris> From scratch, ie all graphics generation, hours
18:15:30 <_zephyris> If its doing a clean make, it always needs to do the graphics gen
18:16:00 <_zephyris> 32bpp -> 8bpp conversion dominantly, but there's various bits that require processing
18:16:23 <truebrain> Still not sure if that is what I am asking about 😄 You want to automate uploading to the CDN
18:16:32 <_zephyris> Actually, building the 1x zoom version only is much faster, not sure how fast
18:16:32 <truebrain> so how long does that take, minus the actual uploading?
18:18:45 <_zephyris> Does it do a new clone of the repo and make, or is there a persistent vm/environment for subsequent make runs?
18:19:02 <_zephyris> (Or am I totally misunderstanding?)
18:19:04 <truebrain> The first; we don't have persistent storage atm between runs
18:19:16 <truebrain> No, it is not you who misunderstands things; it is me who doesn't know how OpenGFX2 works 😄
18:20:04 <_zephyris> So, a clean build from a freshly cloned source of the extra zoom base set takes many hours. The slow bit is processing source graphics to newgrf-useable graphics.
18:20:24 <_zephyris> But, it can do a 1x zoom only build, OGFX2 Classic, which is much faster, but I'm not sure how fast
18:20:51 <truebrain> Okay. So in the repo isn't a prerendered something or something like that?
18:21:34 <_zephyris> Nope. In general, repo only contains 32bpp images which need to be converted to 8bpp (which is surprisingly slow for large extra zoom sprites)
18:21:59 <truebrain> Okay. So I guess the idea is that on release, it builds the OGFX2 Classic, and uploads that
18:22:11 <truebrain> If you have the commands to do that for me, etc
18:22:18 <truebrain> I will see how far I can get tomorrow 🙂
18:22:35 <_zephyris> Good luck, I apologise for wonky python and make in advance!
18:22:48 <truebrain> nothing to apologise for.
18:23:03 <truebrain> even a build doc! Amazing 😄
18:23:31 <_zephyris> Hmm, though it seems to be missing the instructions for only building the classic baseset
18:24:17 <_zephyris> Oh, it does, I'm just not reading properly.
18:25:22 <_zephyris> (`make baseset_highdef` for the 32bpp/extra zoom, `make newgrf` for the OGFX2+ NewGRFs)
18:30:53 *** SigHunter has joined #openttd
18:37:01 <_zephyris> There's no `make` target for bundling the source, but relatively easy to make one which bundles the 1x-zoom baseset-only sources.
19:10:16 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
19:14:19 *** akimoto has quit IRC (Ping timeout: 480 seconds)
19:15:35 <truebrain> We always packed the source of OpenTTD, as in the early days we in fact did lose the source once. So that was a way of saying: "this is no longer going anyway"
19:15:42 <truebrain> but for OpenGFX and friends, I always wondered if it was actually useful
19:16:05 <truebrain> for everyone to lose a git-bundle, that is a pretty hard thing to do 😛
19:16:20 <truebrain> but I will have to check how big it is .. there are limits to what we can store 😄
19:51:34 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
20:30:00 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
20:30:28 *** WormnestAndroid has joined #openttd
20:44:02 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
20:48:27 <cmcaine> OpenTTD takes ages to compile for me. Is there a config using `ninja` or whatever that might be faster?
20:58:57 <Rubidium> are you using make and not passing in a -j flag?
21:00:27 <cmcaine> I'm building with `make -j4` on a quad core CPU
21:01:33 <_glx_> depending on touched files a lot might need to be rebuilt
21:02:07 <_glx_> (english.txt is one of the rebuild everything trigger)
21:40:57 <peter1138[d]> Is that a quad core Rasyberry Pi, or something beefier...
21:45:19 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:46:42 *** tokai|noir has joined #openttd
21:46:42 *** ChanServ sets mode: +v tokai|noir
21:53:41 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:58:25 *** dh1 has quit IRC (Read error: No route to host)
23:23:23 <reldred> peter1138[d]: at this rate I'd probably say a quad core raspberry pi is beefier
continue to next day ⏵
