IRC logs for #openttd on OFTC at 2025-11-16
⏴ go to previous day
00:18:35 *** kuka_lie has quit IRC (Quit: Lost terminal)
02:57:34 *** Wormnest has quit IRC (Quit: Leaving)
03:56:04 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
04:21:36 *** Zathras has joined #openttd
04:24:56 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
04:40:18 <DorpsGek> - Update: Translations from eints (by translators)
05:25:22 *** ChanServ sets mode: +v tokai
05:32:16 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
08:34:23 <andythenorth> I can't make sense of anything yet 😛
08:51:49 <andythenorth> station picker always opens roughyl in the middle of my screen
08:52:20 <andythenorth> I can use the square button to preserve the size, although that state seems to be lost when I crash OpenTTD (which is often)
08:52:30 <andythenorth> but the position isn't preservable
08:52:46 <andythenorth> wondering if we could have construction windows dock to left or right of the screen
10:13:49 <peter1138> > 48 files changed, 917 insertions(+), 875 deletions(-)
10:34:52 *** Flygon has quit IRC (Read error: Connection reset by peer)
10:46:37 <xarick> is this hallucination? I asked copilot to generate commit message. That last phrase seems like hallucination
10:46:37 <xarick> > Update manifest to use asmv3 namespace for Windows settings
10:46:37 <xarick> > Refactored openttd.manifest to use the asmv3 namespace for trustInfo, application, and windowsSettings elements. This improves compatibility with newer Windows manifest schema requirements.
10:48:16 <xarick> i noticed copilot really likes to use the word refactor
10:56:29 <mmtunligit> I think you should probably understand the words you’re using to describe things and not outsource your thinking to a machine and hope what it spits out makes sense to someone
11:04:53 <xarick> i kind of scared to make a PR for this
11:05:10 <xarick> there's a fix in the way, but i'm just impatient
11:19:39 <kaji_kaede> xarick: If you need to ask. Stop.
11:20:01 <kaji_kaede> Stop and just ask someone for help who actually knows what they're doing.
11:23:06 <_glx_> Don't touch the manifest, it's fine as it is
11:26:31 <_glx_> Especially when the issue is "broken" compiler inserting invalid stuff inside the manifest
11:31:17 <_glx_> You can use this change locally, but it doesn't need to go in master
12:02:32 * peter1138 ponders order flags.
12:03:46 <peter1138> Some of them are used like bitsets when it doesn't really make sense.
12:28:21 <peter1138> e.g. order_cmd.cpp:668 ensures that either no bits or only one bit is set for unload type.
12:29:17 <peter1138> :654-666 does the same for load type, except there's more of a mix of values.
12:30:33 <peter1138> I wonder if it makes sense to simplfy this, instead of blindly switching to EnumBitSet.
12:33:12 <xarick> I haven't checked the unload flags
12:34:26 <xarick> but there are issues with the unbunch that I tried to fix while I was at it
12:35:38 <xarick> oh, I also noticed non-stop flags had a little problem when set from AIs
12:35:52 <xarick> I fixed it on the AI side
12:38:57 <xarick> don't recall exactly what it was but it's something about non ground vehicle and nonstop to depot orders combinations being passed to the DoCommand as valid only then to fail as a response.
12:39:23 <xarick> So i made it fail before reaching DoCommand
12:41:00 <peter1138> As long as the command itself correctly fails, that's not really a problem. Just sub-optimal for the AI.
12:45:44 <_glx_> The rules about valid flags for a given type are painful to handle
12:46:26 <_glx_> And it's not surprising some are missing on API side
12:59:13 <peter1138> As Load/Unload types are (almost) mutually exclusive, using a bitmask is weird.
14:14:38 <andythenorth> bring back Timberwolf
14:34:14 *** kaibaneddy has joined #openttd
14:37:50 <kaibaneddy> what did you do to him?
15:07:22 <peter1138> I guess I should split it up.
15:08:42 <rito12_51026> One commit per enum?
15:29:59 <peter1138> The change to OrderLoadFlags/OrderUnloadFlags is more than just a simple enum -> enum class change.
15:38:01 <Borg> howdy.. is there some kind of real clock in OpenTTD? in ms.. I found _realtime_tick but it seems to be updated when game runs (not paused)
15:38:14 <Borg> I want sth declouped from game logic to handle gui timeout/ hotkey timeout
15:44:44 <Borg> oh nevermind. i will hook up directly into loop
15:49:07 <peter1138> There's OnTimeout and OnRealtimeTick window events.
15:53:40 <Borg> hmm but I need it much earlier.. due to how TAB key is handled in Win32
16:02:32 <peter1138> - bool force_unload = (order_flags & OUFB_UNLOAD) != 0;
16:02:32 <peter1138> - bool force_transfer = (order_flags & (OUFB_TRANSFER | OUFB_UNLOAD)) != 0;
16:02:42 <peter1138> Hmm, is unload meant to force transfer as well?
16:06:41 <Borg> what is forced unload is supposed to do anyway?
16:06:51 <Borg> Transfer and leave empty is clear..
16:07:08 <peter1138> It forces unloading even if the station doesn't accept the cargo.
16:07:46 <peter1138> The difference is a fo "unload" order will unload if it's accepted, a
16:07:46 <Borg> but what is the use case?
16:08:05 <peter1138> Transfer always transfers.
16:08:12 <kaibaneddy> unload cashes in the cargo if station accepts, transfers if it doesn't. transfer transfers cargo and leaves it on the platform in either case.
16:08:47 <Borg> imo Force Unload shouldnt exist...
16:08:58 <Borg> but.. I wonder if someone uses it.. and if yes.. what is the use case
16:09:06 <Borg> I either do.. No loading.. or Transfer and leave empty
16:09:11 <Borg> of course nothing for PAX..
16:09:18 <Borg> never ever had to use Force Unloading..
16:09:34 <kaibaneddy> hysterical raisins. before explicit "transfer" was a thing.
16:10:46 <peter1138> The existance of the "force unload" option causes problems for new players who think it's needed for a train to unload.
16:13:30 <kaibaneddy> but it's an original TTD feature so we're more or less stuck with it 😄
16:23:20 *** Wormnest has joined #openttd
16:33:40 <audigex> kaibaneddy: I vaguely recall he got tired of people making requests/demands/complaints for his newGRFs
16:33:40 <audigex> I suspect he might still have an account here, just not under the TW name
16:47:58 <Borg> okey.. workz.. 200ms delay seems good
16:48:11 <Borg> press TAB. hold it at least 200ms.. fastforward will kick in
17:29:38 <xarick> oh, jgrpp 0.68.1 still doesn't have cloneable lists
17:30:30 <xarick> how do you even pass regression tests
17:33:10 <_jgr_> Cloneable lists is ultra-low priority
17:33:38 <_jgr_> When I get round to merging those commits the regression tests will obviously also be updated as required
17:38:40 <xarick> scary to see copilot automatically write squirrel code
17:39:08 <xarick> and actually doing it correctly
17:41:58 <xarick> look where my cursor is and the autocomplete
18:01:41 *** jinks has quit IRC (Ping timeout: 480 seconds)
18:02:49 *** lobster has quit IRC (Read error: Connection reset by peer)
18:02:59 *** lobster has joined #openttd
18:38:15 <xarick> testing the several regression tests on safe btree
18:39:30 <xarick> jgrpp fails the "several" regression test suite
18:39:58 <xarick> openttd-jgrpp-0.68.1-windows-win64
18:41:01 <xarick> the fix is easy, I assume
18:43:17 <xarick> change to `if (this->initialized) this->sorter->Remove(item);`
18:43:58 <xarick> how buildable is jgrpp source code with visual studio?
18:44:26 <xarick> haven't tried building
18:52:17 <andythenorth> jgrpp builds trivially on mac, identical to main
18:53:39 <xarick> eh... almost at first try
18:56:30 <_jgr_> xarick: If this is merged into master I'll make any adjustments required when it comes to merging it into my branch
18:59:12 <_glx_> xarick: somehow missing libs
18:59:18 *** gelignite has joined #openttd
19:00:13 <_glx_> vcpkg should have detected them, unless you forgot to configure vcpkg
19:00:37 <xarick> i just clone repository, then open folder and build
19:01:15 <_glx_> no need to copy vcpkg, but you need the set VCPKG_* vars for cmake
19:02:32 <_glx_> usual CMAKE_TOOLCHAIN_FILE and VCPKG_TARGET_TRIPLET
19:11:36 *** Borg has quit IRC (Quit: leaving)
19:30:05 <peter1138> Okay, SwapList ... should we just reset iterators?
19:30:39 <peter1138> Or should we try to support swapping lists and iterating. Seems mad.
19:30:50 <peter1138> But the code looks like it attempted it.
19:39:58 <xarick> jgrpp has made some additional changes
19:42:07 <xarick> if i undo this, it may pass the "several" tests
19:51:00 <xarick> nice! it finally passes
20:00:16 * andythenorth me plans more railtypes
20:00:26 <andythenorth> 50 shades of red
20:05:41 <xarick> unanimous pass with safe btree map/set!
20:06:55 <xarick> btw why don't you have a windows (Clang) job?
20:14:07 <xarick> seems to be a std::map issue
20:14:33 <xarick> only windows got it right
20:18:03 <_jgr_> xarick: It will be replaced by 14753 as and when that is merged
20:28:04 <xarick> Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0
20:32:19 <Rubidium> now... why is it that monstrosity? Because browsers are trying to tell that they're behaving like another browser, mostly for backward compat. Similarly clang is actively trying to be gcc-alike so it could be easily used instead of gcc, and looking like gcc is one of those things
20:43:22 <_glx_> somewhere inside DefSQNonStaticCallback
20:43:54 <xarick> it does not like my implementation of ScriptList
20:44:15 <xarick> even the station_regression fails
20:57:27 <_jgr_> xarick: I do not think that your trial and error approach is going to work for this
21:01:20 <_jgr_> You really must be aware of the iterator invalidation rules, lifetime behaviour, etc for the approach you're using in that PR
21:06:13 <xarick> definitely not versed on those
21:23:14 <xarick> have a vague idea what it could be
21:24:58 <xarick> _glx_: seems that there were 2 crashes
21:25:04 <xarick> but the log is repeated
21:25:51 <xarick> not sure which log is it for...
21:26:03 <xarick> regression_stationlist or regression_regression
21:28:10 <talltyler> Oof, I just spent an embarrassingly long time implementing random chance from first principles using `Random()` and bitwise operation. Then I realized `Chance16()` has been sitting there the entire time waiting for me to discover it. 😛
21:30:56 <xarick> _glx_: it's the regression_regression crash log repeated twice
21:31:32 <xarick> regression_stationlist savegame has vehicles in it, and the company details show no vehicles
21:35:31 <kuhnovic> I still think rivers need to look a bit less rectangular
21:35:56 <_glx_> xarick: not my fault if cmake runs both at the same time 🙂
21:37:09 <talltyler> OpenGFX+ Landscape has some nice river curves
21:37:52 <_glx_> but yeah second regression run detects crash generated by the first run because they are running in parallel (first thing regression script does is remove any existing crash data)
21:39:34 <talltyler> PR coming once I clean up the code a bit, but the idea is to provide some more variety in generated landscapes and add interesting construction barriers/challenges
21:39:54 <talltyler> Need to get the edge feathering working again too
21:40:05 <kuhnovic> talltyler: Yes those look really good. But I like opengfx2 a lot too so I'm a bit torn 😉
21:40:32 <talltyler> We'll just have to bother _zephyris to make us some curvy rivers 😛
21:40:35 <kuhnovic> Nice idea, I like it
21:41:07 <kuhnovic> Yup, and he was also one of the authors of OpenGFX+landscape
21:48:55 <locosage> talltyler: don't think openttd needs any more construction "challenges", it's already painful enough to build things with such archaic tools
21:49:08 <locosage> besides, your swamp is just rivers so dynamite and go on
21:54:20 <kaji_kaede> kuhnovic: There's OGFX+ Landscape Minus on the browser, if it's any help.
21:54:41 <kaji_kaede> Either way. Extra landscape variety is *very* exciting to see.
22:12:01 <acs121> talltyler: Now that's really interesting
22:12:34 <mmtunligit> thats right fuckers, we're getting water vehicles that start in the year -3000 be prepared for the worst long term game of your life
22:13:01 <acs121> I've been thinking about how realistic geomorphological features could be implemented in OTTD haha
22:13:59 <talltyler> I thought about a new water class to put trees in the water, but that feels a bit of scope for the initial implementation 🙂
22:14:08 <mmtunligit> multilayer map PR but the underground layers have different costs based on the type of rock
22:14:32 <kaji_kaede> talltyler: Nah. You gotta spend a week writing the code before it even compiles. That's how you know you're doing it right. :>
22:14:35 <mmtunligit> full plate techtonics sim on worldgen
22:14:41 <mmtunligit> going full dwarf fortress with it
22:14:58 <talltyler> mmtunligit: Shh, I already talked myself out of this last night 😛
22:15:13 <kaji_kaede> oh god this makes me wanna touch tree code. I'm getting stockholm syndrome from my JGRPP pull request-
22:15:13 <mmtunligit> i was making a joooooooke
22:15:24 <mmtunligit> i mean we gotta get multilayer map first
22:15:31 <mmtunligit> then we can go fuck around with it
22:15:51 <mmtunligit> im not doing shit for that kaji_kaede wayyyyy above my paygrade lol
22:15:58 <talltyler> Fell into a rabbithole thinking about how to get rid of these silly little holes that rivers flow into
22:16:19 <acs121> mmtunligit: Subterranean airports, 100% crash rate 🔥
22:16:29 <mmtunligit> right now im struggling to figure out how to make equivalent functions for saved groups as exist for items and classes in the pickerwindow
22:16:47 <mmtunligit> mainly jsut to do with what data types i need and how to get them
22:17:43 <talltyler> I have some thoughts on a recursive flood fill algorithm to find disconnected water tiles in TGP (before they even get made into tiles) and change them to land, but I need to at least get swamps into a PR before I start a new project 🙂
22:17:59 <mmtunligit> i *think* its std::string but it might be std::pair and an even smaller chance its std::map but im not certain and dont know how to grab them from all the places they need grabbing
22:20:09 <peter1138> Pretty sure you don't need equivalent functions.
22:20:18 <locosage> I tried at some point to come up with a whole concept for multi-layered terrain in openttd but decided it's tmwftlb
22:21:28 <locosage> like, snow is just an optional layer above everything
22:22:11 <mmtunligit> peter1138: im talking like the buildpickergrouplist, ensureselected groupisvalid and ensureselected group is visible
22:22:24 <mmtunligit> wow i meade a mess of that
22:22:53 <locosage> then there is water stuff like ice/swamp/canal/river/ocean
22:23:04 <locosage> and that somehow combines with grass/rocks/sand/etc
22:24:21 <mmtunligit> i might not need EnsureSelectedGroupIsValid (would only get called when the current group is deleted) but i definently need the other two
22:26:07 <peter1138> Probably not. saved groups should be the same for all picker window types so don't need any type-specific handling.
22:29:58 <mmtunligit> im sure i understand what you mean, id still need to build the list at the very least no? and if you have enough groups that you can scrollaway from the currently selected one, and click another item in it, it should snap back to in view like the class list. and you wouldnt want your house groups to show up in the objects menu
22:50:00 <xarick> next step is reverting back PostErase in
22:51:55 <xarick> oh well, cyas goodnight
22:53:46 <peter1138> saved items are already unique per feature, no reason to complicate it by making them not unique.
22:54:55 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:56:55 <mmtunligit> mhm, that helps me narrow down scope a bunch, thanks
23:26:13 *** Zathras_4 has joined #openttd
23:36:00 <talltyler> Town generation in swamps is fun
23:38:10 <kaji_kaede> I think my mind is being blown by the sheer concept of visual variety in this game.
23:40:34 <mmtunligit> talltyler: dutch town names for the swamp town is a good bit
continue to next day ⏵
