Config
Log for #openttdcoop.devzone on 10th May 2010:
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

Powered by YARRSTE version: svn-trunk