IRC logs for #openttd on OFTC at 2025-09-07
⏴ go to previous day
00:55:50 *** Extrems` has joined #openttd
00:55:50 *** Extrems has quit IRC (Remote host closed the connection)
00:55:53 *** Extrems` is now known as Extrems
02:01:16 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
02:14:26 *** toktik has quit IRC (Remote host closed the connection)
02:29:08 *** Wormnest has quit IRC (Quit: Leaving)
03:08:19 *** Extrems has quit IRC (Ping timeout: 480 seconds)
03:33:12 *** toktik has quit IRC (Remote host closed the connection)
03:36:03 *** Extrems has joined #openttd
03:43:18 *** WormnestAndroid has quit IRC (Remote host closed the connection)
03:43:21 *** WormnestAndroid has joined #openttd
04:02:42 *** Zathras_11 has joined #openttd
04:06:05 *** Zathras has quit IRC (Ping timeout: 480 seconds)
04:37:47 <DorpsGek> - Update: Translations from eints (by translators)
06:36:53 *** Emru has quit IRC (Remote host closed the connection)
07:09:47 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
07:16:20 *** truebrain has joined #openttd
07:16:20 <truebrain> That would be Subversion ofc, with TortoiseSVN
07:16:25 <truebrain> it isn't that long ago that you used SVN yourself 😛
07:19:23 <peter1138> I didn't end with a ? because it was rhetorical :)
07:19:32 <truebrain> owh really? I did not pick up on that.
07:19:59 <truebrain> (and now everyone is confused 😛 )
07:20:16 <peter1138> Our last svn commit was 7 years ago.
07:20:36 <truebrain> I still don't regret it a day 🙂
07:20:55 <peter1138> svn was mostly good, git is superior :)
07:21:02 <truebrain> What a terrible way of collaborating it is, subversion. Good for its time, but boy ... the shit we had to endure 🙁
07:21:11 <andythenorth> We should have gone with bzr
07:21:29 <truebrain> subversion was better for velocity, but ... not always the right direction 😄
07:24:02 <peter1138> IIRC mercurial tried to fake sequential revision numbers too, some how, but I can't see that working well.
07:24:11 <kuhnovic> I'd still pick mercurial / TortoiseHg if it were up to me, but the world (and therefore most of the tools) has moved on
07:24:38 <truebrain> It took us a few years to let go of sequential numbers 😄
07:24:42 <peter1138> I'm glad we didn't because I hated it.
07:25:44 <truebrain> These days I moved on the `jujutsu`. It still allows you to push to git repositories (as you kinda have to), but it abstracts away most of the weirdness in git. So now I have the benefit of the nice DX mercurial offered with the speed and compatibility of git 😛
07:27:43 <kuhnovic> Oh that sounds pretty cool!
07:28:11 <truebrain> It takes a bit getting used to, as you have to untrain some bad habits you picked up with git. But after that, it is so much easier (from a cognitive point) to work with it
07:28:23 <truebrain> no more stupid rebases, weird merge conflicts, and all that shit
07:28:56 *** Emru has quit IRC (Quit: Gateway shutdown)
07:33:10 <truebrain> It is also nice to have a tool that doesn't try to integrate AI for no reason other than sounding cool, doesn't have an account system, doesn't require an internet connection to work.
07:33:10 <truebrain> It .. just .. works. Like the good old days 🙂
07:34:11 <kuhnovic> The way it should be
07:37:13 <truebrain> There are more tools up&coming like jj. Most do a pretty good job shifting how we think and work in git.
07:37:13 <truebrain> Sadly, most are also more busy with "how can I make money on this", which makes it often a bit weird 😛
07:47:02 <peter1138> Well, someone needs paying at some point.
07:47:37 <truebrain> Sorry, let me rephrase: they are busy with "how can I make heaps of money with this simple tool" 😛
07:47:43 <peter1138> But requiring it for tools used for distributed development is awkward.
07:47:46 <truebrain> Which often means mandatory account system, etc
07:50:57 <truebrain> also things like GitKraken, they went so overboard with AI ..
07:50:57 <truebrain> AI commit message? Sure, I can take that. It even helps often, as writing commit messages is boring yet predictable.
07:50:57 <truebrain> AI merge conflict resolution? Excuse me, what? Fuck no, keep your dirty hands of my merge conflict resolving please.
07:50:57 <truebrain> I just don't get why "if it doesn't have AI, it is not worth talking about" with these kind of tools 🙁
07:56:21 <andythenorth> because of the funding demands
07:56:31 <andythenorth> VCs won't read pitch decks that don't have AI in
08:14:33 <andythenorth> best commit in recent history
08:14:38 <andythenorth> does it do locks? 😛
08:22:31 <_zephyris> Docks over bridges?
08:33:28 <peter1138> "stations on bridges" would be a nice feature but not one I'm working on :)
08:35:42 <andythenorth> newgrf docks for OpenTTD 18?
08:54:54 <peter1138> Hmm, I lied, it doesn't require 3, but it should do.
09:06:32 *** lobster has joined #openttd
09:11:45 *** lobstarooo has quit IRC (Ping timeout: 480 seconds)
09:17:27 <andythenorth> per-grf pool of non-buildable railtypes? 👀
09:18:40 *** toktik has quit IRC (Remote host closed the connection)
09:23:05 <andythenorth> the main reason would be to "simplify" var 0x63 checks
09:23:35 <andythenorth> as I _think_ they'd only require one label, and the rest would be handled by the railtype, instead of the vehicle using a list of labels
09:23:43 <andythenorth> (1) I'm probably wrong 😛
10:29:14 <dh1> i think it's a travesty that openttd doesn't model every moving part of the train
10:33:27 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
10:53:50 <kuhnovic> Tightening the screws of my garden fence must be the most bikeshedding thing I've done in a while
10:56:19 <andythenorth> Did you silicon spray them too?
11:09:30 *** brickblock19280 has joined #openttd
11:09:30 <brickblock19280> andythenorth: I fully understand why you would need this
11:12:15 <kuhnovic> andythenorth: No, but it did whisper kind words and played some Mozart
11:46:09 <peter1138> Sometimes you can find bugs just by looking at the code ;-)
11:46:30 <andythenorth> can you do it by looking at the author? 👀
11:47:11 <peter1138> > Author: peter1138
11:47:30 <peter1138> 100% accurate prediction.
12:34:38 <brickblock19280> audigex: this would be possible but very easy to mess up
12:35:35 <_glx_> this syntax will never happen I think
12:35:52 <brickblock19280> which is a problem because it is kinda neccesarry
12:38:50 <peter1138> Is this the thing where people don't write comments on the PR so whatever was written is lost?
12:49:21 <brickblock19280> on secound thought this is more of something for nml to deal with
12:58:38 <andythenorth> +1…I’m still unclear on why the spec would try to support that
13:17:04 <peter1138> Ah, yeah, I wrote the bridge-over-larks patch long before the stations stuff.
14:22:58 *** toktik has quit IRC (Remote host closed the connection)
14:25:28 *** toktik has quit IRC (Remote host closed the connection)
14:28:25 *** crimsteel has joined #openttd
14:28:25 <crimsteel> Where can I make suggestions?
14:28:43 <crimsteel> Or alternatively I'll just place it here: diagonal roads
14:29:45 <_zephyris> Doesn't really work... You end up squeezing 4 lanes on a diagonal tile.
14:30:03 <emperorjake> That's been suggested many times
14:30:09 <_zephyris> (I've tried various graphical experiments)
14:30:55 <emperorjake> It does work though, there's even a semi-functional patch
14:32:56 *** toktik has quit IRC (Remote host closed the connection)
14:42:37 <crimsteel> emperorjake: Where can I get it?
14:42:48 <crimsteel> Or is there an add-on?
14:44:47 <emperorjake> crimsteel: It's not playable, there are lots of bugs to be worked out still
14:45:16 <emperorjake> but the proof of concept is there
15:46:10 <peter1138> Well, whatever you meant, that's merged now :o
16:01:25 *** gelignite has joined #openttd
16:08:52 <peter1138> I guess file-scope tables can be moved, but function scope is probably fine as-is, unless the data is duplicated.
16:20:19 *** Wormnest has joined #openttd
17:05:42 <andythenorth> hmm ok railtypes
17:06:05 <andythenorth> I need to make a type compatible with unelectrified rail in NuTracks
17:06:50 <andythenorth> so in the standardised scheme I need to generate `S@AN`
17:07:17 <andythenorth> where @ is all possible characters that can fit in a byte
17:07:27 <andythenorth> I want to autogenerate them
17:07:34 <andythenorth> standardised railtype scheme means all are valid
17:08:57 <andythenorth> can I safely just do ASCII?
17:09:17 <andythenorth> and will I have to shard the railtype table to add these labels?
17:37:12 *** greeter has quit IRC (Remote host closed the connection)
17:40:16 <peter1138> rightnut, the screenshot is outdated, yes.
17:42:08 * andythenorth learning about ascii
17:42:13 <andythenorth> so I don't need control codes
17:42:18 <andythenorth> that cuts the range down
17:42:26 <andythenorth> I probably don't need all the diacritics etc?
17:42:51 <_glx_> well it can be anything from `\x00` to `\xff`
17:43:40 <_glx_> but most likely you only need `[0-9A-Za-z]`
17:43:46 <andythenorth> am I missing some part of the grf spec that limits these? 🙂
17:44:06 <_glx_> there's no limit in the spec
17:44:27 <andythenorth> ok so probably `_` and some others?
17:44:30 <_glx_> but grf devs tend to use only human readable
17:44:55 <_glx_> labels are exactly like grfid
17:45:15 <andythenorth> it's all very silly, in actual context 🙂
17:45:46 <andythenorth> to collaborate, every railtype grf has to either _know_ or _anticipate_ every possible compatible label in another grf
17:46:18 <_glx_> just don't care about future, only current matters
17:46:34 <andythenorth> the only way to know those would be to scrape bananas for all grfs, and decompile them
17:47:27 <_glx_> usually you add support for what you know, and look for other if there's need at some point
17:48:06 <_glx_> you can't know all possible grf combinations users will use
17:48:23 <andythenorth> kind of makes the railtype scheme....not pointless...but very silly
17:49:06 <_glx_> basically if following the scheme you are somehow guaranteed things also following the scheme should be fine
17:49:07 <andythenorth> simple case: I add a type, I make it compatible to `RAIL` and `SAAN`
17:49:15 <andythenorth> now a grf is added to the game
17:49:35 <andythenorth> the grf extends `SAAN` with 5 speed limits, 2 kinds of sleepers, and 2 kinds of ballast
17:50:10 <andythenorth> so the second grf defines `SAAN` through `STAN`
17:50:20 <andythenorth> my type is only compatible to `SAAN` though
17:50:40 <andythenorth> unless I either reactively, or in anticipation add `SAAN` through `STAN` to my grf
17:50:59 <andythenorth> but authors are also insistent that the second character can be used for types, not just appearance
17:51:17 <andythenorth> so `STAN` may actually not be compatible in the 2nd grf with `SAAN`
17:51:25 <andythenorth> but my grf changes that
17:52:02 <andythenorth> railtype subtypes? 😛
18:03:53 *** toktik has quit IRC (Remote host closed the connection)
18:04:36 <brickblock19280> _glx_: Not in nml because bug
18:41:01 <peter1138> Hmm, I think fixing vehicle inclination happens too early.
18:41:23 <peter1138> It sets vehicle flags, but happens way before AfterLoadVehiclesPhase1
18:45:23 <peter1138> Hmm, no it doesn't.
18:45:31 <peter1138> I misread that completely :D
19:19:19 *** meow71828 has joined #openttd
19:19:19 <meow71828> Could anyone try to compile beta for android? Would be really awesome
19:19:52 <peter1138> Vanilla OpenTTD doesn't support Android.
19:21:12 <meow71828> Yeah, thats why I say "could anyone try it?"
19:21:33 <meow71828> There WAS a compiled build for beta for android
19:21:42 <meow71828> But the guy went MIA
19:22:28 <meow71828> So it all went stale
19:22:50 <meow71828> Could anyone try to compile it? Pretty please
19:23:56 <peter1138> There's a port for Android, but it isn't built from vanilla sources.
19:24:34 <meow71828> peter1138: It is not? Thats new to me
19:25:10 <_glx_> i think none of us know how to build things for android
19:30:12 <andythenorth> I have to extend **all** the AC, DC and 3rd rail labels too
19:30:19 <andythenorth> wonder when I hit the limit
19:31:05 <andythenorth> yes, I hit the limit 😛
19:31:15 <andythenorth> ` nmlc ERROR: nmlc: An internal error has occurred:`
19:31:56 <andythenorth> 316 compatible types
19:32:09 <meow71828> Is this info useless for me or there is something important in here?
19:32:10 <meow71828> About how it was built
19:33:29 <_glx_> that's just the data for f-droid store
19:34:04 <andythenorth> 254 labels in the compatible prop appears to build, so I guess it's the byte limit
19:34:24 <andythenorth> wonder what happens if I declare it again, additively
19:37:32 <andythenorth> I understand why frosch said 'forget railtype grfs, just make your own railtypes'
19:38:00 <andythenorth> there's no way to define a new type that's downwards compatible to RAIL
19:38:32 <andythenorth> whilst then being cross-compatible with every railtype grfs extension of RAIL
19:38:42 <peter1138> _glx_, looks like build instructions, but I doubt it's useful for anything much.
19:38:59 <peter1138> _glx_, no mention of cross-compilers or anything.
19:38:59 <andythenorth> the standardised spec requires defining labels well in excess of the actual limits of the railtype spec
19:39:56 <peter1138> Though I guess that might be part of the SDK.
19:42:21 <peter1138> Well, nothing for us anyway :)
19:46:31 <peter1138> Totally normal for it to be in a repository named after a Commander Keen clone.
19:49:53 <andythenorth> hmm maybe I can just support A-Z in these labels
19:51:17 <andythenorth> lowercase is needed
19:51:58 <andythenorth> could railtype props 0x0E and 0x0F be words or dwords, rather than bytes?
19:52:00 <peter1138> Can we get michi_cc_ here to slap andythenorth around a bit with a large trout?
19:52:43 <andythenorth> we (michi) already unfucked the wiki page
19:53:39 *** michi_cc has joined #openttd
19:53:39 <michi_cc> Who needs slapping for what?
19:53:47 <andythenorth> prop 0x0E needs slapping
19:53:51 <andythenorth> it's not large enough
19:55:53 <andythenorth> as the 2nd char of the scheme is unbounded (but I've assumed A-Za-z0-9)
19:56:21 <andythenorth> and then there are 11 variations of electrification
19:57:44 <michi_cc> It's not unbounded. From the POV of a vehicle set it is bounded to exactly A. `"Train sets must not define vehicles for appearance classes."`
19:57:51 <andythenorth> I'm defining a railtype
19:58:09 *** dh1 has quit IRC (Quit: My Mac has gone to sleep. ZZZzzz…)
19:58:14 <andythenorth> that is downwards compatible to RAIL, and any other railtype for which RAIL vehicles are compatible
19:59:03 <meow71828> _glx_: The problem is, there are no build instructions for it
19:59:03 <meow71828> Readme is from vanilla
19:59:03 <meow71828> But, it mentions 15.0 beta 2
19:59:05 <meow71828> But no resent builds! How sad.
19:59:36 <andythenorth> railtype grfs have lots of variations on RAIL for speed limits, ballast, strawberry topping etc
20:00:42 <michi_cc> What for though? Inside the Standardized Scheme, a vehicle shouldn't use it. And if you are outside the scheme (which is totally valid), why care about the scheme at all?
20:01:11 <andythenorth> I am aware that the rules say I shouldn't care 😛
20:01:23 <andythenorth> I thought I could autogenerate my way to success though 😛
20:02:24 <andythenorth> it works for the non-specialised electrification types
20:02:29 <andythenorth> unfortunately my target is JP+
20:02:49 <andythenorth> which has AC, DC, 3rd rail, and a parameter to merge AC and DC back to just E
20:04:01 <andythenorth> maybe I can just refuse the lower case and numeric variants
20:05:07 <michi_cc> If you want to extend a specific NewGRF (JP+), nothing is unbounded either, because you have an exact target list.
20:06:19 <andythenorth> I'm trying to work through all the major railtype grfs and support them
20:06:27 <andythenorth> I guess I should just write a script to decompile all grfs
20:06:32 <andythenorth> and list the labels seen
20:08:26 <michi_cc> I still don't understand what you need special railtypes for though, but that is apparently just me.
20:09:11 <andythenorth> nobody does, so I'll give up explaining
20:09:28 <andythenorth> I just don't buy into this "all trains can go on all railtypes" concept
20:09:39 <andythenorth> the original game had 3 types iirc
20:12:11 <andythenorth> oh there's dual gauge also 😛
20:12:27 <andythenorth> and with most of the electrification types
20:12:50 <michi_cc> andythenorth: They don't? Unless players either deliberately choose it (e.g. Universal Railtype, PURR etc) or use railtype sets with wrong/broken compatibility/powered flags.
20:13:16 <andythenorth> oh, dual gauge is E only
20:14:12 <andythenorth> if we were starting again.... 😛
20:14:19 <michi_cc> 9953 without any additional backwards compatibility shims would break some old savegames though.
20:14:21 <andythenorth> we might not make the label the UUID
20:14:30 <andythenorth> and we might not make the label semantic per char
20:14:46 <andythenorth> but we are where we are 🙂
20:17:35 <andythenorth> I guess I should support dual gauge also
20:18:13 <andythenorth> supporting standard gauge consumes about 136 entries
20:18:21 <andythenorth> then there's D and d for dual guage
20:18:33 <andythenorth> unless we can find a bigger byte, not possible 😛
20:22:20 <andythenorth> ok so maybe I wrap the railtypes and railtype declarations in some conditional detection of specific railtype grfs 🙂
20:22:37 <andythenorth> been trying to avoid it, means I've become OzTrans 🙂
20:26:56 <reldred> I wouldn’t consider anything OzTrans does as aspirational
20:31:20 <andythenorth> I am kind of doing "I don't want to play with everyone else" 😛
20:44:08 <michi_cc> Okay, I've been reading the backlog on the add-on channel... Is most of this railtype stuff about high-speed rail?
20:44:35 <andythenorth> that backlog could do with summarising, there's much confusion and hot air 😛
20:44:54 <andythenorth> TL;DR yes, it's about high-speed rail primarily
20:45:37 <michi_cc> Because if it is, your image of high-speed rail might not be what reality is. Because there is nothing special about high-speed rail at all.
20:46:52 <andythenorth> it's a meta-game at this point. Can I do it
20:46:52 <andythenorth> * without depending on just one railtype grf
20:46:52 <andythenorth> * without putting conditionals in for each railtype grf
20:48:07 <peter1138> Hmm, how can I quickly see what rail and road types are in use on a map.
20:48:16 <peter1138> I fear I need to scan the map :(
20:48:19 <michi_cc> There are basically three "kinds" of high speed rail in the world: a) "German" high speed rail: this is just normal elrail, and on most parts of the network, slow pax and even freight trains run at night.
20:48:19 <michi_cc> b) Japan style HSR: It's not special, except that is does use a different gauge than most of the old rail network did.
20:48:19 <michi_cc> c) French-style LGV (also most of China): Rail is normal rail except only designed for low axle loads (loads below what normal freight waggons have).
20:48:34 <peter1138> For rail types I can use company infrastructure, but roads don't have to be owned.
20:48:56 <michi_cc> So translating that to OTTD and the Scheme: a) nothing to do b) gauge is already included c) axle load is already included.
20:49:24 <andythenorth> the meta-game is just making what Horse already does work with other grfs
20:49:55 <andythenorth> IRL, if HSR was just normal rail, we wouldn't have to build HSR lines as a massive political project
20:49:59 <andythenorth> but IRL doesn't really matter
20:51:02 <andythenorth> I think 'just support known JP+ labels' is the cleanest solution so far
20:52:25 <michi_cc> But it literally is normal rail. It's usually built on dedicated alignments and flat grades (using bridges and tunnels), but that really isn't the domain of the railtype but of the landscaping toolbar.
20:53:55 <andythenorth> I gave up asking for it to be in the Scheme a long time ago
20:54:05 *** toktik has quit IRC (Remote host closed the connection)
20:54:15 <andythenorth> it's an argument with me vs. everyone else
20:54:44 <andythenorth> but within the spec I should still be able to make it downward compatible to RAIL
20:55:04 <andythenorth> maybe that's not true
20:55:26 <andythenorth> the discussion on 9953 implies that we don't know if asymmetric compatibility is permitted or not
20:55:45 <andythenorth> I think that's the crux of it
20:57:17 <peter1138> michi_cc, break old saves \o/
21:02:23 <andythenorth> so, my railtype LOLZ is no different to ELRL in concept
21:03:03 <andythenorth> to add LOLZ as downwards compatible to RAIL I "need" to make it compatible with all variants of `S___`, `d___` and `D___`
21:03:24 <andythenorth> that's infeasible due to property sizes
21:05:04 <andythenorth> JP+ solves it by assuming nobody will use that many ascii chars
21:05:11 <andythenorth> so a typical JP+ entry for 0x0E is `compatible_railtype_list: ["_AAE","_BAE","SAA3","SBA3", "SAB3", "3RDR", "MTRO","RAIL","SAAN","SBAN","SCAN","SDAN","SEAN","SFAN","SGAN","SFAN","dAAN","_AAE","_BAE","SAAD","SBAD","SCAD","SAAA","SBAA","SCAA","SGAA","SHAA","ELRL","SAAE","SBAE","SCAE","SDAE","SEAE","SFAE","SGAE","SHAE","SIAE","dAAE","dBAE"];`
21:05:20 *** ChanServ sets mode: +v tokai
21:06:20 <andythenorth> only consumes 38
21:08:01 <andythenorth> there's named constants in JP+ to insert these lists
21:08:42 <_glx_> you don't have to add all types as compatible, you can assume railtype grf already provides part of the list
21:10:17 <andythenorth> I don't know the terminology I need, but the graph of compatibility is only one node deep
21:10:23 <andythenorth> if I make LOLZ compatible to RAIL
21:10:36 <andythenorth> it doesn't gain evey other label that has been made compatible to RAIL
21:10:40 <andythenorth> I have to do that myself
21:11:30 <andythenorth> ELRL is compatible to RAIL
21:11:41 <andythenorth> but LOLZ has to be made compatible to [RAIL, ELRL]
21:12:02 <andythenorth> otherwise everything would just become compatible to everything? (I think)
21:12:25 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
21:13:10 <andythenorth> then in a 2nd grf, if CATS extends RAIL so that RAIL vehicles can run on CATS
21:13:20 <andythenorth> that doesn't mean LOLZ runs on CATS
21:17:56 <andythenorth> ok so I think I just make a constants list for all the labels used in each railtype grf
21:18:00 <andythenorth> and then detect the grf
21:18:47 <andythenorth> oof, no there could be multiple grfs per game 🤷♂️
21:20:55 <andythenorth> JP+ doesn't have to deal with that, because it uses all the railtype slots
21:21:12 <andythenorth> so it only has to deal with compatibility to vehicles
21:34:36 <andythenorth> then LOLZ railtype doesn't add RAIL or any of the other labels to prop 0x0E
21:34:50 <andythenorth> instead vehicles declare [LOLZ, RAIL]
21:39:45 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:41:04 *** greeter has joined #openttd
22:14:55 <audigex> This whole system just seems insane, frankly
22:14:55 <audigex> Personally I feel like it just ("just" doing a lot of heavy lifting as always) needs ripping out and replacing with something sensible and new, rather than trying to fit any solution in with so much technical debt and "It has to be backwards compatible forever"
22:14:55 <audigex> Otherwise we're just talking in circles because nobody's actually proposing a solution that does anything anyone really wants, because with the technical debt it's not actually really plausible to propose a solution anyone wants
22:14:55 <audigex> Personally I'd just ("just" again...) create a new system that is loosely based on the Standardised Rail Types concept (and thus could have a quick-and-dirty translation layer for old sets that use SRT) but built to do what people actually want rail types to do
22:16:36 <audigex> Maybe I'm misunderstanding, but most of the conversation I'm seeing just revolves around slapping bandaids onto something that's fundamentally not really fit for purpose - loads of great work has been done with them, rail types as a concept have been stretched to their limit. Nobody's fault, just an old old game
22:17:00 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:17:37 <audigex> Like is there anyone in the community actually happy with how rail types work, from either the track set or train set side?
23:03:37 *** toktik is now known as Guest26075
23:39:06 *** Flygon has quit IRC (Remote host closed the connection)
23:56:39 <dh1> @audigex these days i only play openttd like it's a pretty trainset so there's nothing more annoying than a railtype that looks realistic for the look i'm going for but has a speed limit of 18
continue to next day ⏵