Times are UTC Toggle Colours
00:13:48 *** KenjiE20 has quit IRC 00:20:24 *** OwenS has quit IRC 07:11:44 *** ODM has joined #openttdcoop.devzone 08:46:30 <planetmaker> Yexo: now I see which part I was missing when trying to add units :-) tokens.py 08:48:12 <planetmaker> @calc 1/2.55 08:48:12 <Webster> planetmaker: 0.392156862745 08:48:14 <Webster> Latest update from devactivity: Redmine - Revision 3577: Eager load group projects to avoid N SQL queries. <http://dev.openttdcoop.org/projects/redmine/repository/revisions/3577> || Redmine - Revision 3576: Adds missing thead tags (#5440). <http://dev.openttdcoop.org/projects/redmine/repository/revisions/3576> 09:04:21 <Webster> Latest update from devactivity: NFO Meta Language - Bug #929 (Confirmed): allow fractional units for unit 'tons' for vehicles <http://dev.openttdcoop.org/issues/929> || NFO Meta Language - Patch #928 (Feedback): allow unit percent <http://dev.openttdcoop.org/issues/928> || OpenGFX+ - Revision 14: Change: Reflect changes in NML implementation <http://dev.openttdcoop.org/projects/ogfxplus/repository/revisions/14> 09:07:12 <Rubidium> Yexo: maybe you should add (or already have added?) some parameter so it will warn if the in-game value is not available and it will be rounded 09:09:20 <planetmaker> I don't think it's done - or I haven't figured it out 09:10:18 <planetmaker> in general it's quite difficult though. Either you warn every time when dealing with float (and conversion factors often are a float value like 3.2 or so) - or you warn never 09:10:59 <planetmaker> so for small rounding issues I don't think that a rounding warning is required 09:11:34 <Rubidium> really? People are already complaining that rail tile prices aren't added to tunnel construction 09:11:46 <Rubidium> or that the 225 didn't go 225 km/h anymore 09:12:03 <planetmaker> hm, also true 09:12:36 <Rubidium> but yes, with floats determining whether a different value will be chosen is going to be tricky 09:12:42 <planetmaker> but that's actually what exactly the unit conversion shall make easier: to enter a value and get the nearest NFO equivalent 09:13:14 <planetmaker> so... it's useful. Sometimes. I guess a run-time option or flag would be nice. 09:13:30 <Rubidium> nevertheless, any train weight with .25, .5 or .75 will be rounded 09:13:38 <planetmaker> yes, of course :-) 09:13:50 <planetmaker> but road vehicles would work. But that cannot be entered right now ;-) 09:15:47 <Rubidium> and if you enter 100 km/h you expect that to be the value that you get in-game 09:15:58 <planetmaker> intuitively yes 09:16:44 <planetmaker> so a sanity check has to reverse-calculate the hex value and see whether it results ingame in the chosen speed in the given units 09:17:01 <Rubidium> yep 09:17:38 <Rubidium> and what you could do if 100 gives you 99 (due to rounding), try 101 to see whether that gives you 100 in-game 09:18:20 <planetmaker> yes 09:19:09 <planetmaker> I add this as a feature request to the tracker 09:19:19 <planetmaker> I guess that's an issue not solved in 10 minutes ;-) 09:20:25 <Webster> Latest update from devactivity: NFO Meta Language - Feature #930 (New): sanity / rounding error check on supplied values <http://dev.openttdcoop.org/issues/930> 09:35:57 <Ammler> [11:17] <Rubidium> and what you could do if 100 gives you 99 (due to rounding), try 101 to see whether that gives you 100 in-game <-- can't you "adjust" the formula for that? 09:36:54 <Rubidium> Ammler: ofcourse you can, but I doubt the formula would stay understandable 09:38:53 <Ammler> but it is a bit silly, if a value 100 become 99 in game but 101 will get 100 09:41:03 <Rubidium> it all has to do with (integer) rounding 09:42:44 <Ammler> yes, but if that happens, something got wrong anyway 09:45:02 <Ammler> isn't the "rounding-error" people complain about, more the fact, that 1.6 isn't a exact factor for mph -> km/h 09:46:03 <Rubidium> the 225 isn't going 225 km/h is because the internal speed isn't in km/h or mph 09:46:36 <Ammler> yes, so no rounding issue 09:47:44 *** Doorslammer has joined #openttdcoop.devzone 10:05:49 *** OwenS has joined #openttdcoop.devzone 10:11:29 *** ODM has quit IRC 10:40:22 *** KenjiE20 has joined #openttdcoop.devzone 11:01:49 <planetmaker> so basically mph needs a conversion factor, just like km/h :-) 11:03:25 <planetmaker> @calc 1.609344 / 1.6 11:03:25 <Webster> planetmaker: 1.00584 11:04:55 <Ammler> Yep, imo, you simply need the correct factors :-P 11:05:41 <Ammler> I also compared with ttdpatch, it is identical on both 11:06:34 <planetmaker> 1.609344**2 / 1.6 11:06:38 <planetmaker> @calc 1.609344**2 / 1.6 11:06:38 <Webster> planetmaker: 1.61874256896 11:07:39 <planetmaker> @calc 1.609344**2 / 1.6 / 3.6 11:07:39 <Webster> planetmaker: 0.4496507136 11:11:20 *** PeterT has quit IRC 11:26:46 <Webster> Latest update from devactivity: NFO Meta Language - Code Review #931 (New): Don't assume 1 statute mile = 1.6km <http://dev.openttdcoop.org/issues/931> 11:32:02 *** PeterT has joined #openttdcoop.devzone 11:43:30 <Ammler> http://code.google.com/p/freebase-gridworks/ <-- something for DJ? 11:43:31 <Webster> Title: freebase-gridworks - Project Hosting on Google Code (at code.google.com) 11:47:15 <planetmaker> does he need it? 11:48:26 <planetmaker> and what for? 11:54:00 <Ammler> well, database thing 12:02:58 *** Seberoth has joined #openttdcoop.devzone 12:45:01 <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Feature #932 (New): Mail getting fewer after 1990 <http://dev.openttdcoop.org/issues/932> 13:32:47 <Webster> Latest update from devactivity: FIRS Industry Replacement Set - Feature #932 (Resolved): Mail getting fewer after 1990 <http://dev.openttdcoop.org/issues/932#change-2505" target="_blank">http://dev.openttdcoop.org/issues/932#change-2505> || FIRS Industry Replacement Set - Feature #932 (Resolved): Mail getting fewer after 1990 <http://dev.openttdcoop.org/issues/932> 13:39:14 <Yexo> Rubidium: that is a good idea 13:39:49 <Yexo> not sure if trying 101 if 100 doesn't round correctly will have any effect, I've ported the unit conversion code from openttd 13:41:17 <Rubidium> me neither (haven't looked that deeply into nml) 13:42:52 <Rubidium> although for aircraft rounding to the nearest value might be a good thing 13:51:15 <planetmaker> Yexo, what about the proposal to use the real world conversion factors also for miles etc in NML? 13:51:28 <planetmaker> it's tiny but for large numbers it makes a difference. 13:51:36 <planetmaker> And there are certain speeds which are simply not possible 13:52:53 <Rubidium> planetmaker: where would you need to convert miles to something else and to what in that case? 13:53:54 <Yexo> planetmaker: miles/hour is the base speed unit in nml 13:55:01 <planetmaker> Yexo, but not in OpenTTD. There it's like km/h * 1.6. Or do I err? 13:55:17 <planetmaker> Did I get you wrong earlier, Rubidium ? ^ 13:55:18 <Rubidium> planetmaker: no, mph * 1.6 or 3.2 or something like that 13:55:26 <Yexo> in nfo it's 1.6*km/h for train speed 13:55:46 <planetmaker> ok, so mph has a conversion factor of 1.005 instead of 1 13:55:57 <Yexo> but the speed displayed in the openttd gui is in km/h (1o 1.609*mph) 13:56:10 <Rubidium> 09 W Speed in mph*1.6 (see below) 13:56:23 <Rubidium> Train speed is in units of mph*1.6, i.e. approximately km/h. 13:56:23 <planetmaker> so... OpenTTD's internal conversion is not using proper factors? 13:56:40 <Yexo> no, openttd is fine 13:56:53 <Yexo> km/h = 1.609*mph, not 1.6 13:57:06 <Yexo> the unit nfo uses is an odd unit, it's nearly km/h but not exactly 13:57:08 <planetmaker> yes. 1.609344 ;-) 13:57:41 *** yorick has joined #openttdcoop.devzone 13:58:04 <Rubidium> I've dubbed it km-ish/h as unit 13:58:23 <Rubidium> just to remove any doubt that it is in km/h 13:58:36 <planetmaker> yeah, but we shouldn't quite use it as the same. Or people would wonder. As you rightfully stated 13:59:00 <planetmaker> so the conversion from km/h to NFO is like 1.005 then 13:59:03 <Yexo> planetmaker: in nml it is never used, except when writing the final value to the nfo file 13:59:21 <planetmaker> Yexo, yes. And that conversion factor is what I'm talking about ;-) 13:59:31 <Rubidium> @calc 103/(2**6) 13:59:31 <Webster> Rubidium: 1.609375 13:59:46 <Rubidium> that's the conversion factor OpenTTD uses from mph -> km/h 14:00:15 <planetmaker> which is nearly the wiki value. Yes. 14:00:24 <planetmaker> And what does it use from NFO -> km/h? 14:00:28 <Yexo> planetmaker: in unit.py: conversion factor from km/h -> mph: 1.609, action0properties.py: conversion factor from mph to train speed unit (km-ish/h): 1.6 14:00:53 <Rubidium> what happens in OpenTTD is: 14:01:21 <Rubidium> nfo value -> km-ish/h (so divide by 2 for ships/rvs) 14:01:40 <Rubidium> km-ish/h -> mph (so multiply by 10, divide by 16) 14:01:55 <planetmaker> ok. So everywhere there's the km/h-ish value used internally 14:02:02 <Rubidium> mph -> km/h (so multiply by 103, divide by 2**6) 14:02:53 <planetmaker> thanks 14:03:48 <Rubidium> so technically the conversion of km/h -> mph in unit.py is off by 0.000375 14:03:59 <planetmaker> so... (km/h - value) * 2**6 / 103 / 1.6 = NFO 14:04:35 <Rubidium> @calc 100*2**6/103/1.6 14:04:35 <Webster> Rubidium: 38.8349514563 14:04:45 <Rubidium> @calc 100*(2**6/103/1.6 14:04:54 <Rubidium> @calc 100*(2**6)/103/1.6 14:04:54 <Webster> Rubidium: 38.8349514563 14:04:58 <Rubidium> @calc 100*(2**6)/103*1.6 14:04:58 <Webster> Rubidium: 99.4174757282 14:05:02 <planetmaker> and (mph - value) / 1.6 = NFO 14:05:08 <Rubidium> not divide by 1.6, but multiply 14:05:28 <Rubidium> @calc 101*(2**6)/103*1.6 14:05:28 <Webster> Rubidium: 100.411650485 14:05:49 <Rubidium> @calc 99*10/16*103/2**6 14:05:49 <Webster> Rubidium: 99.580078125 14:05:57 <planetmaker> yes, multiplication 14:06:37 <Rubidium> so 100 km/h would yield 99.4, thus 99 for the nfo which is interpreted as 99 in-game as well 14:06:53 <Rubidium> @calc 100*10/16*103/2**6 14:06:53 <Webster> Rubidium: 100.5859375 14:07:55 <Rubidium> using 101 km/h would yield 100.4, thus 100 for the nfo which is interpreted as 100 in-game. In this case trying "n+1" for a better match after conversions would pay-off 14:08:04 <Yexo> something is wrong then, if I write 99km/h in the nml file I get 98km/h ingame 14:08:35 <Yexo> 98 in the nfo too :( 14:08:40 <Rubidium> no, it *all* has to do with rounding 14:08:54 <planetmaker> there are values which cannot be represented. 14:09:28 <planetmaker> does NML use round or trunc? 14:10:24 <Rubidium> nfo *is* a integer, not a floating point. As such you need to do rounding there (for this case rounding down, rouding towards the nearest doesn't matter). Then the reverse is run over the rounded number and that number is (again) rounded (this time always rounded down) 14:10:54 <Rubidium> @calc (2**6)/103*1.6 14:10:54 <Webster> Rubidium: 0.994174757282 14:11:01 <Yexo> nml rounds towars the nearest, but that doesn't matter 14:11:06 <Yexo> 99 in nfo is 98 in game btw 14:11:15 <planetmaker> Rubidium, sure it's integer. But the rounding needs to be done such that the least cases it shows 14:11:17 <Yexo> so 100 km/h in nml -> 99 in nfo -> 98km/h in game 14:11:23 <Rubidium> that is the total conversion factor from km-ish/h -> km/h 14:12:05 <Rubidium> it won't round down twice 14:12:47 <Rubidium> i.e. 1/0.994174757282 > 1 and as such the step in openttd can't decrease the value any more; it doesn't mean it will get it back to the intended value 14:13:06 <Rubidium> @calc 100*0.994174757282 14:13:06 <Webster> Rubidium: 99.4175 14:13:10 <Yexo> you can theorize as much as you want, but openttd does round down 14:13:23 <Rubidium> that gets rounded to 99 km-ish/h 14:13:29 <Rubidium> @calc 99/0.994174757282 14:13:29 <Webster> Rubidium: 99.5800538135 14:13:52 <Rubidium> that gets rounded to 99 km/h, however km/h >= km-ish/h 14:13:59 <Yexo> nml rounds to the closest value, openttd always rounds down 14:14:38 <Rubidium> Yexo: yes, but that's not the point; you say 100 km/h -> 99 km-ish/h -> 98km/h, which simply can't happen mathematically 14:14:51 <Rubidium> or I'm doing something stupid 14:15:00 <Rubidium> @calc 99*10/16 14:15:00 <Webster> Rubidium: 61.875 14:15:08 <Rubidium> oh, there it gets rounded too 14:15:11 <Rubidium> forgot that one 14:15:12 <Yexo> I agree with you on a theoretic level, but I just wrote some nml/nfo that demonstrates this behavior 14:15:13 <planetmaker> Yexo, I assume you just tested that with a grf? 14:15:19 <planetmaker> :-) 14:15:43 <planetmaker> hm... time for some real rounding there? 14:16:47 <Rubidium> @calc 100*10/16 14:16:47 <Webster> Rubidium: 62.5 14:17:01 <Rubidium> @calc 62.5*103/2**6 14:17:01 <Webster> Rubidium: 100.5859375 14:17:07 <Rubidium> @calc 62*103/2**6 14:17:07 <Webster> Rubidium: 99.78125 14:17:12 <Rubidium> @calc 63*103/2**6 14:17:12 <Webster> Rubidium: 101.390625 14:17:12 <Ammler> so the issue is at openttd, which always rounds down? 14:17:36 <Rubidium> Ammler: the issue is more general; intermediate rounding 14:17:48 <Ammler> yeah, but different rounding rules 14:18:21 <Rubidium> Ammler: that doesn't matter that much 14:18:31 <Rubidium> rounding the intermediate values has greater influence 14:18:43 <Ammler> hmm, but maybe "fixeable" if nml always rounds up 14:18:57 <planetmaker> Rubidium, is it possible to do the conversion in OpenTTD from km/h-ish to km/h directly instead of going via mph (as I read you)? 14:19:01 <Yexo> http://devs.openttd.org/~yexo/fix_rounding.diff testing this diff now 14:19:03 <Rubidium> anyhow, I'd say that getting 101 in-game is better than gettin 98 in-game if you specify 100 km/h 14:19:33 <Rubidium> planetmaker: not without a shitload of people complaining the 225 doesn't go 225 anymore 14:20:12 <Yexo> with that patch 100km/h (nml) -> 99km-ish/h (nfo) -> 99km/h (openttd) 14:20:46 <Rubidium> @calc 225/103*2**6 14:20:46 <Webster> Rubidium: 139.805825243 14:20:54 <Rubidium> @calc 140*103/2**6 14:20:54 <Webster> Rubidium: 225.3125 14:21:03 <Rubidium> @calc 140*1.6 14:21:03 <Webster> Rubidium: 224 14:21:16 <Rubidium> @calc 141*1.6 14:21:16 <Webster> Rubidium: 225.6 14:21:30 <Yexo> 225km/h nml -> 225km/h openttd (with that patch applied) 14:21:41 <Rubidium> @calc 141*1.6 14:21:41 <Webster> Rubidium: 225.6 14:21:50 <Rubidium> @calc 141*103/2**6 14:21:51 <Webster> Rubidium: 226.921875 14:22:20 <Rubidium> anyhow, you'd have to speak with peter about that; he was the one that did mess with conversion last time 14:22:37 <Ammler> Yexo: maybe one of the units should be km-ish/h, so if someone like the nfo style, he can still use it 14:23:01 <planetmaker> Ammler, no unit = NFO style 14:23:13 <Ammler> hmm, thought that is mph 14:23:20 <planetmaker> no 14:23:24 <Yexo> no unit is mph 14:23:38 <planetmaker> hm... that sounds wrong 14:23:59 <planetmaker> either no unit = NFO or no unit = SI. But mph? 14:24:00 <Ammler> I wouldn't "reuse" glitches of nfo 14:24:26 <Yexo> planetmaker: no unit = nfo would mean there is a different default unit for train speed and road vehicle speed 14:24:40 <planetmaker> Yexo, yes. But why then mph? 14:24:56 <Ammler> and mph is the only unit which you can easy calc 14:25:01 <Ammler> wihtout rounding issues 14:25:04 <Yexo> that seemed easy at the time, doesn't matter much imo 14:25:20 <planetmaker> well. SI is the world wide standard for all units 14:25:29 <planetmaker> sounds like a reasonable base system 14:25:34 <Ammler> but that would cause rounding troubles 14:25:41 <Rubidium> Ammler: you mean dividing/multiplying by 1.6 or 3.2 doesn't cause rounding trouble? 14:25:48 <Yexo> just always specify a unit directly 14:25:49 <Ammler> Rubidium: less :-) 14:25:58 <planetmaker> Yexo, still :-) 14:26:21 <planetmaker> that's not quite sensible when it comes to readability of NML code then either 14:26:38 <planetmaker> especially as rounding is involved in any case 14:26:39 <Yexo> what? forcing to specify a unit? 14:26:43 <Rubidium> Ammler: then go for SI (m/s). That will have least rounding trouble as it has the largest granularity 14:26:54 <planetmaker> Yexo, no, that's reasonable. But to assume mph without unit. 14:27:05 <Rubidium> and as such I reckon you can get any value you want in-game 14:27:33 <planetmaker> and actually it makes sense to internally work with the SI units, too 14:27:46 <planetmaker> and not cryptic imperial units (whatever they are) 14:27:49 <Ammler> SI would also be coolest :-) 14:27:57 <planetmaker> Ammler, moderately. 14:28:01 <Ammler> :-P 14:28:26 <Rubidium> nevertheless, changing rounding in OpenTTD will be seen as "not following the specs" as we'd diverge from TTDPatch's interpretation 14:28:27 <planetmaker> otherwise you really end up m/s and in kg the weight of trams and engines 14:28:42 <Rubidium> (changing includes removing intermediate rounding) 14:29:42 <Ammler> specs has only 1.6*km/h or is there something else? 14:29:47 <Yexo> yep, I was also afraid of that 14:30:09 <Yexo> Ammler: both ttdpatch and openttd are 'wrong' here, as they both do intermediate rounding 14:30:31 <Ammler> but the intermediate rouning isn't specified, is it?= 14:30:39 <Yexo> but fixing openttd would mean that openttd and ttdpatch differ in behaviour, and people will complain about openttd 14:30:47 <Yexo> no 14:31:13 <Ammler> the spec != ttdpatch 14:31:17 <Ammler> at least not anymore ;-) 14:32:13 <Ammler> well, you could talk to the patch devs, maybe they could fix that too 14:32:49 <Ammler> (seems not a big thing) 14:38:00 <yorick> anyone has a python nfo parser laying around? 14:38:30 <Ammler> nml 14:38:34 <planetmaker> ^ 14:38:43 <Yexo> nml doesn't read nfo files 14:39:16 <Ammler> well, then yorick needs to be more specific 14:39:28 <Yexo> he wants to write grfcodec in python 14:39:29 <planetmaker> yorick, you could write the part which converts NFO into grf using python 14:39:39 <yorick> planetmaker: doing that 14:39:44 <Ammler> I thought, he already did :-) 14:39:47 <planetmaker> Yexo, which kinda makes sense as a backend or so for nml 14:39:54 <Yexo> yes :) 14:40:02 <planetmaker> especially with png support :-) 14:40:05 <Yexo> it's pretty easy, but I didn't get an image library to work 14:40:12 <planetmaker> PIL works here 14:40:28 <yorick> Ammler: the problem is nfo reading and sprite compression...rest is easy 14:41:13 <Ammler> dunno, if that is the right way, if you can generate grfs, is nfo still needed? 14:41:29 <Yexo> it's still useful for debugging 14:41:47 <Yexo> I'd rather have an nfo-file written by nml then one decoded by grfcodec 14:42:03 <planetmaker> yep 14:42:14 <planetmaker> especially as the latter will fail more and more 14:42:27 <Yexo> hmm? why should it fail? 14:42:39 <planetmaker> unsupported features, actions, variables 14:42:46 <Yexo> doesn't matter for grfcodec 14:42:49 <planetmaker> maybe it still works then, though 14:42:50 <planetmaker> ok 14:42:55 <Ammler> grfcodec doesn't work with future linux :-) 14:42:55 <Yexo> grfcodec doesn't support any featuers/actions/variables at all 14:43:06 <Yexo> only nforenum has that problem 14:43:08 <Ammler> it fails on suse 11.3 14:43:35 <Ammler> something with the compression is broken 14:43:39 <Ammler> it works with -u 14:43:54 <planetmaker> doesn't sound like a grfcodec bug, but a library bug 14:44:07 <Ammler> well, it doesn't use a lib 14:44:15 <yorick> libc 14:44:21 <planetmaker> boost 14:44:36 <Ammler> for compression? 14:44:43 <planetmaker> I don't think so 14:47:19 <Ammler> glibc-devel-2.11.1 14:47:47 <Ammler> old distros: glibc-2.10.1 14:48:20 <Ammler> hmm, could try with the older lib 14:57:34 <Ammler> he, replacing glibc is a big task :-) 14:58:21 *** Ragga has joined #openttdcoop.devzone 14:59:05 <Ragga> #help 14:59:18 *** Ragga has left #openttdcoop.devzone 15:06:33 <Webster> Latest update from devactivity: NFO Meta Language - Revision 145: Change: unit m/s as base unit for speed <http://dev.openttdcoop.org/projects/nml/repository/revisions/145> 15:32:32 *** ODM has joined #openttdcoop.devzone 15:34:08 *** welshdragon has quit IRC 15:37:23 <Webster> Latest update from devactivity: NFO Meta Language - Patch #928: allow unit percent <http://dev.openttdcoop.org/issues/928#change-2508> || NFO Meta Language - Bug #929: allow fractional units for unit 'tons' for vehicles <http://dev.openttdcoop.org/issues/929#change-2507> || NFO Meta Language - Code Review #931 (Closed): Don't assume 1 statute mile = 1.6km <http://dev.openttdcoop.org/issues/931#change-2506" target="_blank">http://dev.openttdcoop.org/issues/931#change-2506> || NFO Meta Language - Code Review #931 (Closed): Don't assume 1 statute mile = 1.6km <http://dev.openttdcoop.org/issues/931> 15:43:24 <planetmaker> Yexo, concerning the percent: I thought about using the word 'percent', too 15:43:53 <planetmaker> Surprisingly, defining % as unit works. But I guess then the modulo operator doesn't work anymore? 15:44:59 <Yexo> probably not, I haven't tested it yet 15:45:13 <Yexo> but only one of the two can work at a time 15:48:10 <planetmaker> other point: having fractional numbers would make sense (as also you write) 15:48:52 <planetmaker> especially for those *drag* properties - which by definition usually are values of the range 0..1 - and usually are not given as percent values 15:49:19 <planetmaker> using percent is a means to avoid that, but not really nice either 15:50:48 <planetmaker> any good proposal as of how to define the unit [1] 15:50:56 <planetmaker> or m/m 15:51:11 <planetmaker> or whatever is of unit one? 15:52:52 <Yexo> same as nfo spec? ie 1/256? 15:52:54 <Webster> Latest update from devactivity: Infrastructure Sharing patches - Revision 10: backup push to bitbucket.org <http://dev.openttdcoop.org/projects/is2-patches/repository/revisions/10> 15:57:05 <planetmaker> no :-) 15:57:15 <planetmaker> the real world unit for these things is 1 15:57:26 <planetmaker> and not 1/2.55 ;-) 15:58:05 <planetmaker> *coefficient* are by definition without units 15:58:15 *** welshdragon has joined #openttdcoop.devzone 15:59:28 <planetmaker> hm... can we introduce the unit 'NFO' which then does no conversion? 15:59:41 <planetmaker> And use real-world SI units otherwise? 15:59:52 <planetmaker> And require a unit for things which have a unit? 16:17:09 <Yexo> sure 16:18:03 <Brot6> worldairlineset: no commit since last failed compile, compile skipped (r637) 16:18:03 <Brot6> Following repos didn't need a update: 2cctrainset (r517), 32bpp-extra (r32), airportsplus (r48), bros (r10), comic-houses (r69), firs (r820), fish (r360), heqs (r318), nmts (r15), nutracks (r59), opengfx (r456), openmsx (r53), opensfx (r88), snowlinemod (r10) 16:31:49 *** Doorslammer has quit IRC 16:39:38 <Ammler> hmm, I guess, I silence the annoucement about "no commit since error", what you think? 16:51:20 *** frosch123 has joined #openttdcoop.devzone 18:14:45 *** welshdragon has quit IRC 18:16:08 <Webster> Latest update from devactivity: 2cc train set - Revision 518: Add: 5 generations of mailwagons <http://dev.openttdcoop.org/projects/2cctrainset/repository/revisions/518> 18:24:31 *** welshdragon has joined #openttdcoop.devzone 20:08:46 *** yorick has quit IRC 20:58:16 *** frosch123 has quit IRC 21:38:47 *** Yexo has quit IRC 21:39:02 *** Yexo has joined #openttdcoop.devzone 21:39:21 *** Seberoth has quit IRC 21:58:48 <Webster> Latest update from devactivity: OpenTTD-GUI - Document: mockup for game creation dialogue <http://dev.openttdcoop.org/documents/20> || OpenTTD-GUI - genworld2.png <http://dev.openttdcoop.org/attachments/download/688/genworld2.png> 22:25:13 *** ODM has quit IRC 23:52:23 *** OwenS has quit IRC