IRC logs for #openttd on OFTC at 2025-05-18
⏴ go to previous day
00:00:43 *** WormnestAndroid has joined #openttd
00:25:07 <goddess_ishtar> ...that was actually far easier than I thought
00:56:24 <goddess_ishtar> semantically, a mapping between two values is best represented as a struct, right?
00:56:50 <goddess_ishtar> brain is fried
00:59:39 <goddess_ishtar> right now I just have a simple C-style array converting from the value of the State enum to the sort priority, and I just use the indexes as "keys" and the priority as the values
01:00:05 <goddess_ishtar> but I'm pretty sure there's a more readable way to do it
01:39:52 *** ChanServ sets mode: +v tokai
01:46:50 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:05:17 *** Wormnest has joined #openttd
02:10:19 *** Wormnest has quit IRC (Quit: Leaving)
02:58:04 *** gnu_jj_ has joined #openttd
03:01:40 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:50:15 <DorpsGek> - Update: Translations from eints (by translators)
06:27:52 <peter1138[d]> goddess_ishtar: You can just change the order of the enum, no need for mapping things.
06:49:26 <peter1138[d]> Hmm, forum's on a go-slow.
07:11:22 <andythenorth> maybe it needs coffee
07:14:35 <andythenorth> hmm so there's a thing where reversed state is inherited when auto-replacing
07:14:49 <andythenorth> wonder if setting reverse_build_probability to 0 would prevent that
07:33:18 <peter1138[d]> Nope. It's a misdesign by me again.
07:39:20 <andythenorth> dunno, have you had coffee yet? 😛
07:39:33 <andythenorth> isn't it just 'autoreplace needs to read that prop'?
07:39:45 <peter1138[d]> Callbacks are not properties.
07:40:54 <peter1138[d]> Anyway, to start things off, the probability thing probably needs to be "yes, no, callback failed" rather than just "yes, no"
07:44:40 *** Flygon has quit IRC (Read error: Connection reset by peer)
07:50:28 <goddess_ishtar> peter1138[d]: I assumed that would end up breaking something somewhere, although I probably could
08:41:05 *** nielsm has quit IRC (Ping timeout: 480 seconds)
09:05:42 <xarick> unfortunately, now that I was hoping for a crash from resuming hibernation, it didn't crash
09:19:49 <andythenorth> coffee issues continue
10:06:18 <xarick> is there a way to know my bribe worked as an AI?
10:11:37 <andythenorth> read the town rating?
10:29:28 <xarick> the wings are covering text
10:31:36 <pickpacket> xarick: wouldn't PerformTownAction() return false if the bribe didn't work?
10:32:26 <_glx_> No, IA don't get feedback for this one
10:35:02 <pickpacket> find out if it got caught, at least
10:35:16 <_glx_> Not easy, the command never fails in test mode while it can when executed
10:36:40 <_glx_> There's special handling for local player because of that
10:37:21 <pickpacket> it's an issue of test coverage, then?
10:38:37 <xarick> Chance16(1, 14), how do you come up with the exact odds
10:43:19 <xarick> t->unwanted could be exposed to AIs
10:54:49 <xarick> 39 trees needed after a bribe failed, to bring it back to good stats
10:56:40 <xarick> Spectators and unwanted have no options
10:56:46 <xarick> interesting, so there's a way
11:08:09 <xarick> looks like it's not needed to expose t->unwated
11:08:26 <xarick> just checking if actions are disabled is sufficient
11:11:19 <xarick> shouldn't a bribery be newsworthy?
11:13:47 <xarick> i was caught bribing, but my exclusive transport rights is still in effect, is that how it works in real life?
11:13:57 <xarick> shouldn't it be invalidated
11:21:25 <xarick> i wonder what timer is used here... Calendar? Wallclock?
12:09:32 *** tateisukannanirase has joined #openttd
12:09:32 <tateisukannanirase> Unbunch for ships is suppose to work isn't it? Searched but only few references in the discord history to ship unbunch. I can't seem to get it to work. I am on 15.0-beta1, a bit old :/ .
12:17:16 <talltyler> Yes, it works. Unbunching takes several round trips to start working — it uses a rolling average of each vehicles last trip time, which right after construction is 0. This insulates the feature from major delays due to train jams, etc., from excessive spacing after the jam is cleared.
12:17:16 <talltyler> Ships are slow so several round trips take longer. Just be patient. 🙂
12:21:24 <tateisukannanirase> Thanks Tyler! I had my ships doing a V from a hub port to two small ports but I split them up into two routes so the timetable should be faster to calculate. These ships have been running for 'decades' already but I only just learnt about the unbunch feature. Does the unbunch trip time only calculate from when the unbunch order was added?
12:25:48 <xarick> aircraft can land with a zeppeliner in the way... I don't get it why
12:26:06 <_glx_> trip time is updated every time the vehicle reaches unbunch order
12:27:37 <tateisukannanirase> _glx_: so previous route history from when the unbunch order was not present, is not used? That makes sense, I'll just have to be more patient.
12:29:01 <peter1138[d]> Also requires shared orders, just in case they're not.
12:29:42 <tateisukannanirase> definitely are shared orders!
12:51:57 *** Tirili has quit IRC (Quit: Leaving)
13:01:15 <xarick> someone broke airport movement states?
13:02:12 <xarick> someone had the courage to change those airport flags...
13:09:46 <_glx_> haha found the error I think
13:13:12 <_glx_> hmm or maybe not, bit stuff is hard to read
13:16:13 <xarick> enum AirportMovingDataFlag : uint8_t, but it has 9 flags
13:17:59 <_glx_> well uint8_t can hold 256 values 😉
13:22:10 <peter1138[d]> What sort of airport is it?
13:22:59 <_glx_> zeppelin targets are small ones
13:25:55 <peter1138[d]> Hmm, Zeppelin sets the RunwayIn block, but the small (country?) airport does not have one.
13:26:15 <peter1138[d]> Oh, re-used numbers.
13:26:55 <xarick> it can target large airports too
13:27:03 <xarick> city and small i believe
13:31:10 <_glx_> anyway disaster code looks fine to me
13:32:37 <peter1138[d]> I wonder if it's the same for a large aircraft crashed on the runway.
13:44:28 <xarick> think i found something
13:45:56 <xarick> some 0 was changed to TO_ALL
13:47:55 <_glx_> anyway the ideal thing to do would be `git bisect` but zeppelin crash repeatability is a pain
13:49:57 <peter1138[d]> Step 1) confirm that the commit before this one works. 2) confirm that this commit fails.
13:53:33 <xarick> or... erm maybe the commit before these flags
13:54:38 <_glx_> well knowing if it works in 14.1 or not is also nice info
13:55:15 <_glx_> might be broken for very long time without nobody noticing it
14:06:02 <xarick> wow, it's broken in 14.1
14:06:57 <xarick> how did I not notice this before
14:08:20 <xarick> gonna build OpenTTD 13
14:13:11 <xarick> can't find lzma zlib stuff...
14:14:07 <_glx_> yes it's the old way, needs manual vcpkg install of the packages
14:14:21 <_glx_> easier to test older releases via steam
14:14:29 <xarick> okay, where do I download openttd 13 , oh i dont have steam
14:21:45 <xarick> strange, it works in 14.1 now
14:22:00 <xarick> some conditions seem to be required
14:22:21 <peter1138[d]> It's possible it depends on whether there is an aircraft already there.
14:25:17 <xarick> you're right, that's interesting
14:25:34 <xarick> gonna upload another savegame
14:25:39 <xarick> before the zeppeliner crashes
14:25:52 <peter1138[d]> An aircraft that is already in the block will clear it when it leaves.
14:29:45 <_glx_> hmm but `DisasterTick_Zeppeliner()` is supposed to set the flag continuously
14:37:12 <xarick> how come I never encountered this before, :!
14:40:19 <peter1138[d]> _glx_: Oh, maybe, I didn't check.
14:42:12 <peter1138[d]> _glx_: Could be unset, then a plane starts landing, then the disaster vehicle sets it again. But the landing plane will already be landing. Race condition style.
14:48:03 <xarick> aren't do commands synced or hmm
14:48:24 <xarick> the hash isn't synced?
14:49:10 <_glx_> hash is local and platform dependant
14:49:13 <peter1138[d]> Hash is not synced as it depends on the order things are added.
14:51:16 *** arikover has joined #openttd
14:53:40 <xarick> I notice there's more Train::Iterates around
14:55:49 <peter1138[d]> Adding each VehicleID to a vector, then calling std::ranges::sort() on it would do the job.
14:56:04 <peter1138[d]> There's no need to test for uniqueness.
14:57:18 <peter1138[d]> FlatSet<> and std::map<> would have extra overhead.
14:57:23 <peter1138[d]> Train::Iterate is sorted.
14:58:58 <_glx_> hmm doesn't even need to fill a list, just find the lowest/highest ID matching the condition
14:59:51 <peter1138[d]> Lowest and Highest could be either end of the Vehicle Pool. You'd be iterating a lot.
15:00:55 <_glx_> from the hash it's not different than filling a vector then sorting
15:01:22 <peter1138[d]> I'm not sure what you are proposing.
15:01:34 <peter1138[d]> You have to iterate the hash to get the lowest and highest.
15:01:46 <peter1138[d]> And then you have the lowest and highest, what about the rest?
15:02:11 <_glx_> you have to iterate to hash to fill the vector too, and in the end only the first matching id matters
15:02:30 <_glx_> since you attach to the end of the chain containing it
15:02:59 <peter1138[d]> It's possible for the move command to fail. e.g. wagon attach callbacks.
15:03:34 <peter1138[d]> So you need the vehicles in order. And the hash isn't in order, so you need the sorted list.
15:03:54 <peter1138[d]> In general, any list will probably be quite small
15:04:15 <_glx_> yeah list will contain prefiltered id anyway
15:21:31 *** Wormnest has joined #openttd
15:22:10 <xarick> ah, TrainList is defined below, my bad
15:23:19 <xarick> maybe bad idea to use v and u
15:23:46 <xarick> v is an existing variable
15:29:56 <xarick> free_wagons or free_wagons
15:33:13 <xarick> how do i test more than 1
15:37:13 <xarick> ah, must reach train length limit to increase that to 2
15:37:58 <xarick> in other words... this ordering stuff seems pointless
15:38:22 <xarick> "but newgrfs"... i dont know what they do
15:38:54 <peter1138[d]> Just use `std::vector<VehicleID>` not `TrainList`.
15:39:20 <peter1138[d]> (You want to sort by index, not pointer value)
15:40:06 <xarick> isn't that doing v->index < u->index?
15:40:14 <peter1138[d]> Yes, but there's no need.
15:40:22 <peter1138[d]> You only use v->index in the command.
15:40:32 <peter1138[d]> So just store index in the first place.
15:41:02 <peter1138[d]> Your sort operation then is just `std::ranges::sort(freewagons);`
15:45:50 <_glx_> peter1138[d]: nope, v->index is the new wagon, w->Last()->index is the end of chain, and that's what matters, so storing pointers might be needed
15:46:38 <_glx_> well we can just store last
15:46:45 <peter1138[d]> Store `w->Last()->index`
15:47:32 <peter1138[d]> Just use `std::vector<VehicleID>`, don't use these other types that happen to exist.
15:48:21 <xarick> but VehicleSet is exactly that
15:48:34 <peter1138[d]> VehicleSet is used for something else, and that type might be changed later.
15:48:37 <xarick> code reuse not a good thing?
15:50:16 <peter1138[d]> `std::vector<VehicleID>` is "reusing" std::vector 🙂
16:12:58 <xarick> I'm thinking replacing more cases of Train::Iterate with this vector stuff
16:13:08 <xarick> NormalizeTrainVehInDepot
16:31:30 *** gelignite has joined #openttd
16:33:33 *** arikover has quit IRC (Remote host closed the connection)
16:42:13 <_glx_> don't do it in the current PR
16:56:36 *** arikover has joined #openttd
17:05:19 <xarick> intellisense is failing for some reason since I tried to build openttd 13
17:24:08 <arikover> Hello! I have a problem compiling (Ubuntu 22.04) since commit 55588b052eb2cd9f033eac5e73792c3e61fc2610. It seems to be related to the 'fmt' library. Error message: "error: redefinition of ‘struct fmt::v10::formatter<E, Char>’".
17:24:36 <arikover> Did anyone hear of this problem?
17:27:29 <_jgr_> You need to use gcc 12 instead of the system gcc
17:31:48 <arikover> I installed gcc 12.3.0, still doesn't work, but maybe I need to restart...
17:34:05 *** alexanderfxe4125_yt has quit IRC (Quit: User went offline on Discord a while ago)
17:34:28 <_jgr_> Delete CMakeCache.txt from your build folder
17:34:54 <_jgr_> Then you'll need something along the lines of `CC=/usr/bin/gcc-12 CXX=/usr/bin/g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release`
17:39:03 <xarick> got a crash in findgoodvehiclepos...
17:45:30 <arikover> _jgr_: Thanks! It works now...
17:46:56 <xarick> let me test master just in case
17:53:10 <xarick> ah, I need to break the while
18:19:33 <peter1138[d]> Okay, trackball is no good for Doom 🙂
18:24:35 <andythenorth> I used to play Unreal Tournament 1999 on trackball
18:25:40 <peter1138[d]> Is that different from Unreal Tournament?
18:33:22 <andythenorth> I had some shareware version with only 2 levels or something
18:33:35 <andythenorth> floating platforms in space
18:34:10 <peter1138[d]> There was a reboot a few years ago, but it didn't get much life.
18:34:55 <peter1138[d]> UT was weird because it had a single-player mode 🙂
18:35:20 <andythenorth> yeah I only played that
18:40:51 <_zephyris> Battle royale killed classic shooters
18:41:27 <_zephyris> No way unreal was going to put any money into a new UT when Fortnight was around
18:44:29 <peter1138[d]> Well, they tried, but yeah.
18:45:27 <peter1138[d]> Problem for me is that UT was a winning formula, so the remake was different and not as good.
18:47:10 <_zephyris> UT -> UT2003/2004 suffered from the scale and pace problem
18:47:18 <_zephyris> ie. what doom 2016 managed to fix
18:47:49 <andythenorth> let's see if my compile works 😛
18:48:12 <peter1138[d]> Yeah, UT was in the era when "wow, 3D graphics!" was enough, and it didn't matter that it was all very abstract and out of proportion.
18:48:22 <andythenorth> hmm am on some kind of badge branch currently
18:48:43 <peter1138[d]> And trying to be realistic with jumping, falling, walking and running speed is just tedious.
18:50:47 <xarick> even on a fresh new game there's a boost
18:55:28 *** kuka_lie has joined #openttd
18:56:50 <peter1138[d]> I wouldn't expect searching the hash to ever be slower, tbh.
18:57:26 <peter1138[d]> If there's enough vehicles for the hash performance to tank, then iterating the pool is also going to tank anyway.
19:01:37 <_zephyris> Probably a lesson there... Something about realism not making a game fun 😉
19:02:15 <peter1138[d]> You spotted my subtext 😉
19:03:37 <xarick> the save with 74k trains
19:05:55 <andythenorth> ok so if return `reverse_build_probability: 0` for the pacer thing, it should not be reversed when train 2 is autoreplaced?
19:06:59 <andythenorth> not sure I'm testing right 🙂
19:07:10 <andythenorth> think my build is ok
19:12:56 <peter1138[d]> Nah, if the original is flipped it still tries to flip it. Hmm.
19:21:54 <peter1138[d]> Oh, I need to do the same test for cloning too.
19:24:15 <peter1138[d]> Eh, that's dumb, when cloning the type is the same 😮
19:30:09 <xarick> my english not so good
19:35:33 <xarick> they're all freewagons but k
19:41:40 <andythenorth> peter1138[d]: now appears to work with autoreplace
19:42:09 <andythenorth> if I've anticipated what nml is doing, I've tested with unhandled callback, and explicit result of `o`
19:43:02 <xarick> perhaps i dont need a vector
19:43:37 <xarick> I only need the lowest index
19:44:58 <_glx_> hmm to me #14282 doesn't need a vector, a `Train *` should be enough, init with `nullptr` and updated to lowest index if any
19:46:11 <peter1138[d]> The first thing we looked at needed the vector because if it fails on the first one, it continue to the next.
19:56:25 *** arikover has quit IRC (Quit: ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.1))
20:22:00 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:23:36 *** kuka_lie has quit IRC (Quit: Lost terminal)
20:25:26 <xarick> how do i reach this function
20:28:45 <xarick> ah, must be a human player
20:41:10 <peter1138[d]> Why do you say that?
20:42:28 <peter1138[d]> Yup, and the other reason?
20:43:32 <peter1138[d]> The other reason.
20:46:18 <xarick> without doing anything
20:46:35 <peter1138[d]> That sounds like the same as the first reason, so not the other reason.
20:57:51 <xarick> some Aircraft::Iterate when removing stations
21:01:17 <xarick> Ship::Iterate when removing docks
21:03:20 <xarick> they don't use v->tile
21:32:35 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:33:48 *** Rubidium has joined #openttd
21:40:17 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:40:49 *** Rubidium_ has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
