Times are UTC Toggle Colours
02:14:50 *** glx has quit IRC 02:16:29 *** debdog has joined #openttd 02:19:51 *** D-HUND has quit IRC 02:35:40 *** Wormnest has quit IRC 03:54:04 *** tokai|noir has joined #openttd 03:54:04 *** ChanServ sets mode: +v tokai|noir 04:00:51 *** tokai has quit IRC 05:02:53 *** Flygon has joined #openttd 05:39:30 <DorpsGek> [OpenTTD/OpenTTD] James103 commented on issue #9459: [Crash]: Game crashed out of nowhere https://git.io/JBwFt 06:19:52 *** sla_ro|master has joined #openttd 06:31:25 *** keenriser has quit IRC 06:48:44 *** gelignite has joined #openttd 08:18:29 *** andythenorth has joined #openttd 08:21:26 *** WormnestAndroid has quit IRC 08:21:39 *** WormnestAndroid has joined #openttd 08:28:13 <andythenorth> yo 08:45:04 <FLHerne> oy 08:58:20 <DorpsGek> [OpenTTD/team] YusufSuleman opened issue #236: [ur_PK] Translator access request https://git.io/JBQgy 10:12:53 *** Samu has joined #openttd 10:29:32 *** Wuzzy has joined #openttd 11:02:30 *** andythenorth has quit IRC 11:57:23 *** DooM has joined #openttd 11:59:12 *** virtualrandomnumber has joined #openttd 11:59:45 *** DooM has quit IRC 12:25:45 *** DooM has joined #openttd 12:41:10 *** gelignite has quit IRC 12:41:22 *** snail_UES_ has joined #openttd 12:49:54 *** glx has joined #openttd 12:49:54 *** ChanServ sets mode: +v glx 12:52:26 *** roadt__ has joined #openttd 12:54:19 *** snail_UES_ has quit IRC 12:55:37 <DorpsGek> [OpenTTD/team] glx22 commented on issue #236: [ur_PK] Translator access request https://git.io/JBQgy 12:56:24 <DorpsGek> [OpenTTD/team] glx22 commented on issue #235: [el_GR] Translator access request https://git.io/JBMyA 12:59:25 *** roadt_ has quit IRC 13:14:45 *** iSoSyS has joined #openttd 13:19:40 *** iSoSyS has quit IRC 13:19:58 *** virtualrandomnumber has quit IRC 13:24:33 *** roadt__ has quit IRC 13:29:58 <Samu> testing some new code alternative 13:30:13 <Samu> avoiding AIVehicleList_Station 13:30:27 <Samu> my ai was actually heavily using it 13:30:43 <Samu> now I build the list myself 13:30:58 <Samu> not rellying on openttd to make it for me 13:31:14 *** roadt__ has joined #openttd 13:32:00 <Samu> not entirelly sure how I'm going to do it for road vehicles and aircraft, though 13:32:25 <Samu> those vehicle types can crash 13:32:39 <Samu> meaning, i will lose their v_ids 13:33:00 <Samu> making my self-built vehicle lists broken 13:34:25 <LordAro> you can get their IDs if you process the news message, can't you? 13:34:46 <Samu> yes, but only if I catch it on time 13:35:16 <Samu> if it disappears before I process it... it's gone 13:35:23 <Samu> can't know which vehicle was it 13:35:59 <LordAro> shouldn't be difficult to check for invalid vehicle IDs? 13:41:57 <glx> message still will have the old id, even if vehicle is removed 13:42:38 <LordAro> mm, i don't think the message gets removed before then 13:46:56 <_dp_> hm... I found some modification while iterating issues with pool type... 13:46:57 <_dp_> https://github.com/OpenTTD/OpenTTD/blob/master/src/vehicle.cpp#L959 13:47:20 <Samu> NotPerfectAI has 25 second stalls 13:47:28 <_dp_> here, v->Tick() can create effect vehicles that may or may not be ticked in the same loop depending on their id 13:47:39 <_dp_> in since pool size is not stored in the save it can even desync 13:48:01 <_dp_> not sure what to do about it though 13:48:10 <Samu> haven't investigated much other than that it also using AIVehicleList_Station heavily 13:48:27 *** nielsm has joined #openttd 13:50:40 <_dp_> basically there are two ways to fix it, either fix pool size or modify iteration 13:51:17 <Samu> it also uses Valuate function often 13:51:37 <_dp_> fixing size is simpler and will fix desyncs but won't fix instaticks 13:51:37 <Samu> from what visual studio shows me of that stall 13:54:45 <glx> did a quick search in source, and events are never deleted if AIEventController::GetNextEvent() is not called 13:57:03 <Samu> I remember one of the reasons WrightAI code seemed broken at times was due to the fact GetNextEvent wasn't finding crashed airplanes 13:57:15 <Samu> but that was 2 years ago or so 13:57:18 <Samu> maybe 3 13:58:13 <Samu> seems code has changed 13:58:16 <Samu> gotta try it 13:58:18 <glx> well the old_id may be invalid at the time the event is parsed, meaning you can't get the corrseponding vehicle 13:59:38 <glx> same for AIEventVehicleAutoReplaced(), it just tells vehicle old_id in now vehicle new_id 14:00:32 <Samu> my ai doesn't use EventController at all, gonna have to think how I'm going to implement it 14:02:32 <Samu> i can get vehicle ids from it, and it could belong to any route, air, road, water. The way I have the AI managing routes is that it goes through each individual route per vehicle type 14:02:47 <glx> hmm I think if GS or AI doesn't parse events, it may be a memory usage issue 14:03:16 <glx> because event stack will just grow continuously 14:03:53 <Rubidium> _dp_: how is pool size important for the ID of the created effect vehicle? 14:04:07 <glx> maybe we should add an opt-in setting in AIInfo 14:04:30 <glx> (default to true for previous API version) 14:06:00 <Rubidium> _dp_: as far as I know there are three situations; the pools are big enough, the pool is not big enough at one side and an allocation is done, and the pool is not big enough at one side and the allocation fails. In the first two cases there is no problem, in the latter there is no desync as the game just crashes to desktop with a OOM-error 14:12:37 <_dp_> Rubidium, iterator goes to pool size so it determines whether the new effect will be ticked in the same loop 14:12:48 <_dp_> and if it ticks differently it eventually blows up to the full desync 14:15:42 <_dp_> I even have a save that has it happening 14:16:32 <Samu> almost 5000 ships. Real testing happens past that 14:16:56 <Samu> ai enters management mode only which is where the slowdowns happen 14:17:48 <Samu> got a feeling i will now have AIVehicleList_Group slowing it down :p 14:36:11 <Samu> wow, ScriptVehicleList_Station yet again, looks like I didn't catch all cases 14:43:25 <Samu> im confused 14:43:40 <Samu> ScriptVehicleList_Station is being called by the ai, but how! 14:44:05 <Samu> what did I miss 14:44:59 <Samu> aha, got it 14:45:07 <Samu> it's in the main file 14:45:36 <Samu> performing town actions has it 14:45:45 <Samu> damn :p 14:52:37 <Samu> damn it, lol, more reason to have a cache in the stations themselves 15:03:02 <Samu> random question, are squirrel tables sortable by value? 15:03:08 <Samu> i suppose not 15:10:23 <Samu> at long last, no more calls to AIVehicleList_Group 15:10:31 <Samu> pretty noticeable difference 15:10:55 <Samu> i mean not group, I meant Station 15:12:03 <Samu> AIVehicleList_Group is now the top offender 15:12:19 <Samu> i think i can deal with it in a similar manner 15:20:31 *** virtualrandomnumber has joined #openttd 15:27:51 <Samu> a little bit more complicated apparently 15:29:07 *** Strom has quit IRC 15:30:44 *** Strom has joined #openttd 15:46:37 *** frosch123 has joined #openttd 15:56:08 *** jottyfan has joined #openttd 16:11:38 *** virtualrandomnumber has quit IRC 16:14:13 *** Wormnest has joined #openttd 16:15:10 *** D-HUND has joined #openttd 16:18:29 *** debdog has quit IRC 16:44:40 *** tokai has joined #openttd 16:44:40 *** ChanServ sets mode: +v tokai 16:49:07 *** Progman has joined #openttd 16:51:26 *** tokai|noir has quit IRC 17:07:01 *** andythenorth has joined #openttd 17:14:07 <Rubidium> _dp_: I see why it's going wrong... I'd say someone made a "bad" conversion to these range based for loops. "bad" in the sense that they break things that were working just fine before 17:17:19 <Samu> i can't find out why my AI is still calling ScriptVehicleList_Group. what am i missing 17:21:58 <_dp_> Rubidium, yeah, it looks like desync was introduced here: https://github.com/OpenTTD/OpenTTD/pull/7864 17:22:12 <_dp_> instant tick issue though existed before afaict 17:30:37 <andythenorth> yo 17:30:46 <TrueBrain> hello 17:30:52 <Rubidium> yes, that likely introduced the desync. Whether "instant tick" is really an issue... you could also see it as a simple optimisation. Why all the management, if it's only an effect vehicle? 17:34:46 <_dp_> well, logically ticking it right after creating seems wrong 17:34:51 <_dp_> but I guess for effects it's finne 17:35:58 <_dp_> wonder if there're other affected loops 17:36:21 <_dp_> ideally this case should be guarded somehow 17:41:47 <Samu> managed to find it, it was in the air part of the code 17:41:56 <Samu> not much i can do about it 17:42:14 <glx> Rubidium: care to explain what exactly is wrong ? 17:42:16 <Samu> that code is a whole mess 17:42:26 *** HerzogDeXtEr has joined #openttd 17:44:16 <frosch123> glx: https://github.com/OpenTTD/OpenTTD/blob/master/src/core/pool_type.hpp#L217 17:44:30 <frosch123> end() is evaluated at the start of the loop, and uses GetPoolSize 17:44:52 <frosch123> if items are added after that during the loop, they are skipped in the iteration 17:44:53 <glx> oh 17:45:10 <frosch123> apparently GetPoolSize can be different on different clients due to command test runs? 17:45:19 <frosch123> (no idea, guessing the latter) 17:45:43 <TrueBrain> can we just blame C++? 17:45:44 <TrueBrain> easier that way 17:46:00 <frosch123> as always, the solution is c++20 :) 17:46:01 <TrueBrain> \o/ 17:46:15 <frosch123> ranges with sentinel-end avoid having to know end() at the start :) 17:46:27 <TrueBrain> haha, I did not expect that :P 17:47:15 <frosch123> we do not need a language feature for that, so we do not have to wait for c++20 :) 17:47:24 *** gelignite has joined #openttd 17:47:34 <TrueBrain> but it is more fun! 17:48:32 <glx> so ideally end() should use a constant, and iterator should do the same when it reaches GetPoolSize() 17:49:01 <frosch123> yeah, something like that. unless we iterate backwards somewhere :) 17:49:25 <glx> no, pool iterators are forward only 17:50:44 <Rubidium> frosch123: at CleanPool "GetPoolSize" gets set to 0, then any Allocate sets it to max(GetPoolSize(), index). So it's effectively the highest allocated index within the game. So, remove some of the highest IDs from the game, save the game and reload... then GetPoolSize will return a lower value 17:51:14 <TrueBrain> so (track and) use the highest number instead! :D 17:51:18 <TrueBrain> I am good at this bench-programming 17:51:23 <TrueBrain> just shouting things from the side 17:51:24 <TrueBrain> :P 17:51:38 <frosch123> Rubidium: ah, so joining clients may have smaller pools 17:51:49 <Rubidium> exactly 17:51:53 <glx> but GetPoolSize was already used in the old loop 17:52:46 <frosch123> but it was evaluated every iteration 17:52:48 <Rubidium> glx: true, but... for (i = 0; i < GetPoolSize(); i++) is not equal to s = 0; end = GetPoolSize(); for (i = s; i < end; i++) 17:53:03 <glx> yes I totally understand that 17:53:20 <Rubidium> https://en.cppreference.com/w/cpp/language/range-for for the actual equivalences 17:53:57 <frosch123> TrueBrain: since when is it bench-programming? isn't backseat-programming? 17:54:07 <TrueBrain> I don't like cars 17:54:09 <TrueBrain> I like parks 17:56:48 <Samu> managed to get framerates over 1 17:57:01 <Samu> 1.20 fps on a 4k map with 5000 ships and 1 AI of mine 17:57:06 <Samu> 250k ops very fast 17:57:15 <Samu> I'm happy 17:57:27 <TrueBrain> if you are happy, we are happy 17:57:27 <glx> so as I said, end() should use MAX_SIZE, and ValidateIndex should also set this->index to MAX_SIZE when this->index becomes GetPoolSize() 17:57:30 <TrueBrain> so .. cake for everyone now? 17:58:21 <frosch123> glx: good idea, i had something way more complicated in mind 17:58:27 <Rubidium> https://bit.ly/3zZ9tNx ... yummy ;) 18:03:14 *** Flygon has quit IRC 18:32:03 <planetmaker> hm... got a reminder of an event ~8 years ago on my phone the other day. Looked similar :P Good evenink :) 18:44:58 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 closed issue #9440: [Bug]: Inflation breaks negative cargo payments https://git.io/JCtHI 18:45:01 <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9455: Fix #9440: negative cargo payments not being handled right https://git.io/Jlill 18:45:25 <TrueBrain> omg, WHAT HAVE YOU DONE?! :P 18:45:31 <TrueBrain> and also: hi planetmaker :) 18:46:38 <Rubidium> I clicked some buttons in a web browser 18:47:16 <TrueBrain> I am amazed :P 18:48:52 *** Gustavo6046_ has joined #openttd 18:51:43 <DorpsGek> [OpenTTD/OpenTTD] DorpsGek pushed 1 commits to master https://git.io/JBFVq 18:51:44 <DorpsGek> - Update: Translations from eints (by translators) 18:52:29 <Rubidium> it didn't even break the eints commit ;) 18:52:40 *** Gustavo6046 has quit IRC 18:52:40 *** Gustavo6046_ is now known as Gustavo6046 19:01:12 *** Compu has joined #openttd 19:01:15 <TrueBrain> That is the biggest surprise :p 19:01:16 *** Compu has quit IRC 19:17:57 *** D-HUND is now known as debdog 19:20:42 <andythenorth> oof 19:20:48 <andythenorth> why do I play solitaire? :P 19:28:56 <nielsm> you feel a need for solitude? 19:29:01 <andythenorth> lol 19:29:14 <andythenorth> I think it's because it demands almost no skill 19:29:23 * andythenorth is on holiday 19:33:38 <Samu> i meant game speed over 1.0x 19:33:42 <Samu> not framerates 19:50:16 <Samu> my next goal is to make use of AIEventVehicleCrashed, how am I implementing it in my current code 19:51:08 <Samu> if I skip an event, i can't get back to it later, right? I have to deal with it right away 19:51:41 <nielsm> yeah you'd have to store it in your own "need to handle this later" queue 19:53:12 <Samu> getting the vehicle id is all i need, even if outdated 19:54:19 <Samu> hmm, i still don't see it working in the long run 19:56:59 <Samu> suppose a vehicle crashes, its v_id poofs after a time, becomes available for another vehicle to take it 19:57:43 <Samu> i am maybe creating new vehicles that would re-use the same v_id 19:58:28 <Samu> now i got an invalid list 19:58:54 <Samu> when dealing with the event, i would be removing the v_id from my own list 20:01:35 <Samu> I can't think of a good way to do this 20:02:38 <Samu> I can only think of this working if I manage the event on time and get the v_id when the vehicle still exists 20:06:42 <Samu> must properly validate a vehicle 20:07:21 <Samu> a simple AIVehicle.IsValidVehicle won't suffice 20:30:47 <glx> _dp_: maybe https://github.com/OpenTTD/OpenTTD/compare/master...glx22:pool_iterator 20:35:26 *** nielsm has quit IRC 21:12:07 <_dp_> glx, well, that fixes the desync at least 21:12:09 *** Progman has quit IRC 21:21:23 *** sla_ro|master has quit IRC 21:29:10 *** Samu has quit IRC 21:34:04 *** frosch123 has quit IRC 21:38:48 *** andythenorth has quit IRC 21:54:52 *** HerzogDeXtEr has quit IRC 22:04:53 *** gelignite has quit IRC 22:31:20 *** tokai|noir has joined #openttd 22:31:20 *** ChanServ sets mode: +v tokai|noir 22:38:11 *** tokai has quit IRC 23:45:32 *** Wuzzy has quit IRC 23:58:30 *** hannah777 has joined #openttd 23:58:35 <hannah777> hello 23:58:57 <hannah777> im trying to setup a dedicated openttd server 23:59:18 <hannah777> im getting the error message dbg: [net] getaddrinfo for hostname "f", port 3979, address family either IPv4 or IPv6 and socket type tcp failed: Temporary failure in name resolution 23:59:19 <hannah777> dbg: [net] [server] could not start network: could not create listening socket, has anyone else had this or do you have any idea why i get it? 23:59:56 <FLHerne> hannah777: Does the network connection work for other things?