IRC logs for #openttd on OFTC at 2025-09-12
⏴ go to previous day
01:59:47 *** Wormnest has joined #openttd
02:06:36 *** Wormnest has quit IRC (Quit: Leaving)
02:14:57 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
02:56:25 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
02:57:30 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:57:31 *** WormnestAndroid has joined #openttd
02:57:47 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:57:48 *** WormnestAndroid has joined #openttd
02:57:53 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:57:54 *** WormnestAndroid has joined #openttd
03:56:33 *** Zathras has joined #openttd
04:00:05 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
04:43:55 <DorpsGek> - Update: Translations from eints (by translators)
05:05:00 *** moll has quit IRC (Ping timeout: 480 seconds)
05:50:30 *** Flygon has quit IRC (Remote host closed the connection)
08:32:23 <jfkuayue> longtom_jr: But the bridge camera cannot perform well enough in the 1200mm zoom mode.
08:32:57 <jfkuayue> (enough = photos of planespotting accepted by jetphotos.com)
08:49:30 <reldred> A lot of the time the bridge cameras just printed a 35mm equivelant focus range on the body, rather than the actual focal length, so that whole bridge crop sensor thing has already been accounted for.
08:49:49 <reldred> An actual 20mm focal length on a 1” or smaller sensor wouldn’t actually be very wide
09:12:17 <peter1138> > Can you just create the test EDI file quickly?
09:12:38 <peter1138> First, let me rebase the 3 months old code.
09:12:51 <peter1138> Then update it for the refactoring I've done.
09:13:22 <peter1138> Then figure out why the unit tests are failing.
09:13:42 <cellar> apparently good and proper that helicopters vanish in the end. no osprey or large drone replacement then.
09:14:18 <peter1138> Add some NewGRF vehicles.
09:14:31 <cellar> anyway, looks like someone updated some javascript somewhere, as I'm getting large panels blacked or whited out on openttd wiki pages.
09:15:11 <peter1138> I'd be very surprised if the OpenTTD wiki used any javascript.
09:15:14 <cellar> I just might, in a bit. still getting to know the basic game.
09:16:16 <cellar> oh, looks like it doesn't. then what is mucking up the rendering? That just started a couple days ago.
09:17:19 <peter1138> Probably something wrong with your browser.
09:17:20 <cellar> wouldn't be the first time some external library got updated pulling the rug on the website. but in this case, looks it's not js that's the culprit. serves me right for assuming.
09:17:52 <peter1138> If your system or browser has been updated in the background then it might just need a restart.
09:18:01 <cellar> pretty sure nothing changed with that. it's chrome on 32 bit windows, and that doesn't get updated any longer.
09:19:01 <LordAro> (protip - we can't help if we don't know what you're looking at)
09:19:50 <LordAro> images look like they're working to me
09:20:30 <LordAro> and i can confirm no javascript
09:20:42 <cu-kai> forum looks good to me in firefox
09:20:43 <LordAro> or any external files at all, for that matter
09:20:48 <cu-kai> or rather, the wiki :D
09:21:39 <peter1138> Problem solved, use Firefox.
09:22:28 <cu-kai> i think the bigger question is: why so outdated?
09:25:19 <peter1138> Hmm, running the unit tests in a debugger has caused it all to hang. Great.
09:25:33 <LordAro> printf debugging it is then
09:26:20 <peter1138> Console.WriteLine :(
09:26:47 <peter1138> There's a null reference exception in the unit test.
09:27:02 <peter1138> But the line pointed to has already completed.
09:27:28 <reldred> cu-kai: Biggest question is why the fuck in 2025 using 32bit operating system
09:28:06 <cu-kai> i don't even think windows 11 has a 32 bit version. when did chrome stop supporting 32 bit?
09:28:07 <reldred> With only a few very very minor exceptions everything for the last 15 years has been 64bit capable.
09:29:23 <cu-kai> you're using windows 7 on the internet...?
09:29:40 <cu-kai> this is the wildest thing i've seen posted here in a while lol
09:30:06 <peter1138> Probably time to retire that.
09:30:47 <cellar> palemoon doesn't seem to have a problem, let's see how long that lasts.
09:31:19 <cu-kai> palemoon is gecko based (aka firefox), so yeah
09:31:23 <reldred> jesus just install linux already
09:31:26 <cu-kai> firefox ESR supports windows 7 still
09:31:32 <cu-kai> but really, you should not be using this in 2025
09:31:34 <cellar> yeah, well, it shouldn't even be windows really.
09:31:58 <peter1138> LordAro, and if I make the debugger break on exceptions, well, there's loads that the unit tests expect... :o
09:32:00 <reldred> Eh, I don’t give a shit about windows, but running 32bit win7 in 2025 is a shit show.
09:32:18 <cellar> all it really needs to do is support a vaguely functional browser and a couple putty sessions. unless I accidentally lose myself in openttd, of course.
09:32:31 <reldred> If you’re broke and gotta make your hardware last then Linux.
09:33:14 <cellar> before systemd, yes. after, it looks a bit much like windows now.
09:33:15 <cu-kai> cellar: then you should probably install linux, all of these things will work (and better) on linux
09:33:31 <cu-kai> what's the CPU and memory of that machine?
09:34:35 <cellar> oh, 4 GB and an first-gen i3. which is still ways ahead of what I tend to actually do stuff on (2 GB and a C7)
09:34:44 <reldred> cellar: that is among some of the dumbest crap I’ve heard in a long while, and there are distros still using sysvinit if you feel that strongly about it
09:36:12 <cellar> the blood pressure is but one thing. it tends to spontaneously crap itself in my vicinity.
09:37:01 <cu-kai> so the hardware is 64 bit capable
09:37:28 <cu-kai> also, the systemd argument is stupid too
09:38:08 <cellar> no, that it's not. I can't work with it, so I won't.
09:39:49 <peter1138> Is it a desktop system?
09:40:15 <peter1138> Because on a desktop system, it's not absolutely something that isn't noticable at all.
09:40:26 <peter1138> Because on a desktop system, it's absolutely something that isn't noticable at all.
09:40:58 <cu-kai> i wouldn't bother having the conversation any further, you won't change their mind lol
09:41:05 <cu-kai> i know people like this, there is _no_ convincing them
09:41:28 <cellar> so don't try to convince me. :-)
09:42:06 <peter1138> cu-kai, yes, they read once that Lennart Poettering is trying to ruin everything by... checks notes... making things just work.
09:42:08 <cu-kai> no need, when i re-read the comment about core2 and 2GB RAM being your daily, i realised. good luck anyway, but your current setup is unsupported by this project.
09:43:52 <cellar> heh, except that's not what was going on at all. it was complete politics lots of bs arguments. then again, I am a little prejudiced. used to work with a/v software on linux and the first fix for any weird audio problems was "get rid of pulseaudio".
09:44:49 <cu-kai> i'd have expected that sort of solution to work 10+ years ago, these days things tend to be a lot better.
09:44:50 <cellar> that was a while ago and my current setup is a shambles. even so, it says something deeply troubling when software randomly shitting itself and the only remedy we can think of is "oh your software is too old"
09:45:49 <peter1138> Sure, jackd and pulseaudio bother wanted exclusive access to the audio device. That's entirely nothing to do with systemd, other than it had the same author. Prejudiced indeed.
09:46:04 <cellar> like here, you're accepting ten years of misery and say "oh well, that was then, it's all better now". the fscker deliberately set out to break things, did break things, and all he had to offer was "not our problem".
09:47:17 <cellar> core2? no, C7. but that's not what I'm running openttd on. that's what I write my stuff on. fits in there quite nicely.
09:47:50 <cu-kai> yes sorry, i misread/mistyped
09:47:53 <cu-kai> but that's even worse, arguably
09:48:08 <cellar> no complaints on the openttd front on a 32 bit windows, though.
09:50:59 <cellar> well, except that it manages to soak up a lot of time I really should be spending otherwise.
09:54:43 <peter1138> Probably ought to remove internet access from anything running Windows that old and unsupported.
10:01:32 <cellar> if there's a risk of doing sensitive stuff on it. which I very much don't.
10:04:37 *** ChanServ sets mode: +v tokai
10:08:21 <LordAro> i'd say those black boxes are indicating that your GPU is shutting down
10:09:24 <LordAro> maybe we should stop building for win32
10:09:37 <LordAro> i suppose 32-bit win10 is still supported for another month
10:10:00 <peter1138> They are 256x256 pixels square, which is a good indication. That's not a random size.
10:12:51 <cellar> LordAro: that wouldn't guard against people using browsers to look at wiki.openttd.org using a 32 bit browser, now would it?
10:13:40 <peter1138> It doesn't guard against people using old hardware that is starting to fail, either in software or hardware.
10:14:18 <LordAro> chrome is hardware accelerated, perhaps try turning that off?
10:14:50 <cellar> it's only that site though. not tt-forums, or github, or whatever else I have open. does it group things in per-site processes?
10:14:56 <LordAro> hanlon, hanlon everywhere
10:15:17 <LordAro> i wouldn't pretend to remotely understand how chrome works
10:15:26 <cellar> or, you know, this tab with the qwirc.
10:15:32 <cellar> "most of the time it doesn't"
10:15:35 <LordAro> but it definitely uses the GPU more readily than other browsers or programs
10:17:29 <peter1138> Settings -> System -> Use hardware acceleration when available
10:17:41 <LordAro> peter1138: probably different in old versions :p
10:20:14 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
10:23:29 *** cellar has quit IRC (Quit: gotta restart the browser for that -- thanks for the pointers anyway)
10:26:56 <cellar> without turning off acceleration but just restarting the browser, seems to've made the problem go away for now. still weird it only showed up there. might be interesting to know what it was. oh well.
10:27:27 <cellar> thanks for the pointers anyway.
10:28:50 <cellar> I probably should run memtest on this thing. *adds to todo list*
10:30:28 <peter1138> Hmm, I need change git's editor on a per repo basis :o
10:33:09 <LordAro> mm, could always be system memory too
10:33:24 <LordAro> i'm not aware of any memtest that tests GPU memory :D
10:33:59 <cellar> i3 530 with "intel hd graphics", that's a shared memory thingy.
10:35:46 <peter1138> Saving grace, not affected by Spectre?
10:37:19 <cellar> then again, there was a power dip a couple days back; this box' external power brick ate it, other box rebooted. could still have flipped a couple bits somewhere.
10:37:47 <cellar> heh. looks like you need to go back to i486 or N270 for that.
10:43:10 <peter1138> I don't think it affects Pentium, Pro, II, III and Pentium 4 CPUs and Celeron CPUs from that era.
10:43:31 <peter1138> They reused the Pentium name later.
10:56:00 <cellar> no, it's apparently vulnerable. the entire earlier core solo/core duo/core quad is too. so p4 maybe not. and for meltdown, anything p6 and up.
11:07:44 <peter1138> Sad that my HP Microserver is so limited in memory.
11:07:54 <peter1138> I can get a Raspberry Pi with the same amount.
11:10:20 <peter1138> Shame the Pi 500 doesn't have NVMe.
11:11:18 <peter1138> Annoyingly it has space and circuitry for it, just none of the components.
11:19:13 <peter1138> LordAro, I was good, I remembered to use `git switch -c` !
11:20:00 <peter1138> andythenorth, lunch o'clock?
11:43:07 <LordAro> now your branch is linked to the origin/master remote, rather than anything useful
11:43:58 <peter1138> I don't think it's linked to anything, the same as if I'd done `git checkout -b`.
11:48:07 <cellar> why do helicopters vanish, though? anything beyond "that's how the original does it"?
11:50:38 <peter1138> Vehicles have a finite life time, and the original game has an end point.
11:54:13 <cellar> do the maglev trains die off without replacement?
11:55:21 <LordAro> some of them do, iirc
11:56:25 <LordAro> curious that the wiki doesn't list expiry dates
11:57:11 <peter1138> They're randomised, both by introduction date and by the reliability decay system.
11:57:36 <LordAro> but there's presumably an approximate date
12:00:44 <cellar> so, seems without helicopters, passenger transport to/from oil rigs is back to ships. wiki says "eventually have to use ships to transport oil" -- wait, oil by helicopter? o_O
12:03:41 <LordAro> we make not claims about the correctness of the wiki
12:06:05 <cellar> looks like "helicopter" is a kind of "aircraft" so if only the last few of "aircraft" remain, then sure, no helicopters because none of them are close to the last "aircraft" introductions
12:08:47 <peter1138> Engine aging stops by default in the year 2050, but is extended if add-on vehicles appear later.
12:09:15 <peter1138> "Engine" being the in-code term for a vehicle model definition.
12:09:47 <peter1138> Although seems even if with vehicles the aging stop date can be extended til later.
12:32:49 <rito12_51026> Is this what you meant?
12:58:59 *** cellar has quit IRC (Quit: time to be outside for a bit)
13:22:02 <jfkuayue> cu-kai: One of our beloved NewGRF makers is still using Windows 7 to create all of his objects...
14:33:46 *** gelignite has joined #openttd
14:44:16 <peter1138> Too late. It's now afternoon tea.
14:54:32 <peter1138> Hmm, so if I've tested a shared_ptr against nullptr, then another thread clears it, then I do something with the shared_ptr... that's going to be a race condition, yeah?
15:00:27 <peter1138> Making a copy of the shared_ptr should avoid needing an explicit lock, I think?
15:01:07 <_glx_> increasing reference count ?
15:01:08 <peter1138> (The shared_ptr isn't actually reset, but the object that contains the pointer could be removed.)
15:02:34 <peter1138> Hmm, seems maybe not.
15:03:28 <peter1138> Or I'm misreading the caveat.
15:04:23 <peter1138> Otoh, if it does require a lock, that's a pretty awkward design.
15:06:27 <peter1138> > However, if multiple threads are accessing the same std::shared_ptr object without proper synchronization, there is indeed a risk of data corruption or other errors
15:06:36 <peter1138> But if it's a copy, then it's not the same shared_ptr object.
15:07:08 <peter1138> (Random medium post rather than the spec, though :))
15:09:03 <_glx_> you can have more than one shared_ptr owning the same object
15:09:15 <_jgr_> Multiple threads using the same instance shared_ptr suggests that it shouldn't actually be a shared_ptr
15:09:27 <_jgr_> Generally you'd give each thread their own shared_ptr instance
15:13:43 <peter1138> There's a shared_ptr which is stored in a class and that currently has shared access. I think that actually the users should make their own copy of the shared_ptr before using it, so that when the original class is destroyed they "hang on" to it until they are finished as well.
15:14:05 <peter1138> I also believe that copying the shared_ptr itself doesn't require a lock.
15:15:20 <dwfreed> "All member functions (including copy constructor and copy assignment) can be called by multiple threads on different shared_ptr objects without additional synchronization even if these objects are copies and share ownership of the same object."
15:15:55 <peter1138> Okay. I am mistaken. The thread does already use its own copy of the shared_ptr.
15:18:06 <dwfreed> the race is only if you call a non-const member function on the same shared_ptr (itself) from multiple threads
15:18:26 <dwfreed> the non-const member functions are operator=, reset, and swap
15:18:52 <dwfreed> (in other words, anything that changes what the owned object is)
15:19:29 <dwfreed> but as long as every thread makes their own copy of the shared_ptr, there won't be any issues
16:13:30 *** lobster has quit IRC (Read error: Connection reset by peer)
16:40:38 <michi_cc> peter1138: Just for the future (re #14357): Is it now convention/"policy"/whatever to prefer the explicit function calls over using the operators?
16:45:13 <peter1138> Honestly I'm not sure. There are some cases where the functions are clearer than mixing operators, though |= probably isn't one of them.
16:49:19 <peter1138> (Feel free to ignore my comments if you want)
16:55:04 <michi_cc> peter1138: Most of the comments seem fine to me, but I will have to revisit the explicit casts, because I dimly remember the compiler screaming at me in at least one spot.
16:58:33 <peter1138> *nod* Basically I tried it make it require as few casts as possible because (mainly C-style) casts can accidentally hide mistakes.
18:24:19 <peter1138> Draft ale for lunch? Sure.
18:26:00 <peter1138> Draft wine? Never heard of it.
18:27:09 <andythenorth> Straight from the barrel?
19:15:05 <_glx_> I think it's a known issue
19:16:19 <peter1138> Game does not handle the event because it's busy doing other stuff, or when it's in a debugger, simply not running.
19:16:41 <peter1138> This one is basically "yeah, no shit"
19:18:08 <_glx_> OS/WM should override, but hey it's linux
19:18:33 <rito12_51026> Can't game release the cursor before it starts doing "other stuff" to prevent this from happening?
19:22:43 <peter1138> If it's Linux then there's an OpenTTD driver configuration option to prevent it.
19:25:33 <peter1138> There's a PR that changes mouse capture behaviour on Linux.
19:25:40 <peter1138> Or maybe it was just a branch.
19:38:42 <rito12_51026> peter1138: where?
20:14:10 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
20:36:33 *** Wormnest has joined #openttd
20:40:00 <andythenorth> something about FIRS?
20:40:05 <andythenorth> hmm I could add more objects
20:40:14 <andythenorth> Railtypes in FIRS maybe?
20:40:42 <peter1138> Anyone have a savegame with a shed load of rail/road types in use... that isn't for JGRPP?
20:40:43 <andythenorth> pipes or something
20:41:49 <jessicathegunlady> ...That simultaneously sounds awful and yet kinda cool.
20:48:59 <peter1138> There are pipe line rail (or road) types already.
20:56:47 <peter1138> Hmm, maybe bananas tells me what sets contain rail/road types.
20:57:10 <peter1138> All that juicy tag metadata that OpenTTD can't slurp up.
21:00:17 <peter1138> Oh of course you can filter for it in the downloader, just not the selector.
21:05:35 *** tokai|noir has joined #openttd
21:05:35 *** ChanServ sets mode: +v tokai|noir
21:05:45 <peter1138> We've neglected canal/river/sea types ;(
21:08:31 <jessicathegunlady> ~~what, we getting lava canals and canal boats?~~
21:12:25 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:12:46 <dh1> game won't be done until it fully models fish
21:13:36 <jessicathegunlady> Nah, that's the DLC. Gotta handle moving fish from one part of the ocean to the other.
21:15:10 <dh1> also need tides, currents, and UNCLOS II
21:15:29 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:16:24 <jessicathegunlady> sharks as a hazard you need to build around
21:17:47 <peter1138> So many dumb types.
21:18:19 <jessicathegunlady> I'm not sure at what point one has too many tracks. But it's *definitely* at some point before that many.
21:18:19 <peter1138> I wonder which are SRS.
21:21:53 <peter1138> Hmm, should probably also change a few `RailTypes` to `const RailTypes &`
21:33:06 <peter1138> Copying a uint64_t is not a problem, copying a vector is more of an issue.
21:44:42 <reldred> peter1138: Look I’m generally in the ‘goes it throw out limitation’ camp but that is heinous 😂
21:45:00 <peter1138> Nothing forced me to load this many :p
21:45:21 <peter1138> Gotta test extremes.
21:45:38 <reldred> We’re at the point where we almost need to start brainstorming some UI adaptions.
21:46:40 <peter1138> The sort order system is definitely shite as it requires cooperation.
21:51:29 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
21:52:33 <peter1138> I should probably fine a better image/video hosting system than pasting it into a note on misskey then copying the URL...
21:52:34 <reldred> peter1138: That is a known bug in industrial tracks
21:52:55 <reldred> I was gonna fix it in my own fork of it but then… I didn’t.
21:54:36 <reldred> Wait, that’s not industrial trackset 🤔
21:55:06 <peter1138> "Omni Gauge, CHIPS Asphalt (Electrified)"
21:55:49 <peter1138> Anyway, it's clear that adding more railtypes does not improve the experience.
21:55:56 <peter1138> So I should delete this branch.
21:56:59 <reldred> I think it’s probably going to be useful in the short term until some wrinkles get ironed out
21:57:24 <reldred> I don’t think it’s a wasted effort
21:58:36 *** WormnestAndroid has joined #openttd
21:59:01 <peter1138> If the 63 combined road/tram types is a problem (I've heard complaints, but never seen a game with very many tram types...) this also deals with that.
22:00:36 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
22:07:20 <reldred> I think that will be very useful as well given they’re combined total
22:07:50 <peter1138> I need to download more road and tram types.
22:08:00 <peter1138> Because I don't have > 64 tram types available to test...
22:08:16 <reldred> JP+ roads is already having to pick and choose what to keep/leave out given that limit
22:08:32 <reldred> That one’s still heavily in alpha, it’s on the JP+ GitHub
22:08:35 <peter1138> I was hoping to get AIs to build crap, but they tend to all choose the same types.
22:09:16 <reldred> I tend not to mix and match road sets too much, but I do on occasion
22:12:15 <peter1138> 33 road/tram types with that.
22:19:24 <peter1138> andythenorth, write me an AS/GI to place rails, roads and trams of all different types for me.
22:27:10 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:30:46 <reldred> peter1138: There’s some additional ones hiding behind a parameter, and then yeah I think Yozora is planning to use every available ID.
22:31:46 <peter1138> My branch allows 255 IDs :o
22:32:04 <jessicathegunlady> peter1138: Is Andy even around at this sorta time?
22:34:12 <jessicathegunlady> Hm. If not, I could try and sort one out.
22:40:30 <peter1138> Manually testing with the limit reduced is easier :D
22:50:20 <peter1138> Actually it's not, due to 63 :/
22:52:58 <peter1138> Or something. Maybe that's a bit that's hidden otherwise.
22:58:05 <peter1138> "Can't build railway track here..."
22:58:09 <peter1138> That's kinda terse :D
23:01:13 *** fairyflossy has quit IRC (Quit: User went offline on Discord a while ago)
23:39:59 <peter1138> 45ms to scan the map :(
23:44:45 <peter1138> (Well, 4096x4096 map)
23:51:55 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
23:54:15 *** WormnestAndroid has joined #openttd
continue to next day ⏵