Times are UTC Toggle Colours
10:37:07 <peter1138> Mum, I'm staaaaaaarving! 11:07:22 <DorpsGek> [OpenTTD/OpenTTD] RailwAI opened issue #9813: [Bug]: After removing 'full load any cargo', trains sometimes keep waiting for a full load https://github.com/OpenTTD/OpenTTD/issues/9813 11:11:03 * Gustavo6046 throws a NaN sandwich at peter1138 11:41:04 <Eddi|zuHause> you misspelled "nand switch" 12:00:15 *** WormnestAndroid has quit IRC 12:01:15 <peter1138> Nearly lunch time. 12:01:15 *** WormnestAndroid has joined #openttd 12:04:10 <LordAro> A text: "You've been in close contact with someone who has recently tested positive. Please order a test kit: https://test-kit-<linkbreak>home.com" 12:04:13 <LordAro> i am sus 12:18:20 <peter1138> Avoided so far, to my knowledge. 12:36:22 <peter1138> Yay, lunch :D 12:37:36 <peter1138> I wonder if my phone warns me about sus texts. I had a phoney (hah) phone call that it warned me about once. 13:36:23 *** Gustavo6046 has quit IRC 14:28:09 *** D-HUND is now known as debdog 14:33:57 *** nielsm has joined #openttd 14:42:11 <supermop_work> LordAro: here they just started sending everyone the tests 15:07:12 <nielsm> so I had a thought... which may not be new... but would it be possible to parallelise vehicle ticks (pathfinding etc) if the vehicle ticks were split into two: planning and execution. the planning step is only allowed to examine the world, and only allowed to touch some designated "planned action" fields on the vehicle being planned. the planning runs in parallel. the execution then runs in 15:07:12 <nielsm> serial, well-defined order, and performs the actions calculated for each vehicle 15:09:46 <nielsm> there might then be some cases where a vehicle might not executed the planned action, maybe? like trains crossing a signal will only do it if the planned action is still safe, and road vehicles on a level crossing that become reserved by a train just as the RV is about to enter the tile 15:10:47 <nielsm> like, track reservations for path signals, the train would plan which track it wants to reserve, and then in execution the trains get to actually reserve the track in order, and if a train can't execute the reservation it instead waits 15:11:21 <nielsm> I _think_ that would make it possible to run all the heavy work in parallel 15:16:08 <nielsm> it would probably change the simulation outcome in some situations, but it should still be deterministic as long as the planning step of a vehicle tick does not modify any world state 15:18:19 <Rubidium> I'm quite not sure waiting is the right solution. Why would two trains entering a (big) station and planning to use the same platform block one from entering another free platform? You would get sporadic bug reports of trains that, for no apparant reason, stop 15:19:10 <nielsm> yeah I'm thinking that maybe vehicles that fail their planned action should be put back in a queue for a second (and third etc) run at planning and execution 15:19:27 <nielsm> so it repeats until all vehicles are satisfied 15:22:29 <Rubidium> if you got the time and energy to try, it's definitely worth a try 15:23:22 <Rubidium> I'm quite interested to see how much the improvement you can get with that would be, but don't have the spare time to invest in such a project 15:47:37 *** Gustavo6046 has joined #openttd 16:00:54 <DorpsGek> [OpenTTD/OpenTTD] nielsmh opened pull request #9814: Fix: Original music playback rate was slightly too fast https://github.com/OpenTTD/OpenTTD/pull/9814 16:01:13 *** dP has joined #openttd 16:01:13 *** dP is now known as _dp_ 16:22:58 *** Smedles has joined #openttd 16:24:10 *** frosch123 has joined #openttd 16:29:25 <frosch123> nielsm: my assumption is: the pathfinder is not that important, it uses a lot of caching, so parallized access is probably a nightmare. however stuff like "vehicle acceleraton" could be parallelized and runs way more often than pathfinders 16:30:02 <frosch123> also, newgrf stuff can be mostly parallelized, if you get rid of some global state that does not need to be global 16:30:29 <frosch123> hmm, i think tb has a roadmap somewhere for parallizing viewport draing 16:34:23 <TrueBrain> Did some attempts, gave lovely speeds up.. but also requires lot of refactoring to make it sane :D 16:45:10 <nielsm> ah right... newgrf is a danger point yeah 16:45:36 *** gelignite has joined #openttd 16:45:51 <frosch123> only the ottd implementation 16:46:07 <frosch123> it has some "static" in places that should be "thread_local" 16:49:30 *** glx has joined #openttd 16:49:30 *** ChanServ sets mode: +v glx 16:56:49 *** Wormnest has joined #openttd 17:00:50 *** Gustavo6046 has quit IRC 17:00:57 *** Gustavo6046 has joined #openttd 17:01:49 *** Gustavo6046 has quit IRC 17:34:37 *** Flygon has quit IRC 17:57:48 *** Kitrana1 has quit IRC 18:00:38 *** Kitrana has joined #openttd 18:09:47 *** andythenorth has quit IRC 18:12:17 <nielsm> hmm, the newgrf execution stuff mostly isn't so bad actually, the big joker is persistent storage and its usage of a Pool type 18:15:56 <nielsm> and I'm thinking _current_company should be thread local too 18:20:10 <frosch123> there are very few places which are actually allowed to modify persistent storage 18:20:25 <frosch123> drawing certainly is not :) 18:20:36 *** Kitrana1 has joined #openttd 18:21:10 <frosch123> nor is vehicle movement 18:21:36 <TrueBrain> now I am curious what was up with viewport again .. hmm 18:21:58 *** jottyfan has joined #openttd 18:22:08 *** andythenorth has joined #openttd 18:22:29 <TrueBrain> I have too many local branches :D 18:22:33 <TrueBrain> 338 .. 18:23:31 <TrueBrain> ah, yes, I just added a massive queue in the viewport .. :D 18:26:42 *** Kitrana has quit IRC 18:27:33 <nielsm> https://github.com/OpenTTD/OpenTTD/compare/master...nielsmh:parallellvehticks that's all the suspicious things I found 18:30:22 <TrueBrain> ah, and yes, it needed classification, as _vd is just an ugly hack .. 18:32:29 <frosch123> nielsm: https://github.com/nielsmh/OpenTTD/blob/master/src/newgrf_spritegroup.cpp#L23 <- also that one 18:33:00 <frosch123> though "thread_local" always looked like a hack to me :) 18:33:51 <TrueBrain> very easy to screw up too :P 18:56:00 <TrueBrain> it might surprise everyone in here, but using memory you didn't initialize doesn't work 18:56:06 <TrueBrain> sadly, it takes a few minutes to figure out you are trying that :D 18:56:09 <TrueBrain> stupid compilers not telling me 19:02:55 <Rubidium> might require you to enable more warnings, or maybe something like -fsanitize=memory 19:03:10 <TrueBrain> pfff 19:05:03 <nielsm> frosch123 wow, the usage of that _temp_store is just ugly 19:06:14 <frosch123> it's zeroed before every grf call, but some results are read after the grf call 19:06:51 <frosch123> i do not remember whether it is actually memset, or whether there was some state how much memset was needed 19:07:04 <frosch123> iirc i measured what was faster, and it was measureable :/ 19:14:15 <TrueBrain> I assume you memset A LOT :P 19:17:05 <nielsm> memset'ing a memory size known at compile time probably allows the compiler to generate much tighter code, so I can imagine that being the faster 19:18:24 <frosch123> https://github.com/nielsmh/OpenTTD/blob/master/sr