IRC logs for #openttd on OFTC at 2020-05-31
⏴ go to previous day
00:00:05 <andythenorth> I use that 'wait at station for n days' thing, but I never use timetables
00:21:00 *** dekeract[m] has joined #openttd
00:34:23 <supermop_Home> i honestly can't imaging playing the game without it
00:34:35 <supermop_Home> everything just becomes messy piles
00:42:38 <supermop_Home> i think i need to build another blast furnace
00:45:47 <Eddi|zuHause> i timetable every road route
00:46:13 <Eddi|zuHause> but interacting train routes are painful to set up right
00:48:58 <supermop_Home> hmm this train has a 'non-stop via' order, but a 'stay for 1 day' time on it
01:04:04 *** blim[m] has joined #openttd
01:06:34 *** WormnestAndroid has quit IRC
01:06:44 *** WormnestAndroid has joined #openttd
01:25:56 <Speeder_> noone ever made "pharmeceutics" a cargo item?
01:39:19 *** WormnestAndroid has quit IRC
01:40:21 *** WormnestAndroid has joined #openttd
02:16:27 <Speeder_> should I repurpose some existing cargos of other NewGRFs or create my own?
02:21:07 *** magdalena[m] has joined #openttd
02:23:23 <FLHerne> Speeder_: You should reuse already-known cargo labels/classes wherever possible
02:23:59 <Speeder_> FLHerne, I want for example reuse "BEER" to represent all beverages
02:24:15 <FLHerne> Speeder_: If you want to add new and different cargos, then do
02:24:15 <Speeder_> also any reason why people avoid toyland cargos?
02:24:26 <FLHerne> Speeder_: Sounds reasonable to me
02:24:48 <FLHerne> Speeder_: I imagine any vehicle that can carry beer can carry other beverages
02:25:02 <FLHerne> And would look much the same
02:25:35 <FLHerne> Everyone just ignores Toyland and anything relating to i
02:28:30 <FLHerne> If you reused the Toyland cargos for something sane, you couldn't know if vehicle-grf authors would draw sensible sprites or absurd ones
02:31:01 <supermop_Home> hmm maybe i should grade-separate my express train so it's not taking up a slot through this junction
02:33:38 *** Webster has joined #openttd
02:33:56 <supermop_Home> that 3rd platform at fackslatt is pretty useless excepte when starting new trains right now
02:34:34 *** XeryusTC has joined #openttd
02:35:41 *** planetmaker has joined #openttd
02:35:48 *** planetmaker is now known as Guest26686
02:36:00 *** Hazzard has joined #openttd
02:36:10 <supermop_Home> but if it tunneled under the HQ to join those express tracks directly, then the space held for the express could go to a new North-west bound train
02:36:37 *** fjodor[m] has joined #openttd
02:36:41 *** V453000 has joined #openttd
02:36:41 *** Hirundo has joined #openttd
02:37:11 *** ^Spike^ has joined #openttd
02:39:28 *** igor[m] has joined #openttd
02:56:45 <Speeder_> FLHerne, for example I am thinking of using toyland sugar
03:23:12 *** UncleCJ[m] has joined #openttd
05:11:53 *** leward[m] has joined #openttd
05:23:26 *** cyberjunkie[m] has quit IRC
05:31:47 *** cyberjunkie[m] has joined #openttd
05:48:14 *** ad5twoknebor[m] has quit IRC
05:52:42 *** ad5twoknebor[m] has joined #openttd
06:05:21 *** elliot[m] has joined #openttd
06:16:09 *** Wrench_In_The_Plan has quit IRC
06:37:30 *** jact[m] has joined #openttd
07:17:38 *** ZirconiumX has joined #openttd
07:36:13 *** Terkhen has joined #openttd
07:36:15 *** ChanServ sets mode: +o Terkhen
09:02:59 *** Progman has joined #openttd
09:06:03 *** FLHerne has joined #openttd
09:11:19 *** ericnoan has joined #openttd
09:32:11 *** Alkel__U3 has joined #openttd
09:41:19 *** WormnestAndroid has quit IRC
09:41:32 *** WormnestAndroid has joined #openttd
09:42:53 *** sla_ro|master has joined #openttd
09:47:27 *** DorpsGek has joined #openttd
09:47:27 *** ChanServ sets mode: +o DorpsGek
10:00:19 <andythenorth> there's certainly some noisy demands for it
10:01:25 * andythenorth wonders about modular complete airports
10:01:34 <andythenorth> i.e. airports just become joinable
10:01:40 <andythenorth> but there are no taxi-ways between them
10:02:18 <nielsm> the original city airport would need a lot of special cases under my imagined model
10:02:41 <nielsm> just due to the cross-shaped taxiways
10:06:22 <nielsm> perhaps the solution should be to have some magic multi-tile modules with movements custom defined, but then you're already into complete newgrf airport territory and might as well just do that
10:07:04 <nielsm> regardless even for newgrf airpots, I think defining the state machine could be left out with a sufficiently clever algorithm that works on allowed movements
10:12:57 <Wolf01> Drop the deadlock rule and make aircraft crash :P
10:16:52 <nielsm> nothing would even crash, unless you imagine aircraft parking on the runway and more aircraft then landing there
10:18:01 <Wolf01> Yes, I meant that, also when an aircraft decide to cross a runway at the same time as another one is trying to land
10:25:03 <nielsm> need to support this situation
10:36:02 *** khavik[m] has joined #openttd
10:37:26 *** labs[m] has joined #openttd
10:38:19 *** dude[m] has joined #openttd
10:41:15 *** julie[m] has joined #openttd
10:52:32 <nielsm> would it make sense to allow airports without (reachable) hangars?
11:00:01 <nielsm> expanded a bunch on that ideas page now
11:00:16 *** arron[m] has joined #openttd
11:11:30 *** karl[m] has joined #openttd
11:12:47 <Wolf01> <nielsm> would it make sense to allow airports without (reachable) hangars? <- why not? You won't be able to purchase/replace/service at those
11:12:51 *** robert[m]1 has joined #openttd
11:22:43 *** vanessa[m] has joined #openttd
11:34:39 *** ChanServ sets mode: +o Yexo
11:50:28 <nielsm> I'm closing that with a reference to tt-forums for gameplay and grf dev help
11:50:43 <andythenorth> it's hitting max ship speed I think
11:50:48 <andythenorth> which possibly overflows?
11:50:57 <andythenorth> resulting in a negative speed?
11:51:01 <andythenorth> or is clamped to 0
11:51:14 <andythenorth> redFISH is a fork of FISH
11:51:29 <andythenorth> but I have more projects and ideas than time, and so many bugs on my head already :)
11:51:43 <andythenorth> not going to try and figure out that one
11:52:27 <andythenorth> I like forks, I don't like the obligation I then have to fix the issues in forks :|
11:55:49 <Wolf01> I would like to know what could happen to the people on that ship... would they be splattered to the nearest wall when that happen?
11:56:09 <nielsm> yep the ship that has a speed of 128 km/h goes at absurd slowness
12:07:06 <nielsm> there, made it into a proper report
12:07:51 <nielsm> Wolf01 ah yes maybe it's moving so fast it travels the entire route and then a bit every single tick :D
12:29:12 <Wolf01> So you are looking at a ghost :D
12:29:38 <Wolf01> You can't both see the ship and the speed at which it's going
12:44:37 *** frosch123 has joined #openttd
12:46:04 <DorpsGek_III> [OpenTTD/OpenTTD] FLHerne commented on issue #8177: Ships with max speed overflow to near-zero speed https://git.io/Jf6cI
12:59:16 *** virtualrandomnumber has joined #openttd
13:41:49 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on issue #8177: Ships with max speed overflow to near-zero speed https://git.io/Jf6cI
14:24:42 *** gelignite has joined #openttd
15:02:02 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo closed issue #8098: The transfer value in "Transfer: £[number]" can be negative. https://git.io/Jftgp
15:02:02 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo commented on issue #8098: The transfer value in "Transfer: £[number]" can be negative. https://git.io/Jftgp
15:06:01 *** virtualrandomnumber has quit IRC
15:29:27 <FLHerne> Yexo-: I don't understand, what callback do you think is involved in the ship thing?
15:40:39 <frosch123> yes, CB36 can set speeds up to 0x7FFF
15:42:32 <glx> but I imagine byte casting used on acceleration calculation doesn't like that
15:43:19 <frosch123> most vehiclecontroller have a loop to move a vehicle multiple steps per tick
15:43:35 <frosch123> but iirc ships do not have that, so can only move one world coordinate per tick at max
15:43:56 <frosch123> quite sure people tried to change that in the past, but did not finish
15:44:55 <FLHerne> But CB36 is documented to adjust prop 0B, which is documented as a byte
15:45:08 <FLHerne> So I still don't think it's an actual bug
15:46:01 <frosch123> limitations are never a bug, removing limitations are features
15:46:46 <FLHerne> But currently the issue is tagged as a bug :p
15:48:15 <glx> RV also use a byte prop but I think it's possible to have faster than 127km/h RV
15:48:44 <frosch123> RV have two properties, it's a very silly part of ttdp
15:48:53 <FLHerne> glx: With prop 0B you're limited to 127km/h for RVs
15:49:06 <FLHerne> But prop15 has a different multiplier
15:49:20 <frosch123> which is converted into the same thing in game
15:49:35 <frosch123> anyway, pretty sure RV also have cb36 for speed
15:49:46 <frosch123> so cb36 can set higher speeds than prop15
15:50:47 <glx> prop 08 and 15 are both bytes anyway
15:51:30 <glx> but indeed lower multiplier of prop 15 allows higher speed
16:01:50 <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #8177: Ships with max speed overflow to near-zero speed https://git.io/Jf6cI
16:18:01 <glx> BTW internally max speed is 16 bits
16:22:26 <nielsm> if the ship movement can be changed to work in 16 bits without affecting normal ships I don't see why not
16:23:05 *** Wormnest has joined #openttd
16:55:57 *** andythenorth has joined #openttd
16:59:28 *** Wrench_In_The_Plan has joined #openttd
17:14:33 *** WormnestAndroid has quit IRC
17:15:23 *** WormnestAndroid has joined #openttd
17:17:23 <andythenorth> so anyone tried the tech tree GS?
17:17:45 <andythenorth> can't add it to my running game, and I need to keep this one going for testing newgrfs :P
17:18:19 <Eddi|zuHause> wasn't the speed limit usually because of maximum movement distance per tick?
17:20:36 * andythenorth really wishes the game continued when paused
17:21:22 <FLHerne> Well, you'd still need an actual pause
17:22:54 <andythenorth> I keep thinking about starting a patchpack
17:23:01 <andythenorth> but I am just not good enough at c++
17:23:20 <andythenorth> I've been programming for 37 years, it takes 10 to be good, and I am not good :P
17:29:27 <Eddi|zuHause> "i've been doing this of X years" is never a good argument
17:29:35 <Eddi|zuHause> also, it's 10000 hours, not 10 years
17:30:44 <andythenorth> I was using shorthand :P
17:31:46 <Eddi|zuHause> like lightbulbs that say "1 year" and then go out after 3 months, because you use them for 12 hours a day, instead of 3 like they assumed for "average" use
17:32:30 <andythenorth> so 10k hours would be 3 hours per day for 10 years?
17:33:22 * andythenorth wonders about EddiPP
17:33:41 <Eddi|zuHause> what would that constitute of?
17:34:15 <frosch123> just a turing simulator
17:34:17 <Eddi|zuHause> 10 things that sound good on paper but are eternally unfinished
17:43:21 <andythenorth> probably 10 things the exact opposite of what I would add :)
17:43:32 <andythenorth> and yet many of the ideas in my newgrfs are from Eddi :)
17:43:45 <Yexo> FLHerne: As glx said it's CB36. IMO not an OpenTTD bug. CB36 modifies the original property which is byte-sized, so returning anything larger than 0xFF is a newgrf bug
17:43:59 <andythenorth> is it worth starting a patchpack just to fix tropic landscape gen? :P
17:44:12 <Yexo> And while internal max speed is stored as 16 bits, anything more than 8 bits is not supported by the movement code
17:45:15 <nielsm> ottd should then be warning about a buggy newgrf
17:46:02 <Yexo> It definitely could, but exhaustively warning about everything a newgrf can possible do that's out of spec is not feasible
17:46:05 <nielsm> instead of producing behaviour that's clearly unintended but not clear whose fault it is
17:47:12 <Yexo> ship_cmd.cpp:208 uses CB36 and stores the return value. That'd be the place to introduce an extra check and/or warning
17:47:57 <Eddi|zuHause> just clamp() it?
17:48:28 <Yexo> clamping it has the downside that we hide the issue now, and if at some point in the future we want to expand the spec to allow higher speeds we need to remove that clamp() again
17:48:46 <Yexo> Which might lead to older newgrfs suddenly have ships with higher speeds than intended
17:49:07 <Yexo> For this specific case that's not a problem, but it can hide other bugs
17:49:18 <Eddi|zuHause> that's not a problem, because those grfs were out-of-specs anyway, so no guarantee about keeping their behaviour
17:49:54 <Yexo> If we go that route, we don't have to do anything: they're out of spec, which results in very slow moving ships currently.
17:50:13 <Eddi|zuHause> we'd have to warn about every "but these reserved bits should be zero" instance in the specs
17:53:27 <Eddi|zuHause> so we have two orthogonal options that we can either do or not do: 1) issue a warning for out-of-range, which would amplify the error, and 2) clamp back into range, which would cover up the error
17:55:13 <nielsm> any cb36 warning should probably also have a flag for "has already been shown" to avoid spamming the user
17:59:08 <Eddi|zuHause> next architectural question: should each code calling the callback provide its own range checks, or should the callback handler do the range checking, being provided with the appropriate information (signed, unsigned, lower bound, upper bound)
18:05:33 <frosch123> can we just agree that eddi implements faster ships, and be done with it?
18:05:57 <nielsm> just make all the ships faster yeah
18:09:53 <supermop_Home> switch to a minimum ship speed
18:10:07 <supermop_Home> no ship can go slower than say 70 kmh
18:10:11 <andythenorth> don't write bad newgrfs :P
18:10:34 <andythenorth> I can't find the setting to turn off the vertical gridlines in train depot window
18:10:42 <andythenorth> anyone know what it's called?
18:11:27 <andythenorth> maybe it's in openttd.cfg
18:11:55 <Eddi|zuHause> weren't you the reason they were introduced in the first place? :p
18:12:21 <andythenorth> they're missing in my client
18:12:35 <andythenorth> I want to turn them back on
18:13:15 <andythenorth> or have they been removed recently?
18:13:24 <andythenorth> I couldn't see a commit mentioning removal
18:13:30 <frosch123> they are disabled if you mix 28px and 32px newgrfs
18:13:54 <andythenorth> ok so I need to make my own PIPE grf
18:14:25 <andythenorth> is putting pipelines into Horse out of scope? :)
18:15:27 <nielsm> but why disable them? the point (to me) is to know whether trains will fit in particular stations, not to count cars
18:15:45 <Eddi|zuHause> implement NotPipeTypes?
18:16:10 <andythenorth> the abuse of trains actually works fine
18:16:17 <frosch123> oh, i read the other day that nrt was recoined to newgrf-road&tram-types
18:16:40 <Eddi|zuHause> nielsm: but the platform length is different from the depot pixel length
18:16:40 <andythenorth> I enjoy the evolution
18:16:51 <frosch123> so, we can recoin everything to NoGrf
18:17:04 <andythenorth> I considered merging all my grfs into my patchpack
18:17:10 <Eddi|zuHause> nielsm: so 28px and 32px vehicles need different grid width
18:17:34 <andythenorth> anyway, the PIPE grf really shouldn't work in gameplay, but it really does, for the simple case of short point-to-point routes with one 'train'
18:17:46 <Eddi|zuHause> that, or we deprecate 28px vehicles and stretch everything to 32px
18:17:49 <frosch123> nielsm: the alternative is to draw 4 blank pixels between 28px wagons in depot
18:18:11 <frosch123> both solutions are ugly for some situations :)
18:18:19 <frosch123> both solutions result in bug reports :)
18:18:23 <frosch123> no option is winning
18:18:36 <andythenorth> I have made my peace with bug reports
18:18:48 <andythenorth> frosch123 seems we can kinda just ignore bug reports
18:19:20 <andythenorth> I was very -1, but I am slightly persuaded now, like +0.1
18:19:38 <frosch123> andythenorth: switch to jgrpp
18:19:51 <frosch123> since nrt it probably also has less bugs
18:19:54 <andythenorth> I would, but it doesn't actually do the things I want :P
18:20:04 <andythenorth> it kind of goes the opposite way to what I want
18:20:07 <andythenorth> except daylength
18:20:46 <andythenorth> one day I'll make an NRT grf, and find the bugs :P
18:20:53 <frosch123> you could try to make andy grfs work exclusively in andypp, and see whether that is enough to win the pp competition
18:21:03 <andythenorth> that is what I would do
18:21:07 <andythenorth> also not MP safe
18:21:34 <andythenorth> there are too many things I want to experiment with that require more newgrf API :P
18:22:49 <andythenorth> newgrf town control might be the main one :P
18:23:49 <andythenorth> I'm considering making a 'town' industry
18:24:02 <andythenorth> it would solve a lot of 'problems'
18:24:14 <andythenorth> there might be new problems :P
18:25:05 <andythenorth> did no-one ever do yeti@home?
18:25:26 <andythenorth> your PC scans pictures of the himalayas for cryptids?
18:25:31 <frosch123> it was more about yeti@work
18:25:57 <frosch123> oh, you mean the YETI research project
18:26:03 <frosch123> i think that was canceled years ago
18:26:27 <frosch123> i wonder, what was it's effect in civ1ß
18:27:11 <frosch123> ah, just generic +50% research
18:28:36 <Eddi|zuHause> SETI@HOME was stopped a few months ago
18:29:25 <Eddi|zuHause> but the whole distributed calculation infrastructure is being used for other research projects now
18:32:50 <frosch123> probably for bitcoins
18:33:11 <nielsm> looks like it's just a few minutes now until the astronauts disembarks the Crew Dragon onto the ISS
18:33:16 <frosch123> or is that horse dead yet?
18:34:52 <nielsm> bitcoin still exists and is probably still consuming more energy than the value of the transactions performed
18:36:03 <Borg> saaaatan ;D perfect.. perfect.. ;>
18:36:20 <Borg> PBS back signal as aux path selector
18:36:35 <Borg> took me a while to get correct p0, p1, p2 + pbs_back_penalty
18:36:53 <Eddi|zuHause> no, not bitcoin, but things like protein folding and stuff
18:37:23 <milek7> nielsm: I don't think so, total transaction value is likely huge
18:38:12 <milek7> maybe comparing consumed energy to total mined value
18:40:54 <andythenorth> we should rent our openttd botnet to coin miners?
18:41:17 <andythenorth> based on CPU use, I assume we're doing *something* with the client other than just running the game?
18:41:23 <nielsm> oh yes! make a multithreaded openttd
18:41:33 <nielsm> the other threads don't necessarily play the game tho
18:41:45 <andythenorth> maybe it's just the Horse graphics calculations that take so much CPU
18:41:54 <andythenorth> thread for newgrf action 2 chains? o_O
18:44:17 <Eddi|zuHause> andythenorth: that only works if you can defer reading the resulty by 1 tick
18:44:35 <andythenorth> I'm assuming Horse is to blame
18:47:48 <nielsm> well I did make that newgrf profiling feature which is actually in 1.10 :)
18:54:19 <nielsm> ...but it also requires some more tooling to make sense of the results, I suppose
19:00:19 <andythenorth> seems nml doesn't implement var 0x61?
19:02:31 <nielsm> soryr can't look right now, watching video of a door being opened
19:05:02 <nielsm> but it is several hundred km above the surface of the earth
19:17:42 <Eddi|zuHause> nielsm: that door is probably closer to earth surface than my distance from you
19:19:53 <supermop_Home> is that a sequined dinosaur?
19:22:06 <supermop_Home> i assume that is not official equipment
19:24:53 <SpComb> it's an official SpaceX zero-gravity indicator
19:25:10 <Eddi|zuHause> dinosaurs in space, that was a doctor who episode or something?
19:26:28 <Eddi|zuHause> SpComb: you mean a free fall indicator? because gravity up there is probably still 90% of surface gravity:p
19:27:51 <frosch123> flying is the art of falling and missing the floor
19:35:07 <supermop_Home> we'll i am less interested in watching ted cruz's blue blazer
19:37:35 <frosch123> did he jump out of the dinosaur?
19:43:19 <andythenorth> so what's the go with prop 25?
19:43:34 <andythenorth> I could use it for things like marking up 'this is a passenger car'?
19:43:44 <andythenorth> for the super complicated sprite rules I have?
19:44:54 <andythenorth> nvm, I'll do it in python, less to go wrong :D
19:46:23 <frosch123> prop25 is for communication wagon -> engine
19:48:20 <frosch123> i don't know of a use-case that cannot be done by counting vehids instead
19:54:01 <andythenorth> IDs were my first choice :)
19:54:17 <andythenorth> I have some self-inflicted problems with using them in templating for stored procedures :P
20:04:50 <Eddi|zuHause> frosch123: i think andy's problem is that he wants to count potentially lots of IDs
20:07:55 <frosch123> i wanted to write a for-each operator, but didn't
20:08:18 <frosch123> though now that nml support functions, there is actually a chance of it getting implemented in nml
20:09:19 <Eddi|zuHause> replace prop25 with permanent storage, and make a version of var42 with custom operators (and, or, add, min, max, ...)
20:09:40 <frosch123> declarative languages suck
20:09:57 <frosch123> either for-each or map-reduce
20:10:50 <Eddi|zuHause> functional action 2
20:11:02 <andythenorth> Eddi|zuHause you are correct, but I can count the IDs in python and just do a big switch
20:11:30 <andythenorth> how many values can an action 2 branch on? :P
20:11:46 <Eddi|zuHause> andythenorth: but then you don't have a "position in chain" variable
20:15:09 <andythenorth> I gave up on that case in the assumption it will never be added :)
20:15:48 <andythenorth> there's usually an alternative way to design around the 'problem' which is why I don't mind that newgrf spec is quite conservative nowadays
20:16:10 <andythenorth> what I want to do on Tuesday might be deleted by Friday :P
20:18:38 <andythenorth> also I'm doing the action 2 chain equivalent of trick shots
20:19:04 <andythenorth> making increasingly complicated rules for which sprite to show, modified by neighbouring vehicles :P
20:19:14 <frosch123> andythenorth: there are 255 cases max, but you can chain switches
20:19:29 <andythenorth> thanks, I'll put a guard in
20:19:54 <frosch123> ottd sorts the cases to do binary searches, so many cases are no problem
20:19:56 <Eddi|zuHause> frosch123: i think my dummy switch is closing in on the 255 mark
20:20:51 <frosch123> does it become less dummy if you remove some cases?
20:21:29 <Eddi|zuHause> it's just there so all string ids and "global" action2s are referenced
20:21:59 <frosch123> well, in that case you run out of action2 ids anyway
20:22:10 <Eddi|zuHause> it could trivially be split into two
20:22:37 <Eddi|zuHause> i think string ids are 12 bit or so
20:25:39 <Eddi|zuHause> i was at 187 strings and action2s went 188 to 252
20:27:10 <Eddi|zuHause> i could probably rewrite the action2s with procedures, which ideally would eliminate all but one
20:27:41 <frosch123> sounds like cets source would shrink from 100MB to 1kB
20:28:14 <Eddi|zuHause> i think the combined source file was something like 11MB
20:28:31 <Eddi|zuHause> which is roughly the same as FIRS
20:30:04 <frosch123> horse was 15MB a year ago (that's what's on my disk)
20:30:54 <Eddi|zuHause> by "combined source file" i meant what's fed into nmlc
20:32:21 <Eddi|zuHause> nfo source is 19MB, final GRF is 22MB
20:39:39 *** sla_ro|master has joined #openttd
20:40:02 <andythenorth> I could frosch123 Horse is 6.9MB currently
20:41:57 <frosch123> aw, i looked in the wrong row, 15 was the .grf :/
20:44:03 <Speeder_> can an experient OpenTTD player tell me what is the problems of using industries sets that have lots of cargos?
20:44:08 <Speeder_> compared to using something more simplier, that is.
20:45:17 <Eddi|zuHause> mixed trains may be tricky to set up, trains which focus on one single cargo are simpler
20:45:34 <andythenorth> Speeder_ how long have you got? :)
20:45:46 <Eddi|zuHause> not all vehicle sets support all cargos, or refit at stations
20:45:49 <Speeder_> andythenorth, I am not going anywhere :P
20:46:07 <andythenorth> frosch123 I'm sure Horse *was* 15MB or so until procedures were added to nml
20:46:37 <andythenorth> Speeder_ problems of many cargos (list follows)
20:46:42 <andythenorth> - overwhelming to players
20:46:56 <andythenorth> - makes the cargo payment chart unusable
20:47:07 <andythenorth> - makes the station list unusable (silly 2 char abbreviations)
20:47:28 <andythenorth> - makes the cdist cargoflow unusable
20:47:40 <Speeder_> Eddi|zuHause, ah, so that is not just my impression... I had a bunch of sailing ships routes that were working fine until I switched to a SQUID ship... then the route broke down due to refit at station misbehaving.
20:47:40 <andythenorth> - is hard to design a good grf with
20:47:45 <andythenorth> - takes a long time to play test
20:48:07 <andythenorth> - makes the vehicle refit menu unusable
20:48:17 <andythenorth> - makes the vehicle refit at station menu unusable
20:48:37 * andythenorth can't think of much else,
20:49:08 <Eddi|zuHause> Speeder_: cargodist doesn't properly maintain routes for which a vehicle could be refitted to, only if it actually ran with that refit at least once in the last <some period (2 years?)>
20:49:42 <Speeder_> Eddi|zuHause, I noticed that too
20:50:17 <Speeder_> also noticed cargodist sometimes ignore capacity entirely
20:50:55 <Speeder_> for example I had the following situation: diamond mine -> 70 ships -> far away port. then I built one ship to a closer new port. cargodist solution was send half of the cargo to each port, ignorign one had 70 ships and the other had 1
20:51:06 <andythenorth> cdist almost entirely ignores capacity
20:51:31 <Speeder_> how cdist chooses destination anyway?
20:51:39 <andythenorth> there's no destination
20:51:43 <andythenorth> just a 'next hop'
20:51:47 <Eddi|zuHause> cargodist only ever chooses "next hop"
20:51:48 <Speeder_> for example I Saw a bunch of conflicting opinions on reddit about what settings to use with FIRS
20:52:04 <andythenorth> with FIRS you should use 'effect of distance on demand: 0%'
20:52:06 <Eddi|zuHause> everything else is just guesswork and statistics
20:52:12 <andythenorth> but unfortunately that breaks cities
20:52:22 <andythenorth> so you can't use 0%
20:52:26 <Speeder_> what "effect of distance on demand" does exactly?
20:52:39 <andythenorth> further away hops get less cargo assigned
20:53:05 <andythenorth> cargodist is remarkable, but it really doesn't do what people think it does
20:53:18 <Eddi|zuHause> Speeder_: for cargo, you need low effect of distance, so supplies are distributed evenly across all destinations, but for passengers, you need high effect of distance, or all links will be hopelessly overloaded
20:53:49 <Speeder_> Eddi|zuHause, and lemme guess... ottd doesn't support splitting the effect like that?
20:54:52 <andythenorth> also for cdist with FIRS, you can only serve 2 destinations per pickup station
20:55:29 <Speeder_> andythenorth, why is that?
20:56:57 <andythenorth> subsequent destinations will take a *very* long time to get assigned cargo
20:56:58 <Eddi|zuHause> 2 is a bit exaggerated, but the more you try, the more likely one will end up empty
20:57:13 <Speeder_> totally unrelated question: OTTD behaves well if I rename "existing" cargo? or stuff will break?
20:57:41 <andythenorth> once 2 links are up, no 'any destination' cargo seems to be generated
20:57:58 <andythenorth> I never figured out quite what the issue is, I just changed the way I play the game
20:58:10 <andythenorth> fonso did look into it, but there was no conclusion
20:58:13 <Speeder_> andythenorth, oooh... I see what you mean, I saw that even wiht only one destination
20:58:22 <andythenorth> no it should be fine with one destination
20:58:25 <Eddi|zuHause> Speeder_: you should stay away from modifying passengers, mail, goods or food
20:59:05 <Speeder_> Eddi|zuHause, I heard this is because houses are kinda hardcoded to expect these in certain slots and all
20:59:09 <Speeder_> but what about other cargo?
20:59:45 <Eddi|zuHause> most other cargos should be fine
21:00:52 <nielsm> water can also be risky
21:01:52 <Speeder_> but if I rename for example beans, as "soybeans", would that break newgrfs that rely on beans?
21:02:24 <Eddi|zuHause> no, newgrfs only look for the cargo label
21:03:01 <andythenorth> but if they're soybeans, change the label to SOYB
21:03:03 <nielsm> and AI and GS should also only be looking at the cargo label
21:03:16 <Eddi|zuHause> (but graphics will be wrong if you get too creative with the original expectations)
21:03:21 <andythenorth> there was a fad for reusing labels for a long time
21:06:19 <andythenorth> because apples aren't oranges
21:06:33 <andythenorth> call a thing what the thing is
21:06:51 <Speeder_> well, soybeans are still beans...
21:06:57 <nielsm> if you change BEAN to be soybeans then you can't have "plain beans" any longer
21:06:59 <andythenorth> everything is just cargo then
21:07:10 <andythenorth> there is also a long standing joke about STUF
21:07:16 <nielsm> just distinguish things unless there's an extremely good reason not to
21:07:19 <andythenorth> the one-cargo game
21:07:24 <andythenorth> only one cargo needed
21:07:34 <andythenorth> 'accepts: Stuff, produces: Stuff'
21:07:38 <Speeder_> I wonder if anyone ever made a newgrf about STUF
21:08:22 <Eddi|zuHause> i should make a GRF where your goal is to produce 1 item of "Passierschein A38"
21:09:11 <Speeder_> nielsm, my newgrf probably will end with 40+ cargos... I am trying to figure out if there are reasonable ways to diminish that
21:09:20 <Speeder_> but at same time I wanted to reproduce accurately Brazillian exports
21:09:31 <Speeder_> Brazil exports ridiculous amounts of soybeans
21:09:36 <frosch123> Speeder_: there is an ancient grf that renames goods to stuff
21:09:41 <Speeder_> and of "soybean powder as byproduct of making soybean oil"
21:09:53 <frosch123> and with ancient i mean probably as old os ottd
21:11:55 <andythenorth> Speeder_ Tropic Basic just did Beans, even though it's obviously Soybeans IRL :P
21:12:05 <andythenorth> 40+ cargos sounds about right
21:12:23 <andythenorth> the beans in FIRS are Brazilian :P
21:13:08 <frosch123> Eddi|zuHause: sounds more like a gamescript
21:13:17 <Speeder_> andythenorth, basically when I was seeing FIRS documentation I noticed all brazillian cargos were present, but spread ou many economies
21:13:22 <Speeder_> so I decided to make a new one.
21:13:37 <frosch123> Eddi|zuHause: you can probably make a fork from bee rewards
21:13:52 <Speeder_> for example cassava is staple food here, my parents grow it in their backyard, and cassava flour is popular addition to our barbecue
21:14:44 <frosch123> Eddi|zuHause: just randomise the cargos that shall be transported, independent of which cargos are available at the source or accepted at the destination
21:14:57 <frosch123> transport steel from coal mine to oil refinery
21:22:47 *** jottyfan has joined #openttd
21:29:11 <andythenorth> if you mix industry grfs, that option becomes available :P
21:29:20 <andythenorth> also if I make a mistake in FIRS compile
21:29:57 * andythenorth considers if 'restaurant car' should be a thing
21:30:03 <andythenorth> currently it's an auto-magical sprite
21:34:20 <DorpsGek_III> [OpenTTD/OpenTTD] Yexo opened pull request #8178: Simplify code by removing 2 global variables. https://git.io/Jf6oM
21:38:01 <nielsm> restaurant cars typically carry few passengers though
21:38:27 <andythenorth> and there's no gameplay effect :)
21:38:34 <andythenorth> bit like brake vans though
21:38:40 <andythenorth> or snowploughs :P
21:38:59 <Speeder_> I wish special cars DID had an effect
21:39:07 <Speeder_> like luxury passenger car getting you better rates
21:39:15 <Speeder_> maybe if there was another passenger cargo
21:39:18 <andythenorth> that's possible if you play on huge maps
21:39:22 <Speeder_> I wonder if it is possible to make a second passenger cargo
21:39:28 <andythenorth> if you play on maps where the normal cars won't make money
21:39:41 <andythenorth> then the cargo aging bonus can be used
21:40:00 <andythenorth> but it's not an actual gameplay choice, just a way to work around the failure of large maps
21:40:01 <Speeder_> create a "wealthy passenger" cargo, that requires luxury cars and restaurant car to board a train
21:40:10 <nielsm> the problem is that the entire way passengers and cargo decides/is decided how and where to get transported is upside down
21:40:18 <nielsm> and you can't really change that
21:40:21 <andythenorth> bu then you have to make your own house set to
21:40:45 <andythenorth> I have long wanted a payment bonus / malus property
21:41:09 <Speeder_> andythenorth, you can always make your newgrf support "wealthy passenger" and maybe one day someone will implement that cargo in their house newgrf :)
21:41:51 <DorpsGek_III> [OpenTTD/OpenTTD] frosch123 approved pull request #8178: Simplify code by removing 2 global variables. https://git.io/Jf6Kf
21:41:58 <nielsm> there isn't any way (iirc) to make houses produce other cargo than PASS and MAIL
21:42:59 *** Wrench_In_The_Plan has quit IRC
21:43:53 <Speeder_> nielsm, maybe a city-focused "industry" newgrf?
21:45:17 <frosch123> it probably breaks the cargo flow graph though :)
21:45:50 <andythenorth> Speeder_ just make an industry grf that also provides houses
21:45:52 <frosch123> stations will not even show it as supplied
21:46:22 <frosch123> which means that cdist will likely not work either
21:46:49 <frosch123> so, likely that house production stuff does not work at all :p
21:47:02 <andythenorth> 'probably fine' :D
21:47:17 <Speeder_> I wonder how far people will push this game
21:47:31 <Speeder_> I wish there was a open source version of SimCity 4
21:47:36 <andythenorth> it pushes back when you push hard enough
21:47:43 <Speeder_> that is a game that needs lots of recoding :(
21:47:54 <Yexo> So how did ECS tourists work? Or was that produced/accepted only by industries?
21:48:01 <andythenorth> there's a castle
21:48:09 <andythenorth> and it might be that TTRS works with it
21:48:23 <andythenorth> it's before my time stuff though :)
21:48:35 <frosch123> Yexo: i think industries only
21:48:56 <frosch123> hmm, though there is a ecs-houses grf
21:49:01 <frosch123> with hotels and stuff
21:49:28 <Eddi|zuHause> Yexo: there's a house set that provides houses for tourists and fuel stations, if you didn't use the then-standard house set that i forgot the name of
21:49:51 <frosch123> Eddi|zuHause: fuel is acceptance, not production
21:50:43 <andythenorth> hmm, /me back at var 40, 41 again
21:51:31 <frosch123> Yexo: turns out, AddProducedCargo_Town actually calls that callback as well
21:51:55 <frosch123> so as long as it returns constant results over longer time, it probably work
21:52:23 <Speeder_> by the way, can you query for the current date inside a newgrf?
21:52:36 <frosch123> yes, but it has issues
21:52:38 <Speeder_> for example to make hotels not pump out 300+ passengers per month in 1700
21:53:00 <Eddi|zuHause> caching issues could desync the game
21:53:19 <frosch123> if you change graphics depending on date, you may get partial/mixed redraws when the date changes
21:53:20 <andythenorth> no reported desyncs from FIRS doing
21:53:22 * Speeder_ never played OTTD multiplayer so... has no idea what that is about.
21:53:32 <andythenorth> the partial redraw is a thing
21:54:05 <Speeder_> as in... some tiles acknolwdge change in date and others don't?
21:54:17 <frosch123> when a vehicle passes a house, half of the house may get redrawn, while the other half remains unchanhed
21:54:23 <andythenorth> hmm, I need a var like train var 41, but non-consecutive,
21:54:25 <glx> andythenorth: I think var61 is not implemented because the syntax won't be simple
21:54:28 <frosch123> so the screen shows partially the old, partially the new sprite
21:54:51 <Yexo> Speeder_: OpenTTD multiplayer works by having the server and all clients all do the same simulation. Some values are cached and some NewGRF callbacks are executed by the client when it joins the game. If the newgrf callback gives a different value for that client compared to the last time it ran on the server, the client and server now have a different value for something that should be qual
21:54:53 <andythenorth> glx what could be not simple about "[STORE_TEMP(-1, 0x10F), var[0x61, 0, 0x0000FFFF, 0xC6]]" :D
21:55:22 <Yexo> If that's for pure graphs, it's likely fine. If that's for something like vehicle speed that'll result in a desync since the vehicle will move at different speed on the client and server
21:56:19 <andythenorth> if only action2 could recurse :(
21:56:23 <Eddi|zuHause> glx: i think the syntax would just be: <var_name> [ '(' <offset> ')' ]
21:56:31 <andythenorth> I could walk the consist, and wouldn't need new vars
21:56:44 <andythenorth> I supposed I could encode switches for consists with lengths 1-255
21:56:52 <andythenorth> probably trivial to generate
21:57:59 <andythenorth> hmm, maybe user bits? o_O
21:58:30 <frosch123> Eddi|zuHause: glx: there is probably an old devzone ticket, which suggests adding scopes, like "parent.random_bits", "self.random_bits", "relative_vehicle[5].random_bits"
21:59:10 <Eddi|zuHause> i remember suggestion about scopes, but i don't think it went into syntax
21:59:18 <frosch123> Eddi|zuHause: glx: oh, also "callback.name_for_var_10_18_bit_stuff"
22:00:16 <andythenorth> as usual when I want new version of var 41, turns out I'm trying to do something I shouldn't :D
22:00:27 <andythenorth> this is the 3rd time I'll find a better way instead of a new var
22:02:32 <frosch123> looking at the nml issue tracker on devzone is always fun
22:02:48 <frosch123> it contains all the things that are discussed here regulary
22:03:00 *** Wrench_In_The_Plan has joined #openttd
22:03:36 <Eddi|zuHause> because nobody ever implements anything, all discussions run in circles? :p
22:04:14 <glx> and when we implement stuff othre things break ;)
22:04:20 <frosch123> in the past people at least wrote stuff down. now they prefer to forget it immediately, so it can be discussed again
22:05:13 <andythenorth> it's fun the first 5 times :)
22:05:19 <andythenorth> after that...less
22:05:24 <Eddi|zuHause> frosch123: that's because some people went on a rampage and closed tickets
22:05:49 <Eddi|zuHause> so people stopped opening tickets
22:05:59 <andythenorth> rampage? 800 tickets is more than a rampage
22:06:22 <andythenorth> also the evidence is against the claim that they stopped
22:06:39 <andythenorth> just that PRs no longer increase the ticket count
22:07:20 <frosch123> more than reviews :p
22:08:11 <andythenorth> it's like an R number :P
22:08:27 <andythenorth> if PR > reviews, then there's only one outcome :)
22:08:43 <andythenorth> I rarely close a PR
22:09:18 <andythenorth> what was I looking at?
22:09:22 <andythenorth> oh coop nml project
22:10:35 <frosch123> someone should transfer the issues that contain spec/syntax proposals to the wiki :)
22:11:06 <glx> but yes some requests are valid, just nobody looks at the old repo
22:11:24 <andythenorth> was automated issue transfer too hard?
22:11:38 <andythenorth> I would do it manually, but I am actually making newgrfs, and have missed doing that
22:11:41 <frosch123> 3 people started, noone finished
22:12:03 <andythenorth> there is some irony that there are many NRT grfs, but I have not had time to make one :)
22:12:09 <andythenorth> it's like the ultimate NRT fact
22:12:12 <glx> it's not easy to do the transfer once issues and PR exists on github
22:12:38 <frosch123> glx: the numbering does not matter, coop uses global numbers, so you would never want to keep those
22:13:02 <frosch123> in case of nml, it's also not worth transfering close issues
22:13:19 <frosch123> it's more useful to safe issues that contains actual thoughts
22:13:58 <Eddi|zuHause> i think the main issue is keeping the links from old commit message to matching ticket number
22:14:16 <frosch123> no, that is no issue, because it is not needed
22:14:32 <frosch123> it's nice for ottd, because it has arcane artefacts. but not needed for nml
22:23:10 <Speeder_> Yexo, so how I aovid desync if I am querying dates to change production?
22:23:59 <Speeder_> and there are many things you CAN do in a newgrf that nml can't?
22:24:53 <Eddi|zuHause> there are a few things
22:25:14 <andythenorth> not much else now
22:25:17 <Eddi|zuHause> or some crazy hacks that are intentionally left out
22:25:48 <Speeder_> why stations are not in nml?
22:25:53 <Speeder_> and now... what crazy hacks can be done?
22:32:07 <frosch123> Speeder_: caching/desyncs/var61 are vehicle stuff
22:34:33 <frosch123> Speeder_: ttdp wanted to make many things available with little effort, so it exposed internal ttd data as raw data, independent of how useful it is or whether it makes any sense
22:34:53 <frosch123> Speeder_: nml only supports stuff that "can be explained" :p
22:55:36 <FLHerne> frosch123: That's not how the code's used
22:57:16 <FLHerne> NML calculates the internal grf speed value, *then* calls ottd_display_speed to check if it gets displayed correctly
22:57:20 <frosch123> iirc it does a binary search to find the nfo value, by comparing whatever that function returns with whatever was written in the nml source
22:57:28 <FLHerne> (and to clamp it to the range where it is)
22:58:33 <FLHerne> There's no binary search
22:58:59 <FLHerne> It increments/decrements the grf value by 1 until ottd_display_speed gives the right answer
23:00:40 <FLHerne> I have been wondering if this is a sane way to do it :p
23:00:52 <FLHerne> There's a lot of semi-duplicated code
23:01:36 <frosch123> ok, then the comment above it should probably say "duplicate OpenTTD's Vehicle::GetDisplaySpeed and AircraftVehicleChangeInfo"
23:04:52 <FLHerne> I think we should probably be doing something similar for other units, too
23:05:33 <FLHerne> People probably notice off-by-one errors in power less
23:06:47 <frosch123> i think no other units are as crazy as the speed units :)
23:11:58 <nielsm> radical idea: change to a new speed unit internally in the game, one that is entirely consistent between vehicle types, and has enough precision to convert accurately to both mph and km/h display
23:12:18 <nielsm> and allow newgrfs to use those units too
23:19:17 <Eddi|zuHause> nielsm: changing the grf units probably needs grfv9
23:20:07 <FLHerne> Eddi|zuHause: Or just adding a new vehicle property?
23:20:37 <frosch123> FLHerne: it's not just properties, it's also callbacks and variables
23:20:49 <FLHerne> (of course, RVs would then have *3* speed properties, so that might not be such a good idea...)
23:21:00 <frosch123> and adding a second callback results in andy's favorite dependency graph
23:21:34 <Eddi|zuHause> while at it, also allow better price range
23:22:00 <frosch123> no idea what part of that was intentional :)
23:22:25 <andythenorth> I do love those diagrams though
23:23:10 <andythenorth> it's remarkable that you managed to document it
23:23:40 <frosch123> oh, i spent a lot of time reading ttdp source
23:23:41 <Eddi|zuHause> that's what happens when specs follow implementation instead of the other way around
23:25:05 <andythenorth> so....a new version of var 41, with consecutive IDs matching a list?
23:25:11 <frosch123> i tried to make it consistent by adding the alternative method shown in the section below.
23:25:32 <frosch123> unfortunately it is not the default, and everyone is scared by the graphs, so noone uses it
23:26:08 <frosch123> andythenorth: no, a new procedure call. call switch for each vehicle in the chain, and combine the results
23:26:28 <glx> grfv9 could be a good idea to get station with a sane interface/logic ie action2 like other tile layout
23:26:30 <frosch123> then the callee switch can check whatever, instead of a single thing
23:27:02 <nielsm> glx: sounds like you want to deprecate a ton of old stuff to the extend the entire newgrf stack might need to be implemented twice in ottd
23:27:27 <Eddi|zuHause> if nobody makes a ticket for collecting these grfv9 ideas, nobody will remember them when grfv9 is actually being implemented :)
23:27:52 <andythenorth> frosch123 procedure call sounds valid....but can't I already do that if I write enough switches?
23:28:15 <andythenorth> assuming consist is max 255 vehicles :P
23:28:29 <frosch123> andythenorth: consist is actually max 127 vehicles
23:28:47 <Eddi|zuHause> andythenorth: no, you can only call procedures on the current vehicle, not other vehicles in the chain :p
23:28:49 <glx> station spec looks like a big hack from before houses and industries
23:28:56 <andythenorth> Eddi|zuHause but I can var 61
23:29:01 <frosch123> andythenorth: anyway, the tricky part is the "reduce" step. ideally the "map" step is independent of execution order
23:29:53 <frosch123> glx: you can make them pretty similar, if you remove the ability to define custom sprite layouts
23:30:26 * andythenorth tries to figure out a consist ID counter solely in recursive var 61 checks :P
23:30:33 <frosch123> custom sprite layouts mostly result in grf bugs. usually there is only one way to use them correctly
23:30:37 <andythenorth> the code generation would be hideous :)
23:33:21 <Yexo> glx: I've looked at adding station support to NML. From what I've seen so far the main issue is that the actual sprites are not included in the sprite layout like for other features, but defined later. And at that later point (action2) you can't change the sprite layout, only the actual sprites
23:33:58 <frosch123> Eddi|zuHause: nielsm: btw. both your suggestions (use common speed unit that works for both km/h and mph; and bigger price range) are on that 5 year old wiki page :p
23:34:10 <frosch123> so, same as with nml tracker :)
23:34:13 <Yexo> It looks like it may be possible to abstract that away via the advanced sprite layout
23:34:33 <glx> Yexo: I looked at chip source, and I see sprites are defined via actionA, which is weird for me
23:34:47 <Yexo> Basically: combine all different sprites into one giant spritelayout, then enable/disable parts via register modifiers
23:35:19 <Yexo> actionA + GRM to get sprite numbers?
23:35:24 <frosch123> Yexo: or only offer two sprite layouts: track-tile and non-track-tile
23:36:08 <Yexo> frosch123: but that means custom syntax and not being able to reuse the existing spritelayout blocks
23:37:04 <Yexo> Is there any cooperation between newrailtypes and custom stations?
23:37:15 <nielsm> Yexo am I understanding it right that stations need a kind of indirect spritelayout, while everything else right now uses a "direct" spritelayout?
23:37:41 <nielsm> could it maybe be possible to introduce the indirect spritelayout as a general syntax available for everything, and compile it differently depending on context?
23:37:52 <frosch123> Yexo: stations are supposed to draw the normal rail ground sprite. ottd intercepts that and calls the railtype grf instead
23:38:11 <frosch123> snowy rail ground also works or something
23:38:20 <Eddi|zuHause> non-track tiles should become a separate tile type that works for all station types, instead of being a train station tile
23:38:27 <Yexo> frosch123: thanks, I'll need to look at the drawing code for sure
23:38:49 <Eddi|zuHause> that would allow solving an issue where you can't put them on (some) slopes
23:38:56 <frosch123> there was a lot of speccing with elyon some years ago
23:39:40 <Yexo> frosch123: not yet, thanks (me reads what I've written 9 years ago)
23:45:21 *** jottyfan has joined #openttd
23:47:09 *** WormnestAndroid has quit IRC
23:47:59 *** WormnestAndroid has joined #openttd
23:53:37 <andythenorth> frosch123 call procedure on each vehicle in the chain <- worth writing down? :P
23:54:51 <frosch123> it's on my page with the title "consist search". i have no more insights beyond the title :)
23:55:20 <andythenorth> the case I have is really quite invalid :)
23:55:32 <andythenorth> it's just become a game in itself :P
23:56:00 <andythenorth> I still play the meta-game of 'but can I in newgrf?'
23:56:22 <frosch123> originally the idea was insprited by snails requests for arcane variables
23:56:52 <andythenorth> I have some magic to draw railcars with cabs or not
23:57:01 <frosch123> i can't remember what exactly. but it was along the lines of those industry tile variables that noone uses
23:57:07 <andythenorth> I want it to work across multiple IDs for other reasons
23:57:15 <andythenorth> my case is silly though
23:57:42 <Yexo> frosch123: Thanks for the link. That discussion goes in the same direction as I was thinking: mostly keep the existing syntax as-is, but then goes further (in a good way!) to define required magic necessary for stations
23:57:57 <Yexo> That specs solves several issues I hadn't even seen yet
23:58:15 <andythenorth> if we ever _did_ add vehicle variants (grouping multiple IDs)...then something equivalent to a var 41 would be needed
23:58:20 <andythenorth> but we didn't so eh :)
23:58:33 <frosch123> Yexo: i certainly don't remember any details. but glad that the written stuff helps
23:59:08 <Yexo> Was anything done except for discussing syntax?
23:59:30 <frosch123> elyon did stuff, but i am not aware of anything published
23:59:50 <frosch123> possibly it did not go beyond refactoring existing stuff
23:59:56 <DorpsGek> Yexo: elyon was last seen in #openttd 5 years, 20 weeks, 0 days, 3 hours, 57 minutes, and 3 seconds ago: <Elyon> hiya
continue to next day ⏵
