IRC logs for #openttd on OFTC at 2025-10-21
β΄ go to previous day
00:08:36 <tabytac> Somebody has made a new unofficial iOS port, don't own any apple devices to see how good it is myself tho
00:10:19 <tabytac> Wonder how it holds up next to the unofficial android port by iSoSyS
00:27:36 <reldred> Eh, itβs the web version in a wrapper of some kind
00:27:50 <reldred> Bad scaling/fuzzy pixels,
00:28:07 <reldred> Goes to shit with curved screen corners.
01:13:37 *** Wormnest has quit IRC (Quit: Leaving)
02:16:09 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
03:30:59 *** Flygon has quit IRC (Read error: Connection reset by peer)
03:49:43 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:49:44 *** WormnestAndroid has joined #openttd
03:49:50 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:49:53 *** WormnestAndroid has joined #openttd
03:49:54 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:49:55 *** WormnestAndroid has joined #openttd
04:01:11 *** Zathras_11 has joined #openttd
04:04:31 *** Zathras has quit IRC (Ping timeout: 480 seconds)
06:55:22 <andythenorth> maybe I'll get FIRS GS to place fences like this
06:56:17 <andythenorth> or grf could do it....? π
06:56:53 <andythenorth> using a callback that can loop over nearby tiles, with +/- offsets to the industry N tile?
07:10:21 <andythenorth> "maybe without the animated flag set on all of them"
07:13:37 *** Rikests has joined #openttd
07:20:24 <ahyangyi> It's nice to have animated fences though, isn't it
07:20:37 <ahyangyi> Just don't animate the empty tiles in between
07:25:59 <andythenorth> animated fences with triggers
07:28:13 <ahyangyi> That sounds like a very dangerous kind of fences
08:18:14 <LordAro> the sort of fences where if you saw them in a dark alleyway you'd find another route?
09:03:09 *** tokai has quit IRC (Ping timeout: 480 seconds)
09:07:25 *** ChanServ sets mode: +v tokai
09:19:25 <xarick> I'm listening to weird music againhttps://www.youtube.com/watch?v=1YsC32xLnkY
09:35:14 <mnhebi> andythenorth: why would a factory get a fence that isn't fully enclosed with gates? π€
09:41:10 <andythenorth> because selecting the correct object in VAST is faffy?
09:41:25 <andythenorth> and I couldn't be arsed to complete the example properly π«
10:18:01 <fairyflossy> "Deliver" instead of "Unload" if it really is so confusing
10:18:37 <peter1138> "Leave for transfer" does not clarify anything, IMHO.
10:19:04 <peter1138> "Deliver" instead of "Unload" doesn't help either.
10:19:26 <fairyflossy> It makes at least a bit more difference between the 'types' of unloading
10:19:32 <peter1138> An Unload order does not mean it gets delivered, so renaming it to Deliver is wrong.
10:19:49 <fairyflossy> That is true because delivering depends on station acceptance
10:20:31 <peter1138> Problem is these players have got the acceptance bit wrong, but they don't know it, so they think it's an order issue, see Unload and think they must need to use that.
10:20:43 <peter1138> Seeing Deliver instead would be the same, if not worse.
10:22:05 <LordAro> perhaps the order window could warn instead? similar to invalid orders?
10:23:58 <peter1138> (Not as is though, as doesn't show absense.)
10:39:53 <xarick> i have a vector with 100 items
10:40:05 <xarick> i pick a random item from it
10:40:29 <xarick> now i want to remove all items past that choice
10:40:41 <xarick> from the vector, what is the command?
10:43:27 <LordAro> that'd probably work equivalently well than the erase command i was trying to come up with
10:43:50 <LordAro> peter1138: i was imagining big red text. if it's only an error condition, can't complain about it cluttering the window :)
11:05:47 <xarick> i found an even faster method to build a lake
11:06:25 <xarick> no hasttable digging required
11:07:24 <xarick> I only need to memorise the last tested node
11:08:45 <xarick> make a path out of that, then chose a random tile, crop the vector, build the river as normal
11:09:40 <xarick> it even has the advantage that lakes are never disconnected from the river
11:31:32 <xarick> now that I actually have a path
11:32:11 <xarick> I'd like to pick a random tile starting from the 32th onwards, what should uint32_t nth look like?
12:34:55 <xarick> nth = 32 + randomrange(33 - 32); // 32 + [0-1[ -> 32
12:34:55 <xarick> lake_centre = river_tiles[32];
12:34:55 <xarick> river_tiles.resize(33);
12:36:42 <peter1138> That might annoy the people using it on purpose.
12:37:45 <LordAro> it might, but how often will people be using unload & leave empty (and similar) at stations that otherwise accept that cargo?
12:38:20 <peter1138> That misses the use-case that the station doesn't accept the cargo but the new player doesn't know.
12:38:52 <LordAro> yeah, could do the inverse as well - order doesn't use one of the modifiers but the station doesn't accept it
12:39:17 <LordAro> when would that be used intentionally?
12:39:26 <peter1138> jfkuayue, looga borooga
12:45:10 <peter1138> No idea what that link is.
12:45:38 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:45:40 <andythenorth> it's shades of my childhood
12:45:41 *** WormnestAndroid has joined #openttd
12:46:31 <andythenorth> orders are probably a locally stable, suboptimal maxima
12:46:41 <andythenorth> any change is probably worse
12:46:47 <andythenorth> and players will constantly be confused
12:48:32 <jfkuayue> Kuhnovic said, Learning English is _tough, though through_ practice you might get better
12:49:30 <LordAro> tough, though through thorough* ;)
12:51:54 <emperorjake> English can be learned through tough thorough thought though
12:56:30 *** Wormnest has joined #openttd
13:02:58 <rito12_51026> `nmlc ERROR: nmlc: An internal error has occurred:`
13:02:58 <rito12_51026> should I write a bug report?
13:06:35 <_glx_> rito12_51026: and add `-s` flag to get more info
13:40:13 <xarick> time for benchmarks π
13:56:16 <rito12_51026> nmlc ERROR: There are not enough registers available to perform all required computations in switch blocks. Please reduce the complexity of your code.
13:57:29 <rito12_51026> how registers are calculated?
13:58:05 <_glx_> well this error means you have 127 registers used at the same time
14:11:47 *** orudge` is now known as orudge
14:24:55 <rito12_51026> _glx_: before your suggestion I was using 94/127
14:26:45 <_glx_> I don't see how my suggestion would eat 33 registers
14:55:40 <andythenorth> I am puzzled what could possibly need 127 registers
14:55:47 <andythenorth> unless it's some nmlc internal magic
14:56:03 <ahyangyi> just very long expression
14:56:42 <andythenorth> I can't think of anything that would justify using 127 stored values to compute a result
15:00:18 <rito12_51026> andythenorth: That one uses quite a lot of them but I don't know what it does
15:07:10 <andythenorth> maybe it's an inevitable workaround to 'stations are mad'
15:15:16 <xarick> 100% yapf disappoints sometimes
15:17:04 <xarick> also, master has improved again...
15:17:19 <xarick> i wonder if compiler versions affect performance
15:18:22 <xarick> 3 sub-tropical Master was giving me 97.373172 s last week
15:22:45 <xarick> I got a windows 25H2 update, and a MSVC fixing some /O2 stuff
15:31:12 <kuhnovic> Compiler changes can have a big impact, for better or for worse. Always compare apples to apples.
15:31:24 <kuhnovic> Or windows to windows in your case.
15:32:17 <LordAro> that amount of difference feels unlikely to have been caused by either of those things
15:37:04 <_glx_> rito12_51026: hmm stations are expected to use a lot of registers, but I can see many duplicate values (maybe because many spritelayouts have a parameter)
15:42:18 <peter1138> What went wrong with stations? They didn't have any of this went I implemented it.
15:43:18 <_glx_> in most case the spritelayout parameter is to ignore automatic track selection
15:43:54 <rito12_51026> all spritelayouts have a parameter, for example tile_387 uses:
15:43:54 <rito12_51026> sprite_layouts: [
15:43:54 <rito12_51026> layout_Station_BX(0), layout_Station_BY(0),
15:43:54 <rito12_51026> layout_Station_BX(1), layout_Station_BY(1),
15:43:54 <rito12_51026> layout_Station_BX(2), layout_Station_BY(2),
15:43:56 <rito12_51026> layout_Station_BX(3), layout_Station_BY(3),
15:43:56 <rito12_51026> layout_Station_FX(3), layout_Station_FY(3),
15:43:58 <rito12_51026> layout_Station_BX(4), layout_Station_BY(4),
15:43:58 <rito12_51026> layout_Station_FX(4), layout_Station_FY(4),
15:44:00 <rito12_51026> layout_Station_BX(5), layout_Station_BY(5),
15:44:00 <rito12_51026> layout_Station_FX(5), layout_Station_FY(5),
15:44:02 <rito12_51026> layout_Station_BX(6), layout_Station_BY(6),
15:44:02 <rito12_51026> layout_Station_FX(6), layout_Station_FY(6),
15:44:04 <rito12_51026> layout_Station_BX(7), layout_Station_BY(7),
15:44:04 <rito12_51026> layout_Station_FX(7), layout_Station_FY(7),
15:44:06 <rito12_51026> layout_Station_BX(8), layout_Station_BY(8),
15:44:06 <rito12_51026> layout_Station_FX(8), layout_Station_FY(8),
15:44:08 <rito12_51026> layout_Station_BX(9), layout_Station_BY(9),
15:44:08 <rito12_51026> layout_Station_BX(10), layout_Station_BY(10),
15:44:10 <rito12_51026> layout_Station_FX(10), layout_Station_FY(10),
15:45:37 <_glx_> hehe that's clearly not a good idea with how stations work
15:47:18 <peter1138> I remain unconvinced that anyone making stations knows what they are doing any more.
15:47:50 <andythenorth> I stopped making statins
15:48:00 <_glx_> that's a lot of different layouts for a single tile
15:48:08 <andythenorth> me not doing it improves the ignorance ratio π
15:48:12 <peter1138> One tile only needs one layout.
15:48:44 <rito12_51026> It is to make automatic tiles
15:50:36 <peter1138> Absolutely the wrong idea.
15:50:42 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:50:44 *** WormnestAndroid has joined #openttd
15:50:47 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:52:26 *** WormnestAndroid has joined #openttd
15:52:29 <rito12_51026> it uses tmp storage instead
15:53:28 <peter1138> Callback 14 exists to draw dynamic layouts, but in many cases Callback 24 should be sufficient.
15:54:18 <_glx_> there's also `station_layouts`
15:54:33 <_glx_> (undocumented of course)
15:54:43 <peter1138> Is that NML-speak for static layouts?
15:55:12 <peter1138> Cos yeah, there is, but it's perhaps more suited to when you only have a limited number of different layouts.
15:55:44 <peter1138> Using foxed tables for everything from 1x1 up to 64x64 is going to be a pain compared to CB24 :)
15:57:54 <_glx_> CB24 is `select_tile_type`
15:58:16 <peter1138> Yeah, that's build-time selection of tile layout.
15:59:19 <rito12_51026> What for is `select_sprite_layout` then?
16:04:01 <peter1138> Is select_sprite_layout CB14?
16:04:31 <_glx_> anyway 18 different layouts seems excessive base on the video
16:05:35 <_glx_> yes `select_sprite_layout` is CB14
16:05:38 <peter1138> effectively, prop 0E is "compile time", CB 24 is "build time" and CB 14 is "run time".
16:06:10 <peter1138> But I dunno much about NML's implementation.
16:06:26 <_glx_> and it's even worse if each spritelayout has parameters
16:07:20 <_glx_> in this case it's 18 spritelayouts per axis, so 36 parameters
16:07:24 <peter1138> Traditionally you define all your layouts in act 0 prop 09, then reference the indices from prop 09 in prop 0E/CB 24/CB 14.
16:07:50 <peter1138> Why do the layouts need parameters?
16:08:08 *** kuka_lie has joined #openttd
16:08:27 <_glx_> don't know for this exact case (as it's not a non track tile)
16:08:57 <_glx_> param is currently the only way to disable track
16:10:49 <peter1138> In most cases that isn't necessary -- you just set the blocked tile flag and then draw over the ground.
16:11:37 <rito12_51026> peter1138: to get corresponding sprite from Spriteset
16:12:23 <ahyangyi> They can be hardcoded, though if they're dynamic you do need to use a parameter anyways
16:12:42 <peter1138> That... doesn't need a parameter?
16:13:36 <peter1138> The sprite layout contains the sprite to use.
16:13:54 <ahyangyi> And one can adjust the sprite ID offset in the "advanced tile layout"
16:14:01 <ahyangyi> Persumably that's where they need the parameter
16:14:10 <peter1138> If you want a different sprite, then you can use an additional tile layout./
16:14:30 <ahyangyi> Not a good idea in all cases though.
16:15:51 <ahyangyi> If one tile layout contains lots of conditional things ("draw this if the tile to the south has a track") ("draw this sprite if it's a snowy tile"), the number of additional tile layouts needed might be high
16:16:30 <ahyangyi> Anyways, using more tile layouts in general does make things simpler
16:16:48 <_glx_> `hide_sprite` using a temp register works for that
16:17:15 <_glx_> that's how I did CHIPS magic tile
16:17:27 <ahyangyi> Uh yeah, I'm using temp registers too
16:17:44 <_glx_> `prepare_layout` fills the registers
16:23:49 <peter1138> There's no real limit to the number of tile layouts. With prop 0E/CB 24 you can have 256 of them, with CB 14 you can have 65535 layouts. The action 1 spriteset may become an issue at that point.
16:24:13 <rito12_51026> So I have used temp storage instead like you did and now I only use 12/127 registers
16:41:14 *** tokai has quit IRC (Ping timeout: 480 seconds)
16:43:11 <andythenorth> maybe I should look at FIRS stations again π
16:43:31 <andythenorth> or maybe the channel needs Not That
16:44:03 *** ChanServ sets mode: +v tokai
16:48:52 *** Rikests has quit IRC (Remote host closed the connection)
16:49:28 <ahyangyi> rito12_51026: I think I have used only 12 across all development branches, and even fewer in the main branch. But on the other hand I think the automatic handling in NML might be less efficient than what we do manually?
16:50:34 <andythenorth> grf callback to plant objects? :eyes
16:50:38 <andythenorth> (the fences in this case)
16:51:19 <ahyangyi> It's not off-topic if it's about a potential new OpenTTD feature...?
16:52:48 <peter1138> Industries can plant fields. Is it just a special field? Heh.
16:53:45 <ahyangyi> Oh, I misunderstood the question.
16:54:12 <ahyangyi> Thought it was about industry callbacks accessing information about plants, aka trees.
17:06:35 <mmtunligit> i just set up clangd in my IDE, is it normal to see errors everywhere in the diagnostics?
17:09:59 <rito12_51026> _glx_: How to calculate the sprite offset for provided rail type?
17:12:35 <xarick> FindSpring takes 13% of the time inside std::max shennanigans
17:20:28 <xarick> this->RiverFlowsDown calls GetTileMaxZ, which calls GetTileSlopeGivenHeight
17:22:02 <xarick> I also have a (not a) PR for GetTileSlopeGivenHeight
17:22:13 <xarick> using the look up table
17:25:03 <xarick> this->RiverFlowsDown calls GetTileSlopeZ
17:32:10 <mmtunligit> ok im having some trouble settign up clangd properly. I'm currently trying to generate ```compile_commands.json``` like it says to in the instructions with ```cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=1``` but it isn't working. when i run the command in ~//openttd it says to run ```cmake ..``` in the build directory which ive done, but the error wont go away. and when I try to run it in the build
17:32:10 <mmtunligit> directory it wont work because that directory doesn't contain ```CMakeLists.txt```, should i move that into the build directory?
17:37:10 <mmtunligit> ok moving it did not work
17:42:58 <peter1138> CMAKE_EXPORT_COMPILE_COMMANDS is enabled by our CMakeLists.txt
17:44:33 <peter1138> They will get put in the build directory though.
17:45:02 <peter1138> With my VS Code configuration, it then copies compile_commands.json to the workspace directory where clangd can see it.
17:45:40 <peter1138> `"cmake.copyCompileCommands": "${workspaceFolder}/compile_commands.json",` is the config for that.
17:45:54 <peter1138> (I assume it's part of the CMake integration)
17:51:45 <mmtunligit> ok so i dont need to run the command then cool
17:53:41 <mmtunligit> also how does upsteaming changes work? because i only see one set of all the files so if i made some changes but never pushed them to my fork would they get overridden when upstreaming?
17:53:49 <mmtunligit> and is that intended behvior if so
17:57:01 <peter1138> Sounds like you need a git basics tutorial.
17:58:38 <mmtunligit> yeah, i tend to come into these sorts of things from an angle instead of straight ahead. im not sure if its a bad habit or just my style of learning
20:10:34 *** toktik has quit IRC (Remote host closed the connection)
20:42:29 *** Wormnest_ has joined #openttd
20:42:29 *** Wormnest has quit IRC (Read error: Connection reset by peer)
21:18:47 <xarick> i simplified the passing around of the vector
21:19:22 <xarick> hopefully it's only created once now, it is accessed by & reference stuff
21:19:33 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:20:00 <xarick> in turn that also made me remove the tuples
21:55:51 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:05:14 <xarick> SpiralTileIterator, i have a use case where I'd like to pass the start tile as the top corner of the hole
22:07:00 <xarick> SpiralTileIterator is slower than what I had before anyway
22:11:21 <locosage> cb24 is quite awkward btw, spec says stations doesn't exist and variables aren't available but it kinda does
22:11:46 *** kuka_lie has quit IRC (Remote host closed the connection)
22:11:53 <locosage> like, it has random bits and some vars are accessible albeit fake (purchase)
22:13:07 <mmtunligit> doing this would be bringing it in line with how all the other build toolbars are handled, where they close themselves and reopen at the default position when opened, currently the terraform toolbar simply stays open wherever youve placed it.
22:13:07 <mmtunligit> I'm wondering what other people think of this, and if i should close my current PR and make a new one(s?) for this or just add on to my current one
22:16:02 <peter1138> It doesn't say the station doesn't exist, it says "Since the station hasn't yet been built"
22:16:45 <peter1138> What that means is the tiles to be built during the current build operation haven't yet been built.
22:18:47 <locosage> not sure what you mean by current build operation but tiles are partially built when cb is called
22:19:22 <locosage> even the tile it's called for is build iirc
22:20:01 <peter1138> By "current build operation" I mean the entire command.
22:20:23 <peter1138> If you're building a 4x4 station, then you can't rely pn
22:20:35 <peter1138> Can't rely on other parts of that 4x4 being built yet.
22:27:33 <locosage> what happens when grf uses unavailable var btw?
22:32:22 <_jgr_> Evaluation moves to the first range option (DeterministicSpriteGroup::error_group), which is usually bad news unless you're doing it on purpose
22:34:46 <locosage> oh, that possibly explains some weirdness I've seen..
22:40:45 <peter1138> Exactly the same as trying to use unavailable variables in purchase lists.
22:41:24 <peter1138> In fact the purchase list versions of those "unavailable" variables are used in this case.
22:42:22 <peter1138> (Which means they are not usuable for things like determining where you are in the layout)
22:58:49 *** tokai|noir has joined #openttd
22:58:49 *** ChanServ sets mode: +v tokai|noir
23:05:50 *** tokai has quit IRC (Ping timeout: 480 seconds)
continue to next day β΅