IRC logs for #openttd on OFTC at 2024-05-09
โด go to previous day
00:28:18 *** gelignite has quit IRC (Quit: Stay safe!)
02:00:26 *** Wormnest has quit IRC (Quit: Leaving)
02:15:02 *** tokai|noir has joined #openttd
02:15:02 *** ChanServ sets mode: +v tokai|noir
02:15:44 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:22:09 *** tokai has quit IRC (Ping timeout: 480 seconds)
02:56:14 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:36:29 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
04:42:53 <DorpsGek> - Update: Translations from eints (by translators)
06:50:00 <peter1138> Hmm, annoying. USB got disabled or something. And ssh not runnig.
06:52:12 <peter1138> Less than ideal ๐
06:53:09 *** HerzogDeXtEr has joined #openttd
07:23:13 *** gelignite has joined #openttd
07:34:04 <andythenorth> if we break grfs, does that violate the savegame warranty?
07:34:46 <peter1138> Players get their money back.
07:35:50 <peter1138> Hmm, can I have the old "font" output back? The new one is waaaaay to long.
07:39:33 <peter1138> With windows all filename characters are 2 bytes, so I guess that's UTF-16 surrogate pairs.
07:40:59 <peter1138> Is that worse than current?
07:43:29 <peter1138> Oh, 14.1 has the old terse format anyway.
07:45:03 <peter1138> Fonts 473 through to 1174 are all Iosevka variants. Maybe I should've just download the ones I used instead of the massive combined file ๐
07:48:02 <peter1138> This font is problematic in OpenTTD, it renders noticeably slower.
07:49:48 <peter1138> Hmm, maybe this font list should show families followed by "x styles" instead of listing each individually.
07:50:02 <peter1138> And then providing the family name as a parameter can list the styles.
07:53:46 <LordAro> peter1138: seems sensible
07:53:55 <peter1138> kuhnovic: can you add a little more detail to the PR?
07:54:13 <LordAro> might want to exclude bold/italic/etc variants entirely
07:54:34 <kuhnovic> Doesn't the refered issue speak for itself?
07:54:54 <peter1138> The referred issue speaks for itself, not for your PR.
07:57:06 <peter1138> The commit itself is fine, but I'm not keen on a blank Description section.
07:58:22 <kuhnovic> When submitting the PR I thought "someone is going to complain about this". I was right ๐
07:58:33 <peter1138> You are most welcome.
07:59:12 <peter1138> Hmm, do I EVER need to have a full family -> style list...
08:27:53 <kuhnovic> Does anyone else feel that it takes rather long to generate all the languages?
08:28:38 <kuhnovic> I'm considering adding a cmake option to skip the rest of them
08:29:39 <truebrain> kuhnovic: Compared to the rest of the game? No ๐
08:32:29 <peter1138> How long is too long?
08:33:20 <kuhnovic> On my windows machine it's about 2 minutes for just the lang files
08:33:35 <peter1138> it's 2.9 seconds for me.
08:34:05 <peter1138> (And that includes strgen)
08:34:49 <peter1138> If I precompile strgen, it doesn't even give me a time for the language. `time` says 0.460s
08:34:59 <silent_tempest> I mean the build takes a while on my laptop but the languages I don't think take that long
08:35:32 <peter1138> Are you perhaps using WSL2 with the bad file io choice?
08:35:54 <kuhnovic> Nope, just bare bone windows
08:36:01 <silent_tempest> Oh yeah I'm on Linux. That probably helps
08:36:07 <michi_cc> Random Windows data point: 10 seconds.
08:36:25 <LordAro> how long does the rest of the OTTD build take?
08:36:26 <michi_cc> And yes, process start/fork is rather slow on Windows, so being longer than Linux is expected
08:36:41 <kuhnovic> It also seems to generate one language at a time, no parallellism
08:36:43 <peter1138> Is your build directory on a network share?
08:36:58 <silent_tempest> I mean that sounds like the problem
08:37:44 <kuhnovic> Nope, it on an M.2 SSD, same one as the OS. Not an NVMe drive but it should be plenty fast. And nowhere near full either.
08:39:15 <truebrain> And your CPU is a potato?
08:39:55 <peter1138> Lack of parallelism isn't a problem, that'll also be why it's 10 seconds for michi_cc.
08:40:10 <truebrain> MSVC compiles OpenTTD faster for me than clang (or worse, gcc)
08:40:44 <peter1138> Is your build directory synced with one of thise "cloud storage" things? (One Drive, Dropbox...)
08:41:33 <kuhnovic> truebrain: Intel i7-7700, certainly not winning any races but should be alright ๐
08:42:09 <kuhnovic> peter1138: Not that I know of, my source dir used to be at some point
08:42:46 <kuhnovic> But anyway, you guys don't experience this. No need for a cmake option then.
08:43:00 <truebrain> No, but we want to solve your problem now ๐
08:43:37 <truebrain> Any weird AV active? (So not Defender, but some other?)
08:43:49 <peter1138> I know the perfect solution. netinst.iso ๐
08:44:46 <kuhnovic> I'm no longer behind the machine, the little human was craving too much attention
08:45:26 <silent_tempest> You should obviously get a shit-ton of RAM and use a RAM disk for the OpenTTD source code. ๐
08:46:55 <kuhnovic> Openttd, compiled for potato's, but compiled on the sickest of development rigs ๐
09:10:57 *** XYZ has quit IRC (Remote host closed the connection)
09:12:36 <silent_tempest> I've literally never done that but an old Coworker got the build time from like 40 to like 6 minutes and ram drive was a huge part of it
10:27:45 <LordAro> hmm, guess i'm working from home today
10:30:00 <_glx_> kuhnovic: Using ninja or msbuild?
10:50:38 <_glx_> Msbuild needs a flag for parallelism, and it doesn't always work
11:05:05 <kuhnovic> Yes the /MP flag, but that gave me issues in the past. Maybe I should give it another go.
11:38:00 *** jenkings has joined #openttd
11:38:00 <jenkings> Is it intentional, that when you use transparency settings, it is not applied to "news" ?
11:39:13 <jenkings> I mean, i usualy play with hidden trees, because it is almost impossible to build railway, when you can not see it because of trees. But in the moment, when the "citezens celebrate.." newspaper comes on, it is just a huge forest ๐
11:39:30 <jenkings> Because, i use the "bribe by trees" glitch ๐
11:44:38 *** Eddi|zuHause2 is now known as Eddi|zuHause
11:44:43 <Eddi|zuHause> it has always been this way
12:10:25 <FLHerne> I suppose the transparency doesn't affect the newspaper reporter's camera
12:10:46 <FLHerne> would guess it's less "intentional" and more "no-one thought about it at all"
12:15:12 <peter1138> Nah, it's correct ๐
12:20:56 <ahyangyi> lol, requested before but didn't click on that "join organization" link... *mea culpa*
12:21:25 <ahyangyi> (and placed comments in the wrong place this time, oof)
12:24:13 <audigex> FLHerne: This seems like the obvious logic - itโs a newspaper photo, not the map youโre looking at
12:24:46 <ahyangyi> At least the honest newspapers don't tend to do that ๐
12:30:48 <peter1138> It's definitely intentional. It's a viewport window, so without extra logic to do it it would be transparent like the main viewport.
12:40:23 <merni> commit checker failed with "No common parent found for this merge commit (max-depth of 256 reached)" ...
12:48:06 <merni> #12648 is a nice bug ๐
12:49:43 *** gelignite has quit IRC (Remote host closed the connection)
12:50:44 <peter1138> Ah. I don't have any tools to decode a Windows crash dump
13:05:40 *** gelignite has joined #openttd
13:11:56 <peter1138> Although no idea if that's multibyte in utf-16. And of course it's actually utf-8, with wine on top.
13:14:39 <merni> I think everything is multibyte in UTF-16 since the minimum is 2 bytes :P
13:14:49 <peter1138> Surrogate pair, I meant.
13:15:20 <peter1138> And I'm referring to the bit after 'test', I'm aware that the path separator becomes a different character for whatever reason.
13:22:15 <peter1138> That has surrogate pairs. No glyphs for it but no crash here.
13:22:41 <merni> Analysing the dump might be helpful :P
13:22:42 <LordAro> sounds like you're going to need that crash dump output :)
14:53:39 *** gelignite has quit IRC (Read error: Connection reset by peer)
14:54:31 *** gelignite has joined #openttd
15:54:44 *** gelignite has quit IRC (Quit: Stay safe!)
16:16:45 <peter1138> std::string filename_base = std::filesystem::path(filename).filename().string();
16:17:23 <peter1138> Hmm, so I need some tar files inside my multi-byte directory.
16:19:18 <peter1138> :492 in current master.
16:20:07 <peter1138> filename is in utf-8 format at this point.
16:21:39 <_glx_> and std::filesystem::path tries to convert to wchar I think
16:22:23 <_glx_> ``` template <class _Src, enable_if_t<_Is_Source<_Src>, int> = 0>
16:22:23 <_glx_> path(const _Src& _Source, format = auto_format) : _Text(_Convert_Source_to_wide(_Source)) {
16:22:23 <_glx_> // format has no meaning for this implementation, as the generic grammar is acceptable as a native path
16:23:05 <peter1138> Not sure filesystem::path is doing any conversion here.
16:23:15 <peter1138> But it might be treating it as native anyway.
16:24:47 <peter1138> Part of the rabbit hole I've been looking at is to make all uses of std::filesystem::path be native. But that makes more work where we use it for tar file, which is always utf-8 and native has no bearing on i.t
16:26:37 <peter1138> `std::string filename_base = FS2OTTD(std::filesystem::path(OTTD2FS(filename)).filename().string());`
16:27:07 <peter1138> Might be a quick-and-dirty fix, but I can't test it.
16:27:34 <peter1138> Or we use an old-fashioned `.rfind(PATH_SEP)`
16:27:43 <_glx_> I first need to reproduce
16:28:49 <_glx_> process name in dmp is K:\ใใใ\steamapps\common\OpenTTD\openttd.exe
16:28:51 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
16:29:40 *** gelignite has joined #openttd
16:35:14 <peter1138> Hmm, suspicious, it will crash sometimes...
16:37:30 <wensimehrp> I think the best solution is to tell the player your path should only contain a-z / A-Z / 0-9 and underscores and dashes to avoid the problems
16:38:03 <peter1138> Why does your "best solution" sound like exactly the opposite of the best solution?
16:38:10 <LordAro> "doctor doctor, it hurts when i do this" "well don't do that"
16:39:01 <_glx_> let's try renaming a tar
16:40:54 <wensimehrp> Mostly because this is common within all programs. "Don't install your game under a path that contains a Chinese character (i assume this is similar to the Japanese case)' is something Chinese game players say everyday.
16:41:48 <peter1138> Sorry that why was rhetorical.
16:42:02 <peter1138> It's a bad "solution".
16:42:51 <LordAro> wensimehrp: only because most programs do things incorrectly
16:43:11 <LordAro> doesn't mean it's not an issue, and doesn't mean you should just accept it
16:43:19 <peter1138> Probably not most. You don't hear about the ones that do work...
16:44:20 <peter1138> It is somewhat annoying that C++ allows implicit conversion from std::string to std::filesystem::path as well.
16:45:07 <peter1138> They want us to use u8string for our utf-8 encoded strings, but that's... meh.
16:45:42 <wensimehrp> I personally don't install programs under paths like C:\ๆธธๆ\ๅผๆบ่ฟ่พๅคงไบจ\some_folder just for maximum compatibility
16:45:42 <wensimehrp> But yeah maybe it's because all other programs done the path thing incorrectly.
16:50:13 <ahyangyi> One day I should try installing everything under`C:\๐\` and see what happens
16:51:39 <peter1138> WenSim, you're basically telling us not to fix something because you personally work around it. That is not how things work.
16:52:08 <peter1138> There is also the matter that (I believe) it used to work in 13.x, as the poster talks about downgrading to the previous version.
16:54:13 <_glx_> main issue for me will be to reproduce
16:56:09 <_glx_> because my system is not MBCS
16:58:34 <ahyangyi> It was our traditional wisdom -- "nobody cared about non-ascii paths, so either we work around it or everything breaks".
16:58:34 <ahyangyi> Sure, time has changed a bit... and isn't it nice when developers actually care about non-ascii paths?
17:08:33 <peter1138> ^ Some of this stuff I already had patches for...
17:10:01 <peter1138> The language file stuff explains why there was a crash in the json formatter later.
17:10:11 <_glx_> ahyangyi: don't let the invite expire this time
17:10:50 <peter1138> ```Unhandled exception in ottdgame thread:
17:10:50 <peter1138> [ison.exception.type_error.316] invalid UTF-8 byte at index 49: 0x95 ```
17:11:25 <peter1138> Hmm, I didn't actually try building, haha.
17:13:33 <peter1138> Okay, it builds ๐
17:15:43 <_glx_> of course `string()` can be std::string or std::wstring
17:16:47 <ahyangyi> _glx_: Thanks, this time I clicked accept in time!
17:17:46 <peter1138> It builds for me, anyway ๐
17:19:05 <peter1138> Hmm, we did we do before...
17:20:05 <peter1138> The other way is to forget FS2OTTD and use `.u8string()` , which then needs to be reinterpreted to std::string
17:20:40 <_glx_> FS2OTTD(.native()) should be always fine
17:21:08 <peter1138> Hmm, maybe I don't need anything.
17:22:19 <peter1138> Then the implicit conversion should work.
17:27:18 <_glx_> code looks fine, it should default to native if you don't use string()
17:27:47 <peter1138> Yup, that was we found with c_str() the other week, but I forgot ๐
17:29:34 <_glx_> ``` _NODISCARD const string_type& native() const noexcept {
17:29:34 <_glx_> // return a reference to the internally stored wstring in the native format
17:29:34 <_glx_> _NODISCARD const value_type* c_str() const noexcept {
17:29:36 <_glx_> // return a NTCTS to the internally stored path in the native format
17:29:38 <_glx_> operator string_type() const { // implicitly convert *this into a string containing the native format
17:30:09 <_glx_> but yeah it's easy to forget
17:32:41 <_glx_> string() conversion seems really "random" ``` template <class _EcharT, class _Traits = char_traits<_EcharT>, class _Alloc = allocator<_EcharT>,
17:32:41 <_glx_> enable_if_t<_Is_EcharT<_EcharT>, int> = 0>
17:32:41 <_glx_> _NODISCARD basic_string<_EcharT, _Traits, _Alloc> string(const _Alloc& _Al = _Alloc()) const {
17:32:41 <_glx_> // convert the native path from this instance into a basic_string
17:32:41 <_glx_> return _Convert_wide_to<_Traits>(_Text, _Al);
17:32:42 <_glx_> _NODISCARD _STD string string() const { // convert the native path from this instance into a string
17:33:38 <_glx_> I guess it uses current codepage
17:34:06 <peter1138> Hopefully this fixes it, but who knows ๐
17:34:15 <_glx_> vs ``` _NODISCARD auto u8string() const { // convert the native path from this instance into a UTF-8 string
17:34:15 <_glx_> #ifdef __cpp_lib_char8_t
17:34:15 <_glx_> #else // ^^^ defined(__cpp_lib_char8_t) / !defined(__cpp_lib_char8_t) vvv
17:34:16 <_glx_> #endif // ^^^ !defined(__cpp_lib_char8_t) ^^^
17:34:16 <_glx_> return _Convert_wide_to_narrow<char_traits<_U8Ty>>(__std_code_page::_Utf8, _Text, allocator<_U8Ty>{});
17:34:59 <_glx_> I can trigger a build for the PR so affected users may test
17:36:18 <peter1138> Plus we have a user here who may be able to assist, even if they think it's not worth it ๐
17:37:36 <_glx_> yeah I know I triggered 12648 because my brain saw Fix #12648
17:39:54 <truebrain> and computer said: no ๐
17:59:39 *** aperezdc has quit IRC (Ping timeout: 480 seconds)
18:03:26 <peter1138> What was the macos failure?
18:05:58 <peter1138> I guess the properly solution is to not allow building the extra-long consists.
18:09:14 <_jgr_> You can change the setting at any time regardless of existing trains, so that wouldn't completely avoid the issue
18:10:11 <peter1138> Any indiciation of what engine to buy (year & model?)
18:12:08 <peter1138> DB VT 11.5 10-part is 7.0 exactly, hah
18:12:35 <peter1138> Well, I can just set the limit to 1 tile anyway.
18:12:37 <_jgr_> DB BR 407, from 2010, it's set up in the attached save
18:33:49 *** Wolf01 is now known as Guest5375
18:37:41 *** Wormnest has joined #openttd
18:39:13 <peter1138> Well, rabbit holes eh?
18:39:49 *** Guest5375 has quit IRC (Ping timeout: 480 seconds)
18:44:42 <peter1138> glx22viaGitHub: sadface
18:48:14 *** aperezdc has joined #openttd
18:52:02 <peter1138> Hmm, that build won't be compatible with 14.x any more.
18:54:01 <_glx_> Well it's not your patch, it's the bundling
18:56:02 <_glx_> Ha no second fail is the upload to cdn
19:11:13 <peter1138> That got less far...
19:11:31 <_glx_> it failed on first file, maybe because it was already there
19:11:32 <truebrain> You can't overwrite files that already exist on the CDN ๐
19:12:30 <truebrain> either you have to create a new git hash, and retrigger, or you just download the artifact and ask the user to test ๐
19:14:42 <peter1138> New git hash would probaly just fail again? I'm not sure what the original problem was though, I wasn't looking ๐
19:15:05 <truebrain> seems like a random failure during upload to CDN
19:15:44 <peter1138> Atomic CDN uploads, all or nothing? ๐
19:16:34 <truebrain> that would even be possible, as I can keep the uploads in limbo, till all are uploaded. But #effort ๐
19:17:00 <truebrain> it now failed twice in hundredths of uploads ๐
19:17:44 <peter1138> If a real release fails, do we have to make a new release with a new version? :p
19:18:06 <truebrain> no, then I have to login to the backend, remove files, and retry ... and I will be grumpy, and most likely fix the problem once and for all
19:18:09 <truebrain> till that day .... ๐
19:19:56 <_glx_> posted a link to the build in steam discussion
19:30:33 <peter1138> Hmm, of course 14.x doesn't have changes I already made to use more std::filesystem stuff.
19:31:15 <peter1138> I guess the tar-file symlink stuff won't matter ๐
19:43:12 *** muxydugoulp has joined #openttd
19:43:12 <muxydugoulp> what is wrong with this game script code ?
19:43:12 <muxydugoulp> GSNews.Create( GSNews.NT_GENERAL, "Message", GSCompany.COMPANY_INVALID, GSNews.NR_NONE, 0 );
19:44:25 <muxydugoulp> i get an error : wrong number of parameters
19:45:34 <muxydugoulp> even if "Message" is replaced with a GSText stuff
19:47:40 <_glx_> number of parameters seems fine
19:50:34 <peter1138> Are you using an older compatibility layer?
19:50:38 <muxydugoulp> i have a dedicated serveur under linux with a game script running fine and when using a light script with this function on a server not dedicated on windows it goes wrong
19:50:52 <muxydugoulp> what is an older compatibilty layer ?
19:52:30 <peter1138> Oh it was changed in 2015. Hmm.
19:52:53 <_glx_> GSNews::Create() used to need less parameters
19:53:17 <muxydugoulp> i'm using release 14.1
19:53:49 <_glx_> and what is the API set for your script ?
19:54:19 <_glx_> try with just type, text and company
19:54:53 <muxydugoulp> stupid info.nut file
19:54:53 <muxydugoulp> function GetAPIVersion() { return "1.2"; }
19:56:03 <_glx_> btw log window will tell you "XXX API compatibility in effect."
19:58:25 <peter1138> Hmm, now, filtering the list of fonts to only those that are usable...
20:12:00 <peter1138> Genuinely didn't expact that to work.
20:12:34 <peter1138> Also console with RTL language is kinda broken but nothing new there ๐
20:15:16 <peter1138> Hmm, not exactly working. For urdu I'm listing no fonts, but clearly a font is working.
20:20:34 <peter1138> The joke was that Germans make up long words, but this...
20:32:39 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:33:29 <Eddi|zuHause> that's multiple words as far as i can tell :)
20:48:17 *** gelignite has quit IRC (Quit: Stay safe!)
21:16:14 *** Smedles has joined #openttd
21:39:22 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:07:06 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:19:08 *** Wormnest has quit IRC (Read error: Connection reset by peer)
22:19:34 *** Wormnest has joined #openttd
22:28:50 *** Wormnest has quit IRC (Quit: Leaving)
22:29:52 <truebrain> Lol, the partial upload is now causing issues for publishing the website .. ghehehe, guess I need to fix that tomorrow
22:33:27 <peter1138> `int name_len = (name.length() >= INT_MAX) ? INT_MAX : (int)name.length();`
22:33:33 <peter1138> Hmm, do we often have 2GB strings?
23:13:56 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
continue to next day โต
