IRC logs for #openttd on OFTC at 2024-04-25
β΄ go to previous day
00:19:43 <tateisukannanirase> audigex: I've been working on road vehicles yapf a bit lately to try to improve performance. Mainly I am working now on improving the way they enter drive through road stops and not blindly pile into the same entrance like lemmings. I definitely find the law of unintended consequences is pretty strong here though . For example I experimented with having vehicles take different routes to avoid
00:19:43 <tateisukannanirase> bunching/busy roads, and it worked, but profit dropped because it took longer to get to the destination. I had a few other ideas I haven't trialled yet, like fuzzing the servicing interval by +/- 5% of days (so RVs would enter at different times and sorta get unbunched) and porting the same-destination-avoidance code from jgrpp to master.
00:19:43 <tateisukannanirase> But overall I don't think bunching is the boogeyman because sometimes you *want* bunching if the vehicles don't have to wait for a full load. unbunching would delay them getting to the destination and affect the profit. And then bunching would occur the moment one vehicle breaks down and the others queue up behind it anyway. That's why I decided to focus YAPF performance right now.
00:19:43 <tateisukannanirase> At the moment I have an open pull request that fixes a miscalculation of the drive through stop occupied level and it improves how vehicles use drive through roadstops with multiple 'lanes'. If you are capable of building locally, I'd appreciate it if you could run it and give some feedback - as I've mostly only tested it on passenger cargo. https://github.com/OpenTTD/OpenTTD/pull/12558
00:23:32 <audigex> I can't build locally (never got it working), I should really look at getting it setup though
00:23:32 <audigex> I think bunching is fine (ish) when playing classic TTD, but not so much for those of us who like to approximate realism. And even with classic TTD gameplay it can reduce station ratings if your vehicles get too bunched up
00:28:06 <tateisukannanirase> I mention profit because I see it correlated to efficiency of the network. I don't really chase high scores either.
00:28:32 <tateisukannanirase> Try again if you can build - it would be useful for you to test variations
02:31:13 *** Wormnest has quit IRC (Quit: Leaving)
02:31:32 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:37:14 *** D-HUND has quit IRC (Ping timeout: 480 seconds)
04:42:25 <DorpsGek> - Update: Translations from eints (by translators)
05:14:41 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:38:49 *** HerzogDeXtEr has joined #openttd
08:18:10 *** matusguy has joined #openttd
08:36:11 <peter1138> FYI orudge, forums seem quite slow this morning.
08:36:30 <peter1138> Might be my side of course.
08:40:21 <peter1138> 7 seconds to load a topic.
08:45:13 *** reldred has quit IRC (Quit: User went offline on Discord a while ago)
09:25:25 *** Exec has quit IRC (Quit: File:///)
09:50:28 <peter1138> Admin port unit testing?
09:51:12 <peter1138> Simulate a remote client connecting... π
10:07:58 <peter1138> It's had a little more testing (by users) than tar links π
10:12:08 <peter1138> Oh, WindowDesc unit tests are broken since the `std::source_location::current()` change.
10:12:27 <peter1138> [ctest] /home/petern/src/openttd/src/tests/test_window_desc.cpp:83: FAILED:
10:12:27 <peter1138> [ctest] CHECK( IsNWidgetTreeClosed(window_desc->nwid_begin, window_desc->nwid_end) )
10:12:27 <peter1138> [ctest] with expansion:
10:12:27 <peter1138> [ctest] with message:
10:12:29 <peter1138> [ctest] /home/petern/src/openttd/src/window_gui.h:167
10:12:45 <peter1138> That message is supposed to the source location of the window_desc, not the constructor of WindowDesc.
10:14:39 <peter1138> I guess I should've tested Rubidium's change a bit more.
10:19:37 <_glx_> But CI is supposed to detect that
10:20:01 <peter1138> > Adding a new way to load/unload tars in addition to the usual newgrf window is silly.
10:20:01 <peter1138> > So IMO they should be converted into proper ActionA newgrfs with 32bpp support.
10:20:49 <peter1138> The issue isn't that it fails, the issue is that the message is wrong, since the change to source_location.
10:21:03 <peter1138> It no longer gives a useful source location.
10:24:42 <peter1138> Nice formatting Discord bot π
10:31:10 <peter1138> Yup, works with gcc, fails with clang.
10:36:25 <peter1138> FIxed in clang 16, but that can't compile OpenTTD for me.
10:43:41 <peter1138> clang-16 does not like LineCacheCompare
10:48:25 <peter1138> I have no idea what doing < on against `std::stack<..., std::vector<..>>` actually does π
10:55:01 <peter1138> I'm not even sure the colour_stack should be part of the cache state.
10:56:41 <peter1138> It's used during the layout process, but after that should be empty.
10:56:58 <_glx_> Colour stack as in text colour ?
10:57:31 <peter1138> That seems to be entirely irrelevant?
10:58:34 <peter1138> Surely it's dependent on the parameters in the string?
10:58:59 <peter1138> And if it starts with a different colour, then the cur_colour part of the cache will be different.
10:59:50 <_glx_> Direct colour change, push/pop, indirect changes via code
11:01:51 <peter1138> I don't think it's relevant to the cache key.
11:09:33 <peter1138> If there is something left on the stack between one line and the next.
11:09:39 <peter1138> Dunno if that's possible.
11:10:23 <peter1138> Probably with NewGRF/GS, but maybe only accidentally :p
11:28:29 <locosage> somehow ninja+clang sometimes manages to hang up my system after the build is already done π΅βπ«
11:30:23 <locosage> also ninja removes color from compiler messages for some reason :(
11:33:09 <locosage> have to redirect output to less to look for errors π
12:39:38 *** APTX has quit IRC (Quit: Farewell)
12:55:31 *** matusguy has quit IRC (Quit: matusguy)
13:48:33 *** funwithyoyo has joined #openttd
14:35:51 *** Wormnest has joined #openttd
15:01:28 <truebrain> Your inquiry has been received. You should expect a response within 48 hours.
15:01:28 <truebrain> Seems Oracle doesn't even keep word on that .. lol
15:02:39 <audigex> Considering how badly Oracle handles time zones, thereβs probably a +/-24 hours built into that
15:10:16 <truebrain> Pretty sure a relative time doesn't care about timezones π
15:18:39 <Eddi|zuHause> even time zones differ by more than 24 hours :p
15:20:08 <Eddi|zuHause> also, anyone dared to look at the scam link?
15:49:11 *** mindlesstux has quit IRC ()
15:55:50 *** thelounge345 has joined #openttd
15:55:59 *** thelounge345 has quit IRC ()
15:57:43 *** thelounge345 has joined #openttd
16:04:00 *** thelounge345 has joined #openttd
16:07:24 *** thelounge345 is now known as mindlesstux
16:07:46 <truebrain> Lol, Oracle replied: Unfortunately, we are unable to resolve this or process the transaction. This is all the information we can provide.
16:08:00 <truebrain> In other words, they really do not want new customers
16:08:14 <truebrain> What a stupid process they have in place, lol, incredible
16:08:25 *** mindlesstux has quit IRC ()
16:08:28 <truebrain> Well, at least you know it will never become anything π
16:08:30 <audigex> Oracle are the worst tech company Iβve ever dealt with, Iβd rather pull my own fingernails out
16:08:30 *** mindlesstux has joined #openttd
16:09:09 *** SergioMassa[m] has left #openttd
16:09:31 <truebrain> Just the insanity of it all, it is incredible.
16:10:42 <truebrain> They might be better off just closing the sign up; saves everyone some time π
16:10:58 <peter1138> Not the dynamic layout I was looking for π
16:12:46 <truebrain> Reading up on the Internet, if I would to guess, it is because I have "oracle" in my email during signup
16:13:09 <truebrain> I had that before with SaaS, where you are not allowed to have their company name in your email
16:13:45 <kuhnovic> truebrain: What the actual fuck
16:14:00 <peter1138> And... when you enable both the single-window and split-window interface...
16:14:11 <truebrain> Yeah .. they don't want you to know if they leaked your email (it is what I use it for)
16:14:13 <_glx_> Using an address per service with reference in it is quite common
16:14:44 <truebrain> Reports dating back to 2021, saying that changing the email is often enough to sign up
16:14:48 <peter1138> It used to be common that loads of forms reject email+unique@domain...
16:15:07 <truebrain> I didn't even use a +!
16:17:40 <jfs> use 2 or 3 letter discriminator at the end and use a database to look them up
16:22:08 *** mindlesstux has joined #openttd
16:23:54 <peter1138> Hmm, next trick, do I use the existing small/large window toggle icon?
16:44:52 <frosch123> i want a console tool, which runs all of nile-config and nile-data through nile-validator
16:44:58 <frosch123> i wonder where to put it though
16:45:12 <truebrain> I am going to rename the repos in a sec π
16:45:14 <truebrain> that would help you π
16:48:14 <truebrain> lolz; indeed, with another email address I could signup for Oracle .. that is just terrible
16:48:49 <frosch123> what did you use? oralce, delphi?
16:49:48 <truebrain> right, we now have `nile-library` and `nile-tools`
16:50:00 <truebrain> READMEs need updating, but that are details
16:51:39 <frosch123> ah, nile-tools is also in rust
16:52:02 <truebrain> just what I need to fix, is to make `nile-library` publish itself as a crate, so it can be loaded in
16:52:54 <truebrain> I did consider `nile-cli` instead of `nile-tools` .. still not sure π
16:52:58 <frosch123> how public is that publishing? would it need calling openttd-nile-library?
16:53:41 <frosch123> `nile-cli` sounds like a interface for translators
16:54:06 <frosch123> though i don't think the average translator uses cli tools
16:54:31 <truebrain> I like that your branchname is `wip`
16:55:11 <frosch123> well, i did not know where i was going when i started, nor where i came from when i finished
16:56:19 <truebrain> `The normalized text is the text`
16:56:21 <truebrain> great sentence π
17:02:16 <frosch123> rust compiler checks a lot, but not comments
17:02:32 <truebrain> Sanitize trailing whitespaces .. that is also a new one π
17:03:57 <frosch123> that one knows about `{}` line-breaks, and trims per line
17:03:59 <truebrain> I only looked at the readme, and gave you a bunch of suggestions π
17:04:00 <frosch123> eints already did that
17:04:14 <truebrain> no, I was talking about your use of the English language π
17:05:06 <frosch123> did we figure out yet, what "position" is?
17:05:15 <frosch123> number of unicode codepoints?
17:05:19 <truebrain> I wrote a bit lower what I mean with "position"
17:05:23 <truebrain> but "there where my cursor can go"
17:07:00 <frosch123> well, yes, but is there a proper definition of what that means?
17:07:23 <truebrain> don't ask me, I am just a simple man. I just want to highlight in the HTML text where things broke down π
17:07:30 <truebrain> can you also make it a range, by any chance?
17:07:38 <truebrain> so the whole command is highlighted?
17:14:45 <jfs> truebrain: does `nile-tools` contain a `nile-delta` program perchance? (I have no idea what it is tbh, been too busy with other things to keep up in here)
17:15:51 <frosch123> not sure, it's more about collecting things, than spreading
17:16:00 <frosch123> what is the inverse of a delta?
17:18:25 <frosch123> oh... it actually is... i knew nabla and how it looks like, but i did not know its history
17:20:00 <frosch123> ok, looks like js strings indeed use utf-16, and index by uint16-index
17:20:16 <frosch123> textareas thus probably do the same
17:20:30 <frosch123> i guess i'll teach nile-lib to return both then
17:20:33 <truebrain> Javascript is completely UTF-16, yes. But I already told you that π
17:20:42 <frosch123> unicode-codepoint for the console tool, utf-16 offset for the wasm wrapper
17:21:19 <truebrain> not sure if that makes sense, but okay π
17:21:33 <truebrain> I think just having it by codepoint works best in both worlds
17:21:46 <truebrain> (as that doesn't depend on encoding)
17:22:06 <frosch123> then you have to do the codepoint->utf16-index in js
17:22:27 <truebrain> yeah, but I cannot colour a codepoint if the index you give in utf-16 is in the middle of it anyway
17:24:24 <truebrain> but I guess the more important reasoning is from the user: I would like to know what character on the screen needs to be pointed at
17:24:45 <truebrain> so even if I leave it as text, it would make sense π
17:27:10 <frosch123> i'll definitely leave the grapheme counting to you
17:32:30 <truebrain> mostly means I need to have example strings of where it isn't the same to utf-16 position π That will be fun π
17:36:24 <truebrain> ππΏ would be a good one to test with π
17:41:24 <truebrain> `ΰ€
ΰ€¨ΰ₯ΰ€ΰ₯ΰ€ΰ₯ΰ€¦` .. that are 8 UTF-16 values π
17:41:27 <truebrain> I love unitcode π
17:42:07 *** SigHunter has joined #openttd
17:42:47 <frosch123> i am pretty sure selecting the text is easier than reporting the position as number :p
17:43:11 <truebrain> owh, Javascript has Intl.Segmenter, which does exactly this
17:43:18 <truebrain> as an added bonus, it does it based on the locale
17:43:40 <truebrain> frosch123: well, the other thing I was considering, was having the library return the part of the string that did pass validation
17:43:44 <truebrain> as that makes it even easier
17:43:50 <truebrain> but the (codepoint) position will be fine too
17:44:53 <truebrain> okay ... I need to yolo my release workflow .. I think it should work .... but I cannot test it till I merge it π
17:44:57 <truebrain> downside of not having a fork π
17:45:24 <truebrain> also, sorry, I just created a merge-conflict for your PR
17:48:55 <frosch123> does it refuse to publish things with warnings? or why did you bother prefixing the unused parameters?
17:55:47 <peter1138> > 24 files changed, 1327 insertions(+), 1465 deletions(-)
17:55:50 <peter1138> Eh, that's kinda poor π¦
18:00:01 <truebrain> okay, automation works \o/
18:23:24 <truebrain> `Out of capacity for shape VM.Standard.A1.Flex in availability domain AD-1.`
18:23:28 <truebrain> Great stuff, this Oracle π
18:23:42 <truebrain> during signup, you have to select a region
18:24:06 <truebrain> as long as you have a free account, you cannot add another region to your account
18:24:14 <truebrain> in result, you are forced to that one region, with no way of changing it
18:24:23 <truebrain> and it turns out, they are out of the one VM type I was curious about π
18:25:12 <truebrain> I would guess that offering 4 CPU-cores and 24GB for free to anyone who signs up is making you run out of that type really quick ... but still
18:34:48 <peter1138> Oh yeah, the second filter does not work :S
19:30:09 <LordAro> truebrain: dare i ask what you're up to?
19:30:25 <LordAro> (pls don't make me scroll up however many hours/days)
19:30:26 <truebrain> Oracle Cloud charges much more fair prices for their bandwidth
19:30:34 <truebrain> so I was checking out if it was any good
19:30:49 <truebrain> but it seems they rather not have any customers
19:32:04 <truebrain> 0.09 dollar per GB vs 0.0085 dollar per GB
19:35:09 <Eddi|zuHause> that's only an order of magnitude
19:39:22 <truebrain> I should have signed up with Frankfurt as home region, it might have helped
19:39:42 <truebrain> but that you only know AFTER you figured out how it all works
20:07:04 <frosch123> truebrain: i inserted a merge commit, just so you want to squash it even more :p
20:07:57 <audigex> So about 1/10th? How much bandwidth does the project use?
20:10:09 <truebrain> frosch123: looks good; we can fix anything else some other time/day π
20:10:10 <frosch123> "a lot" is meant relative to the amount of donations
20:10:23 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:10:50 <truebrain> owh, you just have to run `cargo fmt` first π
20:11:03 <frosch123> ah, i forget that every 2nd time
20:11:15 <truebrain> CI is now punishing π
20:11:40 <truebrain> but yeah, let's call this v0.1, meaning we can also use it from nile-tools and nile itself easier π
20:12:58 <truebrain> owh, you first need to accept the invite
20:13:14 <truebrain> I still see 2 choices: move this to OpenTTD org, or create a new OpenTTD-translations org
20:13:22 <truebrain> guess moving it to OpenTTD org for now is sufficient
20:13:42 <frosch123> i got no notification about any invitation
20:14:02 <frosch123> i would keep things in one org
20:14:06 <frosch123> easier to assign roles
20:14:17 <truebrain> but okay, let me just move it to OpenTTD .. easier
20:15:14 <frosch123> oh, you sent the invitation just now, and now you moved the repo
20:15:29 <truebrain> you can now squash it yourself, figuring out a good commit messages yourself π
20:15:29 <frosch123> it read like "i invited you 3 days ago"
20:16:01 <truebrain> no no, I was more being a bit: brr, I just wanted to add you and give you permissions, not invite you and go through all that π
20:17:48 <frosch123> "backend horses" i guess
20:18:43 <truebrain> and .. released π
20:18:49 <truebrain> owh, it will fail to release
20:21:34 <frosch123> 4 mails for everyone
20:21:43 <truebrain> there, that should fix it; library is published as `nile-library` on crates.io btw
20:21:58 <truebrain> frosch123: only for admins π
20:23:01 <frosch123> it amazes me that openttd org has 56 repos by now
20:23:04 <_glx_> I don't receive github emails anyway
20:23:11 <truebrain> frosch123: sorry π
20:23:30 <peter1138> They'll be wanting to charge us...
20:26:45 <truebrain> right, so next up would be to update nile-data to match the new preprocessing .. and then the frontend. I have most scaffolding for the frontend done, just need to click in the validator etc π
20:27:23 <truebrain> after that it is mostly storage and commits
20:27:51 <truebrain> if you want to help out more frosch123 , feel free to look into how we want to automate nile-data π
20:28:04 <truebrain> (so importing and generating language files)
20:28:27 <truebrain> well, importing english.txt and generating language files, ofc π
20:28:52 <frosch123> next i want to look into nile-tools, and run the new validator on all the data
20:29:00 <frosch123> i guess that implies looking at the import
20:29:16 <truebrain> nile-tools currently misses an abstraction for the git-blame; as such, I can't unittest it π
20:29:23 <truebrain> easy fix, but I failed to make it a trait π
20:29:46 <truebrain> the import of language files is very slow, but also meant to be done once, when we switch over
20:29:52 <truebrain> import of english.txt is a lot quicker π
20:30:07 <truebrain> I suggest we make it a single Rust project, where it has different commands to do different things
20:30:20 <truebrain> but go nuts on it π
20:30:32 <truebrain> I will have my hands full with the frontend anyway π
20:30:50 <frosch123> don't worry, i won't distract you from the frontend
20:31:33 <truebrain> what I kinda like about this approach that we have, is that the frontend will have zero knowledge about strings and validation itself
20:31:42 <truebrain> it just shows the base language, and runs nile-library for feedback
20:32:14 <truebrain> did you benchmark nile-library btw? I am very curious how quickly it can validate 5000 strings π
20:32:49 <truebrain> owh, btw, one thing that is currently missing in nile-tools, is the ability to make a summary of a language, like "NNN missing strings, NNN invalid strings", etc
20:32:53 <truebrain> so we can show those reports
20:33:46 <frosch123> i want to have a command which validates all strings of a language, and gives a json result with all errors
20:34:05 <frosch123> but i guess statistics would be a different output
20:34:41 <truebrain> it is simply too expensive to download 1MB * <amount of languages>, every time someone opens that page π
21:18:42 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:14:41 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:42:10 *** ChanServ sets mode: +v tokai
23:49:02 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
continue to next day β΅
