IRC logs for #openttd on OFTC at 2026-02-02
⏴ go to previous day
01:21:55 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:23:33 *** WormnestAndroid has joined #openttd
02:46:48 *** Wormnest has quit IRC (Quit: Leaving)
03:56:21 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:36:44 *** Zathras_4 has joined #openttd
04:38:29 *** Zathras_1 has quit IRC (Ping timeout: 480 seconds)
05:10:59 <DorpsGek> - Update: Translations from eints (by translators)
06:52:07 *** MinchinWeb[m] has quit IRC (Remote host closed the connection)
06:52:30 *** MinchinWeb[m] has joined #openttd
07:25:36 <DorpsGek> - Add: summary for week 05 of 2026 (by OpenTTD Survey)
10:02:53 <xarick> LuDiAI AfterFix - 0.3% share
10:03:02 <xarick> dang, that's quite low :|
10:24:39 <xarick> the name of the AI might be the problem
10:26:59 <xarick> CPU with a 1.4% share, that's so ... unfair
10:28:48 <LordAro> i would suggest that the weekly runs are possibly liable to being skewed
10:29:02 <LordAro> the quarterly results are much more favourable to you
10:31:51 <xarick> oh, that's interesting
10:34:34 <xarick> btw, how do you measure SuperSimpleAI?
10:35:57 <xarick> bananas has version 19
10:36:21 <xarick> if i use the forum version, would that count for the statistics?
10:36:35 <LordAro> why do you think it wouldn't?
10:40:10 <LordAro> looks like it excludes anything that isn't on bananas, but only by name
10:49:30 <peter1138> So if we did waterclass "wetland" and/or clearground "wetland", we could use different graphics for wetlands, which might help with that trypophobia.
10:50:24 <LordAro> peter1138: i rode a bike yesterday
10:53:56 <peter1138> First time in a while?
10:54:40 <LordAro> and i was... alright? after
10:55:33 <LordAro> trouble with trying more than one remedy at once means i can't tell whether the exercises or the drugs are helping (or even if they're just suppressing it)
10:55:52 <ahyangyi> I Googled "trypophobia"
10:56:02 <ahyangyi> And I should have not googled any phobia at all.
11:11:10 <_zephyris> @peter1138 or NewGRF terrain tiles?
11:11:15 <_zephyris> I'm having structured thoughts
11:13:18 <peter1138> Not really relevant, NewGRF wouldn't know that it's wetlands without anything to say so.
11:13:50 <andythenorth[d]> partly it will be the contrast at the edge of the tiles
11:13:58 <andythenorth[d]> it's not just the pattern of water on land
11:14:43 <andythenorth[d]> I won't share trypophobia images, but most of them have that hard edge to the circular shapes, which is emblematic if scar tissue, wounds or rot, which is part of the trypophobia trigger
11:15:17 <andythenorth[d]> afaik, it's the combination of 'a grid' (regular or irregular) + 'disgust trigger at amygdala level'
11:15:36 <peter1138> I'm not querying the trypophobia response.
11:15:55 <andythenorth[d]> my thinking is that the sprites probably affect the respose
11:16:12 <_zephyris> Fuzzy edged river banks would help
11:16:35 <andythenorth[d]> grids trip up the brain because they raise a question about infinite patterns
11:16:44 <andythenorth[d]> and infinite disgust .... some people just 'nope'
11:17:09 <_zephyris> @peter1138, I was thinking that adding a new water tile type and adding a new terrain tile type are kinda equivalent
11:30:32 <reldred> I certainly won't complain about moar tile types
11:30:57 <reldred> but I think swamps as is work quite fine with ogfx1 and andy's ttd rivers.
11:31:11 <reldred> ogfx2 i find less aesthetically pleasing.
11:32:38 <peter1138> Still need to figure out the snow transitions, as my randomised snow looks bad with OpenGFX 2 :(
11:32:54 <reldred> yeah? i didn't think they looked too bad?
11:33:05 <reldred> i quite like the snow transitions in general in ogfx2
11:33:28 <peter1138> It works with original and OpenGFX 1, but 2 has more of a gradient on slopes.
11:33:55 <peter1138> It works better when there's always a jump between transitions, instead of some being smooth and some not.
11:35:53 *** Flygon has quit IRC (Remote host closed the connection)
11:38:36 <_zephyris> I do think you're trying to change it at the wrong scale... The snow line, ie. where snow doesn't melt, is consistent over large scales. A different mountain could have a different snowline.
11:39:40 <_zephyris> How much snow is on land above the snowline depends on if it's very not flat/rocky, wind exposed, etc. Which is already (imperfectly) captured by the patchy snow on grass tiles and the snowy rocks.
11:40:07 <_zephyris> (and sorry for scuppering plans by cementing smooth snow transitions in ogfx1/2)
11:47:38 <peter1138> OpenGFX 1 bug on the right?
11:49:52 <_zephyris> No snow on the lowest snowy level?
11:50:26 <peter1138> Is that on the right?
11:55:15 <LordAro> i think that's known about?
11:55:24 <LordAro> seems familiar anyway
12:06:19 <_zephyris> It's been that way forever, and it my fault
12:06:35 <xarick> how do I allow unlimited airports per town
12:07:18 <_zephyris> Permissive local authority
12:07:20 <xarick> in the AI fight scene, whoever claims most airports just wins by default
12:08:27 <xarick> oh, that doesn't seem to work, but let me try
12:13:19 <xarick> some interesting AI fights gonna happen now
12:22:12 <LordAro> i feel an enum class coming on
12:22:34 <LordAro> or would it require a strongtype?
12:23:04 <peter1138> enum class is how I found it, yes, but that's a separate PR :)
12:24:42 <talltyler> Enum class is already a strong type, no?
12:31:42 <xarick> not quite what I hoped for
12:34:15 <ahyangyi> What did you hope for?
12:34:38 <ahyangyi> I think at least for Hog you can use its setting to enforce it to build airports and nothing else
12:35:20 <peter1138> AI probably expects it to fail if one is already there, as that's traditional behaviour.
12:41:37 <peter1138> Load average: 30.03 20.59 11.41
12:43:27 <ahyangyi> It's a huge map though, the AIs should be able to build at least a few airports if they want to.
12:44:03 <peter1138> For API considerations it might be better if AI had to specify that.
12:45:03 <peter1138> Of course an AI could check/know what it has built.
13:41:21 <_glx_> xarick: I hope the exact same test would be smoother for CPU in nightly
14:01:18 *** Wormnest has joined #openttd
14:09:50 <xarick> no idea what NoNoCAB is doing, but it's heavy
14:11:21 <LordAro> _glx_: didn't you fix/add a workaround for that "not instantiable" issue?
14:12:36 <Wormnest> I should take a look at it sometime, but too many other things at the moment.
14:12:38 <_glx_> at least it doesn't crash the script
14:18:15 <xarick> SimpleAI also doing something heavy :(
14:18:32 <xarick> something from the main loop
14:19:05 <xarick> it has all the new improvements
14:19:15 <xarick> so... probably vehicle lists? maybe
14:27:20 <xarick> I wished NoNoCAB was better than NoCAB
14:27:59 <xarick> NoCAB still ends doing more profits
14:33:20 <xarick> can i have an unlimited memory limit?
14:34:13 <Wormnest> Ah, there even is already a PR for fixing the instantiate errors in NoNoCab. Now to find some time to do a release.
15:46:01 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:46:02 *** WormnestAndroid has joined #openttd
15:46:10 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:46:27 *** WormnestAndroid has joined #openttd
16:27:29 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
16:28:06 *** MinchinWeb[m] has joined #openttd
16:48:27 *** gelignite has joined #openttd
17:14:19 <peter1138> Hmm, shame EnumClassIndexContainer breaks array initialisation :(
17:15:34 <peter1138> Aggregate initialisation needs something else.
17:54:42 <pickpacket> Hehehe. It can't be the first time someone thinks of this but... Ships crashing into icebergs in arctic climate? That'd be fun 🤪
18:29:04 *** Borg has quit IRC (Quit: leaving)
19:33:49 *** gelignite is now known as Guest1268
19:33:53 *** gelignite has joined #openttd
19:35:53 <xarick> which AI will be ruined by that change
19:39:55 *** Guest1268 has quit IRC (Ping timeout: 480 seconds)
20:44:11 <LordAro> i thought 'virtual' meant "can be overridden"
20:44:29 <LordAro> which is obviously distinct from "is overriding something"
20:45:04 <LordAro> i.e. A -> B -> C would need `virtual B::foo() override`
20:56:55 <locosage> can't override what can't be overriden ;)
21:00:11 <dwfreed> LordAro: according to cppreference B::foo is virtual whether virtual is given or not; if one wants to prevent a C::foo, they have to use 'override final' on B::foo, otherwise a C::foo is always possible
21:05:25 <Rubidium> LordAro: no, once a function is virtual it will be for the complete tree of ancestors.
21:06:37 <peter1138> We used to mark with /* virtual */ before we started using override everywhere.
21:06:58 <LordAro> peter1138: i thought that was a declaration vs definition thing
21:07:02 <peter1138> Similar to marking with /* static */
21:07:07 <Rubidium> well... the /* virtual */ was declaration vs definition
21:19:49 <Rubidium> oh joy.. GH actions are on the fritz
21:50:44 *** MinchinWeb[m] has quit IRC (Remote host closed the connection)
21:51:00 *** MinchinWeb[m] has joined #openttd
22:10:05 *** Cursarion has quit IRC (Ping timeout: 480 seconds)
22:13:10 *** Cursarion has joined #openttd
22:21:28 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:29:12 <peter1138> Hmm, yeah, brokened.
22:39:58 <_zephyris> I feel I've fallen into a rabbit hole
22:42:42 <peter1138> Have you considered that "build as much as you can until you can't" is intended behaviour?
22:42:53 <peter1138> (I'm not saying it necessarily is, but it might be)
22:43:55 <_zephyris> Yeah, I'm wondering where that line is/should be
22:44:01 <_zephyris> And fearing pitchforks
22:45:59 <peter1138> (And potentially you are opening bug reports about the same thign)
22:46:17 <_jgr_> The way that the terraform and other action limits work implicitly assume this sort of behaviour
22:47:09 <_jgr_> All or nothing behaviour would be quite awkward/tedious unless you got rid of the action limits
22:50:39 <_zephyris> Hmm. Trees currently do all (if affordable) or nothing (if not affordable) or partial (action limit, though error message broken)
22:51:29 <_zephyris> I like that for building stuff
22:52:15 <peter1138> "All or nothing" is also not ideal for tools like convert rail.
22:52:38 *** goddess_ishtar has joined #openttd
22:52:38 <goddess_ishtar> peter1138: I don't think there is any scenario where the user, having intentionally selected a certain area to buy, would be satisfied with buying only some portion of it silently
22:53:28 <_zephyris> I think convert rail is the opposite tbh, I don't want some random sub-part of my network upgraded if I don't babe enough cash...
22:54:41 <goddess_ishtar> _zephyris: clearly we need an advanced heuristic to determine which trains you're running on the line to avoid stranding any of them if you make a partial upgrade :p
22:54:49 <peter1138> I guess I misremembered how that behaves?
22:55:34 <_zephyris> I think I just tested it and got all or nothing.
22:55:38 <goddess_ishtar> I maintain that the upgrade tool really shouldn't be a box select, but probably path-based like the multirail tool, because train routes are not generally neat box shapes
22:56:35 <_zephyris> (Ctrl+drag for diagonal gets you part of the way there)
22:56:58 <goddess_ishtar> _zephyris: yeah but it's still a hassle and not quite intuitive
22:58:04 <goddess_ishtar> oh, stupid idea
22:58:16 <goddess_ishtar> *upgrade to the nearest junction or station"
22:58:27 <goddess_ishtar> like the autoplace signals heuristic
22:58:46 <_zephyris> Would be nice to have the demolish tool not drain all your cash if you accidentally demolish an area of sea, and give a not enough cash error instead.
22:59:33 <Rubidium> goddess_ishtar: if there isn't any scenario where buying only a part of and area of land would satisfy the user, then that same logic applies to terraforming.
23:00:38 <goddess_ishtar> Rubidium: "terraforming considered harmful"
23:01:05 <_jgr_> The problem is that it means mentally calculating how many tiles the available funds and/or predicting what the current action limit will be
23:01:14 <_jgr_> Instead of just doing what is possible
23:01:53 <_jgr_> Which I suspect that trip up many players
23:02:04 <goddess_ishtar> goddess_ishtar: this is probably a playstyle thing but I consider terraforming large sections of land to be an outlier case anyway
23:02:08 <mmtunligit> upgrade tool should be path based like build rail if youre dragging in a 1x line along rail (diagonal included) and otherwise be area select, i think you could probably make a system smart enough for this
23:03:03 <goddess_ishtar> _jgr_: but... some parts are more important than other parts
23:03:11 <Rubidium> goddess_ishtar: buying land is harmful as well
23:03:33 <goddess_ishtar> great, another BAD FEATURE, we should save some space in the codebase
23:04:49 <_jgr_> Buying land is better than the workarounds that would be used if it was removed
23:05:17 <goddess_ishtar> goddess_ishtar: what I mean is that if I'm applying an operation to a huge swath of land, there are presumably some parts which I find more important than other parts, but there is no way for the code to know which parts the user actually cares about
23:05:31 <goddess_ishtar> it'll just fill in some portion of the box and then stop
23:05:58 <goddess_ishtar> _jgr_: I was being sarcastic - well, okay, no, I wasn't being sarcastic because that implies I was trying to make a point
23:06:05 <goddess_ishtar> I'm just being an annoying little shit
23:06:21 <goddess_ishtar> I don't think buying land is particularly bad for game design
23:07:24 <_zephyris> I think the balance is @JGR's point about wanting to do a big thing, and being annoyed if nothing happens, vs. accidentally doing something very expensive and draining all of your money to do it partially
23:07:55 <goddess_ishtar> it would be nice to have some sort of preview confirmation mode
23:08:33 <goddess_ishtar> you can shift-drag to tell how expensive something is but the box itself isn't persistent
23:09:30 <goddess_ishtar> so it's somewhat tricky to tell if any given selection is a reasonable size or cost, or what the effect would be if you selected a few other rows, or whatever
23:10:02 <_zephyris> Hmm, and doing something partially and not noticing which causes problems (ie building track, and not noticing you only had enough money for all but one tile)
23:12:22 <_jgr_> Having building behaviour be radically different between early game when money is trickling in and later when money is near-infinite also seems non-ideal
23:12:38 <_jgr_> Though the early stage does not last that long in practice
23:13:01 <__abigail> Would it help if it were a setting?
23:13:01 <Rubidium> in any case, I don't see why it's a bigger problem for buying land than clearing it. And for buying you first need to clear trees and such, so you have two actions to run independently and you still can't be sure you can actually buy the land before clearing
23:13:01 <_zephyris> But is important for new/casual players
23:14:18 <_jgr_> You don't have to clear trees separetaly before buying land?
23:15:24 <_jgr_> Not sure I follow the issue
23:15:40 <Rubidium> __abigail: good luck implementing that setting for land clearing and terraforming where there won't be complaints in the form of: "if I clear this area tile-by-tile, all tiles are cleared but if I clear this area at once it won't" as any simple logic will trip up on multi-tile structures.
23:16:29 <__abigail> I tried sorting out a fix for it but god the land buying code just broke my brain
23:16:44 <_zephyris> There are other subtleties BTW, eg failing on one tile (building in the way) blocks some actions (building station, rail) but not others (clearing tiles, buying tiles)
23:17:22 <_zephyris> __abigail: I've got a fix, but it's linked with the change to all or nothing behaviour based on available funds.
23:17:49 <_jgr_> Rail and stations are inherently contiguous but empty/bought tiles are not
23:18:09 <_zephyris> Defo no one size fits all
23:40:44 <xarick> hey wormnest what could possibly be doing such huge spikes
23:46:22 <xarick> well SimpleAI does it even harder
23:47:03 <xarick> 4.1 second stalls, followed by a 4.8 second
23:47:11 <xarick> can't even make a proper screenshot
23:47:11 <Wormnest> xarick: is it a large(r) map: if there are too many possible connections, it may have a lot of options to evaluate
23:48:53 <xarick> SuperSimpleAI, Jaume's fork doesn't have the issue
23:50:02 <xarick> well, it has 135 ms spikes, still felt, but it's not as ridiculous
23:52:37 <xarick> i get so distracted with youtube videos, i really should be looking into these scripts code
23:58:09 <xarick> AdmiralAI still doing incredibly well with very minor code fixes
continue to next day ⏵
