IRC logs for #openttd.dev on OFTC at 2013-03-22
⏴ go to previous day
08:30:44 *** Zuu has joined #openttd.dev
09:47:10 *** ChanServ sets mode: +o orudge
11:01:16 *** Ristovski has joined #openttd.dev
13:37:32 *** Ristovski has joined #openttd.dev
14:02:40 *** ntoskrnl has joined #openttd.dev
17:00:56 *** ChanServ sets mode: +v orudge
18:17:24 *** Alberth has joined #openttd.dev
18:17:24 *** ChanServ sets mode: +v Alberth
19:29:11 *** frosch123 has joined #openttd.dev
19:29:11 *** ChanServ sets mode: +v frosch123
20:25:20 <frosch123> hmm, sometimes bugfixing is like: 1. remove all nonsense 2. insert the missing parts
20:29:19 <michi_cc> No, it's more like: 1. Start coding with the intention to do A, 2. Notice something tangentially related, 3. End up doing something completely different :p
20:30:58 <Alberth> I often have stacks of such things: do A, notice B should be done first, do B, notice C should be done first, ... :)
20:31:20 <michi_cc> Right now I ended up with looking at the non-UNICODE windows build, which seems to have utterly broken file handling. For some strange ;) reason passing characters in some system code page directly into our utf-8 only internals looks very wrong.
20:32:05 <michi_cc> I can only guess that nobody ever tried that build with non-english file names for saves and such.
20:32:31 <frosch123> isn't there some OTTD2FS in all windows code?
20:32:47 <michi_cc> Noop for the non-unicode build
20:33:03 <michi_cc> So yes, there is, but it is used completely wrong.
20:34:43 <frosch123> Zuu: do you know whether gslibs can have texts and translations?
20:34:47 <frosch123> i suppose they cannot :)
20:35:09 <frosch123> hmm, yeah, clearly they cannot
20:35:24 <michi_cc> And the debug log output is sending utf-8 strings via ANSI functions to a console with a different code page to everything else (and for extra fun fixing that means removing the error output the OTTD2FS functions because we'd have an infinite loop on error otherwise).
20:36:38 <Zuu> gs libs can echo text and use the API to display/set text. But it cannot supply translated content using the OpenTTD translation framework.
20:37:18 <Zuu> Eg. it could try to implement one itself, but I don't know if GS have access to the 'language' setting.
20:37:51 <frosch123> well, first of all, ottd only loads english.txt for the main gs script
20:38:16 <frosch123> it would also require "namespaces" for the string identifiers and such :p
20:41:12 <Zuu> I'm in a ticket to ride game, but will devote more attention shortly :-)
20:47:42 <Zuu> While the gs lib cannot provide a english.txt (that OpenTTD reads), I would guess that a lib can do GSText(GSText.STR_SOME_STR) and that will work assuming that the GS have that string.
20:48:54 <Zuu> This is because libraries run in the same global scope as the GSes. So as far as I've understood I wouldn't think that OpenTTD cannot tell if a GSText call was initiated from library or GS code.
20:49:16 <Zuu> hmm one negation too much ...
20:49:30 <Zuu> I don't think that OpenTTD can tell if ... *
20:51:34 <frosch123> dbg: [script] swedish:1: FATAL: Invalid UTF-8 sequence in 'Hej och v�lkommen {COMPANY}!'
20:51:42 <frosch123> your testcase is invalid :p
20:54:01 <frosch123> but the greeting "Hello unknown" is nice
20:54:51 <Zuu> But the nice thing about that is that as soon as you fixed the bug in the report the script will complain that it find string XYZ. :-)
20:55:07 <Zuu> So you get instant feedback :-)
20:56:15 <frosch123> the most fun part is, that there were various comments about making tars work before, which were all wrong :s
21:06:48 <Zuu> Is FOR_ALL_TARS iterating through an in-memory list of all tar files or will it examinate the content of all tar files found by OpenTTD?
21:07:15 <frosch123> it iterates over a std::map
21:07:31 <frosch123> which contains all filenames inside tars, scanned by ottd on startup
21:07:53 <frosch123> this is the same code as for finding .nut files
21:08:02 <Zuu> So the expansive disk read is already made at startup and iterating this std::map is then quite cheap even if it contains the content of 100 tars.
21:08:30 <frosch123> it can be made better, but that is my other wip
21:08:47 <frosch123> this patch works for 1.3 :)
21:11:18 <frosch123> you are on windows?
21:11:40 <Zuu> And yes, for this bug its enough to use what is available rather than fixing all tools too. :-)
21:11:41 <frosch123> just wanted to check that i was right with the removed comments being wrong :)
21:12:34 <Zuu> I've tested both the test case and a GS that I have in unpacked form. (although that one exist both in tar + unpacked)
21:13:02 <Zuu> I haven't tested a GS that is only not in a tar, but the code looks good with respect to that.
21:16:28 <frosch123> oh, i should remove my debug printfs :)
21:18:48 <Zuu> I would comment that the "} else {" is for GSes that are not in a tar. Or comment the check. But that might go against "don't comment obvious things"
21:50:22 *** Alberth has left #openttd.dev
22:46:49 *** Supercheese has joined #openttd.dev
23:46:10 *** Dewin has joined #openttd.dev
continue to next day ⏵