IRC logs for #openttd on OFTC at 2024-04-24
⏴ go to previous day
01:24:59 *** D-HUND is now known as debdog
02:02:12 *** herms has quit IRC (Quit: bye)
02:11:51 *** Wormnest has quit IRC (Quit: Leaving)
02:29:26 *** gnu_jj_ has joined #openttd
02:32:37 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:38:19 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:39:32 *** Eddi|zuHause has quit IRC ()
03:42:16 *** Eddi|zuHause has joined #openttd
04:41:00 <DorpsGek> - Update: Translations from eints (by translators)
05:06:40 <jenkings> how to join translations team ? 🙂 when i open the page and login, i have permission to nothing 🙂
05:07:11 <jenkings> I would like to hel with Czech translation 🙂
05:09:56 <jenkings> and the same time, i want to ask, if you are interested in fixing the translation of signals 🙂
05:09:56 <jenkings> In czech translation, it is now everywhere as "semafor", however the correct name for this device is "návěstidlo".
05:09:56 <jenkings> "semafor" is word, for signals on roads, some people also uses it for signals on railroads, but the correct term is "návěstidlo".
05:09:56 <jenkings> Maybe i am the only one fan of railways, but it really iritates me, to see incorrect name for railway signals 🙂
05:11:27 <jenkings> and don't let my terrible English discourage you, I speak Czech very well 🤗
05:13:23 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:00:49 *** HerzogDeXtEr has joined #openttd
07:38:50 <jenkings> Yup, that is what i have visited, but i have no permissions, so i am not able to make any changes
07:39:20 <jenkings> everything ends here:
08:05:14 <kuhnovic> jenkings: you probably need to do this ^^
08:39:23 *** ChanServ sets mode: +v tokai
08:51:28 <FLHerne> don't know how rigid that is
08:53:23 <FLHerne> jenkings: hm, in 14.0 at least it seems to be "návěstidlo"?
08:59:01 <jenkings> so it is a little bit inconsistent. in bar it is "návěstidlo". but while building i have notice that * you cannot build "semafor" while paused*
08:59:24 <jenkings> of course the notice is complete in czech, this is jist for illustration
10:00:16 <georgevb> kuhnovic: BTW seems my access does not work, I can't change strings
10:07:08 *** Ox7C5 has quit IRC (Ping timeout: 480 seconds)
10:30:06 <_glx_> georgevb: Yes you have not accepted the invitation in time, I sent it again
10:34:28 <_glx_> If it still fails logout then login on eints
11:31:33 <peter1138> johnfranklin: Good idea.
11:44:30 *** Kriktel has joined #openttd
11:45:13 <johnfranklin> So I learned some C++ this afternoon...
11:47:01 <peter1138> Please teach me, cos I have no idea 😄
11:47:54 <johnfranklin> Will it run properly if "date" and "rank" are well defined?
11:49:49 <merni> Your compiler can answer that question much better :)
11:50:56 <johnfranklin> I still don't know how to design a rank funcion and don't know how C++ implies date, so this will definitely not work
11:55:06 *** asasnat has quit IRC (Quit: User went offline on Discord a while ago)
12:38:24 <kuhnovic> To vector or not to vector, thta is the question
12:39:13 <tateisukannanirase> _jgr_: have you ever tried or has it been discussed putting the yapf cost for road vehicles with the same order destination from jgrpp into the main repo?
12:43:49 <_jgr_> tateisukannanirase: I'd expect not. You're welcome to try or to discuss it yourself if you want.
12:44:26 <_jgr_> I can't say that I've thought about it all since it was merged
12:44:29 <peter1138> vector<bool> is a weird one because it does not behave exactly like a normal vector. But I think it should be fine to use unless it's determined to be a problem, rather than assuming it's a problem.
12:45:20 <peter1138> The pool does not use it because it needs to iterate it in a specific way that can be faster when hand-coded.
12:46:15 <peter1138> I quite liked my pool used_bitmap visualisation, but it turns out it was not useful anyway 🙂
12:50:00 <kuhnovic> Yeah vector<bool> is a strange beast
12:52:09 <tateisukannanirase> @jgr I see, thanks. I've been experimenting with the yapf weighting and tried lots of different variations (made another PR yesterday too) but the jgrpp version is still more performant, at least when measured by profit. But perhaps there are some other variables affecting profit.
14:52:46 <peter1138> emplace sounds good until you remember you need constructors too...
14:54:08 *** keikoz has quit IRC (Ping timeout: 480 seconds)
14:55:20 <peter1138> I guess blank emplace and then setting the values is still better than push.
15:54:29 *** Wormnest has joined #openttd
16:01:11 <audigex> Now that the game has unbunching, in theory would it be possible to include some small amount of automatic unbunching too, without requiring the user to set an unbunching order?
16:01:11 <audigex> I know that the idea of using depots was to avoid trains (/vehicle? I'll just say train) potentially blocking stations for a long time, but it seems to me like it might be possible to do some micro-unbunching at every stop, using the same basic calculations as unbunching would use. But instead of waiting for the full duration, the train only waits a shorter amount of time (a few ticks? A second?
16:01:11 <audigex> 1-a few seconds, defined in settings? Whatever seems sensible)
16:01:11 <audigex> It wouldn't completely fulfil the same functionality as unbunching or timetable auto-separation of resolving things quickly, but it would help keep already separated vehicles separated and potentially self-correct over time as long as there isn't anything introducing large delays regularly
16:01:11 <audigex> My thought is that it would potentially be a nice feature for new or very casual users who might not even know unbunching exists, reducing the amount of bunching that happens and how often they have to separate vehicles manually
16:01:12 <audigex> And of course it can just be skipped entirely if there is an unbunching order in the schedule
16:08:36 <_jgr_> audigex: As described, this is not going to help keep things separated
16:09:50 <andythenorth> I had success separating buses using a pinch point stop, with just a single tile
16:10:16 <andythenorth> Forcing a timetable wait there works fine to seaparate buses
16:10:33 <andythenorth> As long as the delay isn’t long enough for tunneling
16:10:42 <andythenorth> It’s quite fragile
16:19:50 <audigex> _jgr_: Wouldn't it work the same as unbunching? What am I missing?
16:19:50 <audigex> At each station calculate/track the average time for a round trip back to that order for the shared vehicles. Divide it by the number of vehicles in the shared orders
16:19:50 <audigex> When a vehicle leaves, store the "ideal next departure time" for that set of shared vehicles at that station. When the next vehicle is about to depart, if the time is <ideal, hold it for 1-2 seconds
16:19:59 <audigex> I presume I'm just missing something obvious
16:24:02 <_jgr_> That could work (though I have doubts about a constant delay), but I very much doubt that only shortening waits as you said above would be effective
16:25:15 <andythenorth> Routes choke due to queues to enter stations?
16:25:22 <andythenorth> Depots mitigate that?
16:26:22 <_jgr_> If you're queuing to enter stations, then you've got too many vehicles
16:27:06 <andythenorth> Stations can be in multiple order graphs though?
16:27:58 <andythenorth> So there is cross-talk between routes due to holding vehicles blocking the station?
16:29:26 <_jgr_> All right, to caveat, if you're always queuing to enter stations, then you've got too many vehicles 😛
16:30:48 <_jgr_> And yes, the rational for using depots is that because they have no capacity limits or ordering constraints, it's basically impossible for the user to get it wrong
16:32:08 <peter1138> Until that gets changed...
16:48:53 <andythenorth> multi-tile realistic depots? 😛
17:04:45 *** j0anjosep has joined #openttd
17:04:45 <j0anjosep> andythenorth: realistic? that would bé a nightmare
17:06:05 <talltyler> Wormhole depots won't get changed since that would "break" savegames. The current extended depots PR just adds new depot tiles where vehicles take up space. If users use those and get things wrong, that's on them. 🙂
17:06:18 <talltyler> We don't block users from jogjamming their trains, for example
17:56:18 <LordAro> peter1138: #12567 could use std::find_first_of ?
17:56:26 <LordAro> (not signed in, on phone)
17:59:21 <peter1138> Probably just std::find()
18:03:13 <LordAro> actually, doesn't StrMakeValid do stuff with nul chars anyway?
18:04:49 <peter1138> Yes but it does it in place.
18:04:56 <peter1138> > /* String termination, if needed, is left to the caller of this function. */
18:05:39 <peter1138> That's the old-style string part.
18:06:18 <peter1138> So yeah. I think it will.
18:07:48 <peter1138> "StrMakeValid already does this"
18:08:59 <peter1138> Might be a completely different patch...
18:14:19 <peter1138> Okay, well that's a rabbit hole.
18:26:32 <LordAro> i'm good at finding those
18:30:52 <peter1138> Although now I wonder. That might be correct still.
18:39:13 <peter1138> Meh, leaving that one along now. Thanks LordAro :S
18:46:05 <truebrain> all content in the category ai / ai-library / game-script / game-script-library uploaded to BaNaNaS, none of those tarballs have any symlinks in them
18:50:13 <peter1138> I misread "none" as "most" then as was a bit surprised...
18:50:25 <peter1138> What about any other tars?
18:50:35 <truebrain> downloading them now, but I can't imagine them having any
18:51:10 <peter1138> Ah not something you can just query on the server 😄
18:51:28 <peter1138> I'm so 20 years ago.
18:51:44 <truebrain> need to actually extract files to see :p
18:51:45 <peter1138> Someone else's server.
18:52:01 <merni> Some of those would be nice
18:52:05 <truebrain> and there are SO MANY NewGRFs ...
18:52:14 <merni> summer blue sky wihtout rain is boring
18:57:45 <truebrain> ```$ find . -type l
18:57:48 <truebrain> so yeah ... nothing
18:58:12 <truebrain> that is over 7334 uploads
19:00:16 <truebrain> come to think of it, not even sure you can get a symlink in an upload done via BaNaNaS 😛
19:02:47 <truebrain> so yeah, maybe frosch123 remembers why he wrote it. But I doubt anyone uses it 🙂 (symlink support in tarballs)
19:03:07 <frosch123> it was for the old 32bpp stuff
19:03:09 *** matusguy has joined #openttd
19:03:23 <frosch123> to be able to provide the same pngs for windows and dos grfs or something
19:03:35 <frosch123> so, obsolete since ottd 1.2
19:04:40 <frosch123> back then grfs were built with makefiles on devzone, so creating symlinks was not that unrealistic
19:06:19 <peter1138> I did actually wonder if it was png sprite related.
19:14:18 <peter1138> I did actually search the forum for it but couldn't fit that :S
19:14:43 <frosch123> yes, google also failed for me, i looked at my post history around the commit date
19:15:13 <frosch123> i assumed i had posted some answer somewhere, not a full announcement topic :p
19:17:28 <frosch123> oh, basesets/opengfx were added a year later, so back then really only the two original basesets existed, and people made 32bpp pngs for them
19:21:19 <peter1138> Why is it so hard to remember 2>&1 correctly 😄
19:21:28 <truebrain> because it is weird
19:21:55 <peter1138> `rm 1` is quite common :p
19:28:42 <dwfreed> "stderr" "redirect to" "also" "stdout"
19:33:36 <peter1138> Okay but new MapMen.
19:45:50 <truebrain> okay, TCP traffic of BaNaNaS is down to 3% (from 6%), so 14.0 does help 🙂
19:46:06 <truebrain> we will see if that impacts the monthly bill of May in any way 🙂
19:48:22 <truebrain> _jgr_: did #12563 actually happen to you, or did you just spot it in the code? As that is a really small window for things to go bad. Like, an extremely small one 😄
19:48:59 <peter1138> Those are the ones that occurr.
19:49:04 <_jgr_> No, I was looking at the code to use as a reference for how to use WinHTTP
19:49:21 <truebrain> as I was about to suggest to please play the lottery 🙂
19:50:30 <_jgr_> Yes, I think I'd have a hard time trying to deliberately trigger that, never mind accidentally
19:50:53 <truebrain> it is not impossible, but .. 😄
19:51:00 <truebrain> but yeah, should be fixed nevertheless!
19:56:55 <peter1138> So eager to remove frosch's hard work 😮
20:34:55 <audigex> andythenorth: That’s why I suggest a minimal delay, a second or a few seconds max, rather than the depot-based unbunching which can wait an unlimited amount of time
20:34:55 <audigex> The idea being that it’s the same basic process as unbunching but done a few seconds at a time at every station rather than all at once in a depot
20:37:32 <audigex> The fact it’s only a second or a few seconds does reduce effectiveness but also removed too many knock on effects too - you’re just turning a 10 second dwell into maybe 11-12 seconds to reduce your bunching a little over time. My assumption is that although you’ll occasionally delay another train by 2 seconds, you’ll get more benefit (on average) than induced delay. By definition, even, you can
20:37:32 <audigex> never induce more delay than you’re reducing
20:37:32 <audigex> The idea being that occasionally delays will be ironed out over time. Obviously it won’t help if you have regular major disruptions, but it’ll just help a little with the classic bunching problem (train in front picks up more pax, so the train behind has fewer to pick up and therefore gets a little closer, so has even fewer to pick up next time)
20:38:57 <peter1138> All that for only 22 lengthofs... so far 🙂
21:03:28 *** SigHunter_ has joined #openttd
21:04:59 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:05:44 *** SigHunter has quit IRC (Ping timeout: 480 seconds)
21:06:58 <talltyler> audigex: I considered this approach, but one of the main pitfalls with this proposal (and the vanilla timetable separation when you Ctrl+Click on Start Date) is vehicles getting out of order on a network where overtaking isn’t possible — trams and some bus and train lines. I’m not sure how to determine which vehicle is “first,” and maybe more importantly, prove to code reviewers that corner cases
21:06:58 <talltyler> can’t break the algorithm. Proof of durability has been a major sticking point of previous implementations, such as #8342.
21:17:33 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:20:17 <audigex> talltyler: Isn’t that the same problem as unbunching has presumably solved though?
21:20:17 <audigex> I’m basically saying to use the unbunching code at every station as-is, but limiting the maximum delay to a few seconds
21:20:46 <audigex> Literally the same code as used in the depot but then let the train depart after (eg) 2 seconds rather than waiting for the target departure time
21:23:40 <talltyler> It couldn’t be every station with the current code, just one.
21:28:43 <talltyler> Because the current code measures round trip time from the depot, as the starting point for the round trip
21:37:27 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
21:38:49 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:55:28 <peter1138> So with my new station/roadstop/object picker code, adding a class list to the waypoint UI is easy.
21:55:38 <peter1138> I need to tidy this and PR it :p
22:12:32 <peter1138> Next up: should blocked waypoint tiles work...
22:15:20 <peter1138> Though I guess that isn't really new.
22:24:34 <audigex> talltyler: But presumably you could just do the exact same thing at each station?
22:25:02 <audigex> It’s not IDENTICAL but it’s very much the same premise
22:27:16 *** Wormnest has joined #openttd
22:39:29 <peter1138> Oof this is working but it's quite absurd 😄
22:50:44 *** matusguy has quit IRC (Remote host closed the connection)
22:55:42 <talltyler> Each vehicle stores the TickCounter of when it left its unbunching depot, the TickCounter of when it will next leave, and how many ticks its last round trip took. That’s 160 bits per vehicle. Multiply that by the number of stations in each order list…no, not a good idea. 😄
23:20:09 <peter1138> Wentbourne has 37632 orders in it.
23:20:45 <peter1138> I think it does not use shared orders.
23:24:27 <peter1138> Each of those picker windows now uses the same base class (and same partial widget definitions).
23:24:51 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
23:25:01 <peter1138> This is not quite the modular window/components/widgets approach I had in mind.
23:29:10 <wensimehrp> Is it possible to group station classes by NewGRFs?
23:30:18 <wensimehrp> waypoints at least? all waypoints are in the same class
23:31:01 <peter1138> peter1138: Maybe not.
23:33:56 <audigex> talltyler: Eh, RAM is cheap
23:34:55 <audigex> 160 bits, 30 stations, 1000 vehicles = 600KB, unless my maths has failed me
23:42:33 *** tokai|noir has joined #openttd
23:42:33 *** ChanServ sets mode: +v tokai|noir
23:49:08 *** tokai has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
