IRC logs for #openttd on OFTC at 2024-10-28
⏴ go to previous day
00:32:47 *** Tirili has quit IRC (Remote host closed the connection)
00:54:53 *** Tirili has quit IRC (Quit: Leaving)
03:39:50 *** Zathras has joined #openttd
03:43:13 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
03:43:28 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:01:40 *** gnu_jj_ has joined #openttd
04:05:14 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:47:46 <DorpsGek> - Update: Translations from eints (by translators)
07:02:56 *** nielsm has quit IRC (Ping timeout: 480 seconds)
07:16:05 <DorpsGek> - Add: summary for week 43 of 2024 (by OpenTTD Survey)
07:41:44 <Artea> is "never_expire_vehicles = false" refered to 'engines' ?
07:43:00 <Artea> I setup my server in my vps and started at 1969 and just went check was 2038 and engine for normal trains wasn't there, just the wagons...
08:27:50 <kuhnovic> Resolved that using the web interface on a phone, fingers crossed that it actually works 😆
08:28:10 <peter1138> Nope. it did a merge.
08:28:54 <kuhnovic> I don't have access to a computer for a few days, i'll fix it when i get back
08:39:52 <Artea> OpenTTD doesn't like OBS Studio ?
08:41:45 <Artea> when I opened with OBS running, turn all red and scratched image as this laptop lcd, all messy and distorced
09:10:09 <peter1138> No problem with it here.
09:11:53 <Artea> strange, notice just now a shadow below trains
09:12:29 <Artea> I did preview update a few days ago and nvidia update
09:13:55 <Artea> well, this Windows is screw for a very long time so is no wonder does this glitches
09:17:51 <Artea> I think I can recreate the bug
09:26:17 *** herms61 is now known as herms
09:27:31 <LordAro> sounds like your graphics card/driver is dying
09:29:04 <Artea> but only happened when I added OTTD as Game Capture
09:29:05 *** argoneus7 has joined #openttd
09:29:17 *** argoneus7 has joined #openttd
09:30:45 <Artea> kept even after delete Display Capture and Game Capture
09:31:04 <Artea> only when I shutdown OBS, OTTD was normal
09:31:12 <Artea> I guess is something related to HDMI
09:34:12 <Artea> anyway, gonna enjoy Sunny day
09:34:18 <Artea> have a good rest of morning
09:57:31 <xarick> t = TileIndex(tile); maybe?
09:58:11 <xarick> it still says +2 overloads
10:17:29 <peter1138> If I was a DBA, would I be able to understand Postgres' EXPLAIN ANALYSE?
10:23:45 <xarick> today I wake up with a weird idea to "improve performance"
10:24:14 <xarick> save trackdirbits into map array
10:30:22 <LordAro> map array is not infinite
10:30:46 <LordAro> nor is saving something to it a magical "makes everything faster"
10:44:57 <truebrain> LordAro: I am missing your "change for the sake of changing" argument 😄
10:51:46 <LordAro> truebrain: this is true
10:51:57 <peter1138> TrackdirBits or TrackBits?
10:52:15 <peter1138> Because they generally are stored on tiles, except water, because most water tiles are all TrackBits.
11:05:30 <truebrain> Always nice when people self answer their questions 🙂
11:06:50 <truebrain> ( talking about the comment on the issue, to be clear 😛 )
11:12:31 <peter1138> Looking at the linked issue though.
11:13:31 <peter1138> I assume that me asking what we should do with a file that was just dumped on us without anything else is considered "unfriendly attitude"?
11:44:24 <ketsuban[d]> I think the "unfriendly attitude" comment was directed at Alberth.
11:45:11 *** yeah_its_gloria has joined #openttd
11:45:11 <yeah_its_gloria> inventing such an awesome software center that can't deal with the inevitable situation of unmatching IDs
11:47:57 <peter1138> xarick: If you're talking about water tiles, then feel free to try it and performance test it. Main concern is making sure the correct bits are set during various map changes. There's enough space at least.
11:52:41 <peter1138> It would avoid all the checks for slope.
11:53:31 <ketsuban[d]> yeah_its_gloria: From what I can tell the point of the metainfo file being part of the upstream repository is so that they're the canonical source of truth (e.g. updating the screenshots provided as the software improves). Since OpenTTD itself doesn't provide any information itself, each packager has provided their own data and they don't match up.
11:56:46 <ketsuban[d]> > Some benefits of sending the file upstream are that upstream can translate the file using the existing translation resources and can also modify the screenshots and descriptions as the application changes over time.
11:58:04 <peter1138> Another advantage is it moves the maintenance burden to upstream who have no use for the file.
11:58:42 <xarick> I nearly made a self recursive function 😮
11:59:02 <peter1138> Is there any other form of recursion?
11:59:40 <peter1138> I made some recursive SQL views. They're always "good" for performance.
12:04:17 <ketsuban[d]> peter1138: I can't exactly blame them. Who's better equipped to tell you why software X is cool and you should use it: the people who make software X, or someone who has barely any knowledge of what software X is but picked up the job of packaging it?
12:08:13 <merni> peter1138: You could argue the same about maintaining MS Store, Steam etc pages? It's just another distribution channel
12:12:17 <peter1138> Urgh, why does my shell history never contain that magic command to fetch a PR from git.
12:19:17 <yeah_its_gloria> ketsuban[d]: those software centers could've easily added a database that finds similar entries across different sources and merges them while letting you pick where to get it
12:19:57 <yeah_its_gloria> those packages aren't even maintained by anyone official (to my knowledge) so personally the metadata problem is like the smallest concern I think
12:20:06 <xarick> I suspect there was a no gain in performance...
12:20:41 <yeah_its_gloria> ketsuban[d]: was anyone forced to package openttd..?
12:21:04 <ketsuban[d]> Unless you expect end users to compile it from source, yes.
12:21:32 <yeah_its_gloria> there's prebuilt tarballs
12:21:51 <yeah_its_gloria> I don't think you need to pick between "poorly built packaging infrastructure" and "source code only"
12:22:52 <yeah_its_gloria> what stopped those random package maintainers from just cross checking with each other anyway
12:25:45 <yeah_its_gloria> the snap repo had its last update 3 years ago
12:26:04 <xarick> unpalpable gains, if any... 😦 I'm sad
12:27:55 <yeah_its_gloria> I think the snap package should find a suitable maintainer before people brabble about unmatching IDs
12:30:01 <LordAro> merni: the difference is that we control those, as opposed to everything else which we don't
12:33:57 <peter1138> xarick: Going with the caching route, you're missing a lot of invalidation when neighbouring tiles are changed.
12:34:28 <peter1138> Or maybe they always reset the water tile.
12:41:28 <yeah_its_gloria> apparently snapcraft themselves aren't too happy about appstream??
12:42:26 <yeah_its_gloria> this is from 2017 but I can't for the life of me find out how even appstream junk is supposed to work
12:42:34 <yeah_its_gloria> I guess it's too awesome for me
12:44:00 <peter1138> Snaps are just a bad idea, IIRC.
12:44:57 <yeah_its_gloria> ok so they need a `common-id: org.openttd.OpenTTD` thing in the `apps` section in the snapcraft file
12:45:04 <yeah_its_gloria> which would give it parity with flatpak
12:47:38 <peter1138> Snap was basically Canonical trying to have a proprietory app store, or something.
12:48:17 <yeah_its_gloria> common-id: org.openttd.OpenTTD
12:48:38 <yeah_its_gloria> will they still think we're unfriendly if we send them this
12:49:12 <yeah_its_gloria> peter1138: snap made me leave ubuntu behind tbh
12:49:22 <yeah_its_gloria> it's such a nightmare to have apt and snap
12:52:30 <yeah_its_gloria> who even manages the debian package
13:15:43 <xarick> hmm invalidating tiles missing 😦
13:18:10 <peter1138> At least, if a coast tile is changed, the trackbits on the water tile next to it need to update. Probably other instances.
13:33:08 <xarick> water regions are invalidating them :p
13:33:17 <xarick> not what i expected but ok
13:36:13 <xarick> misc_gui.cpp:134 is very intrusive
13:38:32 <peter1138> I don't see how water regions can invalidate them.
13:38:53 <xarick> the Force Update has a TrackFollower which checks for tracks
13:39:35 <peter1138> Yeah, that's updating the cached trackbits. That isn't invalidation.
13:44:04 <xarick> some kind of magic happening, something is invalidating them properly, must investigate
13:46:54 <xarick> water_cmd.cpp:172 very convenient 🙂
13:49:08 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
13:49:49 <peter1138> That is not invalidating them.
13:50:01 <peter1138> That is setting the state if it's not already set.
13:50:14 <peter1138> Invalidating is clearing the flag that sets the state is set.
13:56:30 <xarick> locks need invalidating on build
13:59:47 <xarick> I just feel like doing a zero'ed m8()
14:06:37 <xarick> flags unset on MakeWater stuff
14:15:21 <xarick> water regions doing something weird with the corners of a region
14:16:59 <xarick> it's getting the tracks of the adjacent tiles of the edges
14:19:09 <peter1138> You could add TrackBit visual debug too.
14:19:54 <peter1138> That would let you see that the TrackBits that are set are correct.
14:36:31 <_glx_> hacking DrawTile_Water() for visual debug maybe
14:37:34 <peter1138> Yeah, DrawTile_Water would be the place I suppose.
16:36:11 <xarick> so far only locks needed invalidation
17:08:58 *** HerzogDeXtEr has joined #openttd
17:24:28 <xarick> is magic bulldozer a per company setting?
17:24:52 <xarick> will AIs be affected if I enable magic bulldozer
17:49:22 <xarick> * Checks whether the tile is marked as a *dockling *tile.
18:12:34 <xarick> how to test whether this had any effect in performance?
18:18:09 <xarick> i'm gonna be very disappointed
18:22:52 <peter1138> The problem with the caching approach is its less deterministic when it comes to performance testing.
18:27:48 <xarick> woah, i need a much bigger number than 10000 samples
18:39:53 <xarick> no gains... it's actually worse !
18:41:11 *** gelignite has joined #openttd
18:43:25 <xarick> gonna give it a year, to see which openttd advanced faster
18:57:30 <peter1138> You are benchmarking something that is too short.
18:57:47 <peter1138> You should look at overall performance
18:57:56 *** Artea has quit IRC (Remote host closed the connection)
18:57:56 <peter1138> Instead of each individual call.
19:24:26 <andythenorth> Performance benchmarking is generally statistical, comparing representative workloads across revisions and charting key metrics
19:24:51 <andythenorth> Generally repeating runs, to isolate hardware or OS variations
19:25:34 <andythenorth> You generally need to measure multiple indices, such as CPU, RAM, IO, cache churn etc depending on context
19:26:02 <andythenorth> Even a clear benefit in one dimension can have unexpected side effects
19:27:58 <xarick> a year passed... it's 5 days late
19:55:36 <xarick> oh crap, how do i undo a merge commit
20:00:05 <peter1138> Damn, the Warden got m.e
20:07:41 <xarick> LC_Zorg is full of ideas!
20:22:19 <xarick> how do i extract the seed?
20:22:27 <xarick> i wanna try again with same seed
20:23:23 <xarick> generation_seed = 189562935
20:29:37 <xarick> I can't reliably reproduce this cras
20:37:41 <xarick> can only reproduce in a debug build
20:37:46 <xarick> and still... unreliably
20:47:08 <peter1138> Oh, that was meant to just clear the "request changes" state.
21:13:36 *** gelignite has quit IRC (Quit: Stay safe!)
21:20:48 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:30:37 <xarick> float and double are being used
21:41:55 <_glx_> float and double are fine in map generation
21:51:53 *** tokai|noir has joined #openttd
21:51:53 *** ChanServ sets mode: +v tokai|noir
21:54:48 <xarick> i need to learn perlin to understand what's happening
21:55:58 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:56:39 <xarick> apparently it asserted
21:58:48 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:07:33 <peter1138> I have a branch that uses normal perlin
22:07:43 <peter1138> Bit slower but more flexible.
22:09:27 *** Wormnest has joined #openttd
22:12:16 <xarick> i wonder about a static const
22:14:19 <xarick> let me try remove the static
22:15:08 *** ialokin has quit IRC (Ping timeout: 480 seconds)
22:15:19 <peter1138> Actually there might be. Those curve_map should be static too.
22:16:19 <xarick> why static? if it's not cleared
22:16:42 <dwfreed> so the initial value is not calculated every function call
22:16:54 <dwfreed> it does not change, it only needs to be calculated once
22:17:01 <peter1138> Oh, it depends on mh, so.
22:17:16 <peter1138> Xarick might be on to something.
22:17:17 <xarick> it changes based on mh
22:17:33 <dwfreed> ah, yes, then it indeed should not be static
22:17:39 <_glx_> oh indeed static could be wrong
22:18:22 <peter1138> Means it only works properly on first go. Wow.
22:19:06 <dwfreed> surprised there's not a compiler warning for that
22:19:20 <dwfreed> static variable depends on non-static variable
22:19:53 <xarick> just tested, no longer asserts
22:21:20 <xarick> well, i'm off to bed, take care
22:22:39 *** ialokin has joined #openttd
22:22:52 <_glx_> assert was luck here, has curve_maps[] contains valid data only for first run
22:22:56 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:24:14 <peter1138> I've never had an assert here, and I've done a lot of map gen 🙂
22:53:44 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:30:25 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
continue to next day ⏵
