IRC logs for #openttd on OFTC at 2022-05-09
⏴ go to previous day
00:12:38 *** Soni has quit IRC (Ping timeout: 480 seconds)
01:12:47 *** efess has quit IRC (Ping timeout: 480 seconds)
01:35:24 *** ChanServ sets mode: +v tokai
01:42:14 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
02:12:27 *** snail_UES_ has joined #openttd
02:59:06 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:08:54 *** Wormnest has quit IRC (Quit: Leaving)
03:26:40 *** snail_UES_ has quit IRC (Quit: snail_UES_)
05:06:32 <TrueBrain> seems someone is taking the piss
05:31:35 <TrueBrain> blocked the user, banned his IP .. and no, this is not "by accident", as every upload as a new md5sum ;)
05:39:26 <TrueBrain> if we merge that, the spam from the in-game browser disappears :)
05:41:47 <TrueBrain> no clue what the user's intention was here .. to have 1 NewGRF to control a single cargo?
05:46:40 *** andythenorth has joined #openttd
06:07:19 *** andythenorth has quit IRC (Quit: andythenorth)
06:09:11 <LordAro> (phone not logged in)
06:10:09 *** D-HUND is now known as debdog
06:15:08 *** Westie has quit IRC (Ping timeout: 480 seconds)
06:16:27 *** andythenorth has joined #openttd
06:22:28 *** andythenorth has quit IRC (Quit: andythenorth)
06:23:47 *** sla_ro|master has joined #openttd
06:30:54 *** andythenorth has joined #openttd
06:38:49 *** andythenorth has quit IRC (Quit: andythenorth)
06:49:42 <TrueBrain> Turns out to be legitimate.. found the user .. lol
06:49:48 <TrueBrain> Not in a million years
06:50:01 <TrueBrain> Will deal with it tonight
06:50:13 *** andythenorth has joined #openttd
07:32:00 <peter1138> 6 months since I logged in to the forum...
07:32:25 <peter1138> Ooh, TTD in Unity :D
07:52:25 *** andythenorth has quit IRC (Quit: andythenorth)
07:54:10 *** andythenorth has joined #openttd
08:20:58 *** sla_ro|master has quit IRC ()
11:01:50 *** sla_ro|master has joined #openttd
11:21:39 <FLHerne> TrueBrain: the only non-malicious explanation I can think of is that they were being clever and invented a buildsystem that automatically uploads versioned releases when tagged or so?
11:21:44 <FLHerne> and that it was buggy
11:37:15 <FLHerne> I once had an automated mailing system run away on me and spam customers, so can sympathise with that :-/
11:54:03 <nielsm> wow I just discovered that you can in fact _move_ breakpoints in visual studio, just by dragging them from one line to another
11:54:10 <nielsm> and keep the conditions etc set on it
11:56:42 <nielsm> https://0x0.st/omAx.png but, this ship is about to move into the marked tile. for some reason it chooses the left track instead of the X track, and then when it reaches the end of the left track it tries to enter the next tile, which is a land tile, and that of course makes assertions fail
11:56:59 <nielsm> so why is it taking the left track, and why does it crash into land instead of turning
12:01:42 <nielsm> left track is just what YAPF chooses okay
12:13:55 <nielsm> oh, I think I figured out what's going wrong
12:18:29 <nielsm> yep it no longer crashes
12:34:21 *** Etua has quit IRC (Quit: Etua)
12:39:51 *** andythenorth has quit IRC (Quit: andythenorth)
12:49:19 *** andythenorth has joined #openttd
12:49:52 <nielsm> this is so much easier than it should be allowed to be
12:54:32 <LordAro> assuming the compiler actually implements something for it, iirc it doesn't have to
12:55:23 <nielsm> that's 2818 ships, running it in serial gives me about 160 ms ship ticks in debug build, switching it to parallel lowers it to 80 ms
12:55:46 *** andythenorth has quit IRC (Quit: andythenorth)
12:56:33 *** andythenorth has joined #openttd
12:56:40 <glx> luckily ships are stackable ;)
12:56:55 <nielsm> yeah that's why I started with ships, they don't conflict
12:57:03 <nielsm> there's still some bugs
12:57:06 <nielsm> and changes in behaviour
13:02:57 <nielsm> also saves some time if I remove all the debug prints...
13:23:09 <glx> oh with threading it could be possible to increase yapf node limit for ships
13:26:20 <nielsm> zzzzz waiting for vehicles to reach a specific tile to be sure the bug is fixed
13:27:07 <glx> save before it reaches it for next try :)
13:31:08 <nielsm> what was the compile flag for making unchecked release builds...
13:40:21 *** virtualrandomnumber has joined #openttd
13:40:57 <LordAro> that'll turn asserts off, but the build itself will still be debug mode, no?
13:41:07 *** virtualrandomnumber has quit IRC (Remote host closed the connection)
13:41:24 <glx> yes but that wasn't the question ;)
13:41:53 <nielsm> yes of course combine both a release build and a non-assert build
13:54:09 <nielsm> actually in 12.2 the ship ticks time is like 40% less than in my current builds, but the total game loop time is much faster...
14:11:46 *** WormnestAndroid has quit IRC (Remote host closed the connection)
14:36:32 <nielsm> okay this is really, really weird. the degree of parallelization appears to be decreasing over time, the longer the game runs
14:37:55 <nielsm> starts with total CPU usage of about 30%, then after a few minutes it has dropped to 15%
14:37:59 *** andythenorth has quit IRC (Quit: andythenorth)
14:39:38 <glx> could not be pf cache effect ?
14:40:01 <nielsm> I'm not sure how that should affect ut
14:53:26 <FLHerne> well, cache accesses must serialize?
14:53:57 <FLHerne> against updates, anyway
14:54:16 <nielsm> each vehicle has its own path cache, so updating it does not content with other vehicles
14:55:38 <nielsm> also actions on the cache are only updated on the actual vehicle during the serial "execute" stage, the parallel "plan" stage only reads from the path cache and generates a replacement value along with a flag for "replace the path cache with this"
15:00:20 <Rubidium> might it be a decrease in cache locality, causing the CPU to wait a lot on data?
15:01:44 <nielsm> I wouldn't expect that to take effect gradually
15:02:07 <nielsm> when I look at the CPU usage graphs I can actually see it gradually using less and less of the other cores
15:03:56 <Rubidium> I kinda would, though the performance needs to plateau at some point for it
15:05:45 <Rubidium> the first cycle all ship path caches will be allocated, so it's fairly close in memory. The longer the game runs, the more ships have reached their first destination, and thus need to rebuild something. So slowly new allocations are made which are more spread around in memory. And then it would basically plateau at some point when things are basically at random locations
15:26:55 *** andythenorth has joined #openttd
15:39:50 *** WormnestAndroid has joined #openttd
15:58:44 *** Etua has quit IRC (Ping timeout: 480 seconds)
16:38:15 *** virtualrandomnumber has joined #openttd
16:41:49 *** virtualrandomnumber has quit IRC ()
16:42:03 *** HerzogDeXtEr has joined #openttd
16:50:45 *** andythenorth has quit IRC (Quit: andythenorth)
16:51:49 *** andythenorth has joined #openttd
16:54:38 *** gelignite has joined #openttd
17:01:41 *** gelignite has quit IRC (Quit: Stay safe!)
17:07:57 *** sla_ro|master has quit IRC ()
17:24:13 <nielsm> not using iterators fixed that
17:30:52 <TrueBrain> And 9882 derailment continues :D
17:32:21 <nielsm> finally got my homebrew thread pool working (big part of it was fighting C++ ...)
17:32:35 <nielsm> this doesn't seem to have the gradual slowdown/loss of concurrency
17:35:02 <nielsm> also had the brilliant thought to check the VS profiler, of the capture I took, 9305 samples were in Ship::PrepareTick() and 576 samples were in Ship::ExecuteTick(), meaning about 94% of the work for ships is now running in parallel
17:35:07 <nielsm> if I'm interpreting it right
17:38:39 <nielsm> next challenge: it appears I have a leak
17:39:37 <Rubidium> might that leak be the reason for the bad memory locality?
17:39:51 <Rubidium> (or at least it getting slower over time)
17:40:11 <nielsm> it wasn't getting slower, it was being less parallel
17:40:21 <nielsm> if it was just getting slower, it would still be active on all threads
17:42:09 <nielsm> but yes, I'll try again with the STL parallel algorithm instead of my custom thread pool to see if it also leaks there
17:51:03 <andythenorth> also "ships use all the ticks" anyway
17:51:12 <andythenorth> if only you could parallelise PBS :P
17:57:11 <nielsm> okay uh... half the time in Ship::PrepareTick() is taken in operator new...
17:57:14 <nielsm> that's kind of troubling
18:03:41 <TrueBrain> Lol .. at least the profiler does its job :D
18:07:18 *** Wormnest has joined #openttd
18:09:23 <TrueBrain> right .. what to do with those 60+ uploads ..
18:23:47 *** gelignite has joined #openttd
18:25:33 <TrueBrain> anyone wants to approve ^^ pretty please?
18:25:44 <TrueBrain> it hides the content from search etc, while the user can still use them in his scenario
18:28:25 <nielsm> and that was also the source of the leak
18:28:43 *** andythenorth has quit IRC (Quit: andythenorth)
18:29:04 <TrueBrain> now approve of my PR? :D :D
18:29:58 <nielsm> have you talked to the uploader first?
18:30:07 <TrueBrain> that is why I changed the PR to hide it
18:30:10 <TrueBrain> instead of removing it :)
18:30:34 <TrueBrain> it is a silly solution for a problem we didn't know we had :D
18:33:10 <nielsm> but my approval doesn't count
18:36:13 <TrueBrain> now back to you making OpenTTD faster :P
18:36:17 <FLHerne> > each vehicle has its own path cache
18:36:40 <FLHerne> that seems kind of inefficient, wouldn't by order-group or something be better?
18:36:47 <FLHerne> maybe it's Good Enough
18:37:04 <nielsm> no, because very few vehicles are at the same position in the same order
18:38:04 <nielsm> the path cache includes all the world state there was when the vehicle last called the pathfinder, and is specific for that vehicle's position and destination
18:44:50 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
18:49:24 *** andythenorth has joined #openttd
18:50:09 <DorpsGek> - Update: Translations from eints (by translators)
18:52:20 *** andythenorth has quit IRC ()
18:53:58 *** andythenorth has joined #openttd
18:54:44 *** andythenorth has quit IRC ()
18:56:54 *** andythenorth has joined #openttd
19:18:21 *** sla_ro|master has joined #openttd
19:18:21 <nielsm> thing that might surprise you: towns removing and building houses change their population. with the GUI setting that shows town population in the town label on the map, that causes town labels to be re-layouted quite often
19:18:36 <nielsm> in this case, it's 2.8% of the running time
19:18:49 <nielsm> spent on doing text layout for town name labels
19:19:14 <glx> (don't keep industry directory open ;) )
19:21:09 <andythenorth> see also: train window :P
19:21:58 <nielsm> it sure is spending a lot of time figuring out all these trains are all stopped and don't need to move...
19:24:45 <andythenorth> I know it's completely different
19:25:21 <andythenorth> but my attempts to parallelise grf compiles have uncovered a lot of stuff that's just "wtf?" that can make single-threaded faster also
19:25:53 *** frosch123 has joined #openttd
19:28:54 <frosch123> TrueBrain: really, it's your fault. it would not have happened if there was a limit of 56 newgrf per game :)
19:30:21 <TrueBrain> It is jgrpp only, so that even isn't true :p
19:30:51 <frosch123> oh, so they were already hidden
19:31:14 <TrueBrain> Which just looked like spam
19:32:27 <frosch123> oh, i did not expect this to hide it from the website... there are like 5 different methods to hide things
19:33:12 <nielsm> LoadUnloadStation() can be very slow too when you have visible loading indicators enabled...
19:33:28 <frosch123> i guess sentry stats are ruined for this week
19:34:36 <frosch123> the uploads were faster than the github action, so all the canceled/blocked github ations sent 64 mails or so
19:34:54 <frosch123> but ok, maybe sentry does not count them
19:35:06 <frosch123> but info@ mailbox was filled :p
19:35:46 <TrueBrain> Owh well .. the user meant well
20:27:01 <andythenorth> python hates me :(
20:27:06 <andythenorth> `return return self.get_speed_by_class(self.speed_class + "_on_lgv")`
20:27:30 <dwfreed> why are you doubling return
20:28:21 <andythenorth> I think it would be more amusing if that didn't get raised as a syntax error
20:31:02 <nielsm> I still don't understand why the train controller runs twice with slight differences
20:37:49 <andythenorth> vehicles can't get current railtype / roadtype / tramtype in depot, for good reason I have forgotten?
20:38:02 * andythenorth has buy menu consistency issues :)
20:42:16 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
20:43:59 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:59:37 <andythenorth> not sure nml string code name 'VELOCITY' is actually correct :P
21:00:14 <andythenorth> we don't include a vector direction component?
21:28:58 *** sla_ro|master has quit IRC ()
21:33:12 *** frosch123 has quit IRC (Quit: be yourself, except: if you have the opportunity to be a unicorn, then be a unicorn)
22:08:36 *** andythenorth has quit IRC (Quit: andythenorth)
22:19:15 *** Gustavo6046_ has joined #openttd
22:23:23 *** Gustavo6046 has quit IRC (Ping timeout: 480 seconds)
22:23:23 *** Gustavo6046_ is now known as Gustavo6046
23:42:49 *** gelignite has quit IRC (Quit: Stay safe!)
continue to next day ⏵
