Log for #openttd on 2nd August 2021:
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
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
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
12:56:24  <DorpsGek> [OpenTTD/team] glx22 commented on issue #235: [el_GR] Translator access request
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_>
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:
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:
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> 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> ... 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
18:45:01  <DorpsGek> [OpenTTD/OpenTTD] rubidium42 merged pull request #9455: Fix #9440: negative cargo payments not being handled right
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
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
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?

Powered by YARRSTE version: svn-trunk