IRC logs for #openttd on OFTC at 2026-02-24
⏴ go to previous day
00:10:06 <_glx_> xarick: it used to work, but now Convert makes sure the class is correct
00:13:52 <_glx_> because it was possible to Convert between incompatible events
00:29:14 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
00:29:59 *** MinchinWeb[m] has joined #openttd
00:36:26 *** andythenorth has quit IRC (Quit: Connection closed for inactivity)
00:46:39 *** keikoz1 has joined #openttd
00:51:26 *** keikoz has quit IRC (Ping timeout: 480 seconds)
00:53:31 *** keoz has quit IRC (Ping timeout: 480 seconds)
01:42:01 *** lobster has quit IRC (Ping timeout: 480 seconds)
01:55:21 *** lobster has joined #openttd
02:04:19 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
02:05:00 *** MinchinWeb[m] has joined #openttd
02:19:27 *** MinchinWeb[m] has quit IRC (Remote host closed the connection)
02:20:25 *** MinchinWeb[m] has joined #openttd
02:51:58 *** Flygon has quit IRC (Read error: Connection reset by peer)
03:01:41 *** Wormnest has quit IRC (Quit: Leaving)
04:11:30 *** Zathras_4 has joined #openttd
04:11:33 *** Zathras_7 has joined #openttd
04:14:56 *** Zathras_1 has quit IRC (Ping timeout: 480 seconds)
04:15:11 *** Zathras_11 has quit IRC (Ping timeout: 480 seconds)
04:44:03 *** baricus has joined #openttd
04:44:03 <baricus> A long time ago I brought up adding a "screensaver mode" to openttd and I finally have time and something mostly working enough to try to polish up for a pull request, but I wanted to ask:
04:44:03 <baricus> - Is it preferred to put "new functionality" like this into it's own file or should I include it in some other location. Currently it's all in a `screensaver.cpp` file
04:44:03 <baricus> - Is there a better way to schedule somethign to run every game tick than the timer systems? I didn't see anything obvious but I'm not super familiar with the code. Using timers for that feels icky though. I currently use it to smooth-scroll to new vehicles rather than immediately swapping the followed one. Maybe there's also a better way to do that?
05:07:49 <mmtunligit> New file is almost certainly correct for something like this
05:08:23 <DorpsGek> - Update: Translations from eints (by translators)
05:08:58 <mmtunligit> And im not the last word on this but smooth scrolling to new vehicles should probably be a separate PR entirely
05:10:24 <baricus> That's a good point. I originally just did this for personal use so I wasn't thinking about how to handle thing sfor merging. I'll look at what it would be like without the problematic timers, though I still hope there's a nice way to do it
05:10:38 <baricus> I can't remember how bad it was with direct jumping between vehicles
05:34:03 *** andythenorth has joined #openttd
06:45:32 <andythenorth> “InvisiGronk” for Horse then
07:16:31 *** ChanServ sets mode: +v tokai
07:34:44 <LordAro> baricus: there's some stuff around the sign controls for title games. can't remember precisely where that is, but i think it covers scrolling to new vehicles?
08:01:15 <peter1138> Viewports already have smooth scrolling, so it should just be a case of picking the target.
08:26:33 <peter1138> (Smooth scrolling for vehicle following is okay until you fast forward...)
08:50:31 <mmtunligit> id imagine that wouldnt be a problem for a screen saver
09:15:28 <andythenorth> wonder how much HP to give it
10:17:41 *** peter1138 has quit IRC (Ping timeout: 480 seconds)
10:20:56 *** peter1138 has joined #openttd
10:20:56 *** ChanServ sets mode: +o peter1138
11:24:53 <xarick> Trans not that great with airports
12:09:48 <xarick> refresh at the same rate of your fps
12:18:03 <__abigail> I imagine there would be significant performance impacts for very little gain
12:22:42 <xarick> tried a big map with zoom out, not that great of a result
12:28:49 <xarick> ewww it's bad on a 4k map
12:29:24 <xarick> or 240 Hz, one of those
13:44:53 <_glx_> yup, returning reference is dangerrous
13:45:38 *** Wormnest has joined #openttd
13:49:13 <xarick> there's a "Refresh rate over 60 might affect performance"
13:50:02 <xarick> not an excuse to ruin performance in a PR, I know
13:50:03 <_glx_> game target is 30 anyway
13:51:05 <_glx_> so simulation 30 and graphics 60 is already a lot
13:55:17 <_glx_> right, 30ms/frame -> 33frame/s and 27ms/frame -> 37
14:07:51 <LordAro> oh that's the drama i missed last week
14:10:18 <peter1138> Oh ignore the thread, soryr.
14:11:11 <peter1138> Damn, please don't bill me :p
14:19:43 <LordAro> one wonders if the menu would be hated so much if there wasn't a toyland background
14:26:48 <xarick> omg andythenorth take on that topic is quite vile
14:27:14 <LordAro> we don't need your take on this
15:21:48 *** praime3172 has joined #openttd
15:21:48 <praime3172> I am a French student, and a classmate and I have a project for university. We have to write a scientific article on the subject: “A Comparative Analysis of Simulated Annealing, Tabu Search, and Genetic Algorithms for Train Routing Optimization in OpenTTD.”
15:21:48 <praime3172> We would like some advice on a certain point.
15:21:48 <praime3172> We have reached the point where we need to “test” certain algorithms such as Tabu search and genetic algorithms.
15:21:48 <praime3172> Would it be possible to carry out smaller-scale tests using the same game? We are a little unsure about what we need to modify/add in order to carry out tests to compare the results between these algorithms. Any advice? Thank you in advance!
15:30:43 <Rubidium> I guess the easiest way would be to prepare a savegame, and then run the different algorithms on that savegame in subsequent runs. Though I've got no clue how you'd be able to reliably rate the different runs, as minor changes in the routing will yield a different game state and then the effect of all the Random calls might be the thing you're measuring
15:33:56 <Rubidium> alternatively you could run your 3 algorithms and the current pathfinder for every 'YapfTrainChooseTrack' call and log the differences between them. Although comparing those differences might be very hard as you don't have clue what the end result is going to be, as you likely won't have the complete game state to check.
15:37:48 *** Smedles has joined #openttd
15:43:52 *** andythenorth has quit IRC (Quit: Connection closed for inactivity)
15:58:50 *** ahyangyi has joined #openttd
15:58:50 <ahyangyi> praime3172: Is it route design or pathfinding?
16:00:31 <ahyangyi> If the former, you might want to run the existing AIs and I especially recommend AAAHogEx; If the latter, what Rubidium said.
16:32:31 <praime3172> Is it for pathfinding, our job is to compare the 3 algorithms i said
16:33:01 <praime3172> but its quite hard for us to figure where we have to work because the application is big
16:42:14 <Rubidium> if you're talking about pathfinding in the context as in "there are already rails, the train reaches a junction: which way should the train go", then in src/pathfinder (specifically a function called YapfTrainChooseTrack). If it is pathfinding like "I have two industries that I want to connect by rail", then OpenTTD doesn't have that functionality in itself and you need to look at AIs.
16:46:01 *** Flygon has quit IRC (Read error: Connection reset by peer)
16:48:10 *** andythenorth has joined #openttd
16:49:37 <andythenorth> @xarick please don't give your take on that topic - but you're here, you try and contribute, sometimes it goes well, sometimes it doesn't, but you don't ever complain about how awful it all is, and I haven't seen you ever say anything rude or insulting about the people in the project
16:49:53 <andythenorth> it can't be as bad as they say, surely?
16:51:58 <_jgr_> Most likely 99+% of the userbase are playing quite happily and neither know nor care about the stuff in that thread
16:52:08 <_jgr_> I wouldn't worry that much about it
16:53:46 <andythenorth> I was somewhat looking for moral high ground fights last week
16:53:51 <andythenorth> wasn't a good idea
16:54:05 <praime3172> Rubidium: Yes, I understand. I think I should use algorithms rather than AI. But first, since this is pure research, I need to establish an approach to the problem and translate the general “vrp” problem into the tdd game, i.e., decide which hyperparameters to use, etc.
17:01:04 <xarick> I'm experimenting with an idea; towns have a local authority zone. I thought of forbidding a town to expand towards a neighbours town local authority
17:02:06 <andythenorth> would actually help routing trains a lot
17:02:14 <andythenorth> towns often merge
17:02:26 <andythenorth> merging is realistic though
17:06:06 <Rubidium> praime3172: I'm not talking about AI here in the sense of Claude/ChatGPT/..., but about the single player computer competitors as AI. Those are using algorithms to find the 'best' way to place the railroad tracks between two industries. In that context, take a look at, for example, AAAHogEx to see how it is placing its track. Then it's up to you to replace the algorithm that decides which tracks to build
17:52:58 <xarick> A new AI would be nice
18:10:52 <_glx_> happens when owner decides to stop maintaining
18:25:06 <xarick> pull requests probably not accepted...
18:55:19 <peter1138> Or it's possibly been moved to another system, away from github.
18:55:48 <LordAro> something other than github? impossible
19:28:07 <rito12_51026> xarick: Looks a bit like someone has curved out a rhombus centered on neighbouring towns from the middle one
19:28:11 <rito12_51026> Have you tried decreasing probability instead of banning?
19:36:22 <xarick> oh, probability sounds like a nice idea
20:05:29 <xarick> I mean, it works, but they eventually merge :(
20:11:03 <xarick> actually, it's pretty good
20:12:37 <rito12_51026> You could make the decreasement dependent on distance to the center of the other town, although that still wouldn't make them not merge
20:16:06 <rito12_51026> rito12_51026: Ah, you do that already
20:16:08 <xarick> commits were generated by AI
20:16:16 <xarick> cus im just too dumb for that
20:16:23 *** reverend has joined #openttd
20:16:23 <reverend> xarick: I dig the tree ring. looks like a lil suburban metro should swing through there
20:17:02 *** reverend is now known as Guest3640
20:17:03 *** Guest3640 is now known as reverend[d]
20:19:14 <andythenorth> hmm should I also do narrow gauge invisigronks
20:31:25 <rito12_51026> xarick: They feel a bit too long for such small commits, and if you wrote them yourself you could make a PR
20:40:03 <xarick> TownGrowthResult::SearchStopped vs TownGrowthResult::Continue, what's the difference
20:44:30 <xarick> SearchStopped does a better job
20:45:11 <_glx_> there should be some comments around the enum
20:52:50 <andythenorth> instead of silly invisible leading engine, or powered wagons....trains didn't have to have an engine leading the train?
20:53:56 <talltyler> Yes, that would be much better. But it will take some work.
21:00:42 <andythenorth> talltyler: michi has a long branch somewhere :)
22:04:19 *** Wolf01 is now known as Guest3651
22:08:28 <xarick> oh, commit checker detected AI slop
22:10:16 *** Guest3651 has quit IRC (Ping timeout: 480 seconds)
22:45:44 <xarick> AIAI isn't accepting PR's I tried
22:46:05 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
continue to next day ⏵
