IRC logs for #openttd on OFTC at 2026-02-28
⏴ go to previous day
00:24:01 *** andythenorth has quit IRC (Quit: Connection closed for inactivity)
01:30:31 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
01:30:33 *** WormnestAndroid has joined #openttd
02:19:46 *** Tirili has quit IRC (Ping timeout: 480 seconds)
02:52:09 *** Wormnest has quit IRC (Quit: Leaving)
03:41:26 *** WormnestAndroid has quit IRC (Remote host closed the connection)
03:41:53 *** WormnestAndroid has joined #openttd
04:07:30 *** Zathras_11 has joined #openttd
04:07:58 *** Zathras_1 has joined #openttd
04:10:51 *** Zathras_7 has quit IRC (Ping timeout: 480 seconds)
04:11:16 *** Zathras_4 has quit IRC (Ping timeout: 480 seconds)
04:51:30 <DorpsGek> - Update: Translations from eints (by translators)
06:16:49 *** wallabra has joined #openttd
07:09:14 *** andythenorth has joined #openttd
08:01:38 *** SigHunter_ has quit IRC (Remote host closed the connection)
08:03:47 *** SigHunter has joined #openttd
08:31:38 *** Zathras_1 has quit IRC (Quit: Connection reset by beer!)
08:32:10 *** Zathras_11 has quit IRC (Remote host closed the connection)
08:36:33 *** Zathras_7 has joined #openttd
09:22:57 *** Flygon has quit IRC (Read error: Connection reset by peer)
09:44:32 <andythenorth> Horse is so slow to compile
09:49:29 <andythenorth> 4229 is more than 3919 eh
09:50:12 <andythenorth> would save 1.5s maybe
09:53:16 <xarick> is the compiler multithreaded?
09:53:38 <xarick> ~100% cpu usage during compiling?
09:54:15 <rito12_51026> xarick: For cpp should be
09:54:31 <xarick> no, for horse, i guess generating newgrf?
09:56:19 <andythenorth> nmlc is single-threaded
09:56:34 <andythenorth> the Horse compile uses more than nmlc and is multi-threaded
09:57:19 <rito12_51026> How python is not multithreaded, is it?
09:57:44 <goddess_ishtar> you have to use async and await iirc
09:58:14 <goddess_ishtar> probably someone decided it wasn't worth the hassle
09:58:20 <andythenorth> python is not multi-threaded but has libs for threads or pools
09:58:28 <andythenorth> the overhead is relatively high
10:02:26 <andythenorth> as a rough guide, spawning a thread pool to save 1 or 2 seconds doesn't pay off
10:02:39 <andythenorth> this is obvs highly dependent on compute environment
10:02:53 <andythenorth> but a thread pool to save 10s is usually a good investment
10:16:45 <LordAro> goddess_ishtar: async/await didn't exist when it was written ;)
10:17:02 <LordAro> (not that those are the only ways of doing concurrency in python)
10:17:41 <LordAro> (python can do concurrency, not parallelism)
10:17:48 <goddess_ishtar> I don't really deal with it often, so my memory is foggy
10:18:59 <rito12_51026> ah The multiprocessing module, would it be a lot work to use that in nmlc?
10:21:11 <LordAro> retrofitting multithreading is not historically an easy thing to do
10:21:15 <andythenorth> it would be very hard IMHO
10:21:37 <andythenorth> the AST would be unwieldy to share between pool workers
10:21:51 <LordAro> and the amount that andy complains about it, someone would've tried ;)
10:21:57 <andythenorth> the parse step could probably be async, on a sort of map-reduce basis
10:22:09 <andythenorth> but it might lose in overhead what it gains in parse speed
10:22:20 <LordAro> but yes, fundamentally most jobs do not lend themselves to to multithreading
10:22:45 <andythenorth> being able to shard grfs, but package them together would be the Horse solution :P
10:23:05 <LordAro> running many nmlc i s much easier
10:23:07 <andythenorth> or partial compiles of nml, similar to how a C++ compiler works
10:23:58 <goddess_ishtar> yeah algorithms why weren't written with multithreading in mind tend to be difficult to modify to add it later
10:25:14 <andythenorth> it's just compiler basics no?
10:25:26 <andythenorth> nmlc expects to parse a single input file, to a single AST
10:26:36 <andythenorth> it's not the writing grf part that is slow
10:27:04 <andythenorth> nmlc outputs 70MB of compiled Horse in 1 or 2 seconds
10:27:13 <rito12_51026> Does grf-py use multiprocessing?
10:27:25 <andythenorth> grf-py is a different approach
10:27:37 <andythenorth> because it's got no need to parse a clunky pseudo-code text format
10:28:16 <andythenorth> the AST, I'm guessing, is just the python structure
10:28:48 <andythenorth> so two specific proprietary steps are folded into one "it's just declared as a python object tree" step
10:29:05 <rito12_51026> We could use IronPython or something
10:29:37 <goddess_ishtar> transpile-to-nml is messy as hell but at least it's less labour-intensive to implement
10:30:49 <andythenorth> pypy3 significantly improves nmlc performance against python 3.13
10:38:03 <rito12_51026> IronPython uses JIT as like the pypy, but does not have GIL, that would help if nmlc uses concurrency
10:51:25 <xarick> FindSafeTile mismatch problem points towards this track/signal configuration
10:53:49 <xarick> btw, the yapf dump file writter keeps overwritting previous results with new ones
10:54:10 <xarick> couldn't this log all occurrences instead of refreshing it to the latest that occurred?
10:55:17 <andythenorth> The solution to slow nmlc is sometimes ‘make a smaller grf’
10:56:10 <andythenorth> I believe that parse and processing time increases non-linearly with number of items, particularly allocating varact2 ids
10:56:22 <andythenorth> I don’t have any charts though
10:57:48 <andythenorth> Removing a few thousand vehicles from Horse was the best recent improvement to compile time
11:00:40 *** kuhnovic has joined #openttd
11:00:40 <kuhnovic> I don't have time to look into this atm, sorry
11:01:03 <kuhnovic> Or figure out if it's a real issue or a Xarick-problem
11:01:34 <andythenorth> Maybe Horse should be split up?
11:06:55 <rito12_51026> dunno, that will piss of some people, but the save games that only need 1950-2020 would load faster
11:08:55 <andythenorth> Compiles faster though
11:09:15 <reldred> future horse future horse future horse
11:09:30 <reldred> i wont stop believing s/believing/dreaming/
11:10:17 <reldred> my fingers are covered in superglue residue again
11:10:54 <reldred> also kde's default pdf viewer has no business being this good
11:11:39 <andythenorth> hopefully M5 macbook pro next week, maybe fasteeer Horse with that
11:12:06 <andythenorth> Unannounced as yet
11:12:20 <reldred> i would like a nice shiny black macbook but, i wouldn't really have any actual use for it
11:12:28 <reldred> it wouldn't replace my desktop,
11:12:42 <reldred> and it's too big and bulky to carry when i already have a work laptop
11:18:36 <andythenorth> Just it to compile Horse
12:04:04 <rito12_51026> Yep, pypy runs 2 times faster than python and IronPython does not run at all
12:07:49 <ahyangyi> Isn't its newest version 3.4 beta or something
12:08:17 <ahyangyi> I doubt there are many python libraries left that can run with Python 3.4-
12:11:04 <rito12_51026> The main problem is that it only supports pure python libraries and pillow is written in c
13:21:51 <andythenorth> I've never read the parse :P
13:23:09 <andythenorth> I don't really know how to instrument, but instrumenting parser.py and charting the result might be interesting
13:23:49 <andythenorth> possibly it's never going to be fast in python, and would be better as a C++ lib or rust or something
13:24:29 <andythenorth> but there's a chance we could find it's just doing something needlessly slow with string splits or something
13:29:27 <xarick> I question why in one of the results it tries to reserve path and in the other it does not. The bool argument isn't even about cache...
13:32:18 <ahyangyi> Because if you reserve path and find path again you are going to find a different one?
13:32:55 <ahyangyi> So you have to not reserve path when calculating the first path
13:33:15 <ahyangyi> TBH I don't have any context though, just reading the code loudly
13:33:39 <xarick> I see the problem is about here
13:34:14 <xarick> result1, which runs through TryReservePath
13:34:36 <xarick> result2 doesn't even bother and just returns true no matter
13:35:03 <ahyangyi> (I do find it weird that `result2` comes from `pf1` and `result1` comes from `pf2` though ... )
13:35:43 <xarick> the results can't be compared if result1 returns false imo
13:36:41 <ahyangyi> Seems you want a "try to reserve path but don't actually do that" flag or something
13:36:48 <ahyangyi> for that comparison to work?
13:38:31 <xarick> the dump matches in this case
13:38:44 <xarick> exact segments, exact path, trackdirs, etc...
13:38:51 <xarick> it's the TryReservePath that differs
13:39:31 <xarick> or rather, one runs the TryReservePath which fails and the other accepts true due to "dont_reserve"
13:40:22 <xarick> must think of a solution
13:49:24 <_glx_> I think it's fine, might be some corner case where there's actually no reservable path
13:50:40 <xarick> green is the path found
13:50:46 <xarick> red is the tryresevepath
13:50:54 <xarick> fails when walking the path
13:51:17 <xarick> green also points to a tile which can be reserved, the target is not reserved
13:52:02 <xarick> in both cases, the path is the same
13:53:51 <xarick> the train at the top is actually lost, it wants to go to a station that is north of it, but he's currently heading south
13:57:01 <xarick> 2427 hits of FindSafeTile mismatch on that replay
13:57:10 <xarick> i only investigated the first
13:57:23 <xarick> is it safe to assume the others would be the same?
13:59:26 <_glx_> Lost train could be the cause yes
14:05:46 *** Wormnest has joined #openttd
14:16:54 *** Zathras_4 has joined #openttd
14:21:00 *** Mr_rough_ has joined #openttd
14:32:12 <xarick> yeah, it seems it always involve trains going into the wrong tracks
14:32:48 <xarick> trains want to go to the station at the top, but they're in the south path
14:35:16 <xarick> oh, waypoint at the top
14:58:22 *** Zathras_4 has quit IRC (Quit: Connection reset by beer!)
16:02:29 <rito12_51026> Why trams are not accessible when the toolbar is splitted?
16:04:45 <_glx_> my guess is the toolbar splitting was forgotten
16:06:07 <rito12_51026> could it be removed?
16:07:51 <xarick> deleting code fixes the issue, I love it
16:08:08 <xarick> oh, no, i got a crash, didn't fix it
16:11:31 <xarick> actually, i caused a desync
16:12:44 <xarick> the path can't be reserved twice?
16:13:11 <_glx_> why would you reserve a path twice ?
16:13:28 <xarick> one testing for cache, the other testing without cache
16:19:51 <rito12_51026> There are also 3 more buttons that are hidden in splited toolbar. The two for GS (storybook and goal) and also the company league menu whose content is moved to graph menu
16:21:27 <_glx_> depending on numbers of buttons per row
16:23:26 <rito12_51026> The league is only in all and the GS ones in 20 too but when window gets smaller they are gone
16:24:01 <_jgr_> I didn't even know this feature existed, do people actually play with windows narrow enough that the toolbar doesn't fit?
16:31:01 <rito12_51026> If you rotate your screen horizontally and set interface size high then maybe, and then new main menu suits perfectly
16:36:59 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
17:16:20 <peter1138> And hope your monitor has a good pixel arrangement for vertical viewing.
17:54:58 <andythenorth> isn't 'no platform signals' correct?
17:55:10 <andythenorth> I've been told I'm doing it wrong a few times, by including signals
17:55:56 <talltyler> No platform signals works only when it’s a terminus station.
17:56:30 <andythenorth> but isn't through station case solved by disabling 90 degree curves?
17:58:30 <talltyler> No, the problem is that a signal reservation can only end at a signal or the end of the track.
17:58:45 <talltyler> No signals means it keeps reserving until it find the signal, blocking other trains.
18:08:35 <peter1138> "problem" -> "design"
18:17:48 <talltyler> I don’t mean it’s a problem, it is correct. I mean the issue players are experiencing when they do it wrong.
18:29:06 <xarick> I tried something... caused replay desync
18:30:51 <xarick> but FindSafeTile mismatch stopped triggering
18:58:45 <xarick> FreePathReservation isn't too smart
18:59:02 <xarick> FreeTrainTrackReservation i mean
20:16:08 <rito12_51026> andythenorth, when will be next horse release?
20:26:10 <xarick> only he can solve this
21:42:05 *** SigHunter has quit IRC (Remote host closed the connection)
21:44:06 *** SigHunter has joined #openttd
21:49:44 *** Flygon has quit IRC (Read error: Connection reset by peer)
22:18:36 *** Tirili has quit IRC (Ping timeout: 480 seconds)
22:19:07 <xarick> how do I decipher what these commands do?
22:20:29 <xarick> wanted to extract which compay is doing it
22:23:36 <xarick> okay, the 3rd is company
22:57:51 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:43:01 <xarick> that looks very AI driven
23:59:47 <xarick> Any other ideas to fix this?
continue to next day ⏵
