IRC logs for #openttd on OFTC at 2026-09-24
            
00:11:37 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
00:11:57 *** WormnestAndroid has joined #openttd
00:26:14 *** WormnestAndroid has quit IRC (Remote host closed the connection)
00:26:32 *** WormnestAndroid has joined #openttd
00:36:17 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
00:37:10 *** MinchinWeb[m] has joined #openttd
01:12:54 *** Flygon has joined #openttd
02:03:17 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
02:04:15 *** MinchinWeb[m] has joined #openttd
03:00:03 *** herms22 has quit IRC (Quit: bye)
03:05:02 *** herms22 has joined #openttd
03:18:54 *** Philemon has joined #openttd
03:26:42 *** Phileman has quit IRC (Ping timeout: 480 seconds)
08:22:42 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 approved pull request #16031: Codechange: Remove FontColourMap state caching. https://github.com/OpenTTD/OpenTTD/pull/16031#pullrequestreview-5301736526
09:29:30 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/3c91c93222e5f2d3f92b0136a4e0d2754a112d23
09:29:32 <DorpsGek> - Update: Translations from eints (by translators)
09:30:35 *** Flygon has quit IRC (Read error: Connection reset by peer)
09:50:23 *** toktik is now known as Guest874
09:50:30 *** toktik has joined #openttd
09:56:00 *** Guest874 has quit IRC (Ping timeout: 480 seconds)
11:38:25 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:38:38 *** WormnestAndroid has joined #openttd
11:38:56 *** WormnestAndroid has quit IRC (Remote host closed the connection)
11:39:38 *** WormnestAndroid has joined #openttd
11:50:29 *** SigHunter has joined #openttd
14:30:00 *** jfs_ has joined #openttd
14:45:22 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
14:46:31 *** MinchinWeb[m] has joined #openttd
15:46:29 *** jinks has quit IRC (Remote host closed the connection)
15:49:08 *** jinks has joined #openttd
16:46:35 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
16:46:51 *** MinchinWeb[m] has joined #openttd
17:15:34 <Philemon> eventually, by pure chance, I caught a train in the act messing up its Orders. which I have complained about a few weeks back.
17:15:34 <Philemon> https://r3rr.com/image/RswJJS/raw
17:15:34 <Philemon> observe Train #74 leaving its destination station fully loaded because it tries to get to a depot for servicing. this makes this train (12 tiles long) end up at places where it's not supposed to be. clogging up 7 tiles long passenger stations.
17:18:12 <Philemon> 15 tiles ahead of that station is a depot, several tiles after that station the train is forced to go a depot as well.
17:19:42 <Philemon> so my conclusio is, that is a bug in the pathfinder. is this a known issue or should I file a report? or, perhaps, this message is enough :)
17:20:53 <LordAro> doubtful that it's a bug in the pathfinder
17:21:08 <LordAro> but possibly something about what a train does when it leaves for a service
17:21:21 <LordAro> file a report, ideally with the save attached
17:21:34 <LordAro> (ideally ideally just before something goes wrong)
17:22:42 *** _glx_ has joined #openttd
17:22:42 <_glx_> random service is known to cause lost trains, that's why it's better to use service orders
17:24:27 <Philemon> sooo, service takes precedency over a station, a station that is the purpose of the train?
17:24:55 <Philemon> isn't that part of the pathfinder?
17:25:01 <Philemon> and that is not a bug?
17:25:23 <LordAro> pathfinders find paths, doesn't do anything else
17:25:32 <_glx_> when train decides it's time for service it calls pathfinder with distance limit
17:26:00 <Philemon> ok, so maybe it is not a pathfinder issue as such.
17:26:33 <_glx_> in many occasion (with path signals) it won't even see a depot if track is already reserved
17:26:59 *** _jgr_ has joined #openttd
17:26:59 <_jgr_> In general every vehicle should have at least one depot order in its order list
17:27:15 <_jgr_> You can sometimes get away without this for trivial layouts but for anything beyond that it causes these sorts of problems
17:28:16 <Philemon> but IF the dstination station is en route to the depot for service, SHOULDN'T the vehicle decide to service said station?
17:28:35 <Philemon> ..prior to go to the depot?
17:28:39 <_glx_> no, if it's service time it goes to the depot
17:29:21 <LordAro> if your car is pouring smoke out of it, do you stop to do your shopping or do you go straight to the garage?
17:30:10 <peter1138[d]> LordAro, yeesh that NCN 4 and NCN 1 are crap today
17:30:22 <LordAro> they often are :(
17:31:36 <Philemon> LordAro: well, if it is a company car and the destination for delivery, I go there – IF I decide to ride on. then examine the car there and decide what to do.
17:32:10 <Philemon> *destination for delivery is close enough
17:33:54 <LordAro> concerning
17:34:32 <Philemon> ok, if we talk RL now... then why the change in signal behaviour? IRL signals are red by default. except the path is cleared (I really do not care about that but since IRL behavour has been brought up)
17:36:15 <Philemon> LordAro: when the car emits smoke, I do not move it on inch further. of course I have been sarcastic
17:39:17 <Philemon> also, a car ain't a train. a train has rails. and – I mean, at this point I do not know how to make it more clear – the station is right on that track on the way to the depot...
17:40:26 <LordAro> your inability to understand what an analogy is is also concerning
17:41:07 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
17:41:17 <Philemon> I understand analogies. but sometimes the analogiy mentioned is not really valid, as I have explained above
17:41:59 <Philemon> allright then. I'll just adjust my track building behaviour then.
17:42:41 <_jgr_> There is more than one kind of IRL signal and they are not all red by default. The servicing behaviour is inherited from TTD and is not likely to change.
17:43:04 <Philemon> *path signals
17:43:36 *** MinchinWeb[m] has joined #openttd
17:43:38 <Philemon> so many things have changed since TTD....
17:44:26 <Philemon> like, in TTD neither trains nor ships were able to drive backwards
17:44:45 <Philemon> anywho...
17:46:16 <Philemon> I can see you guys' points
17:47:22 <cu-kai> <Philemon> ok, if we talk RL now... then why the change in signal behaviour? IRL signals are red by default. except the path is cleared (I really do not care about that but since IRL behavour has been brought up)
17:47:23 <cu-kai> wrong
17:47:50 <cu-kai> signals protecting junctions or crossings might be red "by default"
17:48:12 <cu-kai> but automatic block signals are common
17:53:17 * Philemon pulls out the TTD disks just to check wheter path signals along a straight track are red there by default or green... if they turn out to be red, why could this original rule could have changed but trains behaviour couldn't?
17:54:23 <Philemon> the vibe I am getting right now is... if it suits devs they alter original TTD rules. if not, they claim butbutbut that wasn't so in TTD
17:58:37 <peter1138[d]> Are you feeling okay?
17:59:50 <peter1138[d]> TYD didn't have path signals, and the block signals it did have were green if the block is clear.
18:00:56 *** Flygon has joined #openttd
18:03:13 <Philemon> peter1138[d]: no, I am not. I am hyper sensitive to EM emissions and each and every day feels like hell. thank you for asking! (really, thank you!)
18:03:55 <Philemon> thanks for explaing that signal situation (at this point I am sorry to even have brougth it up)
18:51:52 *** jinks_ has joined #openttd
18:53:30 *** jinks has quit IRC (Quit: ZNC - http://znc.in)
18:53:30 *** jinks_ is now known as jinks
18:59:45 *** audigex has joined #openttd
18:59:45 <audigex> It might help if it if you think of the “stay true to TTD” as more of a “mostly stay true-ish to TTD unless it seems like there’s a fairly good reason not to”
18:59:45 <audigex> Noting that I don’t think it’d ever been a real rule at all, more of a loose philosophy to avoid just making a totally different game
19:01:07 <Rubidium> Philemon: P-signals in the Netherlands are green by default, and I'd reckon the majority of the signals in the Netherlands is a P-signal.
20:19:28 <kuhnovic> https://cdn.discordapp.com/attachments/1008473233844097104/1552776503559721071/openttd_qJGeC7h0d7.gif?ex=6ab6d74f&is=6ab585cf&hm=a120decfbc0e012f9276fa2288be94db18dc8dac4aa1f997a6b340affed0c4a1&
20:19:28 <kuhnovic> Pseudo-random sea glitter?
20:20:59 <talltyler> How?
20:22:48 <kuhnovic> I added three new sprites, each with a few sea glitter colored pixels (the palette animated colors). These then get selected based on a tile hash, and some tiles don't get one at all.
20:23:35 <kuhnovic> It does require the regular sea sprite to be glitter-free, so I'm using the old OpenGFX here
20:28:26 *** _zephyris has joined #openttd
20:28:26 <_zephyris> Fun
20:28:36 <_zephyris> Hmm... random scatter water objects...
20:31:14 <talltyler> Objects are not traversable by ships, so they’d go all swervy 🙂
20:32:49 *** squirejames has joined #openttd
20:32:49 <squirejames> Not entirely inaccurate though
20:33:57 <talltyler> kuhnovic: If you keep doing ship and ocean PRs we should change your job title in the credits to Pixel Poseidon 😄
20:36:19 <kuhnovic> Trust me, you do not want to see my pixel art 😛
20:51:07 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
20:52:29 *** MinchinWeb[m] has joined #openttd
21:03:55 *** jfs_ has quit IRC (Ping timeout: 480 seconds)
22:56:41 *** WormnestAndroid has quit IRC (Remote host closed the connection)
22:56:51 *** WormnestAndroid has joined #openttd
23:51:22 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
23:51:33 *** MinchinWeb[m] has joined #openttd