Log for #openttdcoop.devzone on 29th September 2010:
Times are UTC Toggle Colours
00:14:34  *** KenjiE20 has quit IRC
04:31:09  <Brot6> Bundles Update: gf71343eb 2010-09-29 cargodist   (
05:05:42  <Brot6> NewGRF Meta Language - Feature Request #1327: allow more than 255 names (Alberth) @
05:08:07  <Brot6> NewGRF Meta Language - Feature Request #1327: allow more than 255 names (Alberth) @
06:49:00  *** ODM has joined #openttdcoop.devzone
08:28:17  <Brot6> FIRS Industry Replacement Set - Revision 1427:ea61fb1beda5: Change: Update German translation (planetmaker) @
08:32:32  <Brot6> FIRS Industry Replacement Set - Revision 1428:58235ddecf49: Fix (r1427): Accidentially committed ... (planetmaker) @
08:32:41  <planetmaker> godd morning
08:37:09  <Terkhen> hi planetmaker
08:38:13  <Brot6> FIRS Industry Replacement Set - Feature #1305: Detect missing strings (planetmaker) @
08:38:16  <planetmaker> I accidentially commited your patch series :-P
08:38:24  <planetmaker> (and removed it again)
08:38:26  <Terkhen> :)
08:38:36  <planetmaker> I leave that commit gladly to you
08:39:19  <planetmaker> what does declare -A do actually?
08:40:56  <Terkhen> it is recommended for declaring associative arrays, I abandoned the idea after realizing that most systems don't have version 4 of bash but I forgot to remove that line
08:41:21  <planetmaker> oh, ok :-)
08:41:27  <planetmaker> I have 2.95 or so... ancient :S
08:42:01  <Terkhen> there's not much that can be done about those false positives, except moving the strings as sparingly as possible or thinking of another way of checking changes
08:42:35  <planetmaker> I agree. I've no solution yet for that issue either
08:43:05  <planetmaker> that's what remains after I restored the exact same order now as in English
08:43:17  <Ammler> how does the opentd WT react on such changes?
08:43:18  <planetmaker> seems that those lines didn't need moving
08:43:27  <planetmaker> as such they show unchanged
08:43:37  <Terkhen> I vote for commiting this version once I correct it and check if I can make it run faster; if we find a better way later it can be changed
08:43:53  <planetmaker> Terkhen: without the -A I'm all for committing it, yes
08:44:04  <planetmaker> It's very fast for me ;-)
08:44:04  <Terkhen> Ammler: I don't know
08:44:12  <Terkhen> but it is way more smart :P
08:44:34  <Terkhen> hmm... maybe it has something to do with running it in a VM
08:44:42  <planetmaker> real 5s, user 1.8s
08:44:51  <Terkhen> not everything could be better, I guess
08:44:51  <planetmaker> that's fine enough for me
08:45:37  <planetmaker> Ammler: I think it works similarily.
08:45:53  <planetmaker> but there I can mark strings again as reviewed ;-)
08:46:03  <planetmaker> as such it has it's own DB
08:46:11  <planetmaker> I *think*
08:53:14  <Terkhen> 34s for me
08:53:27  <planetmaker> he
08:53:31  <Terkhen> but if it runs fast in a real machine I will not bother much with this
08:53:58  <planetmaker> If you can live with the speed :-)
08:54:01  <planetmaker> I definitely can
08:55:32  <Terkhen> I don't mind; I only have to run it once when translating
08:56:39  <planetmaker> that's the point
08:56:49  <planetmaker> it's anything but an often used script
08:57:02  <planetmaker> when run for every built it might need a bit speed-up ;-)
08:57:39  <planetmaker> Now we need the same thing for NML projects :-)
08:57:53  <Ammler> we might run it only nightly build...
08:59:50  <planetmaker> that's fine also :-)
08:59:59  <planetmaker> should I create a make target? :-)
09:00:10  <planetmaker> (which calls that script)
09:00:29  <Terkhen> I was thinking on using the same lng format that NML uses in FIRS, and generating pnfo files from them
09:00:34  <Terkhen> then the script would work in both
09:00:43  <Terkhen> (after conversion, of course)
09:01:21  <planetmaker> *that* would be the most welcome change indeed :-)
09:03:30  <Terkhen> let's see how it can be done... probably will be slow too
09:03:54  <Ammler> all the special codes might get a lot of work
09:06:01  <Terkhen> I was only thinking about adding the defines... all those codes might be too much work for such small benefit
09:07:44  <Ammler> else it would be a easy sed
09:15:18  <Terkhen> and a lot of changes to makefile, it seems
09:16:09  <planetmaker> [11:15]	<Terkhen>	and a lot of changes to makefile, it seems <-- I'm not afraid of that.
09:16:23  <planetmaker> Basically it'd just mean to add one new target for the language files.
09:16:40  <planetmaker> which might be different for NFO / NML. But if it's the same - all the better
09:16:51  <planetmaker> NFO might just have some extra tasks to run in that case.
09:17:20  <Terkhen> there is an existing dep for NML lang folder, maybe it could be used for FIRS too
09:17:23  <planetmaker> But I'd not care too much - initially - about the codes
09:18:12  <planetmaker> sort of. Files in that folder are currently automatically included in NML-projects. Thus I just add those files to the dep check.
09:18:27  <planetmaker> which might actually be a bad idea... hm
09:19:40  <planetmaker> hm... I remembered wrongly. I don't depend on NML language files
09:19:57  <planetmaker> Maybe I should depend on the default one, though. But it has no unique name...
09:20:35  <Terkhen> the script currently checks for #define to find string ids, but it shouldn't be too complicated to use "any line that is not a comment or an empty line"
09:20:36  <Ammler> default.lng or english.lng
09:20:49  <planetmaker> or 7F_english.lng
09:20:55  <planetmaker> or 7F_default.lng
09:20:57  <planetmaker> or...
09:20:59  <planetmaker> :-)
09:21:15  <Ammler> well, force one...
09:21:22  <Ammler> or make it a config
09:21:38  <planetmaker> hm... yet another config :-)
09:21:58  <Terkhen> remove_defines can be autogenerated from default too
09:22:08  <planetmaker> yes
09:22:12  <Ammler> that still doesn't happen?
09:22:13  <Terkhen> just #define -> #undef and remove the string
09:22:15  <planetmaker> and should actually IMHO :-)
09:22:48  <Terkhen> that's what I have been doing whenever I had to update remove_defines, anyways
09:36:15  <Terkhen> hm... EOL strikes again
09:36:48  *** thgergo has joined #openttdcoop.devzone
09:37:06  <Terkhen> grep -v "^$" file did not work because said file is using DOS EOL format
09:37:45  <Terkhen> and I'm guessing that if I just change it to UNIX, the script will fail when used in msys
09:38:07  <Terkhen> things like these make me wish I had a time machine
09:38:41  <planetmaker> time machine?
09:39:10  <planetmaker> dos2unix maybe?
09:39:27  <Terkhen> to stop stupid decisions like adopting different EOL formats in different OS from happening
09:39:50  <Terkhen> yes, I guess I'll worry about msys when it works here
09:41:27  <planetmaker> :-)
09:41:42  <planetmaker> Terkhen: do you know by any chance the game 'Chrononauts'?
09:41:47  <planetmaker> You'd love it then ;-)
09:42:19  <planetmaker>
09:42:20  <Webster> Title: Chrononauts - Wikipedia, the free encyclopedia (at
09:42:25  <planetmaker> it even has a wiki entry :O
09:42:40  <Terkhen> no, but it seems fun :)
09:43:09  <planetmaker> it is. Easy to setup and understand. And high re-play-ability
09:43:18  <planetmaker> and very good for travel. Just a few cards
09:45:19  <planetmaker> though slightly america-centric, it doesn't hurt :-)
09:57:56  *** andythenorth_ has joined #openttdcoop.devzone
10:39:26  <Brot6> Indonesian Town Names - Bug #1581 (New): Makefile dependency not found (fanioz) @
10:42:51  <Brot6> Indonesian Town Names - Bug #1572: Declare $(shell) locally on Makefile.local got failed (Ammler) @
11:00:39  *** KenjiE20 has joined #openttdcoop.devzone
11:29:53  *** welshdragon has left #openttdcoop.devzone
11:48:18  *** ODM has quit IRC
12:13:20  <Terkhen> planetmaker: can you please test if the script works correctly with these patches?
12:26:18  *** fanioz has joined #openttdcoop.devzone
12:26:52  <fanioz> good evening
12:28:10  <Ammler> guten Tag
13:13:07  <planetmaker> Terkhen: seems to do the job for me
13:13:28  <planetmaker> one thing I just noticed though, there seems to be a double path separator: Missing strings at file ../sprites/nfo/lang//02_german.pnfo
13:13:43  <planetmaker> it's of no consequence though
13:16:01  <Terkhen> hm, does not happen for me in msys and linux... as long as it works I wouldn't worry much
13:26:25  <planetmaker> dunno... how do you call it?
13:26:42  <planetmaker> I used "scripts/ 02"
13:26:47  <planetmaker> this is also only using bash
13:30:20  <Terkhen> ./scripts/ 04
13:30:42  <Terkhen> without the ./ the display message is the same, though
13:31:11  <planetmaker> ah
13:31:28  <planetmaker> I guess don't bother
13:33:45  <planetmaker> seems to be related to path search pattern order
13:41:37  <Terkhen> ok, thanks for testing :)
13:42:51  <Brot6> FIRS Industry Replacement Set - Revision 1429:e4ea2407ce00: Change: clarify the code of the langu... (Terkhen) @
13:42:51  <Brot6> FIRS Industry Replacement Set - Revision 1430:c82915765336: Feature: the language script lists st... (Terkhen) @
13:42:51  <Brot6> FIRS Industry Replacement Set - Revision 1431:6b481f45844e: Feature: the language script lists st... (Terkhen) @
14:28:00  *** andythenorth_ has quit IRC
14:32:49  *** andythenorth_ has joined #openttdcoop.devzone
15:26:28  *** ODM has joined #openttdcoop.devzone
16:11:03  <Brot6> grfcodec: update from r771 to r772 done -
16:20:23  <Brot6> firs: update from r1426 to r1431 done (22 errors) -
16:21:29  <Brot6> heqs: update from r376 to r380 done (8 errors) -
16:22:13  <Brot6> Following repos didn't need a nightlies update: 2cctrainset (r615), 32bpp-extra (r39), ai-admiralai (r68), airportsplus (r63), basecosts (r22), belarusiantowns (r7), comic-houses (r71), fish (r394), frenchtowns (r4), grfcodec (r772), indonesiantowns (r31), metrotrackset (r56), newgrf_makefile (r219), nforenum (r506), nml (r806), nutracks (r117), ogfx-trains (r32), ogfx-trees (r30), ogfxplus (r42), opengfx (r550), openmsx (r97), opensfx
16:22:13  <Brot6> (r97), smts (r5), snowlinemod (r45), swedishrails (r182), swisstowns (r20), transrapidtrackset (r15), ttdviewer (r25), ttrs (r23), worldairlinersset (r664)
16:25:37  <Brot6> comic-houses: rebuild of r71 done (2 errors) (Diffsize: 14) (DiffDiffsize: 7) -
16:38:17  <Brot6> Following repos rebuilds successful without any difference to earlier nightlies builds: 2cctrainset (7 errors), 32bpp-extra (Diffsize: 1), basecosts, fish (4 errors), metrotrackset (Diffsize: 1), newgrf_makefile, nutracks (2 errors), ogfx-trees, opengfx (Diffsize: 7), smts, snowlinemod, transrapidtrackset (Diffsize: 12), ttrs (7 errors), worldairlinersset
17:28:10  *** Alberth has joined #openttdcoop.devzone
17:28:27  <Alberth> oddink
17:37:09  *** andythenorth_ has quit IRC
18:09:24  <Brot6> 32bpp-ez-patches: update from r20855 to r20857 done -
18:10:46  *** andythenorth_ has joined #openttdcoop.devzone
18:11:43  <Alberth> hi hi
18:14:46  <andythenorth_> evenink
18:18:26  <Brot6> clientpatches: update from r20855 to r20857 done -
18:27:13  * andythenorth_ ponders
18:27:19  <Brot6> serverpatches: update from h7486e46b to h41d33c9e done (2 errors) -
18:31:22  <Brot6> NewGRF Meta Language - Revision 807:31eebfc93c30: Fix: For large parts in a town-name (with > 255... (Alberth) @
18:33:22  <Alberth> that was the easy part, now the more difficult random bits fixing :(
18:36:29  <Ammler> Alberth: so soemthing was wrong, not just my head?
18:37:20  <Alberth> I think so, but it is far from trivial to understand
18:37:47  <Alberth> random number things are always hard
18:38:16  <Ammler> and you think, openttd itself works right?
18:38:43  <Alberth> I have yet to find the first bug-free program :)
18:39:31  <Alberth> no idea, but if it follows specs, the stated probabilities are not followed due to me moving names into sub-nodes
18:39:59  <Alberth> I am also quite convinced that very few users of Action F realize it
18:41:22  <Alberth> what convinced me eventually was a thought-experiment where you iterate over all 2^32 possible random numbers, and start counting how often each name was picked.
18:42:06  <Ammler> it is quite hard to debug it
18:44:05  <Alberth> indeed
18:45:34  <Alberth> the above patch should fix most of the problem, there is one thing it doesn't do, that is if the sub-nodes have different size, and the bigger one needs more bits than the smaller one.
18:46:12  <Alberth> then the smaller one doubles in chance of being picked
18:47:37  <Alberth> (namely 1 time for that unused bit as 0, and one time if it is 1)
18:47:58  <Ammler> wouldn't it be best to first "sort" the list for probability?
18:48:43  <Alberth> I don't see what you mean
18:49:51  <Ammler> before you didn't implement the >255 support, I thought about to split the parts to names with same probabilty
18:50:20  <Ammler> then you can have those in with "1"
18:50:42  <Ammler> and use the probability for the part
18:51:36  <Alberth> that breaks if I make entries with many different values
18:51:55  <Alberth> or more than 255 with the same value
18:52:43  <Alberth> and it also messes up the probabilities of the non-moved entries
18:52:54  <Alberth> just like my partial moving did :)
18:53:39  <Ammler> hmm
18:53:55  <Ammler> you have max of 127 different subparts then
18:54:13  <Ammler> ah, I see
18:54:43  <Ammler> well, then you can still use the method you have now
18:54:48  <Ammler> just sort it
18:55:39  *** KenjiE20 has quit IRC
18:56:17  <Ammler> if you sort it, then you have most probalby also the "highest" names in the last part and don't waste "slots"
18:59:35  <Alberth> how does it get split after sorting? I don't understand that yet
19:00:52  <Ammler> like now?
19:01:26  <Ammler> but now, you have the name mixed, every part has names with different propabilities
19:03:34  <Alberth> yes, I move bigger probabilities first to the sub-node with the lowest summed probability
19:04:00  <Alberth> that way I have the biggest chance of ending up with somewhat equal sums for each sub-node.
19:04:21  <Ammler> hmm, but the biggest end on last part?
19:05:26  <Alberth> oh, that's random more or less
19:06:22  <Ammler> hmm, maybe I should check your new version first
19:06:44  <Alberth>  this is a simple case
19:06:46  <Webster> Title: Plain Text code- 12 lines - codepad (at
19:07:14  *** KenjiE20 has joined #openttdcoop.devzone
19:07:34  <Alberth>  now watch what happens if you move a b c d to a sub-node
19:07:36  <Webster> Title: Plain Text code- 30 lines - codepad (at
19:11:52  <Ammler> I don't get it
19:13:20  <Alberth> the chance of picking "x" quadruples in the second case
19:14:02  <Alberth> oh, not 4 times, but only 3 times as much
19:15:05  <Alberth> the point is that you need extra bits for selecting inside N. Those bits are 'don't care' for picking x
19:15:19  <Alberth> thus, you get x more often than you should
19:15:44  <Ammler> the the solution is to have all names in same sublevel?
19:16:46  <Ammler> but what you tell sounds more like a bug
19:17:05  <Alberth> yes, in the sense that you want to enforce that you can only pick x one out of 4 times
19:17:35  <Alberth> and a sub-level allows you to specify that
19:18:55  <Alberth> I warned you it was non-trivial :)
19:19:40  <Alberth> I also said that I think many users of Action F don't realize this :)
19:20:14  <Alberth> and I would not be surprised if that inlcudes the designer of ActionF
19:24:09  <Alberth> now what I am currently missing in NML is that picking x from its sub-level may need less bits than picking a value from N. If I allow that (and I do atm), you again have 'don't care' bits, messing up the chances.
19:26:13  <Alberth> do you have any idea of how to check trunk revision with an optional revision number like YX proposes in #1008?
19:26:14  <Brot6> Alberth: #1008 is "NewGRF Meta Language - Feature #1008: verify that the program using the generated grf is new enough - #openttdcoop Development Zone"
19:32:57  *** fanioz has quit IRC
19:39:23  <Alberth> good night
19:40:08  *** Alberth has left #openttdcoop.devzone
19:40:59  <Brot6> NewGRF Meta Language - Feature #1008: verify that the program using the generated grf is new enough (Alberth) @
20:04:51  <Brot6> NewGRF Meta Language - Feature #1008: verify that the program using the generated grf is new enough (Hirundo) @
22:21:09  *** ODM has quit IRC
23:03:34  *** andythenorth_ has quit IRC

Powered by YARRSTE version: svn-trunk