IRC logs for #openttd on OFTC at 2026-02-12
⏴ go to previous day
01:23:24 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
01:24:03 *** MinchinWeb[m] has joined #openttd
01:24:43 *** davidxn has joined #openttd
01:24:43 <davidxn> ^ I got halfway through a video section explaining this tangle of "mult = -1 (or 1 if you've transported twice as much as half of what was missing from last month)" and took it into my own hands 🙂 The code is longer but needs about 1/10th of the comments explaining itself
01:34:59 <davidxn> sorry sorry ignore all that i don't know how to use git
02:43:42 *** Wormnest has quit IRC (Quit: Leaving)
04:23:53 *** Zathras_11 has joined #openttd
04:27:15 *** Zathras_7 has quit IRC (Ping timeout: 480 seconds)
05:11:24 <DorpsGek> - Update: Translations from eints (by translators)
07:06:24 *** Ttech has quit IRC (Remote host closed the connection)
07:31:59 <andythenorth[d]> do cargos have badges? 👀
07:35:36 *** Smedles has joined #openttd
07:36:30 *** Smedles_ has quit IRC (Read error: Connection reset by peer)
07:59:10 <andythenorth[d]> cargos do not have badges in the spec
08:05:19 <LordAro> well, it's not going to work again now
08:24:47 *** gorantev has joined #openttd
08:24:47 <gorantev> At what point can we expect Railway type ID's being expanded again? Some rail sets (JP+ Rails specifically) already have more rail types than can fit 64 limit by itself (thus, configuration options to switch different rail types on and off), and mixing railtype-adding newGRF's sometimes turns into shuffling mini-game, trying to debug and get rid of annoying "invalid sprite" errors.
08:26:13 <andythenorth[d]> that's now how it works
08:26:17 <andythenorth[d]> there's no roadmap
08:26:30 <andythenorth[d]> the prevailing view currently is that 64 types was a mistake
08:26:34 <andythenorth[d]> and shouldn't have been done
08:26:43 <andythenorth[d]> other views have been tested in PRs
08:27:26 <gorantev> andythenorth[d]: Too little, or too allowing?
08:28:28 <ahyangyi> I do understand that people might prefer a more modular approach
08:28:28 <gorantev> ahyangyi: Game balance, apparently, if I understand andythenorth correctly.
08:28:40 <ahyangyi> No, balance has no meaning AFAIK
08:28:42 <andythenorth[d]> 1) UI falls apart
08:28:49 <andythenorth[d]> 2) grf authors constantly argue about it
08:28:56 <andythenorth[d]> 3) lots of the railtypes are just weird
08:28:59 <andythenorth[d]> and shouldn't exist
08:29:12 <ahyangyi> Only 1) looks like a real problem to me
08:29:33 <ahyangyi> Few of the NewGRF railtypes are weirder than Toyland
08:29:43 <ahyangyi> How is that a problem at all 😛
08:30:10 <gorantev> ahyangyi: He meant, that having dozens of railtypes *by itself* is weird.
08:30:13 <andythenorth[d]> expanding the number of types has produced all kinds of weird stuff
08:30:28 <andythenorth[d]> like railtypes that cause narrow gauge vehicles to go on standard gauge track
08:30:35 <andythenorth[d]> and many kinds of voltages
08:31:01 <ahyangyi> That's a railtypetable problem
08:31:02 <andythenorth[d]> and endless railtypes to set the ground tile
08:31:17 <ahyangyi> which is separate from a railtype problem
08:32:05 <gorantev> andythenorth[d]: Voltages actually make sense from modelling perspective. Not that every player likes to deal with that, but that's what options are for.
08:32:25 <andythenorth[d]> yeah but it will never work, unless it's a dedicated railtype <-> train grf set up
08:32:32 <andythenorth[d]> and players like to combine
08:32:43 <andythenorth[d]> any, I guess my point is not about judging what authors should be allowed to do with the grfspec
08:32:49 <andythenorth[d]> it's that none of this is fun or appealing
08:33:01 <ahyangyi> Alright, so I guess the situation is better described as "blocked by railtypetable problems"?
08:33:04 <andythenorth[d]> changes get made when the problem is interesting
08:33:27 <ahyangyi> I definitely don't want to get in railtypetable debates
08:33:30 <andythenorth[d]> changes don't get made when the problem is primarily that a bunch of grf authors are like cats in a sack, having a pissing fight
08:33:48 <ahyangyi> so if that's the blocker, then... I just acknowledge that 😛
08:34:05 <andythenorth[d]> there is also map space and UI
08:34:08 <andythenorth[d]> the UI is shit
08:34:14 <andythenorth[d]> and the map may not have free bits
08:35:03 <ahyangyi> Map can be extended if needed, and UI might be saved by badges, I gues the problem is that none of these are very fun
08:35:30 <andythenorth[d]> they're not fun
08:35:58 <ahyangyi> too many loosely related problems tightly coupled
08:36:18 <ahyangyi> It's one thing if I just come up with a PR that promises better rail type UI with badges
08:36:24 <andythenorth[d]> it's non-trivial because railtypes are not independent of each other
08:36:38 <andythenorth[d]> but we're not prepared to take the prevailing view we've taken with cargos
08:36:39 <ahyangyi> It's another thing if I want UI change, map data structure change, rail type table overhaul and badges
08:36:58 <andythenorth[d]> railtypes modify each other, and the modification is dependent on load order
08:37:08 <andythenorth[d]> so expanding the space is also unappealing
08:37:18 <andythenorth[d]> and many authors don't understand the railtype spec
08:37:20 <gorantev> The simplest solution (but also most memory-intensive one and doesn't play nice with UI), is to give an equivalent of 16-bit integer limit (or larger) worth of railtype ID's, and let newGRF authors handle ID placements. But then, as mentioned above, UI is going to get messy without reworks, and memory usage isn't going to be good either. So the better solution needs to be found, and from what I
08:37:20 <gorantev> had just read, it isn't going to be very fun.
08:37:48 <andythenorth[d]> compounding it, nearly zero train grf authors understand the spec
08:37:51 <ahyangyi> gorantev: The problem is not only allocating stuff, but to decide what is compatible with what
08:37:57 <andythenorth[d]> and they've built elaborate cargo-culting of compatibility
08:37:58 <ahyangyi> in a cooperative fashion
08:38:01 <gorantev> ahyangyi: Good point.
08:38:19 <andythenorth[d]> railtypes lacked any type of class or category system
08:38:33 <andythenorth[d]> and much work has been put into semantically-meaningful railtype labels
08:39:01 <andythenorth[d]> this was unwise
08:39:12 <andythenorth[d]> but only in retrospect 😛
08:39:16 <ahyangyi> I just don't believe in semantics
08:39:21 <ahyangyi> in a game with Toyland 😛
08:41:43 <ahyangyi> From the discussion I do feel that rail type badges can be a meaningful first step though, for that:
08:41:43 <ahyangyi> 1. it's limited in scope and does not touch anything else
08:41:43 <ahyangyi> 2. it brings observable change (UI change)
08:41:43 <ahyangyi> 3. it is a potential foundation of new solutions to rail type tables in the future
08:41:55 <andythenorth[d]> we do have badges on railtypes
08:42:10 <ahyangyi> Do we have the UI to use them though?
08:42:18 <andythenorth[d]> can't remember, might be a PR
08:42:45 <ahyangyi> I have a question, can we store metadata on a badge type
08:42:53 <ahyangyi> Or... can badges have badges?
08:43:17 <gorantev> ahyangyi: ...that sounds like overcomplicating the system.
08:43:20 <ahyangyi> Such as, "have third rail" and "don't have third rail" are both "whether you have third rail"
08:43:22 <andythenorth[d]> it's a large flat namespace, nesting would be....unwise
08:43:52 <ahyangyi> Probably not a good example
08:44:24 <ahyangyi> Anyways, if we want a better way to organize 64 rail types than a list or a search box
08:44:34 <ahyangyi> we might want some hints about what badge is which
08:44:56 <andythenorth[d]> the leading substring is the badge class
08:45:28 <andythenorth[d]> which is what drives the vehicle badge filters and display
09:03:43 *** Smedles has joined #openttd
09:11:49 <pickpacket> I can't find the setting for toggling one-way roads
09:12:39 <mmtunligit> is there one? i thought you just needed to have the road build tool active first
09:12:57 *** alfagamma7 has quit IRC (Quit: User went offline on Discord a while ago)
09:15:53 <pickpacket> mmtunligit: nothing happens when I push that button
09:16:32 <pickpacket> mmtunligit: thanks
09:47:01 <Rubidium> gorantev: I don't think any of the current developers has any intention to increase the number of rail/road types, so it won't happen. Also, increasing the limit is fairly trivial, it's just all the usability issues that are complicated and need a lot of thought and work. Finally, what's in it for the common player to have to choose from dozens of gauges, dozens of electrification schemes, dozens of
09:47:07 <Rubidium> safety systems, dozens of clearange gauges and dozens of rail qualities, dozens of manufacturers and dozens of hardnesses?
09:57:31 *** SigHunter has quit IRC (Remote host closed the connection)
09:59:35 *** SigHunter has joined #openttd
10:00:38 <Rubidium> gorantev: unless someone else comes with a solution for all the current problems with the 64 rail/road types, and any increase of the number of rail/road types
10:06:13 <peter1138> That and the dropdown filter :)
10:06:30 <mmtunligit> i think you could sort of psuedo make it work if you had a railtype composer from all the individual parts and then index the composed types, so railtype GRFs would provide like gauge attributes, electrification attributes and so on, along with optional presets, that way the list length can be entirely dependent on the player. i havent really thought this through w/rt legacy compatability and MP
10:06:30 <mmtunligit> stuff but im sure something could be worked out. not a high priority in any case
10:08:02 <mmtunligit> but that way you decouple all the different ways you can have a rail from needing to fit into 64 types for the map array
10:08:33 <andythenorth[d]> it would still need to compose into 1 of 64 types
10:08:51 <andythenorth[d]> even if it's player composable
10:12:17 <ahyangyi> Composer kind of assumes things are composable.
10:12:24 <mmtunligit> im aware of that, but i think it would be overall easier for compatability. for example train grfs could provide compatability attributes, so if the existing railtype stuff doesnt work you just slap one on to the type you want to run the train on and it goes
10:14:08 <mmtunligit> and since things are split apart, standardization is going to be much easier, a standard gauge attribute is decoupled from an electification attribute, and trin grfs can say "only run on types with standard gauge" "only run on types with third rail" and so on
10:14:55 <ahyangyi> we can build compatiblity on badges.
10:15:10 <mmtunligit> yeah, we already have the tools for this
10:15:34 <ahyangyi> So, turning railtypes composable is not a prerequisite of compatibility
10:16:03 <ahyangyi> And I also have the question of, how to introduce *non-compatibility* when a composer is involved?
10:16:41 <ahyangyi> Say, one NewGRF provides various types of ballasts, a second NewGRF provides suspension monorails
10:16:51 <mmtunligit> it still requires cooperation between authors, wheras composability would remove that limitation
10:16:51 <mmtunligit> and if players want to do silly things i see no reason to stop them
10:16:57 <ahyangyi> How do we prevent stone ballast suspend monorails?
10:17:12 *** reldred has joined #openttd
10:17:12 <reldred> thats easy the suspended monorails are trams
10:17:34 <ahyangyi> Wouldn't it be easier if we just let newgrf authors draw the combinations they want
10:17:39 <ahyangyi> not the atomic parts
10:17:54 <mmtunligit> ahyangyi: i dont see the problem with that, suspended monorail would be a gauge attribute, stone ballast would be a groundsprite attribute
10:19:02 <mmtunligit> i guess id call that gauge
10:19:22 <ahyangyi> I prefer to not categorize what should not be categorized.
10:20:44 <mmtunligit> but like, again, i dont see the problem with lettign the player decide to do silly things. if the grfs provide presets and thats what shwos up in the dropdown initially, then from the average players perspective, nothing has changed, but power users can mix and match, and if authors arent playing nice, instructions can be given as to how to make types compatible
10:22:11 <andythenorth[d]> I don't think we can build compatibility on badges
10:22:18 <andythenorth[d]> but I might be way out of my lane 😛
10:22:33 <andythenorth[d]> resolving compatibility across a huge space of strings is not going to be efficient
10:22:34 <ahyangyi> andythenorth[d]: "graceful degradation"
10:22:46 <ahyangyi> degradation to non-compatible
10:23:27 <andythenorth[d]> my presumption is that the pathfinder has to resolve compatibility frequently
10:23:41 <ahyangyi> I think it can be precomputed
10:24:06 <ahyangyi> So no matter how shitty the computation is, at worse the game needs to pre-compute a NxN table
10:24:24 <ahyangyi> where the maximum value of N is 64 and some of us think it's a bit too low
10:25:59 <ahyangyi> mmtunligit: My problem is that there are also cost, max speed, depot sprite, etc
10:26:11 <ahyangyi> unless all of these are composable
10:26:22 <mmtunligit> ahyangyi: yeah that i have less idea about, again, i havent thought through all of the implications
10:26:35 <mmtunligit> but i think its a good idea in principle
10:26:42 <mmtunligit> i wouldnt be talking about it if i didnt
10:27:01 <ahyangyi> I like the feeling of being able to select rail type with a composer-like UI
10:27:19 <ahyangyi> But I think it can be built with the existing rail type, and a badge-filter layer on top.
10:27:28 <talltyler> Depot sprite should be selectable, like station tiles
10:27:35 <andythenorth[d]> I can't see it
10:28:22 <mmtunligit> andythenorth[d]: i dont think the pathfinder does at all, if you have a mixed electrified/unelectrified network you generally need to use waypoints if you have two routes with varying electrification between a station pair
10:28:30 <andythenorth[d]> what problem are we solving? 🙂
10:28:48 <mmtunligit> insufficient ability to get creative with it
10:28:58 <ahyangyi> "we want more rail types"
10:29:10 <mmtunligit> i toos ee no reason why depot visuals should be dependent on the railtype
10:29:28 <andythenorth[d]> ok so if we want more railtypes, don't unpick the current spec and all of the content
10:29:34 <andythenorth[d]> just expand the number of railtypes
10:29:44 <andythenorth[d]> which will be tricky to persuade anyone to approve currently
10:29:58 <ahyangyi> andythenorth[d]: That's basically what I'm saying 😛
10:30:25 <ahyangyi> "railtypetable problem be railtypetable problem"
10:30:25 <ahyangyi> "UI problem be UI problem"
10:30:35 <ahyangyi> so the number problem is alone and solveable
10:30:36 <andythenorth[d]> what's the railtypetable problem?
10:31:04 <ahyangyi> I don't know, the various things people talk about when we just want more rail types
10:31:17 <ahyangyi> I think they belong to their own question
10:31:31 <andythenorth[d]> I'd file it under "most grf authors don't understand railtypes"
10:31:50 <ahyangyi> I don't understand it but I have excuses
10:32:05 <ahyangyi> I don't do trains or tracks (yet)
10:32:08 <andythenorth[d]> 65k trains was not controversial, because trains are trains
10:32:16 <andythenorth[d]> 65k objects was not controversial because objects are objects
10:32:54 <andythenorth[d]> 65k cargos won't be happening I reckon, because the UI will collapse
10:32:59 <ahyangyi> 65k rail types are controversial, I get it 😛
10:33:15 <andythenorth[d]> well are they?
10:33:23 <LordAro> one rail type per train
10:33:26 <andythenorth[d]> why are trains and objects simple, and railtypes not?
10:34:43 <ahyangyi> Simple things have their own selection windows, complex things are complex because they are in a dropdown menu
10:34:53 *** fairyflossy has joined #openttd
10:34:53 <fairyflossy> Is it because- yeah
10:35:22 <andythenorth[d]> but also trains and objects don't go redefining each other's behaviour, generally
10:35:27 <andythenorth[d]> it can be done, but mostly isn't
10:35:37 <fairyflossy> 65k trains or objects have a selector screen that you can scroll and whatnot, 65k tracktypes would need a very different track selector. Which I don't think is a bad thing, but its extra work
10:36:49 <ahyangyi> andythenorth[d]: Can we fix this by re-re-defining their behavior?
10:37:06 <andythenorth[d]> so train grfs can redefine each other?
10:37:45 <ahyangyi> Can you reredefine something without redefining them?
10:37:57 <andythenorth[d]> the spec fundamentally depends on railtypes being able to modify the behaviour of other railtypes
10:38:05 <andythenorth[d]> and redefine vehicle behaviour also
10:38:21 <andythenorth[d]> "probably fine" TBH
10:38:35 <ahyangyi> so thankfully vehicles are themselves fine, just the rail-type-facing parts not so much
10:38:49 <andythenorth[d]> "probably fine"
10:39:04 <andythenorth[d]> grf authors have made it much harder for themselves than they needed to
10:42:13 <andythenorth[d]> it was the correct play IMHO
10:42:30 <xarick> this update is very suspicious
10:46:59 <andythenorth[d]> merge peter's PR, move on 😛
10:49:08 <LordAro> ...did you type that url by hand?
10:49:53 <xarick> _glx_: I have a suspicion most, if not every Clamp used in script_xxx overflow
10:50:33 <andythenorth[d]> it was in my autocomplete
10:50:43 <andythenorth[d]> you mean the inconsistent capitalisation? 😛
10:50:54 <LordAro> that, and that it's a pull rather than an issue
10:51:24 <LordAro> GH redirects you immediately, hence why i was curious
10:51:39 <andythenorth[d]> probably did type it by hand at some point
10:54:10 <xarick> nevermind glx, they're using Clamp<SQInteger> in most places, my bad
10:55:57 <xarick> ScriptTown::ChangeRating this one might be affected
11:04:58 <xarick> ScriptTown::SetGrowthRate doesn't use Clamp but i have strong suspicions it's overflowing
11:38:57 <xarick> which GS uses SetGrowthRate?
12:25:04 <xarick> I'm questioning whether that clamp is the good approach or if i just put that in the enforceprecondition
14:15:04 *** Wormnest has joined #openttd
14:38:36 <rito12_51026> are image files forwarded from discord to IRC?
14:54:31 <xarick> I wanna PR but LordAro scares me all the time
14:59:53 <_glx_> As always first describe the actual issue before trying to fix it
15:05:41 <LordAro> i have no problems with disallowing PRs from you that don't have an attached and validated issue
15:06:01 <LordAro> saves both us and you wasting time on pointless things
15:09:01 <peter1138> This is your fault for contriving a NewGRF with 64000 badges...
15:11:47 <rito12_51026> I know, but I have made my badges 12 px high, as you advised
15:17:10 <peter1138> Looks like the backport script failed again, only the second commit is backported.
15:17:51 <peter1138> So that's my not backporting properly :(
15:17:57 <peter1138> I can't remember what the other one way.
15:30:49 <locosage> hm, looks like on 10MB/s zstd does reduce connection time by about 30%
15:38:23 <LordAro> peter1138: same problem as the fluidsynth backport?
15:38:58 <peter1138> I'm cherry-picking to make a new PR.
15:41:14 <peter1138> Going through all the backported PRs manually
16:07:29 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
16:07:41 *** MinchinWeb[m] has joined #openttd
16:09:21 <xarick> forgive my broken english, i didn't use copilot
17:02:23 <LordAro> will have to think about how to changelog those entries
17:33:45 <LordAro> theoretically we could rerun them, but the process is involved
18:11:53 <xarick> ScriptCargo::GetCargoIncome is a little bit tricker
18:12:02 <xarick> there's double overflow
18:19:11 <andythenorth[d]> could cargos have badges? 👀
18:19:18 <andythenorth[d]> nothing to do with the above
18:28:13 <xarick> oh, its narrowing cast the english term
18:44:08 <andythenorth[d]> peter1138: To provide sprite hints to vehicle grfs in act2 chain
18:53:05 <peter1138> I checked, all PRs are single commits this time, so nothing missed.
19:06:22 *** toktik is now known as Guest2484
19:11:56 *** Guest2484 has quit IRC (Ping timeout: 480 seconds)
19:14:40 <andythenorth[d]> alternatively to badges, expand cargo class bits to 32?
19:21:41 <andythenorth[d]> nah that's a silly idea
19:25:50 <andythenorth[d]> the use case is that authors want to be able to know whether things like CC_PIECE_GOODS should show a tarpaulin cover or not
19:26:00 <andythenorth[d]> which they were relying on CC_COVERED for
19:28:34 <peter1138> cargo appearance flags?
19:29:19 <andythenorth[d]> :shrug neutral
19:29:22 <andythenorth[d]> cargo sprites do get reused across
19:34:27 <peter1138> Standardised Cargo Overlay REcolour Scheme?
19:34:59 <belajalilija> <a:sabrinashrug2:1253221174578778183>
19:37:53 <andythenorth[d]> mostly this is fine, but there was an unexpected outcome with `CC_COVERED`
19:38:27 <andythenorth[d]> CC_COVERED is meaingless as far as vehicles go, because any cargo can have a cover put over it
19:38:57 <andythenorth[d]> but it appears that some authors have been depending on it to know when to show a tarpaulin or other cover over the cargo
19:39:33 <andythenorth[d]> (1) maybe they shouldn't
19:42:51 *** Zathras_4 has joined #openttd
19:58:36 <_glx_> I see CC_COVERED as this cargo must be covered
20:05:46 <andythenorth[d]> _glx_: that's how I would have interpreted it, and what most of the spec implied
20:06:24 <andythenorth[d]> I'm out on a limb with redfining the meanings in FRAX classes (now used by FIRS 4, FIRS 5, AXIS, ITIL)
20:06:42 <andythenorth[d]> but I didn't anticipate that authors are depending on the classes to switch sprites
20:08:04 <peter1138> If they're testing for CC_COVERED to know if it should be covered, then what's the problem?
20:10:19 <andythenorth[d]> The most honest answer is that the problem is me 😐
20:10:53 <andythenorth[d]> I’ve redefined that bit so it can be used for reliable refits
20:11:24 <andythenorth[d]> I did consider ever refit case and test lots of industry and vehicle grfs
20:11:39 <andythenorth[d]> But I hadn’t considered cargo sprites
20:12:20 <andythenorth[d]> So now (for example) wool might show generic crates, not a tarpaulin
20:15:53 <andythenorth[d]> not that I have actual evidence of this happening, the grf that it applies to hasn't been made yet
20:19:51 <_glx_> wool in crate seems fine to me
20:23:50 <Rubidium> I guess it's under '(Other)'
20:24:04 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
20:24:21 *** MinchinWeb[m] has joined #openttd
20:27:41 *** yiffgirl has quit IRC (Ping timeout: 480 seconds)
20:29:16 *** gorantev has quit IRC (Ping timeout: 480 seconds)
20:29:24 *** davidxn has quit IRC (Ping timeout: 480 seconds)
20:29:25 *** fairyflossy has quit IRC (Ping timeout: 480 seconds)
20:29:25 *** keimfrei has quit IRC (Ping timeout: 480 seconds)
20:29:26 *** sofiedotcafe has quit IRC (Ping timeout: 480 seconds)
20:29:27 *** marktheshark3209 has quit IRC (Remote host closed the connection)
20:29:27 *** xarick has quit IRC (Remote host closed the connection)
20:29:27 *** drmanuel has quit IRC (Write error: connection closed)
20:29:27 *** lea001 has quit IRC (Write error: connection closed)
20:29:27 *** housemd123123[d] has quit IRC (Write error: connection closed)
20:29:27 *** kaibaneddy has quit IRC (Write error: connection closed)
20:29:27 *** ahyangyi has quit IRC (Write error: connection closed)
20:29:27 *** reldred has quit IRC (Remote host closed the connection)
20:29:27 *** locosage has quit IRC (Remote host closed the connection)
20:29:27 *** tabytac has quit IRC (Remote host closed the connection)
20:29:27 *** gwyd4016 has quit IRC (Read error: Connection reset by peer)
20:29:27 *** digitalfox has quit IRC (Write error: connection closed)
20:29:27 *** belajalilija has quit IRC (Read error: Connection reset by peer)
20:29:27 *** brickblock19280 has quit IRC (Write error: connection closed)
20:29:27 *** michke has quit IRC (Write error: connection closed)
20:29:27 *** definitelynotcheese_ has quit IRC (Write error: connection closed)
20:29:27 *** andythenorth[d] has quit IRC (Write error: connection closed)
20:29:27 *** _jgr_ has quit IRC (Write error: connection closed)
20:29:27 *** mmtunligit has quit IRC (Write error: connection closed)
20:29:27 *** michi_cc[d] has quit IRC (Write error: connection closed)
20:29:27 *** talltyler has quit IRC (Write error: connection closed)
20:29:27 *** _zephyris has quit IRC (Write error: connection closed)
20:29:27 *** kuhnovic has quit IRC (Read error: Connection reset by peer)
20:29:27 *** merni has quit IRC (Read error: Connection reset by peer)
20:29:27 *** emperorjake has quit IRC (Write error: connection closed)
20:29:27 *** jfkuayue has quit IRC (Write error: connection closed)
20:29:27 *** __abigail has quit IRC (Write error: connection closed)
20:29:27 *** marihan has quit IRC (Write error: connection closed)
20:29:27 *** keepinitrail has quit IRC (Write error: connection closed)
20:29:27 *** DorpsGek_vi has quit IRC (Write error: connection closed)
20:29:27 *** vondpc has quit IRC (Write error: connection closed)
20:29:27 *** rito12_51026 has quit IRC (Write error: connection closed)
20:29:27 *** squirejames has quit IRC (Write error: connection closed)
20:29:27 *** _glx_ has quit IRC (Write error: connection closed)
20:29:48 *** DorpsGek_vi has joined #openttd
20:36:29 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
20:37:01 *** MinchinWeb[m] has joined #openttd
20:52:19 <Rubidium> are we really going to slow down all API functions because someone obsessed with speed and unplayably large/busy games want the API to not return gibberish when you pass it gibberish?
21:01:31 <peter1138> As long as it's not crashing :)
21:12:08 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:47:49 <xarick> is it slowing down? i made statics
21:49:33 <xarick> oh, I didn't expect regression failing
21:50:53 *** lobster has joined #openttd
21:50:56 <xarick> oopsie, i made a mistake i guess
21:51:47 *** lobstarooo has quit IRC (Read error: Connection reset by peer)
21:55:31 <xarick> I don't have time to fix it :(
21:58:14 <xarick> just fixed it, reopen?
22:08:04 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
22:17:35 *** andythenorth has joined #openttd
22:17:35 <andythenorth> on macOS some global menu items link directly to settings
22:17:51 <andythenorth> wonder if News should do that
22:18:01 <andythenorth> feels like players ask quite often
22:19:25 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
22:19:39 *** WormnestAndroid has joined #openttd
22:22:59 *** WormnestAndroid has quit IRC (Remote host closed the connection)
22:23:18 *** WormnestAndroid has joined #openttd
22:35:04 *** jfkuayue has joined #openttd
22:35:04 <jfkuayue> I just realised i cannot distinguish Lucozade and Lanzarote…
23:21:44 *** MinchinWeb[m] has quit IRC (Read error: Connection reset by peer)
23:22:01 *** MinchinWeb[m] has joined #openttd
23:28:57 *** belajalilija has joined #openttd
continue to next day ⏵
